What you’ll take away
- Describe the customer service and supporting activities before drawing a boundary around teams, locations, information, and systems.
- Record how shared functions and outside providers support the scope, with an owner and evidence for each important handoff.
- Keep scope, control applicability, and certification claims distinct, then review the boundary when the business changes.
In this guide
Begin with the promise your customer is buying
A fictional small SaaS company provides a dispatch scheduling service to logistics businesses. Dispatchers upload delivery details, assign work, and track schedule changes. A prospective customer asks whether the service is covered by ISO 27001 certification. The company has a production cloud environment, remote developers, a support team, shared corporate IT, and several suppliers. Its first decision is what its proposed information security management system will cover and how that boundary relates to the service being sold.
ISO/IEC 27001 defines requirements for an information security management system, or ISMS, through which an organization manages information security risks. [1] Certification concerns that management system within its stated scope. It does not promise that a software product will never contain a vulnerability or experience an incident. For the fictional company, the useful commercial question is whether the activities behind the dispatch service are represented accurately in the proposed scope.
Start by collecting the actual customer request, the relevant contract language, and a plain description of the service. Ask sales and delivery leaders what customers reasonably expect the certificate to cover. A narrow scope that omits a material part of the purchased service can create expensive clarification later. A scope that casually claims every company activity can create work nobody planned to own. Resolve that choice before building a large evidence library.
Describe the operating service before listing systems
Walk through a customer’s experience from onboarding to departure. For the dispatch service, that includes creating customer accounts, importing delivery records, managing permissions, changing schedules, handling support requests, and returning or deleting information when service ends. Then follow the supporting work: developers release changes, administrators maintain access, operations staff recover interrupted service, and support staff investigate customer problems. The scope discussion becomes more useful when it follows these activities instead of starting with a list of cloud subscriptions.
Record the information each activity uses and where it travels. A support ticket might contain a screenshot of a delivery schedule even when the production database remains in a separate cloud account. A developer’s troubleshooting export might contain customer identifiers. These are questions to investigate in the fictional example, not findings about a real company. They help the team discover where an apparently simple production boundary depends on work performed elsewhere.
Use a short service description alongside a working inventory. Identify the responsible organization, service activities, supporting teams, relevant locations and remote-working arrangements, information, and systems. Give each uncertain entry an owner who can confirm the facts. Keep that inventory detailed enough to support decisions without forcing every server name into the public-facing scope statement. The statement should remain understandable while the supporting record explains how the service actually operates.
Draw a proposed boundary that matches the work
Clause 4.3 of ISO/IEC 27001:2022 ties the ISMS boundary to organizational context, relevant interested-party requirements, and interfaces and dependencies with other organizations. It also requires a documented scope. [2] Those considerations make the boundary a business decision supported by operational facts, rather than a box drawn around whichever systems are easiest to prepare for an audit.
For discussion, the fictional company could describe its proposed scope as the development, operation, and customer support of its dispatch scheduling service, including the supporting people, processes, and technology. That is an illustrative starting statement, not approved certificate wording. The supporting record would identify the legal entity, covered activities, relevant working locations, service components, and interfaces. Leaders should be able to point from each part of the statement to an accountable person and an actual workflow.
Suppose the company also has an experimental analytics product with a separate customer base. Excluding that activity may be a reasonable proposal, but the team first needs to examine shared staff, privileged accounts, data stores, deployment tooling, and support arrangements. If those connections can affect dispatch information, they still need treatment in the boundary analysis. An exclusion should explain what is separate and how the remaining interfaces are governed; the product’s name alone does not establish separation.
Start with the service and the work behind it.
Develop, operate, support, and recover.
Responsible teams and documented work locations.
Dispatch records, applications, and supporting technology.
Keep outside providers connected to the boundary
The fictional company uses external cloud hosting and a ticketing provider. Those suppliers are outside the firm’s organizational boundary, yet their services support its dispatch offering. Document what information reaches each provider, which service is used, who configures it, and which operational responsibilities remain with the company. For example, the hosting provider’s responsibilities do not answer who approves a dispatch administrator or checks the application’s recovery settings.
A useful dependency entry connects an outside service to a business activity and a named internal owner. For ticketing, it might cover customer support, permitted ticket contents, staff access, export permissions, incident contacts, retention settings, and exit arrangements. These are practical questions for this example, not a universal checklist of required configurations. Ask for evidence appropriate to the actual service and relationship. A provider’s certificate is one input; read its scope before deciding what it establishes for your dependency.
Also examine changes at the interface. If support begins attaching production exports to tickets, the earlier information-flow description may no longer be accurate. If a supplier introduces a subcontractor or changes an administrative feature, someone needs to evaluate the effect on the dispatch service. Assign that review to the relationship owner and involve the relevant technical owner. The aim is an understandable chain of responsibility from the customer-facing service to the external work on which it depends.
A dependency needs owners on both sides.
- Corporate ITIdentity and endpoint support
IT operates shared services; the service owner confirms required access.
EvidenceAccess reviews and removal records- HRJoiner and leaver handoff
HR signals workforce changes; the access owner completes the change.
EvidenceMatched notice and access-change record- Cloud hostingExternal supplier interface
Document provider duties and the service team’s configuration responsibilities.
EvidenceSupplier review and configuration evidence
Separate scope from risk treatment and control selection
Defining the ISMS scope does not authorize excluding requirements in clauses 4–10 when claiming conformity. Risk treatment determines necessary controls, checks them against Annex A, and records applicability decisions in the Statement of Applicability, including implementation status and justified exclusions. [2] These are connected decisions with different purposes: the scope describes the management system’s reach; control decisions address the risks and requirements within that context.
ISO/IEC 27002 provides guidance on information security controls, while ISO/IEC 27001 establishes ISMS requirements. [3] In the dispatch example, use control guidance to help design appropriate practices after understanding the service and its risks. Do not remove customer support from the proposed scope simply because support access is difficult to manage. Bring the weakness into the improvement work, assign responsibility, and decide how the business will address the exposure.
Maintain links between the service description, risks, treatment decisions, controls, and evidence. If the dispatch company chooses a particular access-control approach, the record should explain the problem it addresses and where it operates. If a control is considered unnecessary, the explanation should survive review against the actual boundary and dependencies. This traceability helps prevent two teams from making incompatible assumptions: one thinks a provider handles an activity, while the other believes the customer has accepted responsibility.
Challenge the draft with three ordinary changes
Before approving the proposed scope internally, walk it through realistic changes. First, a developer joins both the dispatch and analytics teams. Check whether shared access or tooling undermines the proposed separation. Second, support starts using a new ticketing integration. Trace the information and access it introduces. Third, a customer requests a different service arrangement. Decide whether the existing description still represents the activities the company is agreeing to perform.
For each case, record the answer, the supporting evidence, and any unresolved assumption. The fictional firm might discover that analytics staff use the same privileged group as dispatch operators. It should then investigate the actual access and choose a response: revise the boundary, change the access arrangement, or do both. This is a hypothetical decision exercise. It illustrates why a boundary should be tested against operating facts before teams build evidence around it.
Bring engineering, support, corporate IT, HR, commercial leadership, and the ISMS owner into the relevant parts of the review. Each can expose a different missing interface. Keep decisions small and explicit: confirm a responsibility, correct the service description, investigate a connection, or resolve a customer expectation. Record who approves the resulting scope and who maintains the supporting information. A useful review ends with decisions and owners, not merely agreement that the diagram looks reasonable.
Approve a scope the organization can operate.
- Propose the boundary
Name the service, activities, locations, and information.
- Map the dependencies
Record shared functions, suppliers, and handoffs.
- Validate with owners
Confirm responsibilities and available evidence.
- Approve and maintain
Management records the scope, rationale, and version.
Revisit when the business changes.New services, locations, suppliers, or responsibilities can change the boundary.
Distinguish your intended scope from the certificate
ISO develops standards; certification is performed by external certification bodies. [4] Your internally approved scope is therefore an input to the certification process, not evidence that certification has been granted. Discuss the proposed activities, locations, dependencies, and wording with the selected body during planning. Resolve material differences before the team makes commitments to customers based on a certificate it does not yet hold.
Keep sales and procurement communications aligned with the actual stage of work. A company preparing its ISMS can explain its intended scope and readiness work without describing itself as certified. Once a certificate is issued, compare its actual coverage with the services being sold and the commitments customers requested. Escalate ambiguous wording to the certification body rather than filling the gap with an expansive marketing interpretation. The dispatch service and experimental analytics product should not silently become interchangeable in sales materials.
Scope clarity also improves engagement planning. A provider needs to understand the covered activities, organization, operating locations, dependencies, and readiness gaps before estimating the work. Ask what assumptions the proposed engagement uses and how a scope change would be handled. Avoid setting an audit date solely from a sales target while material boundary questions remain open. A documented, agreed starting point gives the readiness team and certification body a more reliable basis for their respective work.
Leave the business with a scope it can maintain
Keep the approved scope statement with its supporting service map, dependency records, decisions, and open actions. Name an owner who can initiate review when the company adds a product, changes suppliers, acquires a business, reorganizes support, or changes how customer information is used. Review the effect on the management system before assuming the existing boundary still fits. Changes can require coordination with the certification body as well as updates to internal records.
Source Point Security’s ISO/IEC 27001 Readiness service helps define the ISMS boundary, assess gaps, prepare the risk method and treatment plan, and develop the Statement of Applicability. The engagement can include internal audit, management review, corrective-action work, and an evidence index ahead of the certification audit. SPS prepares the organization for that process; the independent certification body decides the certificate. A separate Security Risk Assessment can support a defined assessment need with documented criteria, risks, and treatment priorities.
For an initial discussion, bring the customer request, a short service description, the organization chart, major suppliers, and any existing scope statement. Add the uncertainty you most need to resolve: shared staff, an excluded product, remote operations, or responsibility for an outside service. Those inputs help turn a broad ambition to obtain certification into a specific readiness engagement with an understandable boundary, accountable owners, and work the business can review.
Define the ISMS scope your business can stand behind
Bring your customer requirements, service description, and shared dependencies. We can scope an ISO/IEC 27001 readiness engagement with clear responsibilities and practical deliverables.
Discuss ISO/IEC 27001 Readiness