ISO 27001 for SaaS and software companies selling to enterprise and the public sector
If you sell software as a service to larger companies or the public sector, sooner or later a buyer asks for ISO 27001. For a SaaS company, the requirements are the same as for anyone else: the management system in clauses 4 to 10 of ISO/IEC 27001:2022, plus a reasoned decision on each of the 93 Annex A controls. What's different is where the risk sits: in your product, your code, your people's access to production, and the cloud suppliers you build on.
This guide covers why buyers ask, how to scope ISO 27001 for a SaaS business, the controls that do most of the work, how it compares with SOC 2 if you're selling from the UK, and how to keep it running with a small team.
Why enterprise and public-sector buyers ask
When a buyer puts your product into their business, your security becomes part of theirs. Their own obligations (contracts, regulators, their own ISO 27001 supplier controls) pass down to you. ISO 27001 gives them one recognised answer to "do you manage security as a business?", checked by an independent certification body.
In practice, it shows up as:
- A procurement gate. Some enterprise and public-sector contracts list ISO 27001 as a requirement, or score it in the evaluation.
- Security questionnaires. Most larger deals come with a long questionnaire. An ISMS means the answers already exist as approved policies and records. See our guide to customer security questionnaires.
- Public-sector frameworks and tenders. Applying to frameworks such as G-Cloud, or answering a council or NHS tender, means describing how your service and its data are protected. Cyber Essentials is often the floor; ISO 27001 is the step up. See ISO 27001 for public-sector suppliers, and if you sell into health, DSPT vs ISO 27001.
The benefit isn't only the tick. A working ISMS means you know your risks, recover faster when something breaks, and depend less on the one engineer who knows how production is set up.
Choosing your scope
Your scope (clause 4.3) is the boundary of what the certificate covers. It's stated on the certificate, and enterprise buyers do read it. For a SaaS company, a scope that buyers find useful usually covers three things.
1. The product
The platform your customers use: the application, its infrastructure, the data stores, and the processes for building, deploying and operating it. If you have several products, start with the one your biggest buyers are asking about. A scope that leaves out the product customers actually buy is a red flag for a careful buyer.
2. The people and processes around it
Engineering, operations and support, plus the business functions that touch customer data or production access: HR (joiners and leavers), sales (what's promised in contracts) and finance (supplier contracts). You can't usually scope people out if they can reach customer data.
3. The cloud suppliers you build on
You'll almost certainly run on a hyperscale cloud and use a stack of other services: source control, CI/CD, monitoring, email, support desk, AI providers. They sit outside your ISMS, but your use of them is inside it. Your cloud provider's own certificates cover their part of the shared responsibility model, not yours. How you configure accounts, identities, networks and storage is your responsibility, and the auditor will look at it.
Tip: write a scope statement in one or two sentences that a buyer could read, such as "The development, operation and support of [product], including the people, processes and cloud services used to deliver it." Then list what's excluded and why.
The Annex A controls that do most of the work
All 93 controls go into your Statement of Applicability with a decision and a reason. For a SaaS company, these groups usually generate the most evidence.
Suppliers and cloud services (5.19 to 5.23)
| Control | What it means for a SaaS company |
|---|---|
| 5.19 Information security in supplier relationships | Know which suppliers touch your data or production, and manage the risk they bring |
| 5.20 Addressing information security within supplier agreements | Check what the contract or terms say about security, data location and breach notification |
| 5.21 Managing information security in the ICT supply chain | Think about the services and components your suppliers depend on, including open-source dependencies |
| 5.22 Monitoring, review and change management of supplier services | Review key suppliers on a schedule and when they change something significant |
| 5.23 Information security for use of cloud services | Decide how you acquire, use, manage and exit cloud services, including your hyperscaler and SaaS tools |
5.23 was new in the 2022 version, and for a SaaS company it's central: your whole product depends on it. Keep a list of cloud services with an owner each, what data they hold, what you checked, and how you'd leave.
Secure development (8.25 to 8.28, and around them)
| Control | What it means for a SaaS company |
|---|---|
| 8.25 Secure development life cycle | A defined way of building software securely, from design to release |
| 8.26 Application security requirements | Security requirements identified and agreed when you build or buy features |
| 8.27 Secure system architecture and engineering principles | Principles for designing systems securely, documented and applied |
| 8.28 Secure coding | Secure coding practice: reviews, avoiding known weakness patterns, managing dependencies |
Close by, auditors also tend to look at 8.29 (security testing in development and acceptance), 8.31 (separating development, test and production environments), 8.32 (change management) and 8.33 (test information, such as not copying live customer data into test without protection).
The good news is that much of this evidence already exists in your tools: pull requests and reviews, branch protection, CI runs, dependency scanning, tickets and release notes. ISO 27001 asks you to decide how you work, write it down briefly, and keep the records flowing. See our guide to ISO 27001 for software development companies for more on the development side.
The rest of the usual suspects
- Access control (5.15 to 5.18, 8.2, 8.5): least privilege to production, MFA everywhere, privileged access reviewed, and access removed promptly when people leave.
- Logging and monitoring (8.15, 8.16): what you log, how long you keep it, and who looks.
- Vulnerabilities (8.8): patching, dependency updates and how fast you act on a serious issue.
- Backup and continuity (8.13, 5.29, 5.30): restores tested and recorded, and a plan for losing a region or a key supplier.
- Incidents (5.24 to 5.28): a plan for a leaked secret, a compromised laptop or a vulnerable dependency, and a log of what happened.
ISO 27001 vs SOC 2 for UK sellers
UK SaaS companies selling to US customers often hear "do you have SOC 2?" They're both credible ways to show security, but they're different things.
| ISO 27001 | SOC 2 | |
|---|---|---|
| What it is | An international standard for an information security management system | An attestation report under AICPA standards |
| Who issues it | An accredited certification body (in the UK, buyers usually look for UKAS accreditation) | A licensed CPA firm |
| What you get | A certificate with a stated scope, which you can share publicly | A detailed report, usually shared with customers under NDA |
| What it covers | Your ISMS (clauses 4 to 10) and the Annex A controls you've chosen | Controls against the Trust Services Criteria; security is required, and availability, processing integrity, confidentiality and privacy are optional |
| Types | One certification, then annual surveillance and recertification every three years | Type 1 (control design at a point in time) or Type 2 (whether controls operated over a period) |
| Where it's most asked for | The UK, Europe and much of the world; common in UK public-sector and enterprise procurement | Most often by US buyers |
Some practical points:
- If most of your buyers are in the UK or Europe, or you sell to the UK public sector, ISO 27001 is usually the more recognised choice.
- If a large share of your pipeline is in the US, expect SOC 2 requests. Some US buyers accept ISO 27001 instead; others don't. Ask the buyer before you commit to either.
- They overlap a lot. Risk assessment, access control, change management, incident response, supplier management and monitoring appear in both. Building an ISMS first gives you most of the controls and evidence a SOC 2 auditor would also look at, if you need one later.
- Neither is a guarantee that you won't have an incident. Both show that you manage security in a structured way and that someone independent has checked.
This is general information, not advice on which your specific buyers will accept. Ask them, and ask your prospective certification body or auditor about scope.
Running it with a small team
Most SaaS companies going for ISO 27001 don't have a security team, let alone a compliance team. It usually lands on a CTO, a head of engineering or an operations lead, on top of the day job. A few things keep it manageable:
- Scope tightly at first. One product, the people who build and run it, and its suppliers.
- Use engineering evidence you already have. Don't invent parallel paperwork for code review or change management.
- Put the recurring work on a schedule. Access reviews, supplier reviews, restore tests, internal audit and management review all need to happen on time, every time, with a record.
- Make decisions with the right people. Top management approves the policy and leads the management review, and risk owners accept their own risks. A small team can do this, but it has to actually happen.
- Be careful with AI. Assistants are good at drafting policies and questionnaire answers, but pasting your risk register into an unassessed tool is its own risk. See our guide to using AI assistants with ISO 27001.
The hard part is rarely the first audit. It's month seven, when the access review is overdue and the person who set it all up is busy shipping a feature. Plan for that from the start.
How ClearIMS helps
ClearIMS is designed for a business where an IT manager, or a very small team, has been handed ISO 27001. You describe your company in plain English and it drafts your first scope, risks, policies, Statement of Applicability and tasks, and its Recommended tasks list puts the work in order, so whether you have 5 minutes or 5 hours, you know what to do next. It emails owners about outstanding and overdue actions, drafts customer security questionnaire answers from your approved records with sources, and lets you connect your own AI assistant through MCP on any paid plan, with approvals and sign-offs kept with your people. Everything stays a draft until a named person approves it; the AI never approves anything.
We make the software. Your certification is yours, awarded by your certification body.
Take the 2-minute readiness check, or book a 20-minute call.