TIBER-EU scoping and the scope specification document

What the TIBER-EU scope specification document must contain

The TIBER-EU scope specification document must list each critical or important function the entity wants tested, the ICT systems and services that underpin each function, and the flags the red team will try to capture on each system. For every function left out of scope, the document must also give a stated rationale. The entity completes it during the preparation phase, the management body approves it, and the TIBER authority validates it. The document is due to the test manager within six months of the written notification, and the scoping meeting takes place no later than that same six-month point, so the entity should plan its internal approval cycle backward from that date.

Scope drives the whole test. Every flag defines what the red team tries to reach, and every system named becomes a potential target, so an incomplete inventory produces a test that misses the entity's most important exposures. For each function in scope, the document records the reason for inclusion, the supporting ICT systems, whether those systems are supported by an ICT third-party provider and which one, the jurisdictions where they operate, and preliminary flags with the security aspect each covers. Each system needs at least one flag, and the entity's wider ICT infrastructure may serve as an entry or pivot point toward those systems. Teams should confirm early that their asset inventory is current, because an out-of-date inventory is the most common source of gaps in this document.

Two constraints make scoping difficult. The framework treats a maximum of 10 critical or important functions per tested entity as adequate, so the entity must rank its functions and defend the cut. The DORA Article 3(22) definition of a critical or important function sets the test for inclusion, and the entity should document how it applied that definition to each function. Where systems are partly outsourced, the entity should also check whether its ICT service contracts allow testing on the supplier's infrastructure, or add such clauses to future contracts. Confirm these points with your test manager and the TIBER authority before the scope is finalized, since national implementations may add requirements.

Which functions, systems and third parties shape the scope

Scoping decides how much of the entity the red team can reach and how much work the test becomes. The decisions below are linked: the functions chosen drive the systems, the systems drive the third parties and the jurisdictions, and every omission has to be justified in the scope specification document.

Choosing critical or important functions

TIBER-EU uses the DORA Article 3(22) definition of a critical or important function as the test for what goes in scope. Each function you select becomes a line the test manager, the management body and the authority will review, so the list should be narrow enough to test well. The framework considers a maximum of 10 functions per tested entity adequate as a rule of thumb. Check that each function ties to a service the business would struggle to deliver if it failed, and record the reason for inclusion for each one.

Mapping underpinning systems and services

Each function in scope has to be traced to the ICT systems and services that support it, because flags are set against systems, not against functions. Build this map from your configuration management database or asset inventory rather than from memory. Incomplete inventories are a common reason scope discussions run long. Expect the red team to use the wider ICT estate as an entry or pivot point, so the map should show dependencies such as identity, networks and shared databases, not only the front-end application.

Documenting functions left out of scope

Any identified critical or important function that you do not test needs a stated rationale in the scope specification document. Reviewers will read these exclusions closely, so vague reasons such as low priority will not hold up. Acceptable rationales are specific and checkable, for example that a function is already covered by a recent test under another regime and the authority agrees the coverage. Ask your authority which exclusion reasons it has accepted before you write them down.

Partly outsourced infrastructure and supplier clauses

Where part of the ICT infrastructure belongs to a provider, the framework recommends confirming that your ICT service contracts allow testing on that supplier's infrastructure, or adding such clauses to future contracts. Without this, a flag that sits in a provider's environment may be untestable, and the scope will need rework. Review existing contracts for testing rights, notification duties and cooperation obligations, and identify which third parties support each in-scope function.

Setting flags for each system

Each system in scope needs at least one flag, an objective such as compromising the confidentiality, integrity or availability of the target. Flags define what success looks like for the red team and shape the threat intelligence and test plan that follow. Write preliminary flags in the scope specification document with the security aspect each covers, and keep them proportionate to the system's role. Flags set too broadly make the test harder to supervise safely, while flags set too narrowly leave important weaknesses untested.

Recording jurisdictions where systems operate

