DORA Article-by-Article Summary

Bottom Line

DORA is not a documentation exercise. It is an operational mandate with teeth. If your ICT systems go down and you cannot show a tested recovery plan, a classified incident log, and a third-party register that is up to date — your regulator will find out, and the fine is calculated as a percentage of your daily worldwide turnover. The entities that are struggling are not the ones that ignored DORA entirely; they are the ones that treated it as a compliance tick-box and never tested whether their controls actually work.

What Auditors Will Actually Look For

• Board minutes showing the management body approved the ICT risk framework and reviewed it in the last 12 months
• A documented ICT asset inventory that is current — not one last updated two years ago
• Evidence that BCPs and DRPs have been tested, not just written — test reports with dates and outcomes
• An incident log covering the past 12 months with classification decisions documented for each event
• A third-party provider register with all mandatory fields populated and a review date in the last year
• Penetration test or TLPT results for systems supporting critical functions, plus remediation tracking
• Contracts with ICT providers that include Art. 30 mandatory clauses — auditors will ask to see three at random

Common Mistakes

• Treating the ICT risk framework as a Word document that lives in SharePoint — it must be tested, board-approved, and lived-in.
• Classifying every incident as "minor" to avoid the reporting clock — auditors check your incident log against your SLA breach records.
• Updating contracts with a side letter instead of a full renegotiation — many side letters do not satisfy the Art. 30 clause requirements.
• Assuming your cloud provider's compliance certifications cover your DORA obligations — they do not. You own the risk.

Chapter I — Scope: Are You In? (Arts. 1–4)

If you are a bank, insurer, investment firm, payment institution, crypto-asset service provider, or DORA-designated ICT provider, you are in scope. There is no opt-out.

• 22 entity types are covered — if you are regulated by EBA, ESMA, or EIOPA, assume you are in scope.
• Smaller entities qualify for a simplified regime (Art. 4) — but your competent authority decides eligibility, not you.
• Your ICT third-party providers are not directly subject to DORA, but your contracts with them must make them behave as if they are.

Chapter II — ICT Risk Management: The Engine Room (Arts. 5–16)

This is where most mid-market entities are exposed. Twelve articles covering governance, asset management, controls, detection, recovery, and continuous improvement.

• Art. 5: The board owns ICT risk. Not the CIO. Not the CISO. The board. If your board cannot describe your ICT risk appetite, that is a finding.
• Art. 6: You need a documented, tested, board-approved ICT risk management framework — reviewed at least annually.
• Art. 8: You cannot manage what you have not mapped. ICT asset inventory covering hardware, software, data, and third-party dependencies is mandatory.
• Arts. 9–10: Controls and detection must be in place for systems supporting critical functions — MFA, patching SLAs, and 24/7 monitoring are baseline expectations.
• Art. 11: Your RTO and RPO targets must be realistic and tested. Auditors will ask for the last DR test report. "We are planning one" is not an answer.
• Art. 12: Backup systems must be isolated. A backup that lives on the same network as the primary is not a backup — it is a liability.
• Art. 16: Simplified regime for small entities exists but does not eliminate obligations — it reduces their scope.

Chapter III — Incident Reporting: The Clock Starts at Classification (Arts. 17–23)

Miss a reporting deadline and you have committed a regulatory breach on top of whatever the incident itself cost you.

• Art. 17: Every ICT incident must be logged. No verbal-only handling. No "we will deal with it and see".
• Art. 18: Six criteria determine whether an incident is "major". You need a documented classification process — not a gut-feel decision made under pressure.
• Art. 19: Once classified as major, the clock runs: 4 business hours for initial notification, 72 hours for an intermediate report, 1 month for a final report.
• Art. 23: You can voluntarily report significant cyber threats even before they cause an incident. Doing so builds regulatory goodwill.

Chapter IV — Testing: Proof, Not Promises (Arts. 24–27)

Testing under DORA is not optional and it is not a one-off. It is a programme.

• Art. 24: All entities need a testing programme — vulnerability assessments at minimum, scenario-based exercises, and penetration testing for significant entities.
• Art. 25: Vulnerability assessments must be continuous, not annual snapshots. Critical vulnerabilities must be remediated within defined SLAs.
• Art. 26: Significant entities must conduct TLPT at least every 3 years on production systems. A standard penetration test does not satisfy this obligation.
• Art. 27: TLPT testers must meet independence and qualification standards — your internal red team almost certainly cannot run your TLPT without specific controls.

Chapter V — Third-Party Risk: Your Vendors Are Your Problem (Arts. 28–44)

Your cloud provider going down is your DORA problem, not theirs. Act accordingly.

• Art. 28: You need a complete register of all ICT service providers — not just the big ones. Shadow IT providers count.
• Art. 29: Due diligence before signing. If you onboarded a provider in 2024 without a risk assessment, that contract is a gap.
• Art. 30: Mandatory contractual clauses covering SLAs, audit rights, data location, sub-contracting, exit rights, and security standards. Auditors will read your contracts.
• Arts. 31–37: The ESAs will designate the largest cloud and tech providers as Critical Third-Party Providers and directly supervise them. This does not reduce your obligations.
• Art. 43: Exit strategies are mandatory for critical providers. "We would move to AWS" is not an exit strategy. A documented, costed, timeline-tested plan is.

Chapter VI — Intelligence Sharing (Art. 45)

One article, low operational burden, high regulatory goodwill.

• Joining a sector threat intelligence sharing arrangement is voluntary but demonstrates proactive risk management.
• If you share threat intelligence that includes personal data, GDPR obligations apply — get Legal involved before sharing.

3-Step Action Checklist

• 1. This week: Pull your ICT risk management framework and check the last board approval date. If it is more than 12 months ago or was never formally approved, schedule a board agenda item.
• 2. This month: Run an ICT asset inventory sweep. Map every provider, system, and dataset to the business function it supports. Identify gaps against Art. 8 requirements.
• 3. This quarter: Schedule a live DR test for at least one critical system. Document the outcome — RTO achieved or not, issues identified, remediation actions. That report is what your auditor will ask for first.