Automating DORA compliance (Digital Operational Resilience Act) with n8n

Since January 17, 2025, the EU regulation DORA (Digital Operational Resilience Act, EU 2022/2554) has applied directly to financial entities and their critical ICT service providers — banks, payment institutions, insurers, asset managers, crypto-asset service providers, but also fintechs and neobanks that sometimes assumed a rule historically tied to large banks wouldn't reach them. Two obligations account for most of the operational load: keeping an up-to-date register of every contract with an ICT provider, submitted annually to the authorities by March 31 at the latest, and notifying any major ICT incident within 4 hours of classification. Two obligations that don't sit well with a shared spreadsheet, and that fit an n8n pipeline particularly well.

What DORA actually requires

Three pillars structure the regulation, with very different urgency levels:

• The information register (Article 28). Every financial entity must maintain an inventory of all its contracts with ICT providers — including cascading subcontracting, when a provider itself relies on a subcontractor. For each contract: the provider's identity and country, the function performed, its criticality level, start and end dates, and, for functions deemed critical or important, an assessment of the provider's substitutability. This register goes to the competent authorities (the ACPR or AMF in France, depending on the sector) by March 31 each year.
• Major incident notification. Classification criteria — number of affected clients, incident duration, financial impact, geographic scope — are set by the regulatory technical standards (RTS) published by the European Supervisory Authorities (EBA, ESMA, EIOPA) in 2024. Once an incident is classified as major, the initial notification is due within 4 hours, with an absolute cap of 24 hours after detection. An intermediate report follows within 72 hours, then a final report within one month.
• Proportionality. Micro-enterprises and small firms benefit from a simplified ICT risk management framework, but aren't exempt from the register or incident notification. Penalties, meanwhile, aren't symbolic: up to 2% of annual worldwide turnover for a financial entity, and up to 1% of average daily worldwide turnover for an ICT provider designated as critical by the authorities.

Why the 4-hour window changes everything

A 2024 review of the regulation published in the International Journal of Computer Engineering and Technology by Naga Ravi Kiran Alugoju, Digital Operational Resilience Act (DORA), notes that DORA's operational difficulty comes less from the severity of its requirements than from their simultaneity: risk management, resilience testing, subcontracting-chain governance, and incident reporting all have to move forward together, with compliance clocks that leave no slack once an incident is classified as major. That's exactly the kind of strict time pressure — combined with a register that needs to stay current continuously rather than being rebuilt once a year under deadline pressure — that an automated pipeline can absorb without a dedicated team.

Building the ICT register (Article 28) in n8n

The same principle already covered for the NIS2 checklist applies here: turn a static questionnaire into a structured conversational protocol, built on the Compliance & Audit Pack (€149).

1. Adapt the guided questionnaire bot to cover the Article 28 fields: provider identity, country, function performed, criticality level, contract dates, and — for critical functions — the substitutability assessment. One entry per contract, rather than a single form, avoids losing track along a long subcontracting chain.
2. Log every validated answer to Supabase via the audit logging workflow, the same pattern already used for the GDPR audit trail. That continuously updated, timestamped table is the real register — not a spreadsheet rebuilt the day before the deadline.
3. Generate the annual export with our n8n Excel/CSV extraction guide: a scheduled node queries the table a few weeks before March 31 and produces the structured file expected by the competent authority, ready to be reviewed rather than typed up by hand.
4. Chase incomplete or expired contracts with the automated follow-up workflow: a cron job flags records missing an end date, a substitutability assessment, or nearing contract expiry, and nudges the relevant procurement or legal owner.

Automating detection and notification within 4 hours

DORA's real difficulty isn't detecting an incident — it's meeting the deadline once it's classified as major. An n8n Error Workflow attached to your critical systems, paired with a secured webhook receiving alerts from your SIEM, cloud provider, or monitoring tool, can fire an immediate alert as soon as a severity threshold is crossed. Classification — does the incident cross the RTS's quantitative thresholds and warrant being labeled major? — stays a human decision, routed through a Wait-node approval in Slack: the workflow alerts and pre-fills the report fields from the available logs, and the compliance owner confirms the classification and starts the 4-hour clock knowingly. To pre-qualify severity automatically from raw logs without ever deciding ambiguous cases on its own, a Structured Output Parser downstream of an AI node structures the severity, the affected systems, and an estimated number of impacted clients into a format the decision-maker can act on directly.

Tracking resilience tests and recurring deadlines

DORA also requires regular digital operational resilience testing, with frequency scaling to the entity's size and risk profile. A properly configured Schedule Trigger can schedule reminders for the testing campaign, the register push ahead of March 31, and periodic reviews of contracts nearing expiry — the same mechanism already used for the GDPR audit trail or the NIS2 checklist, applied here to DORA's own calendar. For entities that also track technical security evidence in parallel (MFA actually enabled, backups actually tested), our article on automating ISO 27001 / SOC 2 compliance evidence covers how to pair this declarative tracking with technical, API-based collection.

Common pitfalls

• Treating the register as an annual exercise. A register rebuilt in February for the March deadline accumulates gaps in the cascading subcontracting chain; kept current contract by contract as you go, it only needs an export when the deadline arrives.
• Confusing detection with classification. The 4-hour clock starts at "major" classification, not at technical detection — a slow qualification process eats into the available margin before notification even begins.
• Forgetting cascading subcontractors. A critical provider that itself subcontracts an essential function must appear in the register; leaving it out exposes the entity at audit time, not just the subcontractor.
• Under-resourcing human review. Automation speeds up detection and drafts the report, but classifying an incident as "major" carries the entity's liability: it must stay a deliberate decision, not a threshold ticked off without a human look.

Going further

DORA combines a recurring documentation burden (the Article 28 register) with an extreme responsiveness requirement (4-hour notification) — two very different profiles that n8n can cover with the same building blocks: a conversational protocol, a Supabase audit trail, and automated follow-ups. The Compliance & Audit Pack (€149) provides these building blocks ready to adapt to the ICT register and DORA's calendar. For financial entities that also need to watch their inbox so they never miss a supplier alert or regulatory notice, the Complete FlowKit Bundle (€269) brings this pack together with the Inbox AI Pack (€79) and the RAG Assistant Pack (€119).