The scope specification document must state the jurisdictions where each in-scope function and its supporting systems are used. This matters because systems hosted, administered or accessed across borders can bring additional legal and contractual constraints into the test. Confirm with legal counsel which local rules apply before the document is approved by the management body, and check that third-party providers operating in those jurisdictions are covered by your testing rights.

How flags turn each system into a testable objective

Every system listed in the scope specification document needs at least one flag, which is the objective the red team tries to reach. A flag is written as a security outcome against that system, such as compromising its confidentiality, integrity or availability. The scope specification document records a preliminary flag for each system together with the security aspect it covers, so the entity can see which property of each underpinning system is being tested. A system without a flag gives the red team nothing to aim at, so the entity should check that every system behind every in-scope function has at least one flag before the document goes to the test manager.

Flags should be phrased so that the control team can verify later whether the attempt was made, how far it got and what evidence was produced. For example, a flag that says a payment settlement database must not be altered without detection is easier to check than a general goal to get into the core banking estate. Verifiable wording lets the control team record what was attempted, match it against the blue team's logs and avoid arguments about success after the fact. Confirm with your test manager how flags will be recorded and what evidence will count, since the framework gives the structure but the working detail is agreed during scoping.

The entity's wider ICT estate may also be used as an entry or pivot point to reach the systems behind a flag, so a flag on a well-protected system can be approached through a less obvious one. Review your inventory for systems that connect to in-scope functions, including identity services, management networks and systems run by ICT third-party providers, and decide which of them the team may use as a starting point. Where a supplier hosts part of the infrastructure, check that your contracts allow testing on that infrastructure, as the framework recommends. Treat the flag list and the pivot boundaries as one decision, and record the reasoning in the document.

How the TIBER Cyber Team and test manager validate the scope

This table sets out what the TIBER Cyber Team and test manager check in the scope specification document, the evidence they expect for each check, and the gaps that most often delay validation. Read it as a pre-submission checklist: each row is a question the validator will ask, and a weak answer in any row is likely to come back as a request for more information.

Validation check	Evidence requested	Common findings
Completeness of the function list against the DORA definition	Each function mapped to the DORA Article 3(22) definition of a critical or important function, with the reasoning behind each classification and the count of functions in scope	Functions named by business unit rather than by service, or definitions applied loosely, so the list is either too broad or misses functions with ICT dependencies
Rationale for each exclusion	A stated reason for every identified function left out of scope, linked to the entity's own function inventory	Exclusions with no rationale, or rationales that restate the exclusion without explaining why the function is not critical or important
System-to-function traceability	A map from each function to the ICT systems and services that underpin it, including supporting infrastructure such as identity, networks and databases	Systems listed without the function they support, or shared platforms that serve several functions but are recorded only once
Flag coverage per system	At least one flag for each system in scope, with the security aspect it targets (confidentiality, integrity or availability) and the preliminary flag description	Systems with no flag, flags that do not state a security objective, or flags that cannot be verified during the test
Management body approval record	Evidence that the management body approved the scope specification document, such as minutes or a signed resolution with a date	Approval by a delegated committee without a clear mandate, or approval of a draft that was later changed without re-approval
Third-party dependencies and contract clauses	For each function, the ICT third-party provider supporting it, the jurisdictions involved, and the contract terms that allow testing on the supplier's infrastructure or the plan to add them	Outsourced systems listed without the provider's name, or contracts that do not address testing rights, leaving the flags on supplier-hosted systems unreachable
Timing against the six-month deadline	Dates of the written notification, the scoping meeting and delivery of the document to the test manager, all within six months of notification	Late delivery caused by unresolved scope disputes, or a scoping meeting held after the deadline without documented agreement to extend

Sequence for producing the scope specification document

The sequence turns a long list of business services into a short, justified set of critical or important functions, each tied to named systems, providers, jurisdictions and flags. The result is a scope specification document that the management body can approve and the TIBER authority can validate.

