DORA Compliance Checklist: How to Prepare for the Digital Operational Resilience Act

Table of Contents

The Digital Operational Resilience Act (DORA) raises the bar for how financial entities and their ICT providers manage, test, and evidence digital resilience. It is not a documentation exercise or a one-off compliance project. Regulators expect organizations to demonstrate that operational resilience is embedded into day-to-day governance, risk management, testing, and incident response.

Learn more about DORA and the organizations it covers

This DORA compliance checklist is designed to help teams assess readiness in a structured, audit-friendly way. It focuses on practical controls, repeatable processes, and the ability to produce evidence on demand – including the application and API layer, where many operational disruptions begin.

Note that this article is intended as a handy starting point and reference but is not exhaustive and does not constitute legal advice – always see the official DORA document for binding guidance.

DORA compliance checklist at a glance

The table below provides a quick, scannable overview of the most important DORA domains. Each row maps directly to more detailed guidance later in this article, so you can start with a high-level self-assessment and then drill down where gaps appear.

How to use this checklist effectively

This checklist works best as a living reference rather than a one-time assessment. Many DORA gaps only become visible when teams attempt to collect evidence or repeat processes under time pressure.

Use the checklist to assign ownership for each domain, identify missing or outdated evidence, and validate whether controls operate consistently over time. Where possible, focus on continuous validation rather than annual point-in-time reviews, especially for systems and applications that change frequently.

DORA domain	What regulators expect	Key questions to ask internally	Typical evidence to prepare
Governance and accountability	Clear ownership and management body oversight of digital operational resilience, with defined risk tolerance, reporting, and competence (training).	Who is accountable for ICT risk and resilience decisions? How is ICT risk tolerance defined, approved, and reviewed? Do the management body and key stakeholders have documented ICT risk training and competence?	Governance frameworks and ICT risk management framework Management body reporting packs (KRIs/KPIs, risk appetite and tolerance) RACI or accountability matrices Training plans and completion records
ICT asset inventory and dependency mapping	Current inventory of ICT assets and mapped dependencies for services supporting critical or important functions.	Do we know which systems, applications, APIs, and infrastructure support critical or important functions? Do we have up-to-date dependency and data flow visibility, including “shadow” services?	Asset inventories and CMDB extracts Service maps, dependency diagrams, and data flow maps Discovery outputs and update cadence evidence
ICT risk management	A complete ICT risk management framework covering preventive, detective, and corrective controls across the ICT lifecycle.	Are ICT risks assessed based on operational impact to critical or important functions? Are core controls defined and operating (access, change, patching, logging, monitoring, configuration)? Is risk acceptance controlled and time-bound?	ICT risk register and risk assessments Control standards and procedures (access, change, patching, monitoring) Vulnerability and remediation tracking Risk acceptance records with approvals and expiries
ICT business continuity, response and recovery	Documented and tested ICT continuity and recovery capabilities for critical or important functions, including backup/restore and crisis communications.	Do we have BIA-driven recovery objectives (RTO/RPO) for critical or important functions? Are backup, restore, failover, and recovery procedures tested and evidenced? Do we have crisis communication plans that work under real pressure?	BIAs and service continuity requirements (RTO/RPO) ICT continuity and disaster recovery plans and runbooks Backup and restore logs and periodic restore test results Continuity and recovery exercise reports and corrective actions Crisis communication plans and call trees
Digital operational resilience testing	A risk-based, documented testing program with an annual baseline for critical or important systems, independence, remediation validation, and TLPT where applicable.	Is there an annual testing baseline for systems supporting critical or important functions? Are tests independent (or conflicts managed) and scoped to realistic scenarios? Are findings fixed and retested to closure? Does TLPT apply, and if so, is it scheduled and governed correctly?	Testing program, schedule, and scoping methodology Vulnerability assessment and penetration test reports Threat-led test artefacts where applicable (TLPT governance, scope, results) Retest evidence and remediation verification records
Incident management and regulatory reporting	Defined incident detection, classification, escalation, and staged regulatory reporting for major incidents, with strong timestamps and audit trails.	Can we detect and classify ICT incidents rapidly and consistently? Do we track time of awareness, time of classification, and reporting deadlines for “major” incidents? Are playbooks rehearsed, including internal escalation and external communications?	Incident classification criteria and decision records Incident response playbooks and runbooks Incident logs, timelines, and evidence preservation records Regulatory reporting templates, submission timestamps, and communications records Post-incident reviews and lessons-learned actions
ICT third-party risk management	End-to-end oversight of ICT third parties supporting critical or important functions, including contractual controls, concentration risk, exit planning, and a maintained register of information.	Do we know which ICT third parties support critical or important functions? Is the register of information complete and kept current? Do contracts include required audit, access, incident support, subcontracting, and exit terms? Do we assess concentration and subcontracting chain risk?	Supplier inventory and criticality assessments Register of information and update process evidence Third-party risk assessments and ongoing monitoring records Contracts, addenda, audit rights, SLAs, and incident support clauses Exit plans, exit tests, and concentration risk analyses
Information sharing	Controlled internal and external information sharing processes for threat intelligence and lessons learned, with governance and safeguards.	How do teams share actionable threat intelligence and lessons learned internally? Do we participate in sector or peer sharing, and is it controlled and documented? Are confidentiality, data protection, and need-to-know enforced?	Information-sharing procedures and governance Records of internal dissemination (briefings, advisories) Participation records in structured sharing arrangements where applicable
Documentation and evidence	Evidence that controls operate in practice and can be produced on demand with traceability to outcomes.	Can we produce evidence quickly, consistently, and with clear traceability from requirement to control to operation? Are documents versioned and reviewed on a defined cadence?	Central documentation repositories and access controls Version control and review and approval records Audit trails linking controls to tests, incidents, remediation, and decisions

