The DORA Compliance Officer's Daily Checklist: 15 Things to Monitor Every Day

Why Daily Monitoring Matters

DORA requires continuous operational resilience — not point-in-time compliance. Art. 6(5) mandates continuous identification of ICT risk sources. Art. 10 requires prompt detection of anomalous activities. Art. 17 requires mechanisms to detect, manage, and notify incidents. None of these can be achieved with quarterly reviews alone.

The compliance officer under DORA is not an auditor who checks boxes periodically. They are an operational monitor who maintains situational awareness of the institution's resilience posture daily. This checklist provides the structure for that daily discipline.

Each of the 15 items maps to a specific DORA article, has a defined data source, and includes red flag indicators that trigger escalation. The items are organized by DORA's five pillars, with cross-cutting governance items at the end.

Pillar I: ICT Risk Management Framework (Art. 5-16)

1. ICT Asset Register Changes

What to monitor: New assets added, assets decommissioned, classification changes, ownership changes.

Data source: ICT asset register change log, CMDB audit trail.

Red flags:

• Assets added without classification or owner assignment
• Critical asset ownership changes without documentation
• Shadow IT discoveries (assets found in production not in register)

DORA article: Art. 8 — identification and classification of all ICT assets.

Escalation: Any critical asset change without documented approval → notify IT risk manager same day.

2. Vulnerability Status

What to monitor: New vulnerabilities disclosed (CVE feed), patch status for critical systems, time-to-patch SLA compliance.

Data source: Vulnerability scanner dashboard, CVE feed aggregator, patch management system.

DORA article: Art. 9 — protection and prevention, including vulnerability management.

Escalation: Critical vulnerability unpatched > 48 hours on critical system → CISO escalation.

3. Capacity and Performance Indicators

What to monitor: CPU, memory, disk, and network utilization for critical systems. P95/P99 latency for critical services. Connection pool saturation.

Data source: Monitoring platform (Prometheus/Grafana, Datadog, etc.).

Red flags:

• Any critical system > 85% capacity sustained for 30+ minutes
• P95 latency > 2x baseline for any critical service
• Connection pool saturation events

DORA article: Art. 7 — reliable systems with sufficient capacity.

Escalation: Capacity breach on critical system → infrastructure team + IT risk manager immediately.

Pillar II: Incident Management (Art. 17-23)

4. Active Incidents

What to monitor: Open incidents, severity distribution, time since detection, resolution progress.

Data source: Incident management system.

Red flags:

• Critical or major incident without management body notification within 2 hours
• Any incident approaching Art. 19 reporting deadline without draft notification
• Incident without assigned incident manager > 30 minutes post-detection

DORA article: Art. 17 — incident management process; Art. 19 — regulatory reporting.

Escalation: Major incident without regulatory notification draft → compliance escalation immediately.

5. Incident Trend Analysis

What to monitor: Incident count vs. 30-day rolling average. Recurring incident patterns. Resolution time trends.

Data source: Incident management system analytics.

Red flags:

• Incident count > 2x 30-day average
• Same root cause appearing in 3+ incidents within 30 days
• Mean time to resolve (MTTR) increasing trend over 90 days

DORA article: Art. 13 — learning and evolving; Art. 17 — incident management.

Escalation: Recurring root cause pattern → IT risk committee; deteriorating MTTR → management body reporting.

Pillar III: Resilience Testing (Art. 24-27)

6. Testing Programme Progress

What to monitor: Tests scheduled vs. completed, overdue tests, coverage gaps.

Data source: Testing programme tracker, project management system.

Red flags:

• Tests overdue by > 30 days
• Critical function with no test in current quarter
• TLPT timeline at risk

DORA article: Art. 24 — testing programme requirements.

Escalation: Critical function untested > 90 days → resilience programme lead + CISO.

7. Test Findings and Remediation

What to monitor: Open findings from resilience tests, remediation SLA compliance, findings approaching deadline.

Data source: Finding/deviation tracking system.

DORA article: Art. 25 — corrective measures from testing.

Escalation: Critical finding overdue → CISO + IT risk committee; any overdue > 30 days past deadline → management body.

Pillar IV: Third-Party Risk Management (Art. 28-44)

8. Third-Party Service Availability

What to monitor: SLA performance of critical ICT third-party providers. Service degradations, outages, and near-misses.

Data source: Third-party monitoring dashboards, vendor status pages, observability platform.

Red flags:

• Critical third-party SLA breach (any duration)
• Multiple SLA breaches from same provider within 30 days
• Provider status page showing degraded service affecting institution

DORA article: Art. 28 — ICT third-party risk management.

Escalation: Critical provider outage → vendor management + business owner immediately; repeated breaches → contract review trigger.

9. Third-Party Risk Alerts

What to monitor: News alerts for critical vendors (breaches, acquisitions, regulatory actions, financial distress). Threat intelligence related to fourth-party dependencies.

Data source: Media monitoring, threat intelligence feeds, vendor financial monitoring services.

Red flags:

• Critical vendor data breach announced
• Critical vendor acquired by foreign entity
• Critical vendor financial distress indicators (credit downgrade, layoffs, regulatory action)

DORA article: Art. 28 — ongoing monitoring; Art. 28(8) — exit strategy readiness.

Escalation: Vendor breach → immediate assessment of institution's exposure; financial distress → exit strategy review.

10. Register of Information Currency

What to monitor: Register completeness, stale entries, new arrangements not yet registered.

Data source: Register of information, procurement records, contract management system.

