Other frameworks
DORA: digital operational resilience
The Digital Operational Resilience Act applies to EU financial entities and the critical ICT third parties they rely on. If you're a bank, insurer, investment firm or payment provider, DORA is not optional. This guide covers what the law asks for and points you at the parts of the platform that genuinely help today.
Transcript
DORA applies to EU financial entities, and Article 28 requires a register of every ICT third party you depend on. It is about knowing which vendors could take your service down.
A concentration risk means too much depending on one provider with no way out. DORA wants you to see that dependency before it bites, and to have an exit strategy written down.
Open the Trust & Privacy Hub and go to Data & Vendors. This is the processor register, and it is where DORA's ICT dependency tracking lives alongside GDPR's Article 28 contracts.
Add a processor and record what they do, what data they touch, and where it is transferred. Mark it as a critical ICT provider if a failure would materially affect your operations.
Recording a processor captures the DPA status, the transfer mechanism, and whether a transfer impact assessment is needed. The risk tier updates automatically from how you answer.
DORA also wants continuous monitoring. Open Scan Connectors from Settings and connect AWS, Google Cloud, or container registries so infrastructure drift and misconfigurations are caught automatically.
DORA's third chapter is incident reporting. A major ICT incident is reported in stages: an initial notification, an intermediate report, and a final report, each against its own regulatory clock.
Open Incidents and Alerts, then DORA ICT Incidents, and log the incident with its severity, criticality, and how many clients it affects.
Each stage carries its own countdown, calculated from your organisation's configured reporting windows. Marking the initial notification sent starts the clock on the intermediate report.
The result covers all three of DORA's chapters in one place: a third-party register for Article 28, continuous monitoring for concentration risk, and a staged incident clock for Article 19, one source of truth instead of three.
Why this is required
Article 5 requires an ICT risk management framework, owned by management, not delegated to IT alone. Article 9 requires protection and prevention measures, including keeping systems patched. Article 17 requires an ICT-related incident management process, and Article 18 sets out how incidents are classified for reporting.
Articles 28 to 30 are where DORA reaches beyond your own organisation: a register of information on every ICT third party, oversight of concentration risk where too much depends on one provider, and mandatory contractual provisions covering audit rights, service levels and exit arrangements. Article 28 in particular is why vendor risk and DORA belong in the same conversation.
What EuroCompliant does
The Vendors & Processors tab is the natural home for the Article 28 register: name, service, data types, transfer country, and Data Processing Agreement status for every third party, alongside the transfer-mechanism and impact-assessment fields shared with GDPR Article 28. Dedicated critical-ICT-provider and exit-strategy flags exist in the platform's data model but aren't yet exposed as fields you can set on a processor; track that classification in the processor's description or an attached document for now.
Scan connectors for AWS, GCP, Docker registries and Microsoft 365 are explicitly framed around DORA: the AWS and GCP connectors describe themselves as scanning against CIS benchmarks and ICT resilience requirements from Articles 6 to 15, and the Docker registry connector against Article 9 patching service levels.
The Obligations page lists all 13 real DORA articles the platform covers, each classified honestly: some (like the incident-management process, Articles 17/18/23) are automatically evidenced once you've logged a real incident or generated an incident-response template; others (protection and prevention measures, contractual provisions, concentration-risk assessment) are manual checklist items with specific action guidance drawn from the real article text.
Walking through it
Enable DORA
Adds its obligations to your Obligations page; review them alongside, not instead of, the steps below.
Open /settings/profile?tab=frameworks →Build your third-party register
Record every ICT vendor and processor: what they do, what data they touch, and their DPA status. Note criticality and exit strategy in the description field until dedicated fields ship.
Open /privacy-hub →Connect infrastructure for resilience scanning
AWS, GCP, Docker and Microsoft 365 connectors give you dated, objective evidence against the technical resilience articles.
Open /settings/integrations?tab=scan-connectors →The law
Governance and organisation
The management body bears ultimate responsibility for the ICT risk management framework and must actively keep up to date on ICT risk.
Protection and prevention
Continuous monitoring and control of ICT systems, including timely patching.
ICT-related incident management
A process to detect, manage and notify ICT-related incidents.
General principles
A register of all contractual arrangements with ICT third-party providers, kept current, plus due diligence and exit strategies.
Penalties for non-compliance
DORA is enforced by national competent authorities under each member state's financial supervisory regime, with penalties set at national level; critical ICT third-party providers can additionally be brought under direct EU oversight with its own enforcement powers.
Frequently asked
Are we in scope for DORA?
If you're a bank, credit institution, investment firm, insurer, payment or e-money institution, or a similar regulated financial entity operating in the EU, yes. Certain critical ICT third-party providers to the financial sector are also brought into scope.
Why do three of the incident-management articles (17, 18, 23) show the same evidence status?
They're genuinely the same real artifact: Article 17 establishes the incident-management process, Article 18 defines the classification criteria used within it, and Article 23 extends that same process's scope to payment-related incidents for certain entity types. Logging a real incident or generating an incident-response template evidences all three.
Related guides
GDPR & privacy
How data protection obligations run alongside the AI Act, and the parts of the GDPR that carry operational consequences.
Automated Scanning: Continuous Telemetry and Scan Pipelines
How scheduled scan jobs, 12 scan engines and local PII scrubbing produce dated Article 10/15 evidence without moving data outside the EEA.
Integrations, scanning and vendor risk
Connecting your infrastructure for automated scanning, wiring up notifications, and tracking third-party risk.
Try it on your own systems
Everything in this guide runs in the live product. Start a free trial and follow along with your own data.
Start free trial