What the TIBER-IT guide asks of Italian entities and who it applies to
Banca d'Italia, CONSOB and IVASS jointly issue the TIBER-IT National Guide, and version 2.0 (November 2025, published 11 December 2025) is the reference for both mandatory DORA threat-led penetration testing (TLPT) and voluntary tests. An Italian financial entity facing a DORA TLPT request or weighing a voluntary test should first establish which of three situations applies to it, because the obligations and the route into the test differ. The guide is aimed mainly at financial entities in scope of DORA as implemented in Italy by Legislative Decree 23/2025. It also covers ICT service providers where they are included in a test scope, and threat intelligence and red teaming providers that take part in a test.
The first question is whether the entity is in mandatory scope. Banca d'Italia's TIBER-IT page explains that DORA requires certain financial entities, identified by the authorities based on their importance, to carry out TLPT regularly, with the details set by Commission Delegated Regulation (EU) 2025/1190 of 13 February 2025. A second question is whether an ICT provider is included in the scope of a tested entity, which changes who must be named in scope documents and contracts. The third is whether the entity is a voluntary participant. Other financial entities or organisations in Italy can run voluntary TLPT by notifying the single contact point at tiber-it@bancaditalia.it, and the authorities strongly encourage voluntary testing for entities not subject to mandatory requirements. Confirm your status with the authorities before committing budget, since the notification route depends on it.
DeployOpen prepares systems, controls and evidence for a TIBER-IT test. It does not run the threat intelligence, red team or control team roles, and it does not issue the attestation or any certification of the test. Those decisions sit with the authorities and the tested entity, and the entity remains accountable for its controls and for the choice of providers. Use the scope discussion as the point where your internal team, your providers and the authorities agree who owns each flag and each system.
Who must test, who may test voluntarily, and who else is covered
TIBER-IT covers four groups with different obligations: entities that DORA requires to run threat-led penetration testing, entities that may test voluntarily, ICT service providers that fall inside a test scope, and the providers who deliver threat intelligence and red teaming. Each card below sets out what the group owes or can do, and what to confirm before a test starts.
DORA-mandated financial entities
Financial entities that DORA requires to run threat-led penetration testing are identified by the authorities based on their importance, and Legislative Decree 23/2025 implements DORA in Italy. The details of the mandatory tests are set by Commission Delegated Regulation (EU) 2025/1190 of 13 February 2025. Check with the authority whether your entity has been identified, and which version of the TIBER-IT guide applies to your test.
Voluntary tests by other entities
Other financial entities or organisations in Italy can run voluntary threat-led tests under TIBER-IT. They do this by notifying the single contact point, tiber-it@bancaditalia.it, before starting. Authorities strongly encourage voluntary testing for entities not subject to mandatory requirements. Confirm with the contact point that your intended scope and timing fit the guide before committing budget.
ICT service providers in scope
The guide also covers ICT service providers where they are included in the test scope. Your outsourced platforms, hosting or managed services may therefore be tested as part of your entity's exercise. Agree in writing which provider systems are in scope, who authorizes testing on them, and how their participation is recorded in the scope specification.
Threat intelligence and red teaming providers
Threat intelligence and red teaming providers are also covered by the TIBER-IT guide. They take on the threat intelligence and red team roles in a test, so their qualifications and contracts matter as much as the entity's own. Ask each provider how it will work with the control team and the authority, how it handles test data, and how it will document its testing.
Scope limits for each group
Entities should not assume that a voluntary test carries the same status as a mandatory DORA threat-led test. Whether a test meets DORA's requirements depends on whether the entity is in the mandated group and on the authority's confirmation. Ask the single contact point in writing which obligation a planned test satisfies, and record the answer in the initiation documents.
How a TIBER-IT test runs from notification to attestation
The sequence moves a TIBER-IT test from the authority's written notification through preparation, threat-led testing and closure, and ends with an attestation that shows the test was run to the framework. Each phase hands a defined output to the next, so the entity can track progress against the TIBER-EU structure and the Italian guide.
Notify the authority and initiate the test
The test begins with the authority's written notification to the entity, which starts the preparation phase. The entity then appoints its control team and sets up risk management for the test, with the TIBER-IT team at Banca d'Italia, CONSOB or IVASS guiding the initiation. The step closes when the initiation documents are agreed and the control team is in place. Confirm in the TIBER-IT guide who the authority's notification must come from and which documents initiation requires.
Scope critical functions and flags
The entity identifies the critical or important functions to be covered and the flags, the targets the red team will try to reach. The control team records this in the scope specification document, which the authority reviews. The output is an approved scope that defines what the red team may test and what is excluded. Confirm with the authority how Italian scope rules apply to ICT service providers included in the test.
Procure the threat intelligence and red team providers
The entity procures a threat intelligence provider and red team testers that meet the framework's requirements, using the service provider procurement guidance published with TIBER-EU. Providers must be independent of the entity and must be contracted before testing starts. The step closes with signed contracts and a confirmed team that the authority accepts. Ask the authority which provider criteria the TIBER-IT guide adds.
Produce the targeted threat intelligence report
The threat intelligence provider builds a targeted threat intelligence report on threat actors relevant to the entity, and the team selects the attack scenarios the red team will use. The report is reviewed by the control team and the test manager. The output is the targeted threat intelligence report and an agreed set of scenarios that the red team plan will follow. Confirm with the authority any Italian-specific content it expects in this report.
Run the red team test under supervision
The red team writes its test plan, which the control team and test manager review before any attack begins. The red team then tests the flags for at least 12 weeks while the control team and test manager supervise the work. The blue team at the entity works to detect and respond without prior knowledge of the scenarios. The step closes when active testing ends and the red team has covered the agreed flags.
Issue the red and blue team reports
After active testing, the red team issues its test report describing the attacks, the flags reached and the findings. The blue team issues its own report on what it detected, how it responded and where its controls failed. These two reports are the core evidence of the test. Confirm with the authority which report templates and review cycles apply under the Italian guide.
Hold replay, purple teaming and 360 degree feedback
Within 10 weeks of the end of active testing, the red and blue teams replay the attacks together and run purple teaming to test detection and response improvements. The 360 degree feedback gathers input from the parties involved to inform the lessons learned. The output is a set of documented findings and agreed improvements tied to the test results. Confirm the timing and format of these activities in the TIBER-IT guide.
Deliver the summary, remediation plan and attestation
The test manager and the control team prepare the test summary report, which the authority assesses. The entity then delivers its remediation plan within 8 weeks of the authority's assessment. The attestation confirms that the test was carried out under the framework and closes the test. The result shows strengths and weaknesses rather than a pass or fail, so the remediation plan is the working output for the entity. Confirm with the authority how the attestation is issued in Italy.
Who does what in a TIBER-IT test: authority, tested entity and providers
Banca d'Italia, CONSOB and IVASS jointly adopted the TIBER-IT National Guide and run the programme together. Banca d'Italia publishes the guide and hosts the single contact point, so it is the first address for voluntary and mandatory notifications. Under the TIBER-EU model, the authority side includes a TIBER Cyber Team and a test manager who supervise each test from notification to closure.
- Banca d'Italia: publishes the guide, operates the single contact point and receives notifications for tests in Italy.
- CONSOB: co-signed the joint communications of July 2022 and December 2025. Confirm which entities it oversees under the guide.
- IVASS: co-signed the same joint guidance. Confirm its role for insurance undertakings in scope.
- Test manager: supervises the test, reviews the scoping and threat intelligence outputs, and approves progression between phases.
- Attestation: the authority reviews the closure documents and confirms that the test is complete. No other party can confirm completion.
Before notifying, ask the single contact point which authority supervises your entity and who will act as test manager.
The tested entity owns the test, its scope and its outcome. Its control team manages the test's risk and confidentiality during the preparation phase and acts as the link to the authority. Its blue team defends the systems under test, detects and responds to the red team, and writes the blue team test report. The framework's 2025 update renamed the White Team the Control Team, and the entity's management remains accountable for the remediation plan.
- Control team: set up in preparation, it manages risk, controls who knows about the test, and coordinates with the TIBER Cyber Team.
- Blue team: operates the live defenses without advance knowledge of the red team scenarios and documents its detection and response.
- Management body: approves the scope, accepts residual risk decisions and signs off the remediation plan.
- Purple teaming: mandatory under the 2025 framework, so both teams review attack paths together in the closure phase.
- Evidence: keep logs, detection records, alert histories and change records for the systems in scope.
Confirm internally who will hold the control team role, since the authority will expect those names in the early notification and scoping steps.
The threat intelligence provider produces the targeted threat intelligence report that describes the threat actors and attack methods most relevant to the entity. Its findings drive the scenario selection that the red team then tests. The entity procures this provider during the preparation phase, following the framework's guidance on service provider procurement, and the provider works under the control team's supervision.
- Targeted threat intelligence report: identifies relevant threat actors, their likely objectives and the techniques they use against comparable entities.
- Scenario selection: the scenarios chosen from the report are agreed with the control team and the authority before testing starts.
- Procurement: the entity contracts the provider through its own procurement process and must keep the contract within the TIBER requirements.
- Information handling: the provider receives only the information it needs and works under confidentiality terms agreed in advance.
- Output to the red team: the report feeds the red team test plan, so its quality shapes the whole test.
Ask potential providers for the structure of a sample report and confirm with the authority that the Italian process accepts the provider's qualifications.
The red team testers attempt to reach the flags defined in the scope using the scenarios from the threat intelligence report. They write the red team test plan before active testing and the red team test report afterwards. Active testing runs for at least 12 weeks under the supervision of the control team and the test manager, and the entity must keep the testers' activity within the agreed rules of engagement.
- Red team test plan: sets out the attack paths, tools, timing and safeguards, and is reviewed before testing begins.
- Active testing: at least 12 weeks against the flags, with the control team able to pause activity if it creates unacceptable risk.
- Red team test report: records the attack paths, what succeeded, what was detected and where the testers were stopped.
- Replay: during closure, the red and blue teams walk through key steps together so the blue team can see what it missed.
- Qualifications and contract: confirm the testers' skills, insurance and confidentiality obligations in writing before work starts.
Check with the authority which provider qualifications it requires before you sign a contract, because the requirements can vary by jurisdiction.
An implementation partner such as DeployOpen prepares the systems, controls and evidence that the entity needs for a test. It works in the entity's own infrastructure to harden the platforms in scope, improve logging and monitoring, and organize the records the blue team and the attestation file will rely on. It does not issue reports, attestations or certificates. Those come from the authority or from the entity's own process, and the partner's role should be set out in a written, fixed scope before work starts.
- Preparation of systems: hardening, access controls, logging and monitoring on the platforms the test will reach.
- Evidence organization: configuration baselines, runbooks and log retention records that the blue team and the test manager can review.
- Remediation support: helps design and track fixes after the test summary report, under the entity's remediation plan.
- No issuance: the partner does not issue the test summary report, the attestation or any certificate.
- Independence check: confirm with the authority whether a firm that prepared your systems may also take part in testing them.
Ensure the written scope states clearly which deliverables belong to the entity, to the providers and to the partner.
When to contact the single point of contact at Banca d'Italia
An entity that wants a voluntary threat-led penetration test under TIBER-IT should notify the single contact point at Banca d'Italia before starting any procurement. The contact address is tiber-it@bancaditalia.it. Other financial entities or organisations in Italy that are not subject to mandatory requirements use the same route, and the TIBER-IT guide strongly encourages voluntary testing for them. Treat this notification as the first step in the programme, not a formality that follows the choice of a threat intelligence or red team provider.
Before you write to the contact point, assemble a short internal briefing that describes the entity, the functions you would like tested, and the systems and third parties that sit behind them. Include your legal form, your place in the group structure, and whether any ICT service providers would fall inside the proposed scope. Your legal or compliance team should also confirm whether the test is voluntary or part of a mandatory DORA TLPT obligation, because the answer changes who sets the requirements. The guidance does not fix a template for this first contact, so confirm with the contact point what format and level of detail it expects.
Check the Banca d'Italia TIBER-IT page for current instructions before you send anything, since the procedure for notification may be updated alongside the version 2.0 guide. Ask the contact point to confirm the next steps, the documents the authority will expect at initiation, and whether the authority will expect you to run the early phases in a particular order. Plan internal time for this exchange, and avoid signing a provider contract until the authority has confirmed how your test will proceed.
What an Italian entity should have in place before notifying
Preparation under TIBER-IT starts with a written notification to the single contact point, and the preparation phase can run up to six months from that notice. The cards below cover the internal decisions and records an entity should settle first, since weak answers on any of them are the usual reason preparation runs long.
Board-level sponsorship
Confirm that a member of the management body has formally approved the decision to test and accepts that the test will expose weaknesses in production-like systems. Check that the sponsor can resolve disputes about scope, timing and risk to live services without waiting for a committee cycle. Record the approval in minutes, because the authority and the threat intelligence and red team providers will ask who stands behind the decision.
A named control team
Appoint a control team that includes risk, IT security and business representatives, and name one person who manages it day to day. The control team supervises the red team, approves the risk management measures and holds the knowledge needed to stop an exercise safely. Check that each member has a deputy and that the team has clear authority to halt testing, since the framework relies on this group for control throughout the test.
Inventory of critical functions and ICT dependencies
Maintain a current list of critical or important functions, the systems that support them, and the ICT third-party providers they depend on. Scoping decisions and the flags the red team targets are drawn from this inventory, so gaps here delay scope agreement. Check whether hosted services, outsourced operations and cloud components are mapped, and whether the provider contracts allow the testing you plan.
Penetration testing and remediation history
Assemble the reports, findings and closure evidence from recent penetration tests, vulnerability assessments and audits. Authorities and providers use this record to avoid duplicating work and to judge whether known weaknesses have been fixed or accepted. Check that open findings have owners, due dates and documented risk acceptance, because an unresolved backlog tends to shape the scenarios that the test then has to examine.
Provider procurement plan
Plan how the threat intelligence provider and the red team testers will be selected and contracted, and confirm that the candidates meet the rules for external testers, which bar the entity's own staff from acting as red team testers. Check the lead time for the procurement process, the conflict of interest checks, and the confidentiality and liability terms the provider will require. Ask the authority for the current guidance on service provider procurement before drafting the plan.
Named budget owner
Identify the person who approves spending on the test, including the provider fees, internal staff time, remediation work and any follow-up retesting. Costs fall into one-time items such as procurement and the test itself, and recurring items such as remediation and the next cycle. Check that the budget owner has signed off a rough envelope before notification, and ask providers to quote against a written scope so the figures can be compared.
What a TIBER-IT test costs and who gets paid for each part
This table lists each cost component of a TIBER-IT test, who is paid for it, whether it is one-time or recurring, and what pushes it up or down. Use it to build a request for quote and to see where the authority's role ends and procurement begins. No amounts are stated, so confirm every fee and provider price in writing before procurement starts.
| Cost component | Who is paid | One-time or recurring | What drives it |
|---|---|---|---|
| Internal control team and staff time | The entity's own staff (no external payment unless backfilled) | Mostly one-time per test, with ongoing preparation between tests | Number of critical functions in scope, maturity of logging and evidence, and how many staff sit in the control team and blue team |
| Threat intelligence provider | External provider procured by the entity | One-time per test cycle | Depth of the targeted threat intelligence report, number of scenarios, and provider sector experience |
| Red team testers | External testers procured by the entity | One-time per test cycle | Number and complexity of flags, length of active testing, and whether replay and purple teaming are included |
| Implementation partner for systems and evidence | Partner engaged by the entity under a written scope | One-time for preparation, with optional retainers afterward | State of logging, asset inventory and documentation, and the number of systems to be prepared |
| Authority supervision and any authority fee | Authority (Banca d'Italia, CONSOB or IVASS) if a fee applies to the entity | Confirm whether recurring or per test with the authority | Whether the test is voluntary or mandatory DORA TLPT, and the authority's published fee terms in force at the time |
| Remediation work after the test | Internal teams, and any external vendors the entity engages | One-time per finding set, sometimes recurring for follow-up tests | Number and severity of weaknesses in the test summary report and remediation plan, and integration effort with existing change processes |
What makes a TIBER-IT test longer or more expensive
A TIBER-IT test runs through the same preparation, testing and closure phases whatever its size, so the main cost and duration drivers are the decisions made during scoping and procurement. The cards below cover the factors that expand a test, and what to check early to keep them under control.
Number of critical functions and flags
The scope specification document defines which critical or important functions and which flags the red team will attack. Each added function adds threat intelligence work, red team time and blue team investigation. Ask the authority and the control team to confirm, in writing, the list of functions and flags before procurement starts, and challenge any function that cannot show a clear link to a critical service.
ICT third parties in scope
The TIBER-IT guide covers ICT service providers where they are included in the test scope. Each third party needs its own contractual route, consent and coordination with the red team, and may need its own tests of controls. Map which providers host or operate the flagged systems, confirm with each one before scoping closes, and agree who signs what, because a late addition can extend the preparation phase.
Environment complexity across Italian and EU locations
Systems in several Italian sites, other EU jurisdictions or cloud regions raise the number of environments the red team must test safely and the number of local legal or data residency questions. Document every location, hosting model and data flow in the scope, and confirm with legal counsel how cross-border data handling affects the test plan before testers are engaged.
Evidence maturity
When logs, asset inventories, network diagrams and incident runbooks are incomplete or spread across teams, the control team spends more time reconstructing the environment and the blue team report takes longer to close. Before initiation, check whether your monitoring can show what the red team did, when, and from where. Gaps found now are cheaper to fix than gaps found during replay and purple teaming.
Provider procurement cycles
The threat intelligence provider and the red team testers are procured during the preparation phase, which lasts up to six months from the written notification. Slow internal approvals, tender rules or limited availability of qualified providers can push the start of active testing back. Begin procurement planning as soon as the authority's notification arrives, and confirm the provider timetable and the contract structure in writing.
Remediation volume
The closure phase ends with a remediation plan that the entity must deliver within a fixed period after the authority's assessment. The more weaknesses the test finds, and the wider they spread across systems, the longer the plan, the funding requests and the follow-up validation take. Agree early how findings will be prioritized and which fixes are already in progress, so the remediation plan reflects actual ownership and deadlines.
How a TIBER-IT test relates to mandatory DORA threat-led testing
The core point is that a TIBER-IT test and a mandatory DORA threat-led penetration test (TLPT) are built on the same foundation. The ECB states that the core requirements of DORA TLPT and TIBER-EU are identical, and the TIBER-IT National Guide version 2.0, published by Banca d'Italia on 11 December 2025 with a joint communication, serves as the reference for both mandatory DORA TLPT and voluntary tests. For an Italian entity, the practical consequence is that the test process, roles and deliverables described in the guide are the same whether the test is voluntary or required under Legislative Decree 23/2025. Your team should read the guide as the working document for either path, not as a separate rulebook for voluntary testing.
Being subject to the same core requirements does not automatically mean that a given test counts toward a DORA obligation. Banca d'Italia's TIBER-IT page explains that DORA requires certain financial entities, identified by the authorities based on their importance, to carry out TLPT regularly, with the detailed rules set by Commission Delegated Regulation (EU) 2025/1190. An entity that has been identified as mandated should confirm in writing with its authority, through the single contact point at tiber-it@bancaditalia.it, whether a planned test will be accepted as its DORA TLPT, what scope and timing the authority expects, and how the results will be handled. An entity running a voluntary test should confirm the same questions before work starts, so that no testing effort is later found to fall outside the obligation it was meant to satisfy.
Questions Italian entities ask before a TIBER-IT test
Who must run a threat-led penetration test under DORA in Italy?
Only financial entities that the authorities identify, based on their importance, must carry out threat-led penetration testing (TLPT) under DORA. Banca d'Italia's TIBER-IT page explains that DORA requires this regularly for those entities, with the detailed rules set by Commission Delegated Regulation (EU) 2025/1190 of 13 February 2025. The guide is aimed mainly at entities in scope of DORA as implemented in Italy by Legislative Decree 23/2025. If you have not received a written designation, ask the authorities through the single contact point rather than assuming you are out of scope. Entities that are not designated can still test voluntarily, as covered in the next question.
Can an Italian entity run a TIBER-IT test voluntarily?
Yes. Banca d'Italia, CONSOB and IVASS have promoted threat-led tests on a voluntary basis since 2022. Other financial entities or organisations in Italy can run voluntary TLPT by notifying the single contact point, and voluntary testing is strongly encouraged for entities not subject to mandatory requirements. Voluntary tests follow the same TIBER-IT National Guide, version 2.0, so the process, roles and deliverables match a mandatory test. Before notifying, confirm with the authorities how a voluntary test would be treated, since the outcome of a voluntary test does not replace a mandatory DORA test for a designated entity.
What does the work need from our internal team?
The test needs named people on the internal side from the start, because TIBER-EU places several roles inside the tested entity. The control team manages the test on the entity's behalf and is supervised by the authority's test manager, and the blue team is the defensive team whose detection and response is measured. Both roles need time for scoping, weekly coordination and report reviews, and they need access to the systems in scope. The framework's closure phase also requires remediation planning and a formal attestation by the entity's management. Confirm with the authority which people must be named, how much of their time is expected, and whether internal staff may be supported by an outside partner.
How long does preparation take before testing starts?
The preparation phase lasts up to six months from the authority's written notification. It covers notification and initiation, setting up the control team and risk management, scoping critical or important functions and flags, and procuring the threat intelligence provider and red team testers. The main drivers of how much of that window you use are how quickly the scope is agreed with the authority, how fast the procurement of external providers completes, and how ready your inventory of critical functions and systems is. Starting with an accurate asset and function list usually shortens the scoping discussion. The testing phase that follows includes at least 12 weeks of active red team testing.
Can an implementation partner run the whole TIBER-IT test for us?
No. A TIBER-IT test needs independent threat intelligence and red team testers, procured under the authority's process, and it runs under the supervision of the authority's test manager and TIBER Cyber Team. A partner such as DeployOpen can help the organization prepare its systems, environments, logging, documentation and remediation work, and can run security testing in its own right outside the formal test. The partner cannot replace the independent red team or the authority's oversight. Ask any provider to show which parts of the process they are contracted to perform and how they keep the red team independent.
Does DeployOpen issue the TIBER-IT attestation?
No. The attestation is part of the TIBER-EU closure phase and is provided through the authority's process, which requires the entity's own management to confirm the test was carried out as the framework requires. DeployOpen does not issue audit reports, attestations or certifications. Our role is to prepare the systems, controls and evidence that the entity and the authority will review, and to help plan remediation after the test summary report. Confirm the attestation requirements, signatories and timing with the authority in writing before the closure phase begins.
How DeployOpen prepares systems and evidence for a TIBER-IT test
DeployOpen supports financial entities preparing for a TIBER-IT test by planning, building and documenting the self-hosted open-source systems and evidence the test will examine. We do not run the test, issue the attestation or act as the test authority. Our role is to prepare your environment and records so your own team and the providers you procure can work from a clear, agreed baseline.
How we scope
- We agree a written scope before work starts, covering systems, environments and deliverables for your TIBER-IT preparation.
- We map the critical or important functions your organization identifies to the platforms DeployOpen would plan, build or harden.
- We confirm with you which ICT service providers and third parties fall inside the scope and which items your authority must approve.
How we build
- We plan and implement self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks.
- We harden configurations, logging and access controls so the systems in scope can be examined and monitored during an active red team exercise.
- We document architecture, change records and security settings so the control team and blue team can trace what they are defending.
How we hand over
- We deliver written documentation of configurations, system owners, data flows and evidence locations for review by your control team.
- We prepare an evidence pack that shows how each in-scope control is implemented, operated and monitored, mapped to your own test records.
- We transfer administration, runbooks and open items to your staff so the organization can keep operating the systems after handover.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after the fixed-scope engagement ends.
- We can update documentation and evidence when the scope changes, a new authority document is issued, or the systems are upgraded.
- Questions about the authority's requirements, timelines or attestation should go to Banca d'Italia's single contact point, tiber-it@bancaditalia.it, or to your own legal and compliance advisers.
