Scope assessment for security duties: documents to prepare
A scope assessment establishes which security duties apply to your organisation, which systems and data flows fall inside the boundary, and which contracts or vendors sit outside it. The assessment itself takes days to weeks depending on how many entities and vendors are in scope. It ends with a signed scope statement that becomes the reference point for everything that follows, including any remediation plan.
Why the boundary matters before the detail
Teams often start with a checklist of controls before anyone has agreed what "in scope" means. That produces work that has to be redone once the boundary shifts. The assessment fixes the boundary first: which legal entities, which processing activities, which third-party services. Everything downstream — policies, contracts, technical controls — is built against that fixed boundary, not against an assumption of it.
Once the boundary is signed off, changing it requires a formal change request rather than a quiet edit to a spreadsheet. That sign-off is the point of no return in the process: before it, scope is a working draft; after it, scope is a reference document that other teams rely on.
Documents to prepare
Bring the following before the first working session. Missing items do not stop the assessment, but they do stretch the timeline, because each gap becomes a follow-up request to a business owner who may be slow to answer.
| Document | Why it is needed | Who usually holds it |
|---|---|---|
| Asset and system inventory | Defines what could be in scope before anyone discusses obligations | IT or infrastructure lead |
| Data flow map or equivalent notes | Shows where data enters, moves and leaves the organisation | Data protection or engineering lead |
| Vendor and processor list with contracts | Separates obligations that sit with your organisation from those passed to a supplier | Procurement or legal |
| Organisational chart of relevant entities | Confirms which group entities the assessment covers | Group secretary or finance |
| Prior audit or assessment reports | Avoids reopening ground already covered | Compliance or internal audit |
| Incident log for the past 12–24 months | Flags areas that already show weakness | Security or IT operations |
None of these documents need to be polished. A working spreadsheet is fine at this stage; the assessment is where gaps get named, not where they get fixed.
What to do
- Name an owner. One person is accountable for the scope statement, even if several people contribute to it.
- Circulate the document list above to business owners with a short deadline, and note who has not responded by day three.
- Draft the boundary — entities, systems, data flows, vendors — as a single working document, not a set of separate notes.
- Review the draft with each business owner whose area is affected, and log every objection with a date.
- Sign off the scope statement at the level your organisation uses for governance decisions of this kind.
- File the signed statement alongside the documents used to build it, so the next review starts from a record rather than memory.
Who decides and by when
The scope statement is normally signed off by whoever owns security or compliance governance internally — a management board, a designated committee, or a single accountable owner in a smaller organisation. There is no external authority to approach at this stage; the assessment is an internal exercise, and its output is a decision record, not a filing. A realistic internal target is two to four weeks from the first document request to sign-off, longer where several group entities or a large vendor list are involved.
If your assessment runs into these situations
If the assessment surfaces overlapping licensing or ownership arrangements across group entities, resolving those first tends to simplify the security review rather than complicate it: Group restructuring of rights sets out what a decision-maker looks at in that situation.
If a technology component under review is also the subject of an intellectual property dispute, the security assessment and the dispute timeline need to be kept apart rather than merged: see When prior art surfaces after grant: when the other side moved first.
If a technology contract is up for renewal while the assessment is running, align the two calendars deliberately rather than by accident: How renewal and price review technology contract what the decision-maker looks at explains the usual sequence.
If your organisation is also preparing a token listing, the document set for that process overlaps with a security scope assessment more than most teams expect: Listing preparation token issuance documents to prepare lists what is needed on that side.
What this page does not cover
This page does not tell you which specific duties apply to your organisation once scope is fixed — that depends on facts this page cannot see. It does not set out remediation steps once gaps are found; that is a separate exercise with its own document set. It does not cover the substance of any external regulatory filing, because a scope assessment of this kind is an internal governance step, not a submission to an authority.
Related reading
Once the scope statement is signed, the next document is usually the remediation plan itself: How gap review and remediation plan data protection documents sets out what to prepare for that stage.
Verified
This page reflects internal procedural practice for scope assessments as run across group entities in the EU, reviewed on 4 November 2025. It does not cite specific statutory provisions; where a duty depends on a particular regulation, that dependency is addressed in a separate assessment once scope is fixed.
Frequently asked questions
How long does scope assessment for security duties take in practice?
Two to four weeks is typical for a single entity with a modest vendor list. Add a week for each additional group entity that needs its own sign-off, and expect delay wherever a business owner does not respond to the initial document request within the first few days.
Which documents are needed to start?
An asset inventory, a data flow map or equivalent notes, the vendor and processor list with contracts, an organisational chart, prior audit reports if any exist, and an incident log for the past one to two years. Working drafts are acceptable; the assessment is where gaps get identified, not where they need to already be closed.
What happens if the other side does not respond?
Where "the other side" is a vendor, a subprocessor, or a group entity that has not answered an information request, log the date of the request and proceed to draft the scope statement with that item flagged as unresolved. A vendor's failure to respond is itself useful information — it often surfaces during a certification questionnaire later, and When a vendor questionnaire asks about certification: what to do first sets out the usual first move once that happens.