Inventory candidate functions
The entity's risk, business continuity and ICT teams list the business services and processes that could be critical or important under DORA Article 3(22), with the business owner for each. The working list is complete when every candidate has a named owner and a short statement of why it might matter. Expect a long list at this stage, since narrowing happens in the next step.
Select and justify functions
The entity narrows the inventory to the functions it will test, keeping within the framework's rule of thumb of a maximum of 10 critical or important functions per tested entity. Each selected function gets a written reason for inclusion, and each function left out gets a stated rationale for the scope specification document. The step closes when the management body can see both lists and the reasons behind them.
Map supporting systems and providers
For each selected function, the ICT and procurement teams record the systems and services that underpin it, including the applications, networks, identity services and data stores. They also note whether each system is supported by an ICT third-party provider and which one. The output is a dependency map per function, and the step is done when contracts for outsourced parts have been checked for testing rights.
Record jurisdictions and preliminary flags
The team records the jurisdictions where each supporting system is used, since locations affect legal and data handling questions for testing. For every system in scope, it writes at least one preliminary flag, an objective such as compromising confidentiality, integrity or availability, and the security aspect each flag covers. The step is complete when every system has at least one flag and every flag traces back to a function.
Define flags per system
The team reviews the preliminary flags with the control team and checks that each system in scope has at least one flag that a red team could realistically aim for during a live-production test. It also confirms that the entity's ICT infrastructure can be used as an entry or pivot point to reach the systems behind each function. The output is a refined flag list that the control team has reviewed, and the step closes when no system is left without a flag.
Write the scope specification document
The entity assembles the selected functions, rationales, supporting systems, provider details, jurisdictions, flags and exclusion rationales into the scope specification document. Owners of each section check their entries against the source inventories. The document is ready for approval when every function and system traces to a rationale and a flag, and no section is left blank.
Obtain management body approval
The management body reviews the scope specification document and approves it formally, with the approval recorded in the minutes or an equivalent decision record. The approval must be in place before the document goes to the authority. The step closes when the signed or minuted approval is filed with the document version that was approved.
Deliver to the test manager before the scoping meeting
The entity sends the approved scope specification document to the test manager at the TIBER authority, within the six-month window that runs from the written notification. The scoping meeting takes place no later than six months after notification, and the document is validated by the authority before testing moves forward. The step is complete when the authority has acknowledged receipt and validation is recorded.

Evidence that makes the scope defensible

A scope specification document is only as defensible as the records behind it. The cards below cover the artifacts a test manager and the authority will check, and the ones that show the entity can keep its scope accurate until the next test. Each item should trace back to the same critical or important functions and flags.

Completed scope specification document

This is the core deliverable, due to the test manager within six months of the written notification and approved by the management body before validation by the TIBER authority. Check that every function in scope states its reason for inclusion, supporting ICT systems, any ICT third-party provider, the jurisdictions where it runs, and its preliminary flags. Confirm the version approved by the management body is the one submitted.

Function register with rationale

Keep a register listing every identified critical or important function, marking which are in scope and which are not. Any function left out needs a written rationale in the scope specification document, so the register should be the source for that explanation. Ask whether the function definition follows the DORA Article 3(22) definition the framework uses, and whether the number in scope stays within the framework's rule of thumb of a maximum of 10 functions.

System inventory tied to functions

Each in-scope function needs its underpinning systems and services listed, and each system should link back to the function it supports. A hardware and software inventory from a tool such as GLPI, or endpoint data from Wazuh Syscollector covering installed software, open ports and services, can show that the list reflects the environment. Reconcile the export against the function register, since systems that appear in one and not the other are a common gap.

Flag register

Record every flag with its target system, the security aspect it tests (confidentiality, integrity or availability), and the function it serves. Each system in scope needs at least one flag. Note where the entity's wider ICT infrastructure may serve as an entry or pivot point, since the test manager will want to see that those paths were considered and not overlooked.

