If people disagree about what your security risk assessment should cover, agree its scope before the first site visit. Write down the sites, systems, decisions, exclusions and assumptions so new requests can be assessed against an agreed boundary.
A scoping statement fixes this before it becomes a problem. It is a short, agreed document that sets the organisation, dates, boundaries and assumptions of the assessment, signed off by whoever owns the decision to commission the work. It is not a project plan and it is not a report template. It is the thing you point to when someone tries to expand the assessment after it has started.
Why security risk assessment scope drifts
Security assessments are more exposed to scope drift than most other risk work, for three reasons.
First, "security" means different things to different stakeholders in the same conversation. A facilities manager hears physical security. An IT manager hears cyber. A board member hears reputational and regulatory exposure. If you do not write down which of these you are covering, everyone assumes you are covering their version.
Second, security findings tend to cascade. You start on access control at one site and find a shared contractor list that touches four other sites, a legacy VPN, and a visitor process nobody owns. Every one of those is a legitimate finding and none of them was in the original brief. Without a written boundary, "just quickly look at this too" becomes half the project.
Third, the people asking you to expand scope are often the people you need on side for the rest of the engagement. Saying no verbally is hard. Pointing to a document you both signed is not.
What a scoping statement actually needs to contain
A working scoping statement is short — one to two pages — and answers five questions plainly enough that a stakeholder who was not in the room can still understand what was agreed.
- Organisation and context. Who commissioned the assessment, and under what authority. One sentence on why now (new site, incident, contract renewal, board request).
- In-scope boundaries. Named sites, systems, processes or asset classes. Be as concrete as the facts allow — "Building C, levels 1–3" rather than "the head office."
- Out-of-scope items. State explicitly what you are not covering, even where it seems obvious. This is the line you will point back to later.
- Dates and duration. Start date, target completion, and any hard external deadline (a board paper, a contract clause, a regulator's timeframe).
- Assumptions and dependencies. Access you assume you will be given, documents you assume exist and will be provided, and any assumption that if broken changes your ability to deliver on time.
ISO 31000:2018 addresses scope, context and criteria before risk assessment. These need to be revisited when the context changes. The standard does not prescribe a scoping template — that is a practitioner tool — but it is explicit that context has to be set before assessment begins, and security assessments are exactly the kind of work where skipping that step shows up later as rework.
A worked example: Coastal Freight Logistics
Take a fictional three-site logistics operator, Coastal Freight Logistics, that has asked for a security risk assessment after a break-in at one depot.
A vague brief looks like this: "Assess security across our operations." That sentence alone will consume more hours than the client has budgeted, because "operations" could mean warehousing, the vehicle fleet, driver safety, IT systems, or all of it.
A scoped version looks like this:
| Field | Entry |
|---|---|
| Organisation | Coastal Freight Logistics, commissioned by the Operations Director following the Southbank depot break-in |
| In scope | Physical security and access control at Southbank and Ipswich depots only |
| Out of scope | Head office IT systems, driver recruitment vetting, vehicle telematics |
| Dates | Site visits 14–18 October; draft report 1 November; final report 15 November |
| Assumptions | Site managers will arrange access on the visit dates; current CCTV and access logs for the past 90 days will be provided before the site visit |
That single table removes most of the disputes that would otherwise surface in week three. When the Operations Director later asks whether the assessment covers driver vetting, the answer is already written down, and it was agreed before anyone had a stake in a particular answer.
When to revisit scope mid-assessment
A scoping statement is not meant to be rigid for its own sake. Genuine findings sometimes justify a change — the shared contractor list in the earlier example might be a real and material gap. The discipline is not "never change scope," it is "never change scope silently."
When something outside the boundary looks material, raise it as a documented variation: what you found, why it matters, what it would cost in time to include, and what the client wants to do about it. That keeps the decision with the person who owns the budget and the deadline, rather than defaulting to you absorbing extra work because it felt awkward to say no.
Keep the variation note short — a few sentences is usually enough — and send it as soon as the finding is clear, not bundled up and raised for the first time in the final report. A client who hears about a scope issue in week two, with time to decide, is a client who trusts your judgement. A client who reads about it for the first time in a draft report two days before a board deadline is a client who starts wondering what else you did not tell them along the way. The document is what makes that conversation possible on reasonable terms, rather than as a dispute about who should have known better.
Common mistakes
- Writing the scope after the site visit, not before. By then you already know things that bias what you write down as "in scope," and the document stops functioning as a boundary.
- Leaving out-of-scope items blank. An empty out-of-scope section is read as "everything is in scope" by anyone who wants it to be.
- Treating assumptions as throwaway text. An assumption that access logs would be provided, left unstated, becomes your problem when they are not, not the client's.
- No named sign-off. A scoping statement that nobody with authority has actually approved is a draft, not an agreement, and carries no weight when a dispute arises.
- Reusing last year's scope unchanged. Sites, systems and stakeholders change. A scoping statement copied forward without review often has out-of-scope items that are now, quietly, back in scope.
Get the template
The Security Risk Assessment Scoping Statement Template gives you two editable Word versions — one designed, one plain text — for setting these parameters before work starts: organisation, dates, boundaries and assumptions. Once your scope is fixed, the next step is usually building out where findings will live: see How to Build Your First Risk Register (Free Starter Pack) for that. If you are new to the broader method this sits inside, What Is RMBOK? A Practitioner's Introduction is a useful starting point, and if your assessment surfaces bow-tie-style cause-and-consequence questions, Free Online Course: The Risk Bow-Tie Method covers that analysis in more depth.
Download the Security Risk Assessment Scoping Statement Template and get your next assessment's boundaries agreed before you book the first site visit.