An ISO 27001 Statement of Applicability built for a single product does not automatically work once a SaaS company ships a second one. The document that certified your first platform assumes one scope, one set of infrastructure, one risk profile. Add a second product, and the SoA either has to expand honestly or it quietly stops reflecting what you actually run, which is the kind of gap an auditor finds in minutes and a customer’s security team finds in their next questionnaire.
This article walks through what a Statement of Applicability actually contains, why multi-product architecture forces a real scoping decision most single-product guides skip, and what a defensible SoA looks like when it has to account for more than one product line. For the broader case on why the SoA carries the weight it does in certification, see the importance of the SoA in ISO 27001 compliance; this piece assumes that foundation and focuses specifically on the multi-product decision.
What a Statement of Applicability Actually Is
The Statement of Applicability is the document required under ISO 27001 Clause 6.1.3 that connects your risk assessment to Annex A. For each of the 93 Annex A controls in the current standard, the SoA records whether the control is applicable, whether it is implemented, and, where a control is excluded, the written justification for excluding it. It is not a policy summary and it is not a marketing document. It is the single artifact an auditor and a sophisticated enterprise buyer both go to first, because it shows exactly what your organization decided to do about every control the standard requires you to consider.
The 93 Controls, in Four Themes
ISO/IEC 27001:2022 replaced the 2013 structure of 114 controls across 14 domains with 93 controls organized into four themes. Organizational controls make up the largest group at 37, covering policy, roles, and supplier relationships. People controls total 8, covering screening, training, and disciplinary process. Physical controls total 14, covering facilities and equipment. Technological controls total 34, covering the technical security measures that dominate a SaaS company’s actual risk surface. Eleven controls are new to the 2022 revision, and several of them speak directly to cloud and SaaS operations: cloud services security, configuration management, data masking, and data leakage prevention among them. A SoA written before 2022 or copied from an older template will be missing these, which is itself a finding waiting to happen. For the full breakdown of what each theme covers, see the Annex A controls explained.
Why the SoA Is Not Optional
Clause 6.1.3 requires you to compare your chosen risk treatment against the Annex A catalogue and document the result. You are not required to implement all 93 controls. You are required to make a documented decision about every one of them, and any exclusion needs a justification an auditor can evaluate, not a blank cell. An SoA with unexplained gaps or a justification that does not connect to an actual risk assessment finding is one of the most common nonconformities auditors raise, and it is preventable with a document that was built carefully in the first place.
The Scoping Decision Every Multi-Product SaaS Company Faces
Most ISO 27001 guidance for SaaS companies assumes a single product, and the standard advice holds for that case: scope the ISMS around the product, its cloud infrastructure, and the teams that build and operate it, rather than the entire business. That advice stops being sufficient the moment a second product exists, because the scoping question changes from “what does this product touch” to “what do these products share, and what stays separate.”
Shared Infrastructure Versus Product-Specific Systems
A multi-product SaaS company typically has two layers. A shared layer includes the identity provider, the cloud account structure, the CI/CD pipeline, and any centralized logging or monitoring that spans products. A product-specific layer includes the application code, the product’s own data stores, and any infrastructure provisioned exclusively for that product. The SoA has to reflect both layers honestly. A control implemented centrally, like access management through a shared identity provider, applies consistently across every product in scope. A control that depends on how a specific product handles customer data may be implemented differently, or may not apply at all, to a product that does not process that category of data.
Three Scoping Patterns and When Each Fits
The table below sets out the three ways multi-product SaaS companies typically structure scope, and the tradeoff each one carries.
| Scoping pattern | How it works | Best fit |
|---|---|---|
| Single ISMS, single SoA | One SoA covers all products; per-product notes explain where implementation differs | Products share most infrastructure and one buyer conversation covers the whole company |
| Single ISMS, product-level annotations | One SoA and scope statement, with a control-by-control note identifying which products a control applies to and how | Products share core infrastructure but differ meaningfully in data handled or architecture |
| Separate ISMS per product | Each product has its own scope statement and SoA | Products are genuinely separable, sold to different buyers, or run on different infrastructure with little overlap |
Most growth-stage SaaS companies with a shared platform underneath multiple product lines land on the second pattern, because it avoids the overhead of maintaining fully separate ISMS documentation while still giving each product an honest, individually defensible answer for every control. The first pattern works only when the products are similar enough that a single blanket statement does not paper over real differences. The third pattern is the right answer only when the products truly do not share infrastructure, which is less common than founders assume.
The Risk of Getting This Wrong
The failure mode is not usually total silence on a second product. It is a SoA that technically mentions the second product but was never revisited when that product’s architecture diverged from the first. Reviewing which infrastructure is genuinely shared and which is not has to happen every time a new product is added, not once at initial certification, because scope decisions cascade through the risk assessment and the SoA both depend on.
A Related Problem: Multiple Entities Versus Multiple Products
Multi-product scoping is a close cousin to a problem many growth-stage companies also face, scoping ISO 27001 across multiple legal entities. The two are not the same decision. Multiple products under one legal entity is a question of shared infrastructure and differentiated risk. Multiple entities, whether from an acquisition, a subsidiary, or a joint venture structure, adds a governance and ownership question on top of the infrastructure question. A company that has both problems at once, multiple products spread across multiple entities, needs to resolve the entity-level scope first, because the entity boundary determines which product-level SoA logic even applies where.
SoA Example: What a Multi-Product Entry Looks Like
The excerpt below illustrates the structure a well-built SoA entry follows once product-level differentiation is built in. It is illustrative, not a template to copy verbatim, since your own risk assessment and architecture determine the actual content.
| Control | Applicable | Implementation status | Product-level note |
|---|---|---|---|
| A.5.23 Information security for use of cloud services | Yes | Implemented | Applies uniformly; both products run on the same cloud account structure and shared security requirements |
| A.8.9 Configuration management | Yes | Implemented | Baseline configuration standard is shared; Product B has an additional hardening step for its payment-adjacent data store |
| A.8.11 Data masking | Yes, Product B only | Implemented for Product B; not applicable for Product A | Product A does not process the data category this control addresses |
| A.8.24 Use of cryptography | Yes | Implemented | Shared key management service; per-product encryption-at-rest settings documented separately |
The pattern across that table is the same one that should run through the entire document: a control’s applicability and implementation status is a real decision, backed by the risk assessment, and the product-level note is what keeps that decision honest when a control lands differently across the portfolio. An auditor reading this can trace exactly why Product A and Product B are treated differently on data masking, instead of guessing whether the difference was intentional or an oversight.
Where the Risk Assessment Has to Lead
A SoA that differentiates by product without a risk assessment that also differentiates by product is not defensible. If Product A and Product B handle different categories of data, face different threat models, or run on materially different infrastructure, the risk assessment that feeds the SoA needs to capture that. Building the ISO 27001 risk assessment with product-level granularity from the start avoids retrofitting the SoA after the fact, which is where inconsistencies creep in.
Keeping the SoA Current as the Product Line Grows
A Statement of Applicability is not a document you finalize once and file away. It carries a version number and a date, the same way a scope statement does, and both need to move together every time the underlying architecture changes. For a multi-product company, the update trigger is not only a new certification cycle. It is any event that changes what a control’s implementation actually looks like across the portfolio: a new product launch, a product sunset, a shared service that becomes product-specific or vice versa, or a change in which data categories a given product touches.
What Triggers a Real Update
Three events should reliably prompt a SoA review in a multi-product company. First, a new product launch, which requires deciding from day one whether it inherits the shared-infrastructure controls as-is or needs its own product-level notes, rather than retrofitting the decision months later. Second, an infrastructure change that moves a previously shared component to product-specific, or the reverse, since that changes which controls apply uniformly and which need differentiation. Third, a change in the data a product processes, which can shift controls like data masking or cryptography from not applicable to applicable, or change the justification behind an existing entry. Treating these as SoA-review triggers, not just engineering decisions, keeps the document honest between certification cycles rather than only at the next surveillance audit.
Why Auditors Look Closely at Version History
A certification body reviewing a multi-product SaaS company’s SoA will often ask when it was last updated and what changed. A document with a stale version date next to a company that has visibly shipped a second product in the interim is a signal the SoA was not maintained as a living record. A document with a clear version history that tracks each product addition, each infrastructure change, and the reasoning behind each SoA update demonstrates the opposite: that the ISMS is actually operating the way the standard intends, not just producing paperwork once a year.
Why the SoA Matters Beyond the Audit
The SoA is not only an internal certification artifact. It is increasingly a document enterprise buyers and their security teams ask to see directly, particularly when enterprise buyers are evaluating whether to sign a SaaS contract that depends on your certification. A multi-product company that hands over a SoA written for a single product, or one that has not been updated since the second product shipped, raises exactly the question a sophisticated buyer is trying to answer: does this certification actually cover the product I am buying. Getting the SoA right the first time removes that friction from every deal that follows.
Elevate helps growth-stage SaaS companies build a Statement of Applicability that holds up under audit and under a demanding enterprise buyer’s scrutiny, including the product-level differentiation a multi-product architecture requires. To review how your current SoA handles multiple products, book a readiness call with an Elevate advisor.
Conclusion
A Statement of Applicability written for one product does not transfer cleanly to a second. The 93 Annex A controls still apply, but a multi-product SaaS company has to make a deliberate scoping decision, whether that is one SoA with product-level notes, a fully differentiated single document, or separate ISMS documentation per product, and then keep that decision current as the product line grows. The companies that treat the SoA as a living document tied to an equally current risk assessment are the ones whose certification actually means what it says, to an auditor and to a buyer reading it before signing a contract.
Elevate builds Statements of Applicability that reflect real multi-product architecture instead of a single-product template stretched thin. Book a readiness call to get your SoA aligned to how your company actually ships product.
Key Takeaways
- The SoA documents a decision for all 93 Annex A controls, not just the ones you implement. Every exclusion needs a written justification tied to your risk assessment, and gaps or generic justifications are among the most common audit findings.
- Multi-product SaaS companies face a real scoping decision that single-product guidance skips. Shared infrastructure and product-specific systems need different treatment, and the right pattern depends on how genuinely separable your products are.
- Product-level annotation is usually the right middle ground. A single ISMS and SoA with control-by-control notes on where implementation differs avoids both a misleading blanket statement and the overhead of fully separate documentation.
- The risk assessment has to differentiate by product before the SoA can. A SoA that treats products differently without a risk assessment that supports that difference is not defensible under audit.
- The SoA is now a buyer-facing document, not just an audit artifact. Enterprise security teams increasingly ask to see it directly, and a SoA that does not reflect the product being purchased raises exactly the question it should answer.
FAQs
What is a Statement of Applicability in ISO 27001? The Statement of Applicability, or SoA, is a mandatory document required under ISO 27001 Clause 6.1.3 that records your organization’s decision on each of the 93 Annex A controls: whether it is applicable, whether it is implemented, and the justification for any exclusion. It connects your risk assessment to the control catalogue and is one of the first documents an auditor reviews during certification. It is also increasingly reviewed directly by enterprise buyers evaluating your security posture before signing a contract.
How many controls does the ISO 27001 SoA need to cover? The current version of ISO 27001, published in 2022, organizes Annex A into 93 controls across four themes: 37 Organizational, 8 People, 14 Physical, and 34 Technological. Your SoA must document a decision for all 93, though you are not required to implement every one. Controls not relevant to your identified risks can be excluded, provided the exclusion is justified in writing and traces back to your risk assessment.
Should a multi-product SaaS company have one SoA or separate SoAs per product? It depends on how much infrastructure the products genuinely share. If products run on largely shared infrastructure with a common identity provider, cloud account structure, and pipeline, a single SoA with product-level notes on any control that applies differently is usually the right balance. If the products are truly separable, sold to different buyers, or run on materially different infrastructure, separate ISMS scope and SoA documentation per product is more defensible and easier to keep accurate.
What happens if the SoA is not updated when a new product launches? An SoA that was accurate for a single product and was never revisited after a second product launched creates a real gap between what the certification claims to cover and what the company actually operates. This surfaces in two places: an auditor will flag controls that no longer reflect the current architecture, and an enterprise buyer’s security team reviewing the SoA before a contract may find that it does not clearly cover the product they are purchasing, which stalls the deal.
What is the difference between the ISO 27001 scope statement and the Statement of Applicability? The scope statement, defined under Clause 4.3, sets the boundaries of what the ISMS covers, such as which products, teams, and infrastructure are included. The Statement of Applicability then documents, for everything inside that scope, which of the 93 Annex A controls apply and how. The scope statement answers what is covered; the SoA answers what is done about it. Both need to stay aligned as a multi-product company’s architecture changes.