Management body minutes or resolution

The scope specification document must be approved by the management body, so retain the signed resolution or the minutes that record the approval, including the date and the version approved. Confirm that the resolution names the scope version, not a draft. Assessors commonly ask whether the people who approved the scope had the information to judge it, so keep the briefing material presented to them.

Third-party inventory and contract clauses

Where parts of the ICT infrastructure are outsourced, list each provider supporting an in-scope function and the contract under which it is supported. The framework recommends that contracts allow testing on the supplier's infrastructure, or that such clauses are added to future contracts. Check each contract for a testing clause, and record any gap as a risk to raise with the provider before the test begins.

Scoping meeting record

Keep the agenda, attendee list, decisions and action items from the scoping meeting, which must take place no later than six months after notification. The record should show which functions and flags were discussed, what the test manager challenged, and how each point was resolved. Attach it to the scope version it informed so an assessor can follow the path from discussion to final document.

Keeping the inventory current

The next test is normally about three years away, so the inventory will drift unless someone owns it. Assign an owner for the function register and system inventory, set a recurring review that also follows major changes such as new providers or retired systems, and log each change with a date. Ask the team to confirm before each cycle that the register still matches production, because an outdated scope is harder to defend than a missing one.

What scoping costs in staff time, inventory work and advisory fees

This table lists the cost components of building a TIBER-EU scope specification document, who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to ask for quotes that separate internal effort from external support, and to see where the largest savings usually come from.

Cost component	Who carries the cost	One-time or recurring	What drives it and how to keep it down
Internal scoping staff time	Tested entity: business owners, ICT architects, security and risk staff	One-time for the first test, then recurring at each test cycle	Number of critical or important functions in scope. Keep the list to the functions that truly matter and document the rationale for each exclusion early.
Inventory and CMDB cleanup	Tested entity: IT operations and asset management teams	One-time cleanup, recurring upkeep	System sprawl and stale records. Use existing asset and inventory tools as the starting point and reconcile them against the function-to-system mapping before scoping meetings.
Management body preparation	Tested entity: board or management body, with staff preparing papers	One-time per approval cycle	Clarity of the document. A concise scope specification with clear rationale makes approval faster and reduces rework.
External advisory or scoping support	Tested entity pays an advisor or implementation partner under a written scope	One-time for the scoping phase	Depth of the in-house team and the number of functions. Ask for a fixed scope, named deliverables and the exact documents the partner will prepare.
Contract review for supplier testing clauses	Tested entity: legal, procurement and third-party risk teams	One-time per contract, recurring at renewals	Number of outsourced systems and ICT third-party providers. The framework recommends checking whether contracts allow testing on supplier infrastructure, so review the contracts with the most critical services first.
Supplier coordination	Tested entity: third-party risk and service owners	Recurring during scoping and any later change	Number of jurisdictions and providers involved. Build a single register of providers and their locations before outreach starts.
Tooling for inventory and flag mapping	Tested entity pays licences or hosting, or uses existing platforms	Recurring licences or hosting, one-time configuration	Whether existing tools already hold accurate inventory data. Confirm licence terms and deployment model with the vendor before buying anything new.
Updates after scope changes	Tested entity and any advisor engaged for the change	Recurring when systems or functions change	Pace of change in the environment. Assign an owner to update the scope record whenever a system is added, retired or moved.

Who owns scope, who prepares the inventory, and who validates it

The tested entity owns the scope. Its management body must approve the scope specification document, and the entity answers for the choice of critical or important functions, the reasons for including or excluding each one, and the flags that will be captured. No outside party can make those decisions on its behalf. The entity's risk, operations and business owners are the people who know which services would cause real harm if disrupted, so they should drive the function selection, with the security team challenging it.