Red flags:

• New ICT vendor contract signed but not yet in register > 5 business days
• Register entry with stale data (> 12 months since last review)
• Critical vendor with incomplete register fields

DORA article: Art. 28(3) — register of information on all ICT third-party arrangements.

Escalation: Stale critical vendor entry → vendor management lead; new contract unregistered > 5 days → procurement + compliance.

Pillar V: Information Sharing (Art. 45-49)

11. Threat Intelligence Review

What to monitor: New threat intelligence relevant to the institution's risk profile. ISAC alerts, ENISA advisories, sector-specific warnings.

Data source: ISAC membership portal, threat intelligence platform, ENISA threat landscape.

Red flags:

• Threat intelligence targeting the institution's sector, technology stack, or geographic region
• IOCs matching patterns observed in the institution's logs
• Active exploitation of vulnerabilities present in the institution's environment

DORA article: Art. 45 — information sharing arrangements.

Escalation: Active exploitation of present vulnerability → SOC + CISO immediately; sector-targeting threat → risk assessment update.

Cross-Cutting Governance

12. Audit Trail Integrity

What to monitor: Audit log volume consistency, gaps in logging, Merkle tree verification results.

Data source: Audit log system, integrity verification results.

Red flags:

• Gaps in audit logging (time periods with zero events from critical systems)
• Audit log volume significantly lower than baseline (may indicate logging failure)
• Integrity verification failure (tamper detection alert)

DORA article: Art. 5 — governance framework; Art. 6 — ICT risk management framework.

Escalation: Integrity verification failure → immediate investigation; logging gap → system admin + CISO.

13. Access Control Anomalies

What to monitor: Failed authentication attempts, privilege escalation events, access outside normal patterns.

Data source: IAM system, SIEM correlation rules.

DORA article: Art. 9(4)(a) — authentication and access control.

Escalation: Unauthorized privilege escalation → security incident; dormant account access → immediate lock + investigation.

14. Regulatory and Policy Updates

What to monitor: New guidance from EBA, ESMA, ECB, and national competent authorities. DORA RTS/ITS amendments. Industry best practice updates.

Data source: Regulatory monitoring service, ESA publication feeds, national authority newsletters.

Red flags:

• New RTS/ITS published with implementation deadline
• Supervisory guidance changing interpretation of existing requirements
• Enforcement action against a peer institution (lessons learned)

DORA article: Cross-cutting — all pillars affected by regulatory evolution.

Escalation: New RTS/ITS → impact assessment within 5 business days; enforcement action against peer → gap analysis within 10 days.

15. Board Reporting Pipeline

What to monitor: Data currency for Art. 14 management body reporting. Upcoming board meeting deadlines. KPI data quality.

Data source: Board reporting calendar, DORA KPI dashboard, report preparation tracker.

Red flags:

• Board meeting in < 10 days with ICT risk report not drafted
• KPI data stale > 7 days for a board-reported metric
• Significant risk development not reflected in draft board report

DORA article: Art. 14 — reporting to the management body.

Escalation: Board report not drafted < 10 days before meeting → CISO + CTO; stale KPI data → data source owner.

Implementing the Daily Checklist

Time Investment

The 15 items can be reviewed in 45-60 minutes per day if the data sources are accessible and the monitoring infrastructure is in place. The initial setup — configuring dashboards, alert feeds, and data sources — requires a one-time investment that pays back through structured daily discipline.

Automation Priority

Not all 15 items require manual daily review. Items 1-3 (asset changes, vulnerabilities, capacity) and items 8-9 (third-party availability, risk alerts) should be automated with exception-based alerting. The compliance officer reviews alerts, not raw data. Items 4-5 (incidents) and 12-13 (audit trail, access control) should be automated with daily summary reports. Items 6-7 (testing progress), 10-11 (register currency, threat intel), 14-15 (regulatory updates, board reporting) require deliberate daily review.

Key Takeaways

• DORA compliance requires daily operational monitoring, not periodic review. Art. 6(5) mandates continuous risk identification; Art. 10 requires prompt detection.
• 15 items across five pillars provide comprehensive daily coverage with defined data sources, red flags, and escalation triggers.
• Automation reduces daily review to 45-60 minutes. Invest in exception-based alerting and daily summary reports.
• Escalation triggers must be pre-defined so that red flags produce immediate action, not deferred investigation.
• The compliance officer's daily discipline is the mechanism that transforms DORA from a documentation exercise into operational resilience.

---

Resume en francais

La conformite DORA n'est pas un exercice annuel — c'est une discipline operationnelle quotidienne. L'article 6(5) exige l'identification continue des risques TIC, l'article 10 la detection rapide des anomalies. Ce guide propose 15 points de controle quotidiens organises par les cinq piliers de DORA : Pilier I — changements au registre d'actifs, statut des vulnerabilites, indicateurs de capacite. Pilier II — incidents actifs, analyse des tendances. Pilier III — avancement du programme de tests, remediation des constats. Pilier IV — disponibilite des tiers, alertes de risque, actualite du registre. Pilier V — revue du renseignement sur les menaces. Transversal — integrite de la piste d'audit, anomalies de controle d'acces, mises a jour reglementaires, pipeline de reporting au conseil. Chaque point a une source de donnees definie, des indicateurs d'alerte rouge et des declencheurs d'escalade. L'automatisation reduit la revue quotidienne a 45-60 minutes : alertes automatiques sur exception (10 min), rapports de synthese automatises (15 min) et revue manuelle deliberee (30 min).