ISO 27001 for SaaS Companies: Scoping the ISMS Around a Product, Not an Office

ISO 27001 for a SaaS company is mostly a scoping exercise. The certificate covers your product, the cloud it runs on, the team that builds it, and the customer data that flows through it — not your office, not your marketing site, and not every tool the company happens to pay for. Draw that boundary well and the rest of the project is manageable. Draw it badly and you spend a year certifying things your customers never asked about.

A SaaS company is a strange shape for a security standard written before cloud software existed. You own no servers. Your team may sit in five cities, or five countries. Your product updates ten times a day. And your customers' data sits in the same databases as your competitors' customers' data, separated by code rather than walls. ISO/IEC 27001:2022 still fits that shape — it was written to be technology-neutral — but only if you scope the management system around the product and say so plainly.

What does ISO 27001 actually certify for a SaaS company?

It certifies your information security management system, the ISMS — the documented way you identify risks, choose controls, run them, and improve them. It does not certify your product. No certificate says your code has no bugs. What it says is that you run a system that finds security problems, fixes them on a schedule, and can prove it did.

That distinction matters the first time an enterprise buyer sends you a security questionnaire. They will ask for the certificate and the scope statement together. A certificate whose scope reads "the cloud-hosted product platform and the engineering and support teams" answers their question. A certificate scoped to "the whole company" with no boundaries tells them nothing, and a certificate scoped to an office address tells them less.

Think of the scope as the fence around a plot before you build on it. The fence does not make the house secure. It decides what is yours to protect and what is outside your responsibility. Every control, every risk, every audit question follows from where you drew it.

Drawing the scope: what goes inside

For a typical SaaS company, four things belong inside the scope. First, the production cloud environment — the named accounts, regions, and services where customer data is processed. Name the provider and the region in the scope statement itself. Second, the engineering work that touches production: code repositories, the CI/CD pipeline, and deployment infrastructure. Third, customer data handling — how data is stored, who can see it, how it moves, and how it is deleted. Fourth, the internal tooling your production-access teams use: identity providers, ticketing, logging, and monitoring.

Write the scope statement in one page. It should name the product, the cloud provider and regions, the teams in scope, and the services that support the product. A stranger reading it should be able to draw the boundary without asking you a question. If they cannot, the auditor will have the same problem, and an unclear scope is where audit findings begin.

What stays out, at least for a first certification? Systems with no access to customer data: the marketing site, the HR system, the finance tool, the office Wi-Fi. You can bring them in later. A tight first scope is not a shortcut. It is the standard working as intended — clause 4.3 asks you to determine the boundaries, not to swallow the whole company in one go.

The shared-responsibility line with your cloud provider

This is the single most misunderstood part of SaaS certification, and it has its own control now: A.5.23, information security for the use of cloud services, added in the 2022 edition. Your cloud provider — AWS, GCP, Azure — holds its own ISO 27001 certificate for its infrastructure. That certificate covers the physical data centre, the hypervisor, and the host network. It does not cover you.

Renting a flat in a guarded building is a fair picture. The building's security guards, the locked gate, and the CCTV belong to the landlord. Your door lock, your safe, and who holds your keys belong to you. If someone walks into your flat, nobody blames the gate. In the same way, the shared-responsibility model splits the work: the provider owns the physical and host layers, you own identity and access management, your network configuration, your encryption settings, and everything at the application layer.

Document that split. The auditor will ask for it by name. Your scope statement or supplier register should say, in plain words, which controls the provider operates and which ones you operate, and point at the provider's certificate and your own evidence for each side. A SaaS team that cannot describe this boundary will spend its audit arguing about controls that were never theirs to run.

Physical controls: what you can exclude, and what you cannot

Annex A theme A.7 covers physical security — perimeters, entry controls, securing offices and equipment. A cloud-native SaaS company with no servers of its own can exclude several of these controls, and most do. The exclusion goes in the Statement of Applicability with a reason: production runs in a certified provider's data centres, so controls A.7.1 to A.7.3 do not apply to your own premises in the way the standard describes.

Do not strike the whole theme in one stroke. Your laptops hold production credentials. Your office has a door. The hard drive in the drawer still exists. The controls that cover your own equipment, your office entry, and clear desks still apply to you, even when the server room does not. Item 43 of this series, our ISO 27001 documents checklist, explains how the Statement of Applicability records each exclusion with its reason — an exclusion that reads "not applicable" with no reason will draw a finding; one that explains the business reality will not.

The controls that do the heavy lifting for SaaS

Out of the 93 Annex A controls, a handful carry most of the weight for a SaaS product. These are the ones auditors probe hardest and customers ask about first.

Cloud services (A.5.23). The shared-responsibility split above, plus exit planning: what happens to customer data if you leave the provider, and who can get it out.

Supplier relationships (A.5.19, A.5.20). Your sub-processors — payment gateways, identity providers, analytics, support tools — each need a security assessment and a contract that covers breach notification and audit rights. Enterprise customers will ask for your sub-processor list by name.

Secure development (A.8.25, A.8.28). The secure development lifecycle and secure coding principles. Code review, change management, and security testing are not extras for a SaaS team; they are the controls that map directly onto how your product is actually built.

Configuration and change (A.8.9, A.8.32). Infrastructure as code, configuration management, and change control. In a team that deploys ten times a day, the pipeline is the control — the auditor will want to see that a change cannot reach production without review and a record.