DORA compliance checklist: Detailed guidance

The following sections expand each checklist domain into practical guidance. The focus is on how DORA requirements typically translate into operating models, controls, and evidence that stand up to supervisory scrutiny. The emphasis is not only on having policies in place, but on demonstrating that controls operate consistently and can be evidenced on demand.

1. Governance and accountability

DORA requires clear accountability for digital operational resilience at the management body level, supported by defined risk tolerance, reporting structures, and demonstrable competence. In practice, this means that ICT risk and resilience are treated as business risks, not just technical concerns.

Organizations should be able to show who is accountable for ICT risk decisions, how risk tolerance is defined and approved, and how that tolerance is reviewed as the threat landscape and operating environment change. Management body oversight is expected to be active and informed, supported by meaningful metrics rather than purely technical status updates.

Competence is also part of governance. DORA expects management body members and key stakeholders to understand ICT risks well enough to challenge decisions and oversee resilience effectively. This is typically evidenced through documented training plans, role-based learning, and records showing that relevant training has been completed and refreshed.

2. ICT asset inventory and dependency mapping

A reliable inventory of ICT assets is foundational to almost every other DORA requirement. Organizations are expected to maintain a current view of the systems, applications, APIs, and infrastructure components that support critical or important functions, along with the dependencies between them and suitable configuration management database (CMDB) views.

Dependency mapping goes beyond listing assets. It includes understanding how services rely on each other, how data flows between components, and where single points of failure or hidden dependencies exist. This visibility is particularly important for identifying undocumented or “shadow” services that may fall outside standard change, testing, or monitoring processes.

From a supervisory perspective, asset and dependency information should be kept up to date and reviewed regularly, with evidence showing how inventories are maintained and validated rather than treated as static documentation.

3. ICT risk management

DORA requires a comprehensive ICT risk management framework covering preventive, detective, and corrective controls across the ICT lifecycle. Risk assessments should focus on how ICT risks could affect the availability, integrity, and continuity of services supporting critical or important functions.

In operational terms, this means defining and operating core control domains such as access management, change management, patching, configuration, logging, and monitoring. Risk acceptance should be controlled, documented, and time-bound, with clear ownership and review dates rather than open-ended exceptions.

Supervisors typically expect to see that ICT risks are assessed based on operational impact, not just technical severity, and that remediation progress is tracked and governed through to closure.

4. ICT business continuity, response, and recovery

Business continuity and recovery capabilities are integral to DORA’s ICT risk management framework. Organizations should be able to demonstrate that recovery objectives for critical or important functions are defined through business impact analysis (BIA) and translated into concrete ICT continuity and disaster recovery arrangements.

This includes documented recovery time and recovery point objectives, tested backup and restore processes, and rehearsed failover or recovery procedures. Testing should not be purely theoretical. Evidence of restore tests, recovery exercises, and follow-up actions is a key indicator that plans are workable under real conditions.

Crisis communication is another critical element. DORA expects organizations to be prepared to communicate effectively during severe ICT incidents, both internally and externally. This is typically supported by crisis communication plans, call trees, and evidence that these arrangements have been exercised.

5. Digital operational resilience testing

Testing is a core pillar of DORA and is expected to be risk-based, documented, and repeatable. For systems supporting critical or important functions, organizations should have an annual baseline of testing, complemented by additional testing triggered by material changes or emerging risks.

