If new sites, systems and questions keep appearing during an assessment, use an agreed change process rather than quietly absorbing the work. Clear boundaries and a record of decisions help you address new findings without losing control of the original commission.

Security risk assessment scope creep is a credibility problem, not just a workload problem
An assessment that expands mid-flight has two costs. The first is obvious: time and budget blow out, and something scoped for a week becomes a month. The second is less visible and more damaging: when the report lands, whoever commissioned it can point out that half the findings are about things they never asked you to look at, and use that to discount the findings they did ask for. ISO 31000:2018 addresses scope, context and criteria before assessment. Agree them early and revisit them explicitly when circumstances change. A scoping statement is how you make that agreement concrete enough that it can be pointed back to when someone tries to relitigate it in week three.
The five clauses that hold the line
A scoping statement does not need to be long. It needs to answer five questions clearly enough that a disagreement about scope can be settled by rereading it rather than re-arguing it.
| Clause | What it fixes | What goes wrong without it |
|---|---|---|
| Boundaries | Which sites, systems, business units or processes are in scope | “The main site” turns out to mean three buildings, then a fourth |
| Exclusions | What is explicitly out of scope, named rather than implied | Silence gets read as “everything else is fair game” |
| Assumptions | What you are taking as given because it was out of scope to verify | An assessment gets criticised for not verifying something it was never asked to verify |
| Timeframe and currency | The dates the assessment covers and how current the findings are expected to remain | Findings get applied to a system that has since changed, or a report sits unused because nobody knows when it expires |
| Sign-off and change control | Who approved the scope, and the process for changing it mid-assessment | Scope changes get agreed verbally in a corridor and nobody remembers the new boundary |
Each clause is doing a specific job. Boundaries and exclusions work together — a boundary that says “the main site” without an exclusions clause naming what is not covered leaves room for someone to argue the warehouse should have been included because nobody said it wasn’t. Assumptions protect you the other way: if you assumed the fire evacuation plan was current because verifying it was out of scope, and it turns out not to be, the assumptions clause is what shows that was a stated limitation, not an oversight. Sign-off and change control is the clause that actually stops creep in real time — it says any change to the four clauses above requires the same approval the original scope got, not a nod in a meeting.
Worked example: before and after
A fictional regional manufacturer, Torrens Fabrication, commissions a security risk assessment after a near-miss involving an unescorted contractor. The initial brief, verbal, is “look at contractor access at the plant.” Compare the scoping statement that should have been written against what actually happened without one.
Without a scoping statement: the assessor starts at the plant, notices the visitor sign-in process is manual, then notices the second gate has no camera coverage, then is asked by an enthusiastic operations manager to “also have a look” at the loading dock two kilometres away because it has the same contractor traffic. Three weeks in, the report covers two sites and a mix of physical and access-control findings, and the original near-miss — the actual reason the assessment was commissioned — is one paragraph out of twenty.
With a scoping statement: boundaries name the main plant only, specifically the two contractor entry points involved in the near-miss; exclusions explicitly name the loading dock as out of scope for this engagement; assumptions state that the visitor sign-in process at the excluded site is assumed unchanged; timeframe covers a two-week assessment window with findings current as at the assessment date; and sign-off names the operations manager as the approver for any change to boundaries. When the request to add the loading dock comes up, it goes through that clause as a documented scope variation with its own timeline, rather than absorbing silently into the original one.
Scoping statements for multi-phase assessments
Longer assessments raise a variant of the same problem: scope that was reasonable for phase one quietly becomes the assumed scope for phase two, without anyone re-checking that it still fits. If an assessment runs in phases — a desktop review followed by site visits, say — treat each phase as needing its own confirmation against the five clauses rather than inheriting the original statement unread. This does not mean rewriting the document each time. It means a short check at the start of each phase: are the boundaries, exclusions and assumptions from the original statement still accurate, or has something changed that needs a documented variation before the next phase starts. Skipping that check is how a scoping statement that was tight on day one becomes irrelevant by week four, while everyone involved still believes it is being followed.
Common mistakes
- Treating scope as implied by the trigger event. A near-miss at one gate does not imply the whole site is in scope; say explicitly what is and is not covered.
- No named approver for scope changes. Without one, “can you also just look at…” becomes the actual scope, agreed by nobody in particular.
- Assumptions left unstated. If you did not verify something because it was out of scope, write that down. It is the difference between a stated limitation and a missed finding.
- No expiry on currency. A scoping statement that does not say how long its findings are expected to hold gets treated as permanently current, including for systems that changed the week after the report was issued.
- Scoping statement written after the assessment starts. If it is drafted to match what has already been looked at, it is documentation, not a control.
- Reusing an old scoping statement without reviewing it. A boundary that was correct for last year’s assessment is not automatically correct for this year’s; sites, systems and ownership all change.
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. It is free to download. Once scope is locked down, Risk Register Fields: The Minimum Set That Actually Works covers what to do with the findings, and Explaining Risk Management to Colleagues Who Think It’s Paperwork is worth reading if the scoping conversation itself keeps getting waved off as red tape. For help organising a new responsibility, see Where Do I Start When I Am Given Security Risk Responsibility?.
