DORA
Europe's resilience rule for financial services. Major IT incidents have to be reported on tight statutory deadlines, in a fixed format: what failed, when, who was affected, how it was contained. IntentGate captures those fields on every authorization decision, so the report writes itself from the audit log instead of from a panicked log-grep across siloed systems. The table below maps each DORA article to the gateway output.
Obligation to evidence
| Obligation | IntentGate output |
|---|---|
| Art. 17 — ICT-related incident management process | Documented, repeatable process anchored on the audit chain; not ad-hoc forensics |
| Art. 18 — classification of ICT-related incidents | Refused-call type and severity captured per row; classifier rules in Rego |
| Art. 19(1) — initial notification of major ICT incident | Webhook on detection plus audit export for the affected window |
| Art. 19(1) — intermediate and final reports | Same chain queried at later timestamps; nothing new to reconstruct |
| Art. 6 — ICT risk management framework | The gateway as a documented preventive (refusal) and detective (audit) control |
| Art. 28 — ICT third-party risk management | Per-tool attribution: every agent action on a third-party API is named in the audit row |
DORA reviewers expect the incident report to align with the data fields in the Commission Delegated Regulation on incident reporting. The audit row already carries those fields by construction; the report is a query, not a reconstruction.
Want the mapping for your specific audit?
Each organisation has a different combination of regulations and a different audit cycle. We can walk through your specific obligations in a 30-minute call.
Start the conversation