Inside the Scope Specification Document: what goes in, what gets challenged
The SSD is the most operationally consequential artefact in a DORA TLPT engagement. What the RTS requires, where NCAs push back, and why drafts must start at T+3, not T+5.
Of all the documents a designated entity will produce during a DORA TLPT engagement, the Scope Specification Document is the one that decides how the rest of the programme runs. It defines what gets tested, what is out of bounds, what the red team is trying to achieve, and which third parties have to be brought into the conversation. Get it right and the next 12 months are about execution. Get it wrong and you are negotiating revisions with your competent authority while the T+6 month clock keeps running.
Most first-cycle programmes underestimate the SSD. They treat it as a scope statement with extra paperwork. It is not. It is the artefact your NCA validates before any threat intelligence work or red team activity can start, and it is the document the TLPT Cyber Team will return to throughout the engagement when something needs to be checked against the agreed scope.
Not yet sure whether you are in the designated population that has to draft an SSD? Run the free 60-second scope check first.
What the SSD is and why the RTS singles it out
The Scope Specification Document is the formal description of the test perimeter, agreed between the designated entity and the competent authority before the active phases of the engagement begin. Commission Delegated Regulation (EU) 2025/1190 (the TLPT RTS, directly applicable from 8 July 2025) specifies the SSD as a discrete deliverable with its own validation process. Article 26(2) of Regulation (EU) 2022/2554 requires that TLPT cover “several or all critical or important functions” of the entity. The SSD is where that requirement becomes concrete.
The reason the RTS singles it out is straightforward: TLPT is a high-impact exercise run against live production systems, and the supervisory authority has to be satisfied, before the test starts, that the scope is right. Too narrow, and the test does not satisfy Article 26. Too broad, and the operational risk to the institution becomes unmanageable. The SSD is where that balance gets struck.
It is also the document that defines the engagement’s relationship with third parties. If an ICT third-party provider is in scope, the SSD captures that decision and the basis for it. Decisions in the SSD propagate into legal arrangements with cloud providers, payment processors, and any other in-scope vendor. That makes it operationally consequential well beyond the testing phase.
The eight things every SSD must define
The structure varies by jurisdiction, but the substantive content the RTS expects an SSD to address breaks down into eight areas:
- Critical or Important Functions (CIFs) in scope. Identified per the Article 3(22) definition, with the rationale for inclusion. The CIFs you select must, together, allow the test to satisfy the “several or all” threshold.
- Supporting ICT systems and infrastructure. The applications, platforms, networks, identity systems, and data stores that underpin each in-scope CIF. This is the technical perimeter against which the red team will operate.
- ICT third-party providers in scope. Any vendor whose participation is required for the test to be operationally valid against the chosen CIFs. Hyperscalers, payment networks, market infrastructure, and managed service providers all sit in this category.
- Flags. The specific objectives the red team must attempt to reach. Flags are how the test demonstrates impact against the CIFs: data exfiltration from a named system, the ability to authorise a transaction, the integrity compromise of a settlement record. Vague flags produce vague results.
- Risk-management measures. The controls, monitoring, and rollback procedures in place to manage the operational risk of testing live production. The Control Team’s authority to halt or modify testing actions belongs here.
- Communications plan. Who within the entity is informed, who is not, how the Control Team interacts with the TLPT Cyber Team at the NCA, and how third-party providers are briefed when their participation is required.
- Escalation and pause procedures. The conditions under which testing must be paused or stopped, the decision authority, and how the engagement resumes. The RTS expects this to be specific, not a generic incident clause.
- Attestation context. Where this test sits in the entity’s TLPT cycle, the role of the SSD in the eventual attestation package, and the linkage to the summary findings and remediation plan that will go to the competent authority at the end.
If any of these eight is missing or thin, the NCA will ask for a revision.
The two areas where SSDs get challenged most
Two parts of the SSD attract the most NCA pushback in first-cycle programmes: flag definition and third-party participation scope.
Flag definition. Programme managers often write flags that are observable but not material. “Obtain domain admin” is observable. It tells you nothing about whether the entity’s critical functions are at risk. Flags should be tied to the CIFs and expressed in terms of impact against them: the ability to alter a record, exfiltrate a defined data set, or interrupt a process that the institution relies on. NCAs that have run TIBER-style programmes for years recognise weak flags immediately and will ask you to rewrite them. The fix is to anchor each flag to a CIF and a regulatory or business consequence, not to a technical milestone.
Third-party participation scope. Entities frequently propose to include a third-party provider in scope without having confirmed with the provider that participation is possible within the test window. Hyperscalers in particular have specific processes for being included in a TLPT, and those processes do not move at the same pace as your internal programme. The NCA will ask whether the third party has confirmed participation, what the contractual basis is, and how the test will proceed if the third party withdraws or delays. If you do not have answers, the SSD does not get approved.
A related challenge is the opposite case: a third party that should be in scope but is excluded for convenience. If a CIF cannot meaningfully be tested without engaging a specific third party, scoping that party out is a credibility problem. NCAs read for this directly.
The T+6 month deadline and why drafts must start at T+3
The SSD must be submitted to the competent authority within six months of the notification letter. That is the hard deadline. The drafting timeline that fits behind it is shorter than it looks.
CIF identification at the level the RTS expects takes time. You will need input from business owners, IT architecture, third-party risk, and legal, and you will need to defend the inclusions and exclusions to a Control Team that is itself only weeks old. The first internal draft is rarely the version that goes to the NCA. Two or three internal revisions are normal.
Once you submit, the NCA validation cycle begins. Expect questions. Expect at least one round of requested revisions. Build that into your plan. Submitting at T+5 months and 28 days, with no contingency for NCA-requested changes, is how programmes end up in their first supervisory conversation about delay.
The practical schedule that works: SSD drafting begins no later than T+3 months, internal review concludes by T+4 months, first submission to the NCA at T+4 to T+4.5 months, and the buffer between then and T+6 absorbs revisions. If your provider procurement is running in parallel, your TI provider can begin scoping work informally against a near-final SSD draft before formal approval lands. They cannot begin formal TTI work, but the preparation is not wasted.
NCA validation: what they actually look for
The TLPT Cyber Team at your competent authority is not approving the SSD as a paperwork exercise. They are checking that the proposed scope will produce a test that satisfies Article 26 and that the operational risk is being managed appropriately.
In practice, they look at:
- Whether the selected CIFs are genuinely the most important ones, or whether the entity has avoided harder targets
- Whether the supporting ICT inventory is at the right level of granularity (specific systems, not “the core banking estate”)
- Whether the flags are tied to CIF-level impact rather than internal red team milestones
- Whether third-party participation is realistic and confirmed
- Whether the Control Team has the authority described, and whether the pause procedures will hold up under real test conditions
Where they ask for revisions, the most common requests are: expand the CIF selection, sharpen the flags, evidence the third-party participation, and tighten the escalation procedure. Each of these is a request you can prepare for in advance by stress-testing your own draft against these specific points before submitting.
For SSM significant institutions, the ECB SSM Supervisory Guide (November 2025) sets out additional ECB-level expectations. The TIBER-EU framework documentation refreshed by the ECB in February 2025 is the closest available analogue for how a TLPT Cyber Team will read your SSD.
The relationship between the SSD and the TTI report
The SSD and the Targeted Threat Intelligence report are two different artefacts with two different jobs. They have to work together.
The SSD defines scope: the CIFs, the systems, the third parties, the flags. The TTI report shapes scenarios: which threat actors are most likely to target this entity, what their tradecraft looks like, how they would approach the in-scope CIFs given the current threat landscape. The red team’s testing plan is built where the two meet. The flags from the SSD become the objectives. The threat actor profiles from the TTI report become the means.
This sequencing has a programme implication: the SSD has to be near-final before the TTI provider can begin meaningful scenario development. If the SSD is still in flux when the TTI work starts, the TTI report ends up either too generic to drive scenarios or has to be partially redone after scope changes. Either outcome compresses the timeline downstream.
Get the SSD right first. Let the TTI report do its job against an agreed scope.
A short evidence checklist before submission
Before the SSD goes to the NCA, the Control Team should be able to evidence each of the following:
- Every in-scope CIF has a named business owner and a documented rationale for inclusion
- Every CIF maps to specific named ICT systems, not categories
- Every flag is tied to a CIF and expresses a regulatory or business consequence
- Every in-scope third party has confirmed participation in writing, or the SSD records the engagement and a fallback
- The Control Team Lead’s authority to pause testing is documented and signed off
- The escalation procedure has been tested against at least two realistic scenarios
- Internal Legal has reviewed the third-party arrangements and confirmed they support the test
- The submission package matches the format the NCA expects
If any of these is missing, fix it before submission, not after. The NCA round-trip is the expensive bit.
For the full TLPT phase timeline and a preparation checklist for the engagement around the SSD, see the DORA TLPT timeline page.