Function selection: The entity decides which critical or important functions to test, using the DORA Article 3(22) definition, and records a stated rationale for any identified function left out of scope.
Management body approval: Senior management formally approves the document before it goes to the test manager, so the approval record should be kept with the scope file.
Flag ownership: The entity sets the objectives for each system, such as compromising confidentiality, integrity or availability, and confirms that each system in scope has at least one flag.
Third-party dependencies: The entity records which ICT third-party providers support each system and whether its contracts allow testing on the supplier's infrastructure.

Before the scoping meeting, confirm that your management body has a named approver and a date for sign-off.

Where scoping usually goes wrong

Most scoping problems surface late, when the test manager or the validating authority reads the scope specification document. The gaps below share one root cause: the document describes what the entity believes it runs, not what the production environment actually contains and what can be tested.

Incomplete function list

Critical or important functions are often identified from org charts rather than from the DORA Article 3(22) definition, so a payment, settlement or customer-facing service is missing. Re-run the identification with business owners and ICT risk staff, and record the reasoning for each function. As a rule of thumb, the framework considers up to 10 critical or important functions per tested entity adequate, so the list should be specific rather than padded.

Systems missing from the inventory

A function is only as testable as the systems behind it. Shadow servers, legacy middleware and cloud workloads that no one registered will not appear in the scope specification document, and they may become the path an attacker uses to pivot. Reconcile the function map against a maintained asset register and an endpoint inventory, such as GLPI assets or Wazuh system inventory data, before the document is drafted.

Flags that cannot be tested

A flag such as "full compromise of the core banking platform" gives the red team no measurable objective and gives the control team no clear stop condition. Each system in scope needs at least one flag tied to confidentiality, integrity or availability, written so the red team can attempt it and the control team can judge whether it was reached. Draft flags with the threat intelligence provider in mind, and check each one against the production safeguards it must respect.

Exclusions without rationale

Teams sometimes leave out a function to protect a deadline or an outage window, or because an owner objects. The framework requires a stated rationale for any identified function left out of scope, and validators will ask for it. Keep a dated exclusion log that names the decision maker and the reason, and revisit each exclusion before the document goes to the management body.

Supplier infrastructure without testing rights

Where part of the ICT infrastructure is run by a third party, the entity may not hold the contractual right to let testers reach it. Review each ICT service contract for clauses that allow testing on the supplier's infrastructure, and confirm the supplier's position in writing. Where existing contracts are silent, plan an amendment or add the clause at the next renewal, and record the third-party provider for each function in the document.

Late management body approval

The scope specification document needs approval from the entity's management body before the authority validates it, and the document is due to the test manager within six months of written notification. Schedule the management body meeting backward from that deadline, and send a near-final draft ahead of it so board members can challenge scope early. A document approved after the deadline puts the whole test timeline at risk.

Scoping questions buyers ask before hiring help

How long does TIBER-EU scoping take before the six-month deadline?

Scoping has a hard outer limit: the scope specification document must reach the test manager within six months of the authority's written notification, and the scoping meeting must take place no later than six months after notification. The duration depends on how quickly the entity can agree its critical or important functions, map the systems behind each one and set flags with the control team and management body. The main drivers are how well the ICT asset inventory is maintained, how many functions are proposed, how many third-party providers sit behind them, and how many approval rounds the management body and the authority require. Ask any partner for a written timeline that works back from the notification date and shows when the management body must approve the document.

Can an implementation partner write the scope specification document for us?

A partner can prepare the working material, but the entity owns the scope. The scope specification document is the entity's own submission, approved by its management body and validated by the TIBER authority, so accountability for the choices stays with the entity. A partner can help by collecting inventory data, drafting the function-to-system mapping, proposing preliminary flags and organizing evidence for each function, including the reason for inclusion, supporting ICT systems, third-party providers and jurisdictions. Ask the partner which parts it drafts, which parts your staff must confirm, and who signs off on each section before the management body sees it.

How many critical or important functions should a TIBER-EU test include?

