ISO 27001 Scope for Multi-Product SaaS Companies

Scope is the first real decision in an ISO 27001 programme, and it quietly determines almost everything that follows. For a company with one product and one platform, scope is close to obvious. For a company running three products on shared infrastructure, two of which came in through acquisition, the same question becomes genuinely hard. This post is about how to reason through it.

Why scope is harder with multiple products

A single-product SaaS company can usually describe its information security management system (ISMS) in a sentence. The service, the infrastructure it runs on, the people who build and operate it. Auditors understand it, buyers understand it, and the boundary is clean.

Multi-product companies lose that clarity fast. You may have:

• Products at different levels of maturity, some greenfield and some inherited
• Shared platform services such as authentication, billing and logging that cut across products
• Separate engineering teams with different tooling and different habits
• Customers who only care about one of your products but ask about the whole company

The temptation is to either certify everything at once to look impressive, or to carve out the smallest possible slice to move quickly. Both instincts are usually wrong. The first inflates cost and delays your first certificate. The second creates a boundary so narrow that buyers see through it.

The three questions that actually define scope

Before drawing any diagrams, answer three questions honestly.

What are buyers asking about? Look at your last twenty security questionnaires and due diligence requests. If they all reference Product A and none mention Product B, that tells you where the commercial pressure is. Scope should follow revenue and sales friction, not internal org charts.

Where does the data actually flow? Customer data rarely respects product boundaries. If Product A and Product B share a data warehouse, a common identity provider, or the same production Kubernetes cluster, you cannot cleanly certify one without addressing the shared layer. The technical reality constrains the scope more than any preference you have.

What can you honestly operate to a standard? An ISMS is a set of controls you run every day, not a document. If a recently acquired team still uses its own ticketing, its own cloud account and its own access model, folding it into scope on day one means you are certifying practices you do not yet control. That is how audits go badly.

Drawing the boundary

Most multi-product companies land on one of three patterns.

Whole-company scope. Everything is in. This works when products share infrastructure heavily and teams already operate consistently. It is the strongest position commercially because there are no awkward carve-outs to explain. It is also the most work, and it punishes you if any single team is immature.

Product-led scope with shared services. You scope one flagship product plus the shared platform services it depends on: identity, infrastructure, logging, incident response, HR and access management. This is the most common landing point for growing SaaS companies. It gives buyers a credible answer, it keeps the first certification achievable, and the shared services you include become reusable when you expand scope later.

Platform-led scope. You certify the underlying platform and the security functions that serve all products, then describe products as consumers of that platform. This suits companies where the platform is the real asset and products are relatively thin layers on top. It requires a mature platform team and clear internal service boundaries.

The pattern to avoid is the artificial carve-out: scoping a single small product that shares its entire technical foundation with out-of-scope products. Auditors will ask about the shared components anyway, and buyers will notice that the certificate does not cover the product they are buying.

Shared services are where scope succeeds or fails

In a multi-product company, the shared services are the load-bearing walls. Your identity provider, cloud accounts, CI/CD pipeline, secrets management, logging and monitoring, and your people processes usually serve every product at once.

Two consequences follow.

First, if a shared service is in scope, it is in scope for the whole way it operates, not just the portion that touches your flagship product. You cannot certify how access control works for Product A while ignoring that the same admin role grants access to Product B. The control either meets the standard or it does not.

Second, shared services are the highest-leverage place to invest. Every control you get right in identity, access management and infrastructure applies across products. When you later expand scope to a second product, much of the hard work is already done. This is the practical argument for the product-led-with-shared-services pattern: it front-loads the reusable work.

Phasing scope over time

Scope is not permanent. A sensible approach is to certify a defensible core first, then expand in deliberate stages.

• Phase one: flagship product plus shared services. Achievable, credible, commercially useful.
• Phase two: fold in the next product, mostly by extending existing controls rather than building new ones.
• Phase three: acquired or immature products, once their operations have been brought onto common tooling and processes.

Each expansion should be a smaller lift than the first, because the management system, the policies and the shared controls already exist. The mistake is treating every product as a fresh programme. If your ISMS is built well, adding a product is an integration exercise, not a rebuild.

State your scope plainly in your Statement of Applicability and your scope statement. Buyers and auditors both prefer an honest, well-reasoned boundary over an ambitious one you cannot defend. A tight scope you operate flawlessly beats a broad scope you operate loosely.

Bottom line

For multi-product SaaS, scope is a commercial and technical decision before it is a compliance one. Follow the revenue, respect the data flows, and only include what you can genuinely operate. In practice that usually means certifying a flagship product plus its shared services first, then expanding in stages that reuse the work. If you are weighing which boundary to draw and how to phase it, a Kellwick readiness review can help you pressure-test the options against your architecture and your sales pipeline before you commit.