Vulnerability management (A.8.8) and logging (A.8.15, A.8.16). Patching on a schedule, scanning that actually runs, and logs that survive long enough to investigate an incident. Keep logs for at least six months; a shorter window leaves you blind when a customer reports something from last quarter.

Incident response (A.5.24, A.5.26). A plan that says who decides, who tells customers, and how fast. Your customers' contracts will set notification deadlines, and the plan has to meet them.

Deletion of information (A.8.10). Tenant offboarding. When a customer cancels, their data must actually go — from the database, the backups on their retention cycle, and the sub-processors. Multi-tenancy makes this a real engineering task, not a checkbox.

Multi-tenancy: the risk your customers actually worry about

Your customers share your infrastructure. Their data sits in the same databases, served by the same application, separated by your code. That is the risk enterprise buyers picture when they read your scope, and it is the one your risk assessment has to treat seriously.

Tenant isolation is a design question before it is a control question. How does the application stop one tenant reading another's data? What happens when a tenant's administrator has broad rights? What stops a bug in a shared query from leaking rows across tenants? The risk assessment should name cross-tenant access as a risk in its own right, with controls chosen against it: authorisation checks tested per tenant, data-layer separation, and tests that specifically try to cross the boundary. A penetration test that never attempts a cross-tenant read has missed the point of your product.

This is also where the certificate earns its keep in sales. A buyer who asks "how do you keep my data separate from your other customers?" is not asking for a slogan. They are asking for a risk, a control, and evidence. The ISMS gives you all three in one place.

How long does it take, and what does it cost?

For a small Indian SaaS team working steadily, four to nine months from gap assessment to certificate is a realistic range. The stages run in order: gap assessment, scope and risk work, writing the documents, running the system, internal audit, management review, then the certification body's Stage 1 document review and Stage 2 audit of the working system. Our ISO 27001 process guide walks through those stages in order.

One timing rule catches SaaS teams out: the certification body wants to see the system actually running before Stage 2, not just documented. Three months of operating records — risk reviews, access reviews, incident logs, monitoring results — is the working rule most teams plan around. Start the clock early. If you write the documents in month two and sit the Stage 2 audit in month three, there will not be enough evidence to audit.

On cost, keep the two parts separate, as our ISO 27001 cost guide for IT companies and startups explains. ComplyKart's ISO 27001 consultancy starts at ₹14,999 for companies up to 25 employees and ₹29,999 for 26 to 100 employees, covering the consultancy: scope, risk work, documents, and audit preparation. Certification-body audit fees sit outside it, charged at actuals, and they vary with scope, sites, and headcount. For budgeting, one published Indian roadmap puts a typical small-to-mid company's first-year total — consultancy plus audit fees plus tooling — at roughly ₹3–15 lakh. Before you sign with any certification body, check how to verify an ISO certificate is genuine — the same care applies to choosing the body as to choosing the scope.

One more honest note on cost: the certificate is not a government licence and it guarantees no order. What it does is pass the security review that otherwise blocks enterprise deals. Price it against the deals it unblocks, not against the audit fee alone.

Five mistakes SaaS teams make

• Scoping the whole company instead of the product, then drowning in controls for systems that never touch customer data.
• Citing the cloud provider's certificate as if it covered them — the provider's certificate covers the provider's side of the shared-responsibility line, not yours.
• Excluding the entire physical theme, then having no answer for laptops, office access, and equipment disposal.
• Treating the Statement of Applicability as a formality, with exclusions that say "not applicable" and no reason behind them.
• Skipping the internal audit or rushing it, so the certification auditor finds the cross-tenant risk your own team should have caught first.

If the scope still feels hard to draw, start with the product and work outward. List everything that touches customer data — the cloud accounts, the pipeline, the repositories, the tools with production access — and draw the fence around that. Everything else can wait for the second cycle. And if you would rather have the scope drawn with you than drawn alone, the ISO 27001 certification service page carries the current consultancy prices, and the compliance fee calculator can help you line up the year's filing costs beside it.

FAQs

Does ISO 27001 certify my SaaS product?

No. It certifies your information security management system — the way you manage risks, run controls, and prove it. The certificate says your system is sound, not that your code has no vulnerabilities. Your scope statement is the document that says exactly what the certificate covers.

Can a cloud-only SaaS company exclude the physical security controls?

Some of them, yes, with a justified reason in the Statement of Applicability — controls for data-centre perimeters and server rooms sit with your cloud provider. But the controls covering your own laptops, office entry, and equipment disposal still apply to you.

Does my cloud provider's ISO 27001 certificate cover me?

No. It covers the provider's side of the shared-responsibility line: the data centre, the hypervisor, the host network. You still own identity and access management, network configuration, encryption settings, and the application layer. Document the split under control A.5.23.

Do I need SOC 2 as well as ISO 27001?

It depends on who buys from you. US buyers often ask for SOC 2; European and Indian enterprise buyers usually accept ISO 27001. The two frameworks overlap heavily — the controls you build for one carry over to the other — so most SaaS companies start with the one their largest prospects ask for and add the second later.

How long before the Stage 2 audit can I sit it?

Plan for three months of operating records before Stage 2. The certification body audits a working system, not a document set, so the internal audit, management review, access reviews, and incident records all need to exist by then.