Testing activities commonly include vulnerability assessments and penetration testing, with clear scoping, independence or conflict management, and defined remediation processes. Findings should be tracked through to closure, with retesting used to verify that remediation is effective.

Where threat-led penetration testing (TLPT) applies, additional governance is required around scope, oversight, and coordination. Even where advanced testing is not mandatory, organizations are expected to ensure that testing scenarios are realistic and aligned to credible threat models rather than limited to checklist-style exercises.

Learn how DORA mandates application security testing

6. Incident management and regulatory reporting

DORA introduces detailed expectations for ICT incident management, including detection, classification, escalation, and regulatory reporting for major incidents. Organizations should be able to detect incidents promptly, apply consistent classification criteria, and maintain strong audit trails covering key timestamps and decisions.

Incident response processes should define how incidents are escalated internally, how decisions are documented, and how external communications are managed. Regulatory reporting is typically staged, with different levels of detail provided as an incident evolves, and organizations are expected to track reporting deadlines and submissions carefully.

Evidence in this area often includes incident classification criteria, response playbooks, incident logs with timelines, reporting templates, and records of post-incident reviews and lessons learned.

7. ICT third-party risk management

DORA significantly expands expectations around ICT third-party risk management, particularly for providers supporting critical or important functions. Organizations should maintain a clear view of which third parties are critical, supported by a complete and current register of information.

Contracts play a central role in meeting DORA requirements. Agreements are expected to include provisions covering audit and access rights, incident support, subcontracting conditions, and exit strategies. Beyond contractual terms, organizations should be able to demonstrate ongoing oversight, including monitoring of performance, assessment of concentration risk, and evaluation of subcontracting chains.

Exit planning is not purely theoretical. Supervisors may expect evidence that exit strategies are realistic and, where appropriate, tested to confirm that services can be transitioned without unacceptable disruption.

8. Information sharing

DORA supports controlled information sharing as a way to strengthen collective resilience. Organizations may participate in information-sharing arrangements to exchange threat intelligence and lessons learned, provided appropriate governance and safeguards are in place.

Internally, this means having defined processes for disseminating relevant security information to the right stakeholders in a timely manner. Externally, participation in sector or peer initiatives should be documented and governed, with controls to protect confidentiality, data protection obligations, and need-to-know principles.

Information sharing is not a blanket obligation, but where it is undertaken, it should be structured, deliberate, and auditable.

9. Documentation and evidence

Across all DORA domains, the ability to produce clear, current, and traceable evidence is critical. Supervisors are not only interested in whether controls are defined, but also whether they operate in practice and are reviewed over time.

Organizations should be able to demonstrate traceability from regulatory requirement to internal control, and from control to operational evidence such as tests, incidents, remediation actions, and management decisions. Documentation should be versioned, subject to defined review cycles, and stored in a way that supports timely access during audits or supervisory reviews.

Well-structured documentation and evidence management reduces friction during oversight and provides confidence that digital operational resilience is embedded rather than improvised.

How Invicti can help with key aspects of DORA compliance

Many DORA requirements intersect directly with application and API security, particularly around asset visibility, risk management, and resilience testing. Invicti supports these areas by enabling continuous testing of web applications and APIs to help teams identify vulnerabilities that could realistically disrupt operations. Scans from multiple security testing tools are orchestrated, aggregated, and correlated within a central application security posture management (ASPM) platform, with Invicti’s industry-leading DAST acting as the runtime fact-checker.

Proof-based scanning helps validate exploitable vulnerabilities, reducing noise and supporting risk-based prioritization. Discovery capabilities assist with identifying hidden or undocumented apps and APIs, while built-in retesting confirms whether remediation efforts are effective. Thanks to deep DevSecOps integration, development teams can make security a routine part of software quality to fix issues quickly and demonstrably reduce the risk of security gaps in production.

By centralizing application-layer security insights, Invicti helps organizations maintain clearer visibility into operational risk and produce more consistent, audit-ready evidence across several key DORA domains.

Turning DORA from obligation into a resilience advantage

Used well, DORA can become more than a regulatory obligation. It can serve as a forcing function for tighter governance, better visibility into application risk, and more disciplined, repeatable security practices across the software lifecycle.

If you are assessing how your application and API security program supports DORA expectations in practice, request a demo of the Invicti platform to see how application-layer testing, discovery, and validation can support your operational resilience efforts – without adding unnecessary complexity.

Frequently asked questions

No items found.

Table of Contents

Text Link