These are the areas to review in your DORA compliance checklist:
- Confirm whether DORA applies and define the scope
- Establish governance and accountability
- Build an ICT risk management framework
- Maintain asset, service and dependency inventories
- Apply protection, prevention and detection controls
- Define ICT incident management and reporting
- Establish a resilience testing programme
- Manage ICT third-party risk
- Prepare continuity, backup and recovery
- Maintain evidence, reporting and continuous improvement
The Digital Operational Resilience Act (DORA), formally Regulation (EU) 2022/2554, has applied since 17 January 2025. It requires financial entities to manage ICT risk, prepare for operational disruption, report major incidents and oversee the technology providers on which their critical services depend.
DORA is not limited to the IT department. It affects corporate governance, risk management, procurement, business continuity, incident response, internal audit and senior management oversight. This checklist offers a practical way to review the main areas of readiness. The official DORA Regulation should be read alongside the applicable regulatory and implementing technical standards.
10 areas to review for DORA compliance
1. Confirm whether DORA applies and define the scope
Identify the entities in scope
Start by identifying every legal entity, branch and business unit that may be subject to DORA. The analysis should consider whether the organisation is a bank, an investment firm, a payment institution, an insurance company, a crypto-asset service provider, a regulated market or another category covered by the Regulation.
The scope should also take group structures into account. A parent company may provide shared technology, security or operational services to several regulated entities, while each entity may retain independent responsibility for its own regulatory obligations.
Document the scoping decision
The organisation should record why each entity, service and technology environment is included or excluded. This decision should be approved by the relevant governance body and reviewed when the business changes, another entity is acquired or a new regulated service is introduced.
A clear scoping decision prevents later gaps in the ICT risk assessment, the vendor inventory, the incident management process and the evidence programme.
2. Establish governance and accountability
Assign accountability to management
DORA places significant responsibility on the management body. The management body must approve the ICT risk management framework, understand the relevant technology risks and oversee the organisation’s resilience programme.
Responsibilities should be documented in mandates, policies, committee terms of reference and reporting calendars. It should be clear who approves risk acceptance, who receives incident reports and who decides whether a control weakness requires additional investment.
Connect governance to evidence
Governance must be demonstrable. Useful records include approved policies, meeting minutes, risk reports, decisions on corrective actions, incident reviews, test results and management approvals.
Organisations that already use a structured risk management framework can extend it to cover DORA responsibilities instead of creating a separate process.
3. Build an ICT risk management framework
Use a consistent methodology
The framework should identify threats, vulnerabilities, potential impacts, affected services and existing safeguards. It should cover confidentiality, integrity, availability, authenticity and operational resilience.
The risk register should show the owner, rating, treatment decision, target date and residual exposure for each relevant risk. It should also distinguish between risks that are accepted, transferred, mitigated or avoided.
Link risks to treatment and evidence
A DORA risk assessment is incomplete if it only lists risks. Each significant risk needs a treatment measure, an owner and supporting evidence. The organisation should be able to show how a decision was made and whether the treatment actually reduced exposure.
The relationship between the risk register, treatment measures and evidence can be structured through an ISO 27001 risk treatment plan, even when ISO 27001 certification is not part of the immediate scope.
4. Maintain asset, service and dependency inventories
Record ICT assets and services
The inventory should cover applications, infrastructure, cloud services, networks, endpoints, data stores, identities, interfaces and security tools. It should also identify owners, locations, criticality levels, dependencies and recovery requirements.
Technology teams should reconcile the inventory with procurement records, identity platforms, cloud accounts, configuration management systems and vendor records. Informal tools and solutions adopted without central approval should also be taken into account.
Map critical or important functions
The organisation should connect ICT assets to business services and critical or important functions. This helps determine which systems need more demanding recovery objectives, additional monitoring or more frequent testing.
A structured approach to protecting infrastructure against cyberattacks can help organise technical information, but the business must define the relationships between services and the operational importance of each asset.
5. Apply protection, prevention and detection controls
Protect access and configurations
DORA requires the management of identity, authentication, privileged access, secure configuration, changes, patching and vulnerability handling. Controls should be proportionate to the risks of the relevant system or service.
Important questions include:
- Is privileged access restricted and reviewed?
- Are security updates tracked through to completion?
- Are changes approved, tested and reversible?
- Are production and development environments properly separated?
- Are responsibilities for encryption and key management documented?
Monitor for anomalous activity
Prevention must be backed by detection. Logging, monitoring and alerting should cover important systems, administrative activity, security events and service degradation.
Monitoring arrangements should define who reviews alerts, how events are escalated and how logs are retained. The process should also explain how monitoring continues during a vendor outage or other disruption.
6. Define ICT incident management and reporting
Build an escalation process
The incident process should define what constitutes an ICT-related incident, how incidents are classified and who coordinates the response.
It should bring together technology, risk, legal, compliance, communications, privacy and business teams. Roles should be clear before an incident occurs, including who preserves evidence, who informs management and who coordinates the response with affected vendors.
Prepare for regulatory reporting
DORA sets requirements for classifying and reporting major ICT-related incidents. The organisation should define the decision criteria, reporting responsibilities, approval process and the records needed to support its communications.
Templates and applicable deadlines should be checked against the latest regulatory standards, including the technical standards for major incident reporting.
Incident simulations should test both the technical response and regulatory decision-making. A tabletop exercise should show whether the organisation can prepare an accurate notification while continuing to manage the disruption.
7. Establish a resilience testing programme
Define a testing calendar
Testing should be based on the organisation’s risk profile and the criticality of its services. Possible activities include vulnerability assessments, penetration tests, scenario-based exercises, recovery tests, failover exercises and crisis simulations.
The testing plan should identify the system or process tested, the objective, the participants, the expected evidence and the owner of corrective actions. Testing should not be treated as a one-off certification exercise.
Address advanced testing where applicable
Some financial entities may be subject to more demanding threat-led penetration testing requirements. The organisation should confirm whether these requirements apply and plan the necessary scope, qualified testers, evidence and corrective actions.
Results should be reported to management and relevant findings should be tracked through the risk and corrective action process.
8. Manage ICT third-party risk
Carry out due diligence before contracting
Vendor reviews should assess security controls, resilience, subcontractors, data locations, incident notification, access, recovery capability and service dependencies.
The review should cover more than a questionnaire. Contracts, independent assurance reports, penetration test summaries, business continuity information and technical documentation may also be relevant. In addition, DORA requires financial entities to maintain a register of information covering all contractual arrangements with ICT third-party service providers, which must be submitted periodically to the competent authority.
In organisations that rely heavily on SaaS or API providers, vendor oversight, data processing and operational dependency should be assessed together. PrivaLex’s analysis of privacy risks that SaaS companies often overlook shows why technical and privacy dependencies should not be reviewed in isolation.
Include contractual and exit requirements
DORA-related contracts may need provisions on security obligations, audit rights, cooperation, incident notification, access to information, subcontracting and support during termination.
The organisation should also assess concentration risk. If several critical services depend on the same cloud provider, connectivity provider or managed security partner, a single outage can affect several business functions at once.
The exit plan should determine whether data, configurations, logs and operational documents can be exported within a realistic timeframe. It should also consider alternative providers, transition support and the resources needed to migrate.
9. Prepare continuity, backup and recovery
Define recovery objectives
Business continuity arrangements should identify the services that must be restored, the maximum tolerable disruption and the dependencies that must be available during recovery.
Recovery objectives should be supported by practical technical and organisational measures, including backups, redundant infrastructure, alternative communication channels, manual procedures and emergency decision-making mechanisms.
Test recovery under realistic conditions
A backup does not prove that systems can be recovered. The organisation should check whether data can be restored, systems can be rebuilt, access can be re-established and critical operations can continue.
Tests should include scenarios such as vendor failure, ransomware, loss of privileged access, cloud region outage and data corruption. Lessons learned should be documented, assigned to owners and reviewed by management.
10. Maintain evidence, reporting and continuous improvement
Build an evidence structure
The DORA evidence set may include:
- ICT risk assessments and registers.
- Asset and dependency inventories.
- Policies and procedures.
- Access reviews and change records.
- Vulnerability and patching reports.
- Incident logs and regulatory notifications.
- Continuity and recovery test results.
- Vendor assessments and contracts, and the ICT third-party register of information.
- Penetration test reports.
- Staff training records.
- Management and committee minutes.
- Corrective action tracking.
Evidence should be linked to specific controls, risks and owners. A folder full of documents is not enough if the organisation cannot explain what each record proves or when it was last reviewed.
Review and improve the programme
DORA requires a continuous approach to resilience. After an incident, a test or an audit, the organisation should identify lessons learned, update controls and track corrective actions through to completion.
Where privacy, ICT risk and regulatory evidence overlap, PrivaLex’s seven-point assessment on whether you need an external DPO can help determine when additional governance capacity is justified.
Turning DORA requirements into an operational programme with PrivaLex
At PrivaLex, we help financial and technology organisations turn DORA obligations into an operational programme that management, security, compliance and technology teams can use.
The work usually starts with scope confirmation and a maturity assessment. We identify the entities, ICT services, critical business functions, vendors and existing frameworks that need to be considered. This creates a practical baseline before the organisation invests in new tools, policies or testing activities.
We then help structure the core programme: ICT risk methodology, risk register, treatment plan, control owners, vendor review workflow, incident escalation, resilience testing and evidence requirements. Each priority action is linked to an owner, a deadline, an expected outcome and a supporting record.
When the organisation already has an ISO 27001, GDPR, NIS2 or ENS programme, we map shared requirements into a single governance model while keeping DORA-specific obligations visible. This can reduce duplicated assessments and give management a clearer view of which controls support several regulatory requirements.
PrivaLex can also support vendor and subcontractor oversight, continuity planning, incident exercises, management reporting, internal audit preparation and corrective action tracking. Where a compliance platform already exists, we help configure it around the organisation’s real scope and operating model, so it does not become a collection of disconnected checklists.
The goal is a DORA programme that can respond to an incident, a vendor review, an internal audit or a supervisory inspection. It should show not only that policies exist, but that controls have owners, operate, are tested and improve.
Conclusion
DORA compliance depends on much more than a policy library or a completed questionnaire. Financial entities need a connected operating model that covers governance, ICT risk, asset inventories, incident response, resilience testing, vendor oversight, recovery and evidence.
A practical implementation sequence is to:
- Confirm scope and responsibilities.
- Map critical services and ICT dependencies.
- Build the risk and control framework.
- Review vendors and contractual protections.
- Test response and recovery processes.
- Organise evidence for management and regulatory supervision.
Book a strategy session with PrivaLex to assess your DORA readiness and prioritise your next actions. You can also request a free risk assessment if you need a first view of your current exposure.
Frequently Asked Questions (FAQs)
DORA compliance means establishing the governance, ICT risk-management, incident-reporting, resilience-testing and third-party oversight arrangements required by the Digital Operational Resilience Act.
DORA applies to a wide range of financial entities established in the European Union, including banks, investment firms, payment institutions, insurance companies, crypto-asset service providers and other regulated organisations covered by the regulation. It also creates obligations affecting ICT third-party providers serving the financial sector.
The main areas include ICT risk management, governance, incident management and reporting, resilience testing, business continuity, information sharing and ICT third-party risk management.
No. ISO 27001 and DORA address related but different requirements. ISO 27001 provides a structured information-security management system, while DORA includes specific obligations for financial-sector resilience, incident reporting, testing and ICT third-party oversight.
Cloud and SaaS providers may fall within DORA’s ICT third-party risk framework when they provide services to financial entities. The financial entity remains responsible for managing its own third-party risk, even when a supplier operates important infrastructure or security controls.
Controls should be reviewed according to risk, regulatory requirements, significant changes, incidents and testing results. Reviews should not depend only on an annual calendar. New suppliers, major system changes, serious vulnerabilities and incidents may require an earlier review.
PrivaLex supports scope analysis, ICT risk management, supplier oversight, incident readiness, resilience testing, evidence preparation, framework alignment and management reporting. The work can be adapted to organisations starting from the beginning or improving an existing DORA programme.