How a TIBER-EU test starts and what the three-month clock requires
If you have received a written notification from a TIBER authority, the clock has already started. The notification states the start date of the preparation phase, which is also the start of the test, and the authority's TIBER Cyber Team assigns a test manager and at least one alternate. Your first job is to name an accountable control team lead and send the initiation documents to the test manager. Those documents must reach the test manager, and the initiation meeting must take place, no later than three months after the written notification. The same three-month limit applies under the DORA threat-led penetration testing standard, Delegated Regulation (EU) 2025/1190, so treat it as a hard contractual date rather than a target.
The initiation documents are more than paperwork. They include a project charter with a high-level plan and deadlines for the preparation, testing and closure phases and the remediation plan, the control team lead's contact details, your intended use of internal or external red team testers, the secure channels you will use to exchange data, the test code name, and any critical or important functions run in another member state or supported by ICT third-party providers. Confirm early which of your critical functions depend on cloud, hosting or software providers, because those dependencies affect who must agree to the test and which contracts must allow it. Ask the authority which format and channels it expects before you draft anything.
Three things usually make the deadline hard. The first is ownership: no single executive is clearly accountable for the test, so decisions stall between security, operations and the business. The second is third-party dependencies that nobody has mapped, so the team cannot say whether a provider's systems are in scope or who must sign off. The third is a control team that has not been formed. Once the documents are validated, the control team lead must assemble a small group with decision-making authority or specialist expertise, placed at the top of the security incident escalation chain, and the test manager must validate its composition. Name the owner, map the third-party dependencies and form the control team in the first weeks, not in the last.
Which entities, functions and third parties the initiation documents must reflect
Several decisions made before the initiation meeting change what the initiation documents must contain. Each card below covers one of them and the effect it has on the project charter, the control team details and the scope the test manager validates. Settle these early, because the three-month deadline for the documents runs from the authority's written notification, not from when the decisions are finalized.
Voluntary or mandated test
Confirm whether the test is voluntary, meaning the entity expressed interest, or mandated by its authority under DORA threat-led penetration testing. The notification that starts the clock comes from the TIBER Cyber Team in both cases, but a mandated test may bring national rules that add requirements to the documents. Ask the test manager which national implementation document applies before drafting the project charter.
Critical functions in another member state
If a critical or important function is operated from another EU member state, the initiation documents must name it. That affects which authority is involved, which jurisdiction's rules apply to the test, and who must be told about the test. Check where each function's systems run, including backup and support sites, before the initiation meeting so the project charter does not understate the test's reach.
ICT third-party providers behind the functions
Any ICT third-party provider that supports a tested function must be identified in the initiation documents. Providers hosting systems, managing networks or running monitoring may need to agree to the test in writing, and their contracts may restrict what the red team can do. Build a list of providers and contract clauses now so the control team does not discover an unapproved dependency during active testing.
Internal or external red team testers
The initiation documents must state whether the entity intends to use internal red team testers, external testers or both. Internal testers change the independence arguments the test manager will review and the evidence the control team must hold, while external testers bring procurement timelines that run in parallel. Decide this before drafting, because it shapes the later procurement and the team composition the test manager validates.
Secure channels and data transfer
The documents must describe the secure communication and data transfer channels the test will use, including how threat intelligence and test results move between parties. Choices made for cross-border functions or third-party providers can add data protection obligations and new transfer routes. Confirm which channels the control team lead can use with each party and which data may leave the entity before the documents are submitted.
Code name and need-to-know list
The test code name appears in the initiation documents, and information about the test is limited to a need-to-know basis, including within the management body. Each function, provider and cross-border party added to the scope widens the list of people who must receive the code name and test details. Record who is told what, and keep a separate progress channel for the management body so it stays informed of risks without seeing operational detail it does not need.
Steps from written notification to validated initiation documents
This sequence takes the tested entity from the authority's written notification to a set of initiation documents the test manager has validated, with a named control team ready to run the test. Each step produces a record that the authority can check before the testing phase begins.
Receive the written notification and start date
The TIBER Cyber Team sends a written notification to the entity's designated contact, either after the entity expresses voluntary interest or because it is mandated to test. The notification sets the start date of the preparation phase, which is the start of the test. The entity should confirm receipt in writing, record the date and calendar the deadline for the initiation documents. Done means the notification is filed with the date that starts the clock.
Confirm the test manager and alternate
The TIBER Cyber Team assigns a test manager at the authority and at least one alternate. The entity's contact should confirm the named individuals, their contact details and the channel used for formal correspondence with them. Where the authority's assignment is unclear, the entity should ask for it to be restated in writing. Done means the entity holds a written record of who the test manager and alternate are.
Draft the project charter and high-level plan
The entity prepares the project charter, which sets out a high-level plan with deadlines for the preparation, testing and closure phases and for the remediation plan. Owners typically include the security function, the business sponsor and whoever will run the control team. The draft should state assumptions about timing so the test manager can judge whether the schedule is realistic. Done means a charter draft exists that covers every phase and deadline the framework requires.
Name the control team lead and contact details
The entity appoints the control team lead, who then sets up a control team of a few people with decision-making capacity or relevant expertise. The team sits at the top of the security incident escalation chain. The lead's contact details go into the initiation documents. Ask the lead to confirm which people will hold decision rights during live testing, because the test manager will validate that composition. Done means the lead and the proposed members are named and recorded.
Choose the test code name and red team sourcing
The initiation documents include a test code name, which the control team should choose so it does not reveal the test to staff outside the need-to-know group. The documents also state whether the entity intends to use internal or external red team testers and whether any critical or important functions run in another member state or depend on ICT third-party providers. Done means the code name, sourcing intent and cross-border or third-party dependencies are written into the draft.
Set secure communication and data transfer channels
The entity documents the secure communication and data transfer channels it will use with the test manager, the threat intelligence provider and the red team testers. Channels should be agreed in advance, access-controlled and restricted to the need-to-know group. Where a self-hosted file sharing platform is used for test documents, access rules can limit uploads, downloads and sync by user group, IP address or file type. Done means each channel is listed with its owner and its permitted users.
Hold the initiation meeting and submit the documents
The initiation documents must reach the test manager, and the initiation meeting must take place, no later than three months after the written notification. The entity should submit the complete package early enough to leave time for questions. The meeting confirms the plan, the control team and the channels. Done means the documents and meeting are both recorded within the three-month window.
Obtain validation of the initiation documents
After receiving the documents, the test manager assesses and validates them. The entity should log every comment, answer each one in writing and update the documents where the test manager asks for changes. Once validated, the control team lead can set up the control team in full and the entity can move on to the scoping work of the preparation phase. Done means the test manager's written validation is on file, and any later change to the control team's composition is also validated.
How an authority's test manager validates initiation
This table lists what the TIBER Cyber Team's test manager checks when the entity submits its initiation documents, the evidence usually requested for each check, and the findings that most often send documents back. The authority performs this validation; the entity does not self-certify, so the documents must stand on their own when the test manager reads them.
| Check | Evidence requested | Common finding |
|---|---|---|
| Presence and completeness of initiation documents | Project charter, high-level plan, control team lead contact details, red team tester intentions, secure channels, test code name and foreign or third-party function disclosure, all delivered together | One document missing, or a charter that omits the remediation plan deadline |
| Realism of the high-level plan | Dated deadlines for preparation, testing and closure phases and the remediation plan, checked against the framework's phase timelines | Deadlines that cannot fit the sequence of testing, closure and remediation, or no dates at all |
| Control team lead contact details | Named lead with role, reachable contact points and confirmation the lead sits at the top of the security incident escalation chain | Generic mailbox only, or a lead who is not senior enough to make decisions during live testing |
| Disclosure of foreign functions and ICT third parties | List of critical or important functions run in another member state and those supported by ICT third-party providers, even if none apply, stated explicitly | Silence on the topic instead of a nil statement, or providers named without the functions they support |
| Intended use of internal or external red team testers | Statement of whether internal or external testers will be used, with the planned sourcing route | Plans left open, which later forces a change the test manager must revalidate |
| Test code name and secure channels | Code name that does not reveal the entity or the test, and described encrypted channels for communication and data transfer | Code name that identifies the institution, or channels described in general terms without tools or controls |
| Meeting timing | Initiation meeting held and documents received no later than three months after the written notification, with the date recorded | Documents or meeting landing after the three-month limit, which is a timing failure the authority will record |
Setting up and validating the control team after initiation
Once the test manager has validated the initiation documents, the control team lead assembles the control team. The group is deliberately small, made up of a few people who either hold decision-making authority or bring relevant technical expertise, and it sits at the top of the security incident escalation chain. That placement matters because the control team is the point where a live-production test can be paused, redirected or stopped, so its members need to be reachable at the moment an alert from the blue team would otherwise be escalated as a real incident. When you choose members, check that each person can make or quickly obtain a decision on risk, that backups of named people exist for out-of-hours coverage, and that the lead's contact details already listed in the initiation documents are current.
Information about the test stays on a need-to-know basis, and that rule applies inside the management body as well as outside it. Confirm which individuals will see the flags, the threat intelligence and the red team test plan, and record who receives each category of information. At the same time, the control team must keep the management body informed of the test's progress and of the risks it creates. Plan a reporting rhythm for the board or management committee that gives them enough detail to oversee the risk without exposing operational specifics to people who do not need them. Ask your authority what level of management reporting it expects before the first control team meeting.
The test manager validates the composition of the control team, and must also validate any later changes, such as a departing member or a new expert brought in mid-test. Treat every change as a formal request: name the person, state their role and authority, explain why they are needed, and wait for validation before they receive test information. Keep a dated record of the composition and each validated change, because the authority will check it during the test. Confirm with your test manager which form this record should take and how changes should be communicated to them.
Evidence that shows initiation was completed on time
Initiation is judged on dated, versioned records, not on memory of what happened in the room. The cards below cover the artifacts a test manager will ask to see and the routine that keeps each one current between tests. Organizations should confirm the exact format the TIBER Cyber Team expects before the test starts.
Signed notification letter
The authority's written notification fixes the start date of the preparation phase, so it anchors the three-month clock for the initiation documents and meeting. Store the signed original, the date it was received and the name of the designated contact who received it. Check that the start date in your calendar and project plan matches the letter exactly.
Initiation documents with version history
The project charter, control team lead details, red team sourcing intentions, secure channels, test code name and any critical or important functions run in another member state or supported by ICT third-party providers all sit in these documents. Keep a version log that records who changed each section, when, and why, so the submitted version can be traced. Review the log against the authority's submission date before sending.
Initiation meeting minutes and attendance
Minutes show that the initiation meeting took place within the deadline and record which decisions were agreed. Record attendance by name and role, including the control team lead and the test manager. Circulate the minutes quickly and file the signed or accepted version with the meeting date.
Test manager validation record
The test manager assesses and validates the initiation documents, so this record proves that validation happened after submission and before the control team was formed. Keep the validation message or form, the date, and any conditions attached. Each open condition should link to the revised document version that resolved it.
Control team roster and validation
The control team is a small group with decision-making capacity or relevant expertise, placed at the top of the security incident escalation chain. Maintain a roster with names, roles, contact details and escalation position, and keep the test manager's validation of its composition on file. Update the roster and resubmit it for validation whenever membership changes.
Need-to-know distribution list and management body briefings
Access to test information is limited to people who need it, including inside the management body, yet the control team must keep that body informed of progress and risks. Keep a distribution list that names each recipient and the reason for access, and a dated log of every management body briefing with the risks discussed. Review the list at each briefing so that access matches current need.
What notification and initiation cost in money and effort
This table lists the cost components of getting a TIBER-EU test started, who carries each one, whether it is one-time or recurring, and what pushes it up or down. Use it to build the questions you put to a quote, not as a budget. No fee figures are published for this phase, so every number should come from the written scope and the provider's own estimate.
| Cost component | Who is paid or who pays | One-time or recurring | What drives it and what to ask for |
|---|---|---|---|
| Project management for the charter and high-level plan | Internal project manager; external advisor if drafting support is bought | One-time for the initial charter, with updates when deadlines move | Number of phases and parties to coordinate. Ask the provider how many drafting iterations the quote covers and who owns version control. |
| Control team lead time | Internal staff; no external fee unless backfill is hired | Recurring through the test, starting at set-up | Team size and seniority needed for decision-making. Ask how many hours per week the lead is expected to commit and who covers absences. |
| Control team member time | Internal staff from security, operations and risk functions | Recurring through the test | Number of members and whether they sit at the top of the incident escalation chain. Ask the test manager to confirm the composition before committing staff. |
| Legal and governance review of initiation documents | Internal legal, compliance and management body time; external counsel if engaged | One-time for the initial review, plus review of later changes | Governance complexity, such as multiple approval layers and the need-to-know handling of test information. Ask whether the quote includes counsel review or only internal review. |
| Coordination for critical functions in other member states | Internal staff in each affected jurisdiction; possibly local counsel | One-time for listing, recurring if coordination continues | Number of foreign functions named in the initiation documents. Ask how each foreign function changes the scope of the drafting work. |
| Coordination with ICT third-party providers | Internal contract owners; provider time for consent or information requests | One-time for identification, recurring for ongoing contact | Number of ICT third-party providers supporting critical or important functions. Ask who contacts each provider and whether contract amendments are needed. |
| Secure communication and data transfer channels | Software licences or hosting, internal IT administration, or an external provider | Set-up is one-time; licences, hosting and administration recur | Choice between existing tools and new systems, and the classification of data exchanged. Ask whether the quote covers configuration, access control and testing of the channel. |
| External advisory support for drafting | External consultant or advisor, billed under the written scope | One-time per document set, with optional recurring support | Internal skills gaps and the number of documents to produce. Ask for a fixed-scope quote with named deliverables and a clear point where work stops. |
Where initiation usually slips and how to close each gap
Initiation is the first point where a TIBER-EU test can stall, because the documents, people and decisions it requires are all due within a short window. The gaps below recur across tests, and each one is closed by a decision or check made before the written notification arrives or before the initiation meeting is booked.
No named control team lead
The control team lead is the person who sets up the control team after validation and who must be named in the initiation documents with contact details. If nobody holds that role when the notification arrives, the entity spends its initiation window choosing a lead instead of preparing the project charter. Confirm before notification who will lead, that this person can act at short notice, and that the management body knows the role exists.
Third-party dependencies missing
The initiation documents must list any critical or important functions operated in another member state or supported by ICT third-party providers. Teams often list the core application but omit the hosting provider, managed security service or outsourced support desk that also touches those functions. Map each function to its ICT providers and their locations before drafting, and ask each provider which of its staff or systems would be in the test path.
Unrealistic high-level plan
The project charter needs a high-level plan with deadlines for the preparation, testing and closure phases and for the remediation plan. Plans that copy generic timelines fail once procurement or internal approvals take longer than expected. Build the plan backward from the phase limits, add time for management body approval and provider contracting, and have the control team check each deadline against its own calendar.
Code name chosen without confidentiality review
The test code name appears in the initiation documents and in routine communications, so a name that hints at the entity, its systems or the planned attack scenarios can leak information. Choose a neutral name, have the confidentiality owner review it, and confirm that the name is used in all written channels, including ticketing systems and email subject lines, so that only need-to-know staff can connect it to the test.
Control team too large or without decision rights
The control team should be a few people with decision-making capacity or relevant expertise, placed at the top of the security incident escalation chain. Large teams slow decisions and widen the circle of people who know about the test, while teams without authority cannot halt activity or approve risk actions. Name a small group, document who can stop the test, and send the composition to the test manager for validation before any later changes.
Meeting held after the three-month limit
The initiation documents must reach the test manager, and the initiation meeting must take place, no later than three months after the written notification. Entities often treat this as a soft target and let documents drift while internal reviews run. Record the notification date when it arrives, set the document submission date and meeting date at the start, and escalate any internal dependency that threatens them.
Questions buyers ask about starting a TIBER-EU test
What does the three-month initiation deadline count from?
The deadline counts from the date of the authority's written notification, not from the date your organization agrees to test or signs a contract. The notification is sent to your designated contact and states the start date of the preparation phase, which is also the start of the test. Within that window, the initiation documents must reach the test manager and the initiation meeting must take place. DORA's TLPT standard sets the same three-month timing in Delegated Regulation (EU) 2025/1190, so treat the date on the notification as the date your clock starts. Confirm the exact dates with your authority as soon as the letter arrives.
Can our own staff draft the initiation documents?
Yes. The initiation documents are your organization's submission, so your staff should own them and sign off on their content. They cover a project charter with a high-level plan and deadlines for the preparation, testing and closure phases and the remediation plan, the control team lead's contact details, the intended use of internal or external red team testers, secure communication and data transfer channels, the test code name, and any critical or important functions run in another member state or supported by ICT third-party providers. Staff who already know the business services, third-party dependencies and escalation chain can usually draft these faster. An outside partner can help with structure and cross-checking against the ECB guidance on initiation documents, but the content must reflect your real arrangements.
How much work does initiation take, and what do we need from staff?
The workload depends on how many critical or important functions are in play, how many third parties support them, and how many people sit on the control team. Drivers include whether you already maintain a current register of ICT services and their providers, how clearly your escalation chain is documented, and how quickly legal and procurement can confirm contract details. You will need a named control team lead who can make decisions, legal and procurement input on third-party arrangements, and someone who knows where critical systems run across borders. Ask any partner to show a written list of tasks, owners and dates tied to the three-month deadline before work starts.
Can an implementation partner prepare the initiation documents but not validate them?
Yes. A partner can help prepare the documents, check them against the framework and organize the evidence, but validation belongs to the test manager at the authority. The test manager assesses the documents after they are submitted and decides whether they are acceptable. Your partner therefore prepares material and supports the initiation meeting, while the TIBER Cyber Team and test manager carry out the validation. Ask your partner to state this split in writing in the engagement scope so that nobody assumes the partner's review replaces the authority's.
Who is allowed to see information about the test?
Information is shared on a need-to-know basis, and that includes inside the management body. Only people whose role needs the detail should receive it, such as the control team, the test manager and the people who must act on it. The control team still has to keep the management body informed of progress and risks, so you need a way to report at a suitable level of detail without spreading operational information. Set up secure communication and data transfer channels during initiation and agree the list of recipients in writing. Any partner or outside tester who needs access should be named in the documents.
What can an implementation partner sign, and what must your organization sign?
Your organization signs the initiation documents and any commitments made on its behalf, including the control team composition and the decisions the management body approves. A partner can sign its own contract, confidentiality terms and statements about the work it performed, but it cannot sign for your organization or act as the authority's validator. The attestation at the end of the test is issued by the appropriate parties under the framework, and an independent auditor or certification body issues assurance reports or certificates for compliance assessments, not an implementation partner. Check every signature block against your delegation of authority before anyone signs.
Where to read the framework and DORA text on initiation
The initiation rules in this topic come from two primary texts, and you should read both before you prepare the initiation documents. The first is the *TIBER-EU Framework* dated January 2025, which sets out the initiation documents, the test manager's validation role and the control team set-up. The second is Commission Delegated Regulation (EU) 2025/1190, the DORA technical standard on threat-led penetration testing, whose Article 9(2) requires TLPT initiation information within three months of the authority's written notification. The framework and the delegated regulation set the same timing, so a single deadline calendar can serve both. Start with the TIBER-EU Framework (January 2025) and read the initiation section alongside the EUR-Lex text of the delegated regulation.
Read the national implementation document for your jurisdiction before you treat the European text as complete. Adopting authorities publish a national or European implementation document that must carry the framework's mandatory requirements, and they may add local rules or adapt optional requirements. Confirm with your TIBER Cyber Team or test manager whether your authority has published additional requirements on the initiation documents, the format of the notification, the named contacts or the secure channels for data transfer. Ask for these in writing at the first contact, because a local rule that differs from the European text will change what you submit. The ECB's TIBER-EU page lists the adopting jurisdictions and is the place to confirm which document applies to you.
Assign an owner to the source review itself. The person who maintains the initiation calendar should record the document version used, the date it was read and any national additions, and should flag any conflict with the European text to the authority early. A short written note of the timing rules, the list of initiation contents and the contacts you have confirmed gives the management body and the control team a shared reference. This record also shows an assessor that the entity planned against the governing text rather than from memory.
How DeployOpen prepares initiation evidence
DeployOpen helps the tested entity prepare the initiation documents and the control team set-up that the test manager validates before testing can move forward. The entity owns the decisions and the documents, and DeployOpen prepares the supporting systems, records and evidence under a written, fixed scope.
How we scope
- We agree the written scope for initiation work, including which documents and records DeployOpen will prepare.
- We confirm the three-month deadline from the authority's written notification and map the dates into the project charter.
- We list critical or important functions operated in other member states or supported by ICT third-party providers, so none are missed.
How we build
- We set up secure communication and data transfer channels inside the client's own infrastructure for control team use.
- We configure access controls so initiation material is shared only on a need-to-know basis with named individuals.
- We draft the project charter, control team lead contact details and test code name for the entity to review and approve.
How we hand over
- We deliver the initiation documents as an organized package ready for the test manager's assessment and validation.
- We document the control team composition, including roles, decision authority and escalation position for validation.
- We record each document's owner, version and approval status so later changes can be tracked against the validated set.
How we support
- We support the control team lead through the validation feedback loop until the test manager accepts the documents.
- Ongoing support, upgrades and continuous testing are available as a retainer if the entity wants help into the testing phase.
- We confirm with the entity which points of its own governance, such as management body reporting, remain its responsibility.
