Continuous Assurance Under DORA: Moving Beyond Annual Compliance Checks
The 365-Day Blind Spot
On April 28, 2025, the Iberian Peninsula experienced a cascading power failure that disconnected Spain and Portugal from the European grid for hours. Financial services were disrupted across both countries. ATMs went dark. Payment terminals failed. Core banking systems switched to backup power — where backup power existed and had been tested.
On October 14, 2025, AWS experienced a 15-hour outage generating 17 million user reports across 60 countries. Barclays, Lloyds, Coinbase, and Capital One were among the financial institutions affected.
Between these two events — and the dozens of other cloud outages, cyberattacks, and infrastructure failures that occurred throughout the year — institutions that assessed their operational resilience annually had no systematic mechanism to detect how each incident changed their compliance posture. The testing programme completed in March was already outdated by April. The third-party risk assessment finalized in Q1 did not account for the CTPP designations announced in November.
This is the 365-day blind spot: the gap between annual compliance reviews and the continuous stream of events that alter an institution's actual resilience posture.
What DORA Actually Requires — and What It Implies
DORA Article 6(5) requires that the ICT risk management framework be "documented and reviewed at least once a year, or periodically in the case of microenterprises, as well as upon the occurrence of major ICT-related incidents." Article 6(8) adds that the framework must be "improved continuously on the basis of lessons drawn from implementation and monitoring."
The explicit requirement is annual review. The implicit requirement — derived from Art. 6(8)'s "improved continuously" language and Art. 13's mandate to "learn and evolve" — is that institutions must have the capability to detect and respond to changes in their resilience posture between annual reviews.
| DORA provision | Explicit requirement | Implied continuous capability |
|---|---|---|
| Art. 6(5) | Annual framework review | Event-triggered reassessment on major incidents |
| Art. 6(8) | Continuous improvement | Mechanism to detect improvement opportunities in real time |
| Art. 13 | Learn and evolve | Structured process for integrating lessons continuously |
| Art. 24(1) | Testing programme | Ongoing testing coverage monitoring, not just annual planning |
| Art. 11(6) | Review BCP at least annually | Recovery capability validation after significant changes |
The institutions that will meet supervisory expectations — not just the letter of the regulation — are those that implement continuous assurance: the ability to evaluate compliance posture in real time, detect degradation when it occurs, and trigger remediation before the annual review reveals the gap.
The Continuous Assurance Architecture
Continuous assurance replaces point-in-time assessments with a stream of structured claims — assertions — about the state of systems, controls, and processes. Each assertion is evaluated against policies, and failures trigger automated workflows.
The Assertion Model
An assertion is a structured, machine-readable claim about the state of a specific control, system, or process. It follows a simple pattern:
Subject (what is being assessed) + Claim (what is being asserted) + Result (PASS / FAIL / WARN / INFO) + Timestamp (when the assessment was performed) + Source (which system or process produced the assertion)
Examples of assertions in a DORA context:
| Subject | Claim | Result | Frequency |
|---|---|---|---|
| Core banking system | Backup completed successfully | PASS | Daily |
| Payment processing | RTO test completed within target | FAIL | Monthly |
| AWS third-party SLA | Uptime exceeded 99.95% threshold | PASS | Weekly |
| Incident response playbook | Tabletop exercise conducted | WARN (overdue) | Quarterly |
| ICT asset register | All critical assets have assigned owners | PASS | Weekly |
| Penetration test | No critical findings remain unresolved | FAIL | After each test |
| Employee training | 95% completion rate for ICT awareness | WARN (92%) | Monthly |
Freshness Thresholds
An assertion that passed six months ago is not evidence of current compliance. Freshness thresholds define how recently an assertion must have been evaluated to remain valid. These thresholds should vary by criticality tier:
| Criticality tier | Assertion type | Freshness threshold | Staleness action |
|---|---|---|---|
| Tier 1 (Critical) | Backup verification | 24 hours | Auto-alert + deviation |
| Tier 1 (Critical) | Recovery capability | 30 days | Auto-alert + escalation |
| Tier 2 (High) | Third-party SLA compliance | 7 days | Auto-alert |
| Tier 2 (High) | Vulnerability scan results | 14 days | Auto-alert |
| Tier 3 (Medium) | Training completion | 30 days | Dashboard warning |
| Tier 4 (Standard) | Policy review completion | 90 days | Dashboard warning |
When an assertion exceeds its freshness threshold without renewal, the system should treat the control as unverified — not as passing. Absence of evidence is not evidence of compliance.
The Evaluation Engine
Figure 1: The continuous assurance evaluation engine. Assertions flow from monitoring systems through ingestion, evaluation, scoring, and alerting, with critical failures automatically creating deviations in the corrective action workflow.
The evaluation engine operates on a continuous cycle:
- Ingest. Assertions arrive from monitoring systems, testing tools, third-party integrations, and manual attestations. Each assertion is validated against the expected schema (subject exists in asset register, claim maps to a known control, result is a valid enum).
- Evaluate. Each assertion is evaluated against the applicable policy: Does the result meet the threshold? Is the assertion within its freshness window? Does the assertion conflict with other recent assertions for the same subject?
- Score. Compliance scores are recalculated in real time as assertions arrive. A compliance score is not a single number — it is a multi-dimensional assessment across DORA pillars, criticality tiers, and entity types.
- Alert. Policy violations trigger alerts through configured channels (dashboard, email, escalation queue). Alert severity maps to the criticality tier of the affected control.
- Remediate. Critical assertion failures automatically create deviations (findings) in the corrective action workflow, with severity derived from the affected control's criticality tier.
From Annual Review to Continuous Posture
Figure 2: Traditional annual review vs. continuous assurance. The traditional model produces a sawtooth pattern of compliance; continuous assurance maintains steady posture with the annual review becoming a confirmation exercise.
The shift from annual to continuous assurance does not eliminate annual reviews. It transforms them from discovery exercises into confirmation exercises.
The Annual Review Under Traditional Compliance
Under the traditional model, the annual review is where the institution discovers its compliance gaps. Teams spend weeks gathering evidence, interviewing stakeholders, and assembling documentation. Findings are frequently surprises — gaps that existed for months but went undetected because no systematic monitoring was in place.
The result: a burst of remediation activity post-review, followed by gradual drift until the next annual cycle. This sawtooth pattern — improve after review, degrade until next review — is the fundamental weakness of point-in-time compliance.
The Annual Review Under Continuous Assurance
Under continuous assurance, the annual review confirms what the institution already knows. The compliance posture is visible in real time. Gaps are detected and remediated when they occur, not 11 months later. The annual review becomes a strategic exercise — assessing whether the framework itself is adequate — rather than an operational scramble to document what controls exist and whether they work.
The shift in resource allocation is significant. Institutions report spending 60-70% of their annual review effort on evidence gathering and gap identification. Under continuous assurance, that effort drops to 10-15%, freeing resources for strategic improvement, testing, and scenario analysis.
Practical Implementation: Where to Start
Implementing continuous assurance across all DORA pillars simultaneously is impractical. A phased approach prioritized by regulatory risk and operational impact provides the highest return.
Phase 1: Critical Infrastructure Monitoring (Months 1-3)
Start with assertions that can be automated from existing monitoring infrastructure:
- Backup completion status (daily assertions from backup systems)
- System availability against SLA thresholds (continuous assertions from monitoring)
- Vulnerability scan completion and findings status (assertions after each scan)
- Patch compliance for critical systems (weekly assertions from patch management)
These assertions require minimal manual effort because the data sources already exist. The implementation effort is in building the assertion ingestion pipeline and freshness monitoring.
Phase 2: Testing Programme Coverage (Months 3-6)
Extend to assertions about the testing programme:
- Testing programme completion against plan (assertions from test management)
- Recovery test results against RTO/RPO targets (assertions after each test)
- Penetration test findings remediation status (assertions linked to deviation workflow)
- Business continuity exercise completion (assertions from exercise records)
These assertions have longer freshness thresholds (monthly or quarterly) but are critical for DORA Pillar III compliance.
Phase 3: Third-Party and Governance (Months 6-12)
The most complex phase covers third-party risk and governance assertions:
- Third-party SLA performance against contractual thresholds
- Concentration risk metrics (HHI recalculation on provider changes)
- Contract clause compliance for critical providers
- Board reporting completion and training records
- Policy review and update completion
These assertions often require manual attestation or data from external sources, making automation more complex.
The Auto-Deviation Workflow
The most powerful capability of continuous assurance is automatic deviation creation. When an assertion fails above a configured severity threshold, the system creates a deviation (finding) in the corrective action workflow without human intervention.
The auto-deviation workflow follows this logic:
- Assertion failure detected. A FAIL result is recorded for a Tier 1 or Tier 2 control.
- Duplicate check. The system verifies no open deviation already exists for the same subject and claim. If a deviation is already open, the assertion failure is linked to the existing deviation rather than creating a duplicate.
- Deviation created. A new deviation is created with severity derived from the criticality tier, assigned to the control owner, and linked to the failed assertion as evidence.
- SLA clock starts. The deviation SLA (response time, resolution time) begins immediately — not when someone notices the gap during an annual review.
- Escalation. If the deviation is not acknowledged within the SLA response window, automatic escalation follows the institution's deviation management policy.
This workflow ensures that compliance gaps detected through continuous monitoring receive the same rigorous treatment as findings from formal examinations — with the advantage of detection in days rather than months.
Measuring Continuous Assurance Maturity
Not all institutions will reach full continuous assurance immediately. A maturity model provides a roadmap for progressive capability development.
| Maturity level | Characteristics | Assertion coverage | Detection latency |
|---|---|---|---|
| Level 1: Reactive | Annual reviews, manual evidence gathering | < 10% automated | 6-12 months |
| Level 2: Periodic | Quarterly assessments, some automated monitoring | 20-40% automated | 1-3 months |
| Level 3: Proactive | Monthly dashboards, automated critical assertions | 50-70% automated | 1-4 weeks |
| Level 4: Continuous | Real-time assertion streams, auto-deviation workflows | 80-95% automated | Hours to days |
| Level 5: Predictive | Trend analysis, predictive failure detection, proactive remediation | > 95% automated | Proactive (before failure) |
Most institutions begin at Level 1 or 2. The target for DORA compliance is Level 3, with progression toward Level 4 for critical controls. Level 5 is aspirational for most institutions but represents the direction of travel for industry leaders.
The Supervisory Expectation
Regulators have not explicitly mandated continuous assurance. But the supervisory direction is clear. The Joint ESA guidance on DORA oversight activities (July 2025) emphasizes "ongoing assessment" and "continuous monitoring" of ICT risk management frameworks. NCAs are building their own continuous supervisory capabilities — using Register of Information data, incident reports, and third-party intelligence to maintain a real-time view of supervised entities.
An institution that can demonstrate continuous compliance monitoring — with assertion trails, freshness verification, and automated deviation management — will present a fundamentally stronger posture to examiners than one that relies on annual reviews supplemented by ad-hoc monitoring.
Actionable Takeaways
- Audit your current detection latency. How long does it take your institution to detect a compliance gap? If the answer is "until the next annual review," you have a 365-day blind spot that continuous assurance can close.
- Start with what you can automate today. Backup verification, availability monitoring, and vulnerability scan results are already captured by existing systems. Build assertion pipelines from these sources first.
- Define freshness thresholds by criticality tier. Not every control needs daily validation. Align assertion freshness to the criticality of the control and the velocity of change in the underlying system.
- Implement auto-deviation for critical failures. Connect assertion failures to your corrective action workflow. A failed backup assertion for a Tier 1 system should create a deviation automatically, not wait for someone to notice.
- Measure and report assurance coverage. Track the percentage of DORA controls covered by automated assertions. Report this metric to the board alongside traditional compliance scores. It measures not just compliance but the institution's confidence in its compliance.
This guide reflects DORA Regulation (EU) 2022/2554 requirements for ICT risk management framework review. Evaluate your current posture with our self-assessment tool and continuous improvement. The continuous assurance architecture described represents an implementation approach aligned with supervisory expectations — not a regulatory mandate.