The framework's rule of thumb considers a maximum of 10 critical or important functions per tested entity adequate. Fewer functions usually mean a tighter test, a shorter scoping exercise and less coordination across the control team and the red team. Any identified function left out of scope must still carry a stated rationale in the scope specification document, so the authority can see that the exclusion was a deliberate decision. Buyers should be wary of proposals that try to cover every business line at once, because more functions increase the number of systems, flags and third parties that the control team must manage during live testing.

What information must our team supply for the scope document?

Your team must supply the substance of the document, which a partner cannot invent. For each function in scope, the document requires the reason for inclusion, the supporting ICT systems and services, whether and by which ICT third-party provider they are supported, the jurisdictions where they are used, and preliminary flags with the security aspect each one covers. Each system needs at least one flag, such as compromising its confidentiality, integrity or availability. Inventory tools can speed up collection. For example, an illustrative asset inventory in GLPI or a Wazuh Syscollector export can show hardware, installed software, open ports and services per endpoint, which helps staff confirm what actually exists before they map it to functions.

Do our ICT supplier contracts need to allow testing on their infrastructure?

The framework recommends that the entity ensure its ICT service contracts allow testing on the supplier's infrastructure where part of the ICT estate is outsourced. If existing contracts do not allow it, the recommended approach is to add such clauses to future contracts. Review this early, because a supplier that has not agreed to testing terms can limit which flags and pivot paths are realistic during the test. Legal, procurement and the relevant third-party risk owners should check current agreements against the systems listed in the scope document. Ask any partner how it will handle supplier-hosted systems and whether it expects your contract team to confirm terms before the scoping meeting.

What happens if the TIBER authority rejects our scope specification?

The scope specification document must be validated by the TIBER authority, so the authority reviews it before the test moves on. The framework does not describe a fixed sequence of rejection steps in the supplied material, so confirm the revision process with your test manager at the authority and in your national or European implementation document. Practical preparation reduces the risk: a documented rationale for every excluded function, a flag for each in-scope system, clear third-party mapping and management body approval already in hand. Ask any partner how it would support revisions within the six-month window and what work it would expect your team to do if the authority requests changes.

Is scoping a fixed-price piece of work we can budget in advance?

Scoping cost depends on the written scope, which is why most implementation engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, and a quote follows from that written scope. The main cost components are internal staff time from the business, IT and risk functions, any external partner effort for inventory, mapping and document preparation, and the management body time needed for approval. Ask every provider for a quote that itemizes deliverables, the systems and functions covered, assumptions about inventory quality and what is excluded, so you can compare offers on the same basis.

How DeployOpen prepares scope and system inventory

DeployOpen works with the tested entity to turn its critical or important functions into a written scope and a system inventory that the management body can approve. We plan and document the work, deploy the self-hosted tooling that records systems and third-party dependencies, and hand over evidence that the entity owns and can maintain.

How we scope

We agree a written scope covering the functions under review, the systems behind each one and the rationale for any function left out.
We map ICT third-party dependencies for each function, including where suppliers host systems and which jurisdictions apply.
We propose preliminary flags for each in-scope system, with the security aspect each flag covers, for the entity to confirm.

How we build

We deploy self-hosted asset management, such as GLPI, inside the entity's own infrastructure to hold the function-to-system register.
We configure agents such as Wazuh Syscollector to collect hardware, software, open ports and services from in-scope endpoints.
We reconcile discovered inventory against the scope draft so gaps, shadow systems and outsourced components are visible before sign-off.

How we hand over

We deliver the scope specification document draft and inventory exports in a form the entity can review, amend and submit for approval.
We document the inventory process, owners and update cadence so the register stays accurate between test cycles.
We walk the control team and management body through the scope, its evidence and the open questions before validation by the authority.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous monitoring of the inventory are available as a retainer.
Confirm with us which steps the entity will own internally, since the organization remains responsible for its controls and its submissions.