Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

How do we…

How do we set the scope of our ISMS?

7 decision pointsThe pack behind this answer: ISO 27001 Implementation & Certification Readiness

Add to board memo

The short answer

Recommendation
Scope the ISMS around the services customers buy, described in their words. Include everything those services depend on, name what you rely on but do not manage as an interface, exclude only what does no work for them, and have top management approve the scope before the risk assessment starts.
Reasoning
The scope is the first thing the certification body reads and the only thing a customer reads on the certificate. Every inventory row and every risk depends on it, so a scope changed after the risk assessment means assessing again. The scope must name the organisation, locations, services and interfaces, and each exclusion with its reason (IS-02). The auditor samples records over the operating period, so a service with no records by Stage 2 has nothing to sample (IS-05). A first scope that grows later costs less than one narrowed after Stage 1.
Considerations
  • The 3-month operating period before Stage 2 is the pack's default (IS-05). Ask your certification body what period it expects, and never plan for a shorter one.
  • Excluding part of the organisation from the scope is a different thing from excluding an Annex A control in the Statement of Applicability. Do not use one to avoid the other.
  • A cloud provider's platform is an interface, never simply out of scope. Group IT that runs systems the scope depends on and will give the auditor access is included, not named as an interface.
  • Who counts as top management depends on how you are governed: the board or a board committee it has delegated to, the management board in a two-tier structure, or executive management where there is no board.

The decision, step by step

Select any step for the reasoning behind it and where the pack covers it.

  • Start
  • Step
  • Decision
  • Outcome
  • Loop back

Keyboard: Tab to a step, arrow keys move along the flow, Enter pins its explanation, + and − zoom, 0 fits the diagram, Esc closes. The text version below has the same content.

Where a step quotes a number, it is the default in the CISO Times pack. Your own standard may set a different one.

Read as text

