DORA Implementation
Digital transformation in the financial sector has brought speed, efficiency and new business models — but also a structural dependence on technology, the cloud, third-party software, integrations and digital supply chains. The DORA (Digital Operational Resilience Act) was created precisely to respond to this systemic risk: to ensure that financial entities can resist, respond and recover from ICT/cyber incidents (as well as operational failures) without compromising the continuity of critical services.
DORA is a European regulation (i.e. directly applicable), with harmonised requirements for the financial sector in the European Union. It came into force on 17 January 2025.
In Portugal, Law No. 73/2025 of 23 December ensured the national framework for implementation, supervision and sanctions associated with digital operational resilience in the financial sector.
This article is an implementation guide: without unnecessary jargon, but with clear steps, priorities and deliverables.
What DORA requires, in simple terms
DORA organises obligations into five major blocks (pillars) that reinforce each other:
- ICT governance and risk management (framework, policies, controls, roles and responsibilities)
- ICT incident management and reporting (classification, notifications, communication)
- Digital operational resilience testing (from basic testing to advanced exercises)
- ICT third-party risk management (contracts, supplier registration, exit plans)
- Threat information sharing (mechanisms and best practices, where applicable)
European and national authorities have been summarising this logic of ‘digital operational resilience’ as an ongoing capability (not a one-off project).
Who is covered (and why it matters to your “perimeter”)
DORA applies to a wide range of financial entities (e.g. banking, insurance, investment and other regulated participants), and also introduces a European supervisory framework for critical ICT service providers supporting the financial sector.
In practice, the first implementation task is not to ‘write policies’ — it is to define the perimeter:
- Which entities in the group are under financial supervision?
- What are the critical or important services/products and functions (CIFs) supported by ICT?
- What are the dependencies (applications, infrastructure, suppliers, data, integrations)?
- Who ‘owns’ each risk and each control (actual operational ownership)?
If you fail here, everything else (incidents, tests, contracts, evidence) becomes inconsistent.
What specifically changes in Portugal
With Law No. 73/2025, the national framework is aligned with the European regime and strengthens enforcement/supervision. The law designates as competent authorities the Bank of Portugal, the CMVM and the ASF, and provides for institutional cooperation within the financial supervision system.
A very relevant practical point for operations and compliance: the national framework centralises the reporting of serious ICT incidents at the Bank of Portugal (with coordination between supervisors).
In addition, Portugal has strengthened institutional communication on DORA, including the role of the National Council of Financial Supervisors in coordinating the resilience package.
ICT incidents: from ‘we handle it internally’ to a timed process
One of the areas with the greatest operational shock is incident reporting. DORA requires the ability to:
- quickly detect and classify ICT incidents;
- decide whether they are ‘major ICT-related incidents’ (according to applicable criteria/thresholds);
- report with standardised content and strict timings, via defined templates and processes.
The deadlines are particularly tight: there are technical standards that require initial notification within 4 hours of classification (and up to 24 hours after detection/knowledge, depending on the context), followed by an interim and final report.
In operational terms, this requires two changes:
- Process engineering (workflow) — who detects, who classifies, who approves, who submits, on which channel, with what evidence.
- 24/7 decision-making capacity — cannot depend on ‘the team will be back tomorrow’.
👉 Implementation tip: build a DORA incident playbook with:
- classification and escalation criteria;
- RACI (responsible/decision makers);
- pre-filled report templates (where possible);
- simulation exercises to test response time.
How to implement DORA: 10-step roadmap (realistic)
1) Create a ‘DORA Scope Map’ (2–3 weeks)
- inventory of critical/important services and functions;
- map of ICT assets (applications, infrastructure, data, integrations);
- list of ICT suppliers and dependencies.
Deliverable: perimeter map + list of CIFs + initial inventory.
2) Gap assessment (DORA vs reality)
Assess the ‘as-is’ against the 5 pillars: what exists, what is missing, what is only informal.
Deliverable: gap matrix prioritised by risk and effort.
3) Governance and accountability (the ‘tone from the top’ with evidence)
DORA requires management involvement: decisions, approvals, monitoring and accountability.
Without this, policies look good — but they don’t stand up to scrutiny.
Deliverable: governance model (committees, reporting, KRIs/KPIs).
4) ICT risk framework (policies + controls + evidence)
This includes policies and procedures such as:
- vulnerability management and patching,
- access management,
- logging and monitoring,
- change management,
- backup/restore and continuity,
- configuration management,
- secure SDLC (if development is involved),
- data management (aligned with GDPR where applicable).
Deliverable: set of policies/procedures + evidence (records, reports, tickets).
5) Incidents and reporting (process + training)
Design the flow and train: detect → classify → report → communicate → close with RCA (root cause analysis).
Deliverable: incident playbook + exercises (tabletop) + lessons learned.
6) Resilience testing (basic to advanced)
Not just annual pentesting. Includes:
- backup/restore testing,
- continuity testing,
- incident simulations,
- escalation process testing,
- and, for relevant entities, more demanding exercises (e.g., TLPT-type approaches).
Deliverable: annual testing plan + evidence of execution and remediation.
7) ICT third-party risk management (contracts, registration, exit)
This is the typical ‘Achilles heel’: cloud, SaaS, MSSP, integrators, payments, KYC, etc.
DORA introduces contractual and control obligations and creates European supervision over critical third parties.
Deliverables:
- registration of contracts and services,
- risk assessment by supplier,
- DORA contractual clauses (audit rights, SLAs, subcontracting, location, incidents, exit),
- exit strategy for critical services.
8) Metrics and continuous reporting (not a ‘one-off project’)
Create a resilience dashboard:
- incidents and response times,
- availability of critical services,
- test results,
- supplier risk,
- remediation backlog.
9) Preparation for supervision
Supervision will ask for evidence: it is not enough to say ‘we have a policy’.
Organise the evidence repository by pillar.
10) Training and operational culture
Without training, rapid reporting fails.
Train: IT, operations, risk, compliance, management, and critical suppliers.
DORA and NIS2: overlap, but not replacement
If your organisation (or part of it) also falls under NIS2, there are common areas (incidents, risk management, supply chain). But beware: in the financial sector, DORA functions as a specialised regime for digital resilience — and specific obligations must still be met in accordance with the applicable framework.
The practical approach is to build an integrated system, with:
- a single incident taxonomy,
- base controls aligned with standards (e.g. ISO 27001/22301),
- but workflows and reporting tailored to each obligation (DORA vs NIS2 vs GDPR).
Common mistakes that lead to non-compliance (and headaches)
- Poorly defined perimeter (vague CIFs, critical suppliers ‘forgotten’)
- Cloud/SaaS contracts without DORA clauses and without a real exit strategy
- Incidents without rapid classification and without 24/7 authority to report
- Tests that do not close remediations (tested, found, but not corrected)
- Scattered evidence (no one can prove, in two days, that they control the risk)
Final checklist: ‘DORA in 30 days’ (the minimum you should have)
- Scope map (CIFs + assets + integrations)
- Inventory of ICT suppliers + criticality
- Gap assessment + approved roadmap
- Formal governance (committees, reporting, responsible parties)
- Incident process with classification and escalation
- Response time reporting and testing templates
- Resilience testing plan + calendar
- Contract register + contractual remediation plan
- Exit strategy for critical services
- Evidence repository prepared for supervision
How iCompliance.eu can help
At iCompliance.eu, we typically implement DORA as an operational resilience programme (not as ‘documentation for show’), with a focus on evidence and actual response capability:
- DORA Readiness & Gap Assessment (scope, CIFs, risks, maturity)
- 90/180-day roadmap with quick wins and priorities by risk
- Governance, policies and procedures package (aligned with audit/supervision)
- Incident reporting pack (workflow, RACI, templates, exercises)
- Third-party ICT pack (registration, due diligence, contractual clauses, exit plans)
- Test plan and support in exercises and preparation for inspections
Next steps:
- DORA Diagnosis: If you want to know, objectively, what your organisation needs to do to comply, iCompliance.eu can carry out a quick DORA assessment and deliver a compliance roadmap with evidence ready for supervision and auditing.
- To help you get started, download a DORA Portugal checklist in PDF format by requesting it below in the comments section of this article.
- Contact us: Contacts | iCompliance