Scope Creep at a 60-Person SaaS Firm
Nordwind Analytics is a 60-person SaaS company preparing for its first ISO/IEC 27001 certification. The CTO wrote the ISMS scope as: "All information systems, people, and processes of Nordwind Analytics worldwide." The company hosts its product on AWS, but payroll runs through a local bureau, and a 12-person engineering team in Lisbon operates as a legally separate subsidiary that Nordwind does not control operationally. The internal auditor flagged that the scope statement is not credible: there are no interfaces documented with the payroll bureau, and the Lisbon team's access to production databases is not covered by any Nordwind policy. The certification body has not yet been engaged. The CTO argues that keeping the scope broad avoids "having to explain exclusions" to customers.
1. Evaluate the CTO's reasoning against ISO/IEC 27001 scope requirements. What must the scope statement actually reflect, and what are the consequences of an over-broad claim?
Read the worked answer
The scope must accurately reflect the organization's business, its context, and the interfaces and dependencies that bear on information security (Clause 4.3). A scope is not a marketing statement - it defines the boundary within which the ISMS must be demonstrably effective.
An over-broad claim is not neutral: it creates auditable obligations. If the scope says "worldwide" and "all processes," the auditor will sample the payroll interface and the Lisbon subsidiary's production access. If those are undocumented and uncontrolled, the organization fails those clauses - the broad scope converts a small gap into a major nonconformity.
The defensible move is to scope precisely to what Nordwind controls operationally, document the interfaces (payroll bureau, subsidiary access) as dependencies with defined security requirements, and either bring the Lisbon team's access under the ISMS or explicitly exclude it with a justification. Exclusions must be justified and must not undermine the credibility of the certification. Customers are better served by a credible scope plus a documented interface-control story than by a claim the organization cannot back.
2. The CTO wants to exclude the Lisbon subsidiary entirely. What conditions must be met for that exclusion to be acceptable, and what residual risk remains?
Read the worked answer
An exclusion is acceptable only if it is justified and does not compromise the ISMS's ability to ensure security of information within scope (Clause 4.3). The justification must be documented and defensible to the certification body.
Conditions: (1) a written rationale for why the entity falls outside the ISMS boundary (e.g., separate legal control, no shared production access); (2) documented interfaces and security requirements for any interaction that crosses the boundary; (3) confirmation that excluding it does not leave in-scope information unprotected.
Residual risk: if Lisbon engineers hold production database credentials, the exclusion is hollow - in-scope information is reachable from out-of-scope people. Nordwind must either revoke/limit that access, bring it under ISMS controls (access review, policy acknowledgment, logging), or document it as a managed interface with contractual and technical controls. The auditor will test exactly this seam. An exclusion that hides a real access path is worse than no exclusion, because it signals the risk was known and unmanaged.