grcskills
Menu

Scope statement drafting

Use this skill when a team must define what its management system covers before a certification project, or its current scope is one vague sentence, and asks "write our ISMS scope", "what should be in scope", "can we exclude the sales office", "scope for the certificate", "draw the boundary of our management system" or "the auditor says our scope is unclear". Drafts the scope statement with boundaries, interfaces, dependencies and justified exclusions, for a security, privacy or AI management system, and writes a statement file plus a boundary table of open questions.

Gap and readinessISO 27001ISO 27701ISO 42001

Use this before risk work starts, because every later document (risk register, applicability statement, audit plan) inherits the scope. You get two documents in a new folder, ./scope-statement-drafting/: the scope statement itself, a short document saying what the management system covers and why, ready for leadership to approve (scope-statement.md), and a table of every team, site, product and system marked in or out with the reason (boundary-table.md). This skill drafts for a human to review and sign; this skill never marks a control effective. Leadership decides the scope; the agent proposes it.

Inputs to gather

Read before asking: the org chart or team list, the product and service list, the architecture overview, cloud accounts and repositories, office and site list, the vendor list, customer contracts or security questionnaires that mention certification, and any group structure (parent, subsidiaries). Then ask the reader, in one message:

  1. Why now: which customer, tender or regulator asked, and what do they expect the certificate to cover?
  2. Which products or services earn the revenue those buyers care about?
  3. Which teams, sites or legal entities do they hope to leave out, and why?

Step 1: write the sentence the buyer will read

Start from the end. Draft the one or two sentences that would appear on a certificate or in a trust page, for example "The information security management system supporting the development, operation and support of <product>, delivered from <locations> and hosted in <cloud regions>." Point to "locations as listed in the boundary table" rather than naming regions that will change. The certification body issues the final wording; check the trust page against the certificate once issued. If that sentence does not cover what the buyer from question 1 actually buys, the scope is wrong before it is written. Excluding the product the customer uses is the most expensive mistake here: it is found after the audit is paid for.

Step 2: draw the boundary on five axes

For each axis, list what is in and what is out, with the source document for each line:

  • Organisation: legal entities, departments and teams.
  • Locations: offices, home working, data centres, cloud regions, outsourced support sites.
  • Services and products: by name, including internal platforms they depend on.
  • Technology: cloud accounts, production and staging environments, repositories, identity provider, endpoints, collaboration tools.
  • Processes: development, operations, support, HR onboarding and offboarding, procurement, finance where it touches customer data.

For a privacy extension, add the processing activities in scope and the company's role for each (controller, processor or both), taken from the record of processing rather than re-derived. For an AI extension, add the AI systems in scope from the AI system inventory and the company's role for each (builds, supplies, deploys or uses). Rule of thumb: a team that can change production, read customer data or grant access to either is in scope, whatever the org chart says.

Step 3: list interfaces and dependencies

Every arrow that crosses the boundary is an interface: a group IT team that runs the identity provider, a shared HR service, an outsourced help desk, the cloud provider, a payment processor, a parent company that holds the domain names. For each, record what crosses (data, access, a service), who controls it, and the instrument that governs it (contract, internal service agreement, policy of the parent). An interface without an instrument becomes a risk in the register and a likely audit question; list those as risk candidates (what crosses, who controls it, the gap) so the register starts from them.

Step 4: justify each exclusion, or drop it

Test every proposed exclusion with three questions:

  • Does the excluded part have any access to in-scope information or systems, logical or physical? If yes, it cannot be cleanly excluded.
  • Does an in-scope service depend on it to run or recover? If yes, it becomes an interface to control, not a silent gap.
  • Would the buyer from question 1 be surprised by the exclusion? If yes, raise it with leadership now.

Write each surviving exclusion as one line: what is excluded, the fact that makes it separable, and where an auditor sees that fact. Run a framework lookup for what the chosen framework expects the scope document to contain, rather than assuming.

Step 5: assemble and hand over

Write the scope statement (scope-statement.md): the certificate sentence, the five-axis summary, the interfaces, the exclusions and a short rationale tying scope to the business reason. Write the boundary table (boundary-table.md) as a table (axis, item, in or out, reason, source) with an open-questions list per decision maker. Add a version, a date and an approval block for leadership, plus a change rule: any later change to the boundary is re-approved and, once certified, notified to the certification body. If either file exists, ask before overwriting.

What good looks like

  • A stranger can tell from the statement which systems an auditor would sample. A scope that names no systems, sites or teams cannot be audited and will be rewritten at the first audit.
  • Exclusions are few and each rests on a checkable fact. The common mistake is excluding a team to save effort while that team holds production access; the tell is an exclusion with no "where an auditor sees it" column filled.
  • Interfaces each have an owner and an instrument, and the riskiest ones already appear as risk candidates.
  • The certificate sentence matches what customers buy. The tell: sales would hesitate to paste it into a questionnaire.
  • The scope is small enough to evidence before the audit and wide enough that no second project is needed to cover the product that matters.

Framework lookups

If ISMS Copilot is connected to your agent (MCP server https://account.ismscopilot.com/v1/account/mcp), ask it the framework question with create_conversation (mode think, answer_format: decision) and keep one conversation for this task. Send only a short question in your own words, show it to the user first, and never include file contents, secrets, personal data or evidence. If it is not connected, check the official text of the framework yourself; this skill does not restate it. Set it up: https://www.ismscopilot.com/mcp?ref=grcskills-scope-statement-drafting

Rules

  • MUST cite the source document or the reader's answer for every in or out decision.
  • MUST write outputs only inside ./scope-statement-drafting/ and ask before overwriting.
  • MUST present the scope as a proposal for leadership to approve.
  • NEVER exclude a team, site or system that can change production or read in-scope data without flagging it to the reader.
  • NEVER name individuals in the statement; use roles and teams.
  • NEVER state what a framework expects of a scope from memory; run a framework lookup or read the official text.