What DORA is
Regulation (EU) 2022/2554, on digital operational resilience for the financial sector, known as DORA, has applied since 17 January 2025 (art. 64). It is a regulation, not a directive: it applies directly in every Member State, without transposition, to banks, payment and electronic money institutions, investment firms, insurers, fund managers and the other entities in art. 2, and to their ICT service providers.
In Portugal, Lei n.º 73/2025 of 23 December, the national implementing law, gives effect to the regulation: it designates as competent authorities the Banco de Portugal (the central bank), the ASF (Autoridade de Supervisão de Seguros e Fundos de Pensões, the insurance and pension funds supervisor) and the CMVM (Comissão do Mercado de Valores Mobiliários, the securities market supervisor), each for the entities it already supervises (art. 3(1)), and it sets the fines, which DORA leaves to the Member States (DORA, art. 50). The law also extends the regime to insurers and pension fund management companies authorised in Portugal (art. 2(1)).
Verified on 26 September 2026 against the text of Regulation (EU) 2022/2554 as published in the Official Journal, its delegated regulations and Lei n.º 73/2025. The sources are at the end of the page.
Does DORA apply to your organisation?
An indication in two questions. The answers are not stored or sent to anyone.
The five pillars
Each pillar is a chapter of the regulation, given here with its Official Journal title.
| Chapter | What it asks |
|---|---|
| ICT risk managementChapter II | A sound, comprehensive and well-documented ICT risk management framework, for which the management body bears ultimate responsibility (arts. 5 and 6); the identification and classification of all functions, assets and dependencies (art. 8); protection, detection of anomalous activities, and continuity plans tested at least once a year (arts. 9 to 11); backups restored on separate systems (art. 12). |
| ICT-related incident management, classification and reportingChapter III | A process to detect, manage and record all incidents and significant cyber threats (art. 17), their classification (art. 18) and the reporting of major ICT-related incidents to the competent authority, in three steps (art. 19). |
| Digital operational resilience testingChapter IV | A testing programme, with tests at least yearly of all systems that support critical or important functions (art. 24); the list of tests in art. 25(1), which includes "source code reviews where feasible"; and, for the identified entities, threat-led penetration testing (TLPT) at least every three years (art. 26). |
| Managing of ICT third-party riskChapter V | The entity remains fully responsible for what it outsources; it keeps a register of information on all arrangements with ICT service providers (art. 28); it assesses concentration risk (art. 29); and contracts have minimum provisions, stricter for critical or important functions (art. 30). |
| Information-sharing arrangementsChapter VI | The voluntary sharing of cyber threat information, such as indicators of compromise and tactics, within trusted communities of financial entities, notified to the authorities (art. 45). |
When there is a major ICT-related incident
The deadlines are not in DORA but in Delegated Regulation (EU) 2025/301, art. 5, and each one runs from the previous step.
Initial notification
Within 4 hours of classifying the incident as major, and no later than 24 hours after the entity became aware of it.
Intermediate report
No later than 72 hours after the initial notification, even if nothing has changed, and updated when regular activities have been recovered.
Final report
No later than one month after the intermediate report, or after the latest updated intermediate report.
An incident is major when it affects critical services and exceeds the threshold for data losses through malicious unauthorised access, or two or more of the other thresholds, such as more than 10% or more than 100,000 clients affected, a duration of more than 24 hours, two or more Member States, or an economic impact above €100,000 (Delegated Regulation (EU) 2024/1772, arts. 8 and 9). An entity supervised by more than one authority reports incidents to the one responsible for its prudential supervision (Lei n.º 73/2025, art. 3(2)).
Testing, TLPT and TIBER-PT
All entities except microenterprises maintain a digital operational resilience testing programme, with tests carried out by independent parties and, at least once a year, of all systems and applications that support critical or important functions (art. 24). Art. 25(1) lists the tests: vulnerability assessments, network security assessments, gap analyses, physical security reviews, source code reviews where feasible, scenario-based tests, performance testing, end-to-end testing and penetration testing, among others.
Threat-led penetration testing, TLPT, is something else: red team testing on live production systems, at least every three years, and only for the entities the authority identifies (art. 26), with testers who meet the requirements of art. 27, including professional indemnity insurance. Delegated Regulation (EU) 2025/1190 defines who is in by default, such as systemically important credit institutions. In Portugal, the Banco de Portugal adopted TIBER-PT, the national version of TIBER-EU, on 26 April 2022, and its April 2026 guide uses it for DORA TLPT in the banking sector. According to the Banco de Portugal, in January 2025 only credit institutions classified as other systemically important institutions were directly covered.
Where we come in
We do not carry out TLPT or run the regime. We produce the technical evidence some articles ask for.
| Article | What it asks | What we bring |
|---|---|---|
| Art. 25(1)Source code review | A testing programme that includes source code reviews where feasible. | The source code audit: a manual review against OWASP ASVS 5.0, with CVSS v4.0 calculated per finding, in a report the testing programme can file. Goshawk does it self-service. |
| Art. 8Identification | Identify, classify and document the functions, the ICT assets and the dependencies between them, and review that identification at least once a year. | Ibex discovers the devices on each network segment, including where no cloud service reaches, and keeps a record per device. |
| Art. 24(6)Annual tests | Test all systems and applications that support critical or important functions at least once a year. | Vulnerability assessments of the network with Ibex and of the external exposure of your domains with Buteo, repeatable whenever needed. |
| Art. 28Third-party risk | Assess the risk of each ICT service provider and keep the register of information. | An audit of the code the supplier delivers, before acceptance or renewal, is evidence for that assessment that does not depend on the supplier's word. |
Frequently asked questions
What are the fines?
DORA does not set them for financial entities and leaves them to the Member States (art. 50). In Portugal, Lei n.º 73/2025 sets, for banks, investment firms, payment and electronic money institutions, insurers and the other entities in the same point, fines of €10,000 to €5,000,000 for legal persons and €5,000 to €2,500,000 for natural persons, raised up to three times the economic benefit or, for legal persons, up to 10% of turnover (art. 11). Negligence is punishable, with the maximum limits halved (art. 9).
Who is accountable for the ICT risk management framework?
The management body, which defines, approves, oversees and bears ultimate responsibility for managing ICT risk, and whose members regularly follow specific training (art. 5).
Does DORA apply to my suppliers?
ICT third-party service providers are within scope (art. 2(1)(u)), but responsibility remains with the financial entity (art. 28). DORA reaches them through the contracts, with the provisions of art. 30, and those designated as critical come under the oversight of the European Supervisory Authorities (art. 31).
What is the register of information?
A register of all contractual arrangements for ICT services, at entity level and, where there is one, at group level, made available to the authority on request, with the new arrangements reported at least yearly (art. 28(3)). The templates are in Implementing Regulation (EU) 2024/2956, and providers that are legal persons are identified by their LEI or EUID.
Does a bank also have to comply with the RJC?
It may. Financial entities covered by both the RJC and DORA report ICT incidents to the financial authorities, but they still designate the Responsável de Cibersegurança (cybersecurity officer) and the permanent point of contact, and still comply with the RJC's incident notification (Regulamento n.º 756/2026, art. 10(2) and (3)). The RJC is explained in NIS2 in Portugal: the RJC.
Are microenterprises exempt?
No. They remain in scope, but are exempt from some obligations, such as the independent ICT risk control function, the internal audit of the framework, the annual tests of critical systems and TLPT, and they test under a lighter rule (arts. 6, 24, 25(3) and 26).
What does a code audit count towards?
Towards the source code review that art. 25(1) includes in the testing programme, and as evidence in the risk assessment of a supplier when the code is theirs (art. 28). It does not replace TLPT, which are red team tests on production.
Sources
- Regulation (EU) 2022/2554 on digital operational resilience for the financial sector, OJ L 333, 27.12.2022: arts. 2 to 6, 8 to 12, 16 to 19, 24 to 31, 45, 50 and 64.
- Delegated Regulation (EU) 2025/301 (incident reporting deadlines), art. 5; Delegated Regulation (EU) 2024/1772 (classification), arts. 8 and 9; Delegated Regulation (EU) 2025/1190 (TLPT); Implementing Regulation (EU) 2024/2956 (register of information).
- Lei n.º 73/2025 of 23 December, Diário da República, 1.ª série, n.º 246 (in Portuguese): arts. 2, 3, 9 and 11.
- Regulamento n.º 756/2026 of the CNCS (Centro Nacional de Cibersegurança, the national cybersecurity centre), art. 10 (in Portuguese).
- Banco de Portugal, TIBER-PT (in Portuguese) and the press release of 17 January 2025 on the digital operational resilience legislative package.