The same flow written out: each step, its reasoning and where the pack covers it. 19 steps.
  1. Start

    We need to decide what the ISMS covers

    The scope is the first thing the certification body reads and the only thing a customer reads on the certificate. Decide it before the asset inventory and the risk assessment. Every inventory row and every risk depends on what is in scope, so a scope changed afterwards means assessing again.

    In the pack

  2. Step

    Agree why you want the certificate, and who will read it

    A certificate is usually wanted for customers, tenders or a regulator. Knowing who will read it tells you which services must be covered. Record the issues and interested parties that shape the ISMS, and what they require. Name the sponsor and the ISMS manager at the same time.

    In the pack

  3. Step

    Name the services in the customers' own words

    Write down what is delivered to customers, not the departments that deliver it. Then name the legal entities or business units that deliver those services. Name the group only if every company in it is ready; naming the group when one company is ready is a common mistake.

    In the pack

  4. Decision

    Will every service named have records by the Stage 2 audit?

    The auditor samples records over the operating period, which is 3 months in the pack's default. A service that is not live yet, or will not have run for that period by Stage 2, has nothing to sample. If you cannot say when it goes live, treat it as not ready.

  5. Step

    Leave the new service out; add it at a surveillance audit

    Adding a service later is normal and is audited at a surveillance or recertification audit once it has records. Say in the scope that it is excluded and why. Narrowing a scope after the Stage 1 audit is expensive, so a first scope that is too ambitious costs more than one that grows.

    In the pack

  6. Step

    List every part that might be in or out

    Go through sites, including home working; development teams; subsidiaries and group IT; corporate functions such as HR, finance and legal; and the platforms the services run on, including cloud services. Take each one through the next questions in turn.

    In the pack

  7. Decision

    Does this part deliver or support an in-scope service?

    A second site is in when in-scope services are delivered or supported from it. Development is in when you build the software you deliver. Corporate functions are almost always in, because people, contracts and legal duties touch every scope. If you are not sure, treat it as yes.

    In the pack

  8. Step

    Exclude it, state why, and control its access

    Write the exclusion into the scope with its reason. If the excluded part can still reach in-scope systems, control that access. Excluding part of the organisation is a different thing from excluding an Annex A control. Do not use one to avoid the other.

    In the pack

  9. Decision

    Is it under your management, or will it give your auditor access?

    Your own teams, sites and functions are managed by you. A subsidiary or group IT that runs systems the scope depends on and will give the auditor access is included, not named as an interface. One that is a separate business with its own management, a cloud provider, or a supplier of software you only configure is named as an interface. The cloud provider's platform is an interface, never simply out of scope.

    In the pack

  10. Step

    Include it in the scope

    Include it and expect the auditor to test it. For corporate functions, expect questions on how screening, contracts and legal requirements are met. Name locations as they are in practice, including remote working, and cloud regions where they matter to customers.

    In the pack

  11. Step

    Name it as an interface, with an agreement

    Say where the scope meets the outside party and where responsibility changes hands. Cover what it provides in an agreement, and manage it under your supplier controls. An auditor who cannot see where responsibility passes will ask, and an in-scope service that depends on something unnamed fails the scope tests.

    In the pack

  12. Step

    Write the statement: who, what, where, on what, and what is out

    One or two pages is typical, with a diagram of locations and interfaces. It names the organisation, the services, the locations, the technology, the interfaces and each exclusion with its reason. Common gaps are missing interfaces, exclusions with no reason and cloud services not mentioned.

    In the pack

  13. Decision

    Would a customer recognise the service they buy?

    Read the statement as a customer reading the certificate would. If it describes departments or internal systems they would not recognise, the auditor will struggle to map it to real services too, and will challenge it at Stage 1.

    In the pack

  14. Decision

    Is every exclusion justified, and nothing needed left out?

    Each exclusion needs a reason that does not amount to 'not ready'. Nothing excluded may be something an in-scope service cannot run without. Where it is, name it as an interface and control it. A scope nobody can explain is one of the common first-certification failures.

    In the pack

  15. Decision

    Can every in-scope service produce records in the plan's time?

    Check the scope against the project plan. Every in-scope service needs records for the whole operating period by the Stage 2 audit. If the plan cannot deliver that, narrow the first scope or re-plan the date. If you do not know, treat the answer as no.

    In the pack

  16. Step

    Narrow the first scope, and plan to widen it later

    Start with the services that can be ready, and plan to add the rest at a surveillance or recertification audit. The narrower scope must still pass every test: customers recognise the service, and nothing left out is something an in-scope service needs. Say what is left out and why, so top management approves it knowingly.

    In the pack

  17. Decision

    Has top management approved it, knowing what it leaves out?

    Top management approves the scope, the policy direction and the resources together, in a minute or a signed record. Who that is depends on how you are governed: the board or a board committee it has delegated to, the management board in a two-tier structure, or executive management where there is no board.

    In the pack

  18. Outcome

    Hold the risk assessment until the scope is approved

    Every inventory row and every risk depends on what is in scope, so a scope changed after the risk assessment means assessing again. Take the scope back to top management with what it covers, what it leaves out and why, and wait for the decision.

    In the pack

  19. Outcome

    Scope approved: start the asset inventory and risk assessment

    Put the approved statement under document control, and use the same version everywhere, including on the application to the certification body. The Statement of Applicability covers the whole scope and nothing outside it. Review the scope when the organisation or its services change.

    In the pack

Practical checklist

  1. Agree why you want the certificate and who will read it, and record the issues and interested parties that shape the ISMS.
  2. Name the services in the customers' words, and the legal entities or business units that deliver them.
  3. Leave out any service that will not have records for the operating period by Stage 2, and say why.
  4. Take every site, team, function and platform through the questions: does it support a service, and do you manage it?
  5. Write the statement: organisation, services, locations, technology, interfaces, and each exclusion with its reason.
  6. Test it: a customer recognises the service, every exclusion is justified, and every service can have records in time.
  7. Take it to top management with what it leaves out and why, and hold the risk assessment until it is approved.
  8. Put the approved version under document control and use the same version everywhere, including the certification application.

Evidence to have ready

  • The approved scope statement, with a diagram of locations and interfaces, under document control.
  • The minute or signed record of top management approving the scope, the policy direction and the resources (IS-01).
  • The reason for each exclusion, and the agreement covering each interface.
  • The record of the issues and interested parties that shape the ISMS, and their requirements.
  • The application to the certification body, showing the same scope as the approved statement.

Assumptions

  • You are preparing for ISO/IEC 27001 certification, or want a management system built so it could be certified.
  • The operating period before the Stage 2 audit is the pack's default of 3 months. Your certification body may expect a different period; never plan for a shorter one.

Not covered here