DORA Compliance Checklist Template: An Architect's Field Guide (Not Just a GRC Tick-Box)
Most of the search results for "dora compliance checklist template" are written for GRC and compliance teams. They list the five pillars, tell you to "establish an ICT risk management framework," and hand you a PDF of yes/no questions. That's useful for a steering committee. It is nearly useless for the people who actually have to make the systems resilient: the enterprise architects, staff engineers, and engineering leaders who own the diagrams, the dependency graphs, and the deployment topology.
This DORA compliance checklist template is written for that audience. The Digital Operational Resilience Act (Regulation (EU) 2022/2554) has applied across the EU since 17 January 2025, and the uncomfortable truth most generic checklists skip is this: DORA is an architecture regulation wearing a compliance costume. Its real demand is that you can demonstrate, with traceable evidence, that your system design tolerates ICT failure. You cannot tick that box from a policy document. You tick it from your architecture.
Below is the checklist as an architect should actually run it — organized by the five regulatory pillars, but translated into design decisions, artifacts, and the evidence a supervisor will ask for.
Why a Generic DORA Checklist Fails the Architecture Test
The five pillars of DORA — ICT risk management, incident reporting, resilience testing, third-party risk, and information sharing — are well documented. The problem is the altitude at which most checklists operate. They ask "Do you have an incident response plan?" A supervisor under DORA Article 17 doesn't want the plan; they want evidence the plan operates: classification thresholds wired into monitoring, a reporting clock that starts automatically, and a post-incident review that fed a design change.
The recurring failure mode I see in pre-audit reviews is the traceability gap. An organization has a 60-page ICT risk policy and a separate set of architecture diagrams, and nothing connects requirement → control → component → evidence. When the regulator asks "show me which system implements your recovery-time objective for this critical-or-important function," there is a meeting, three Slack threads, and a guess. DORA's machine-readable Register of Information (the ITS templates) exists precisely because supervisors got tired of that answer.
So treat this DORA compliance checklist template as a way to close that gap. For every item, the test is not "do we have a document" but "can I point at the architectural artifact and the operational evidence that proves it."
Pillar 1 — ICT Risk Management: The Checklist Items That Are Really Design Decisions
Articles 5–16 are the backbone. The compliance team frames this as governance; the architect should frame it as dependency mapping and blast-radius control.
| Checklist item | What it actually requires from architecture | Evidence a supervisor accepts |
|---|---|---|
| Identify critical-or-important functions (CIFs) | A function-to-system map; every CIF traced to the apps, data stores, and infra that serve it | ArchiMate/C4 model linking business functions to application and technology layers |
| ICT asset inventory | Complete, current inventory including dependencies (not just a CMDB list) | Machine-readable inventory with dependency edges, dated |
| Risk identification & protection | Threat model per CIF; segmentation so one failure doesn't cascade | Network/trust-boundary diagrams, segmentation policy-as-code |
| Detection | Monitoring coverage mapped to each CIF, with defined thresholds | Alert-to-function mapping; dashboards |
| Response & recovery | RTO/RPO defined per CIF, backups tested, failover proven | DR test reports with timestamps and measured recovery times |
| Backups & restoration | Restoration tested, not just backup taken | Last successful restore test, dated, per critical data store |
The single most common pitfall here is treating the asset inventory as a flat list. DORA cares about dependencies. If your payments function depends on a shared identity service that depends on a single third-party KMS, the regulator wants that chain visible. Architects who maintain a real dependency graph — not a spreadsheet — clear this pillar in a fraction of the time.
Concrete tip: define RTO and RPO at the critical-or-important function level, not the application level. A single app might serve one CIF that needs 15-minute recovery and another that can tolerate four hours. Lumping them produces over-engineered DR for the tolerant function and, worse, hides under-provisioned DR for the critical one.
Pillar 2 — ICT Incident Reporting: Wire the Clock Into the System
DORA's incident reporting timeline is strict, and the RTS on incident classification makes the thresholds concrete. Under the reporting regime, a major incident triggers an initial notification (no later than 4 hours after you classify the incident as major, and within 24 hours of detection), an intermediate report (within 72 hours of the initial), and a final report (within one month). Generic checklists say "have a process." The architectural checklist says automate the classification so the clock starts without a human deciding to start it.
- [ ] Classification criteria are codified, not tribal. The DORA RTS thresholds — clients affected, data losses, duration, geographical spread, economic impact, reputational impact — should be expressed as rules in your incident tooling, so a P1 is auto-evaluated against "is this DORA-reportable?"
- [ ] The reporting clock is event-driven. Detection time, not ticket-creation time, anchors the timeline. Capture the first signal timestamp automatically.
- [ ] Templates are pre-filled from telemetry. The initial/intermediate/final reports should pull affected-function, duration, and impact data from the same dependency map you built in Pillar 1.
- [ ] Root-cause feeds back into design. Each final report should reference the architectural change it triggered. A post-incident review that closes with "we'll be more careful" fails the spirit of Article 17.
The pitfall: organizations build a beautiful classification matrix that lives in Confluence and is consulted manually at 3 a.m. by whoever is on call. Under pressure, people under-classify to avoid the reporting burden. Codify the thresholds so the system classifies, and your reporting becomes defensible rather than discretionary.
Pillar 3 — Digital Operational Resilience Testing: Prove It, Don't Assert It
Articles 24–27 set testing requirements that scale with the entity. Everyone must run a baseline testing program (vulnerability assessments, scenario tests, performance and penetration testing). Significant entities additionally face Threat-Led Penetration Testing (TLPT) — mandated in Articles 26–27 — roughly every three years, aligned to the TIBER-EU framework.
The architect's checklist:
- [ ] Test scope is derived from the CIF map. You test the functions that matter, with scenarios that reflect real failure modes of your topology — not a generic OWASP run.
- [ ] Scenario tests are chaos-engineering, not tabletop. Kill the primary region. Sever the third-party KMS. Inject latency into the shared identity service. If your DR plan has never survived an actual failover under load, you do not have a tested plan; you have a hypothesis.
- [ ] TLPT targets production-representative environments. A pen test against a sanitized staging env that diverges from prod is theater.
- [ ] Findings have owners and architectural remediation, not just patches. A recurring vulnerability class is a design problem.
The biggest trap is DR-test theater: a quarterly failover that runs in a controlled window, with traffic drained, that "passes" every time and proves nothing about a real incident. Test the way you'll fail: unannounced-ish, under realistic load, with the dependency you're least confident about as the thing you break.
Pillar 4 — ICT Third-Party Risk and the Register of Information
This is where DORA bites hardest, and where architecture and compliance finally converge. Articles 28–30 plus the ITS on the Register of Information require a machine-readable record of every ICT third-party arrangement — what the provider does, which CIF it supports, the contractual provisions, the concentration risk, and exit/substitutability.
- [ ] Register of Information is generated from your architecture, not hand-maintained. Every third-party dependency in your dependency graph should map to a register entry. If a service appears in your topology but not the register, that's a finding waiting to happen.
- [ ] Concentration risk is visible. If five "independent" critical functions all route to one cloud region or one KMS, that's a single point of failure the regulator will flag. Your architecture diagrams should make concentration obvious.
- [ ] Exit strategy is real and technical. "We could migrate" is not an exit plan. Which abstraction layer makes the provider swappable? Where is the lock-in? Document the substitutability per critical provider.
- [ ] Contracts carry the DORA-mandated provisions — audit rights, incident cooperation, sub-outsourcing transparency, service levels, termination triggers — for every provider tied to a critical-or-important function.
The pitfall here is the register drifting out of sync with reality. Teams ship a new SaaS integration on Tuesday and update the register next quarter. The fix is to make the register a derived artifact of your dependency model, so a new third-party edge in the architecture forces a register entry by construction.
Pillar 5 — Information Sharing, and the Evidence Backbone That Ties It All Together
Article 45 (cyber-threat information sharing) is the lightest pillar to implement — voluntary participation in threat-intelligence exchanges — but don't let its size hide the real lesson of DORA, which lives underneath all five pillars: the evidence backbone.
A supervisor's questions are almost always traceability questions:
- Show me the requirement (which DORA article).
- Show me the control that implements it.
- Show me the system/component the control lives in.
- Show me the operational evidence it works (a test, a log, a dated report).
If you can walk that chain for any pillar, you pass. If any link is a verbal hand-wave, you have a gap. This is why the best version of a DORA compliance checklist template is not a static PDF — it's a living traceability matrix keyed to your actual architecture, where each row links a regulatory requirement to a design element and a piece of evidence.
A minimal traceability row looks like this:
| DORA ref | Control | Architectural element | Evidence artifact |
|---|---|---|---|
| Art. 12 (backup) | RPO ≤ 15 min for payments CIF | payments-db async replica + PITR | Restore test 2026-04-30, 11-min RTO |
| Art. 28 (3rd party) | KMS substitutability | crypto-abstraction layer | Exit-plan doc + register entry |
| Art. 24 (testing) | Quarterly region-failover | multi-AZ active/passive | Chaos test report 2026-05-12 |
Build this once, keep it derived from your models, and every audit becomes a query instead of a fire drill.
How Architecture-First Tooling Closes the Traceability Gap
Everything above points to one conclusion: DORA compliance is downstream of good, documented, traceable architecture. The organizations that struggle are the ones whose architecture lives in stale diagrams and engineers' heads, so every pillar becomes a manual evidence-gathering exercise.
This is the gap Archiet is built to close. Because Archiet turns a requirements document into a formal architecture model (ArchiMate 3.2, DMN, BPMN) and keeps the model as the source of truth for generated code, the requirement-to-control-to-component-to-evidence chain isn't an afterthought you assemble before an audit — it's a property of how the system was designed. The dependency graph that DORA's Register of Information demands, the CIF-to-system map Pillar 1 requires, and the traceability matrix that satisfies a supervisor all fall out of the same formal model. If your DORA program is fighting the traceability gap, fixing the architecture-documentation layer is the highest-leverage move you can make.
Bottom line: treat a dora compliance checklist template not as a list to tick but as a set of architectural assertions you must be able to prove. Map every pillar to a design decision and a dated piece of evidence, keep that mapping derived from a living model, and the audit takes care of itself.