Starter contract

dora_ict_incident

30 rules · plain YAML · starts in observation mode

OpenDQV Cloud starter template (v0.1) — your tenant inherits this baseline. First customer edit creates v1.0 in your audit trail; pin by yaml_hash for replay. Digital Operational Resilience Act (DORA) — Regulation (EU) 2022/2554, Article 17–19. ICT-related incident report compliance contract for financial entities operating in the EU. DORA requires financial entities to classify and record ICT incidents and to report major ICT incidents in three stages (Article 19(4)): initial notification (within 4 hours of classification as major, no later than 24 hours from becoming aware), intermediate report (within 72 hours of the initial notification), and final report (within one month of the intermediate report) — time limits per Commission Delegated Regulation (EU) 2025/301. This contract enforces completeness at the point of write: entity type, incident classification, detection timestamp, reporting timelines, root cause for major/significant incidents, and remediation tracking. The omission failure mode: an ICT incident is recorded without classification, detection timestamp, or notification timestamp. The entity misses the statutory reporting window. Competent authority imposes administrative penalties under Article 50. For critical ICT third-party providers, competent authorities may, as a last resort, require financial entities to suspend or terminate use of the provider's services under Article 42(6).

These are starting points you own. Every rule below ships in the trial, starts in observation mode, and is yours to read, edit, or delete from day one. Rules that reference a lookup list (lookup_file) validate against reference data you control in your tenant.
Rules as at 29 August 2026 — starting points you own, not a maintained regulatory feed. We correct errors in these samples; tracking regulatory change in your active contracts is yours.
RuleFieldSeverityWhat it enforces (the message your team sees)
incident_id_requiredincident_iderrorincident_id is required — every ICT incident must be uniquely identifiable per Article 17(2) DORA (financial entities shall record all ICT-related incidents)
incident_id_uniqueincident_iderrorincident_id must be unique within this batch — duplicate incident identifiers compromise the incident register per Article 17(2) DORA (financial entities shall record all ICT-related incidents). Note: OpenDQV validates uniqueness within the input payload only; cross-batch uniqueness against the firm's incident register is the responsibility of the upstream system.
incident_title_requiredincident_titleerrorincident_title is required — a descriptive title is needed for the incident register per Article 17(2) DORA (financial entities shall record all ICT-related incidents)
entity_name_requiredentity_nameerrorentity_name is required — Article 19(1) DORA requires the reporting entity to be identified in the incident notification
entity_type_requiredentity_typeerrorentity_type is required — Article 2 DORA defines the financial entities in scope; the entity type must be recorded
entity_type_validentity_typeerrorentity_type must be one of the Article 2 DORA entity types: credit_institution, investment_firm, payment_institution, electronic_money_institution, crypto_asset_service_provider, central_counterparty, central_securities_depository, trade_repository, insurance_undertaking, reinsurance_undertaking, management_company, alternative_investment_fund_manager, ict_third_party_service_provider, other
incident_classification_requiredincident_classificationerrorincident_classification is required — ICT incidents are classified per the Article 18(1) criteria (clients affected, duration, geographical spread, data losses, criticality, economic impact); 'major' is determined against the RTS materiality thresholds (Article 18(3)); this template's severity enum is template-level
incident_classification_validincident_classificationerrorincident_classification must be one of: major, significant, minor — template-level enum; classification per the Article 18(1) criteria, with major determined against the RTS materiality thresholds (Article 18(3))
incident_description_requiredincident_descriptionerrorincident_description is required — Article 19(4) DORA requires a description of the incident including the nature and impact
affected_services_requiredaffected_serviceserroraffected_services is required — Article 18(1)(e) DORA (criticality of the services affected) requires identification of critical or important functions affected
detection_timestamp_requireddetection_timestamperrordetection_timestamp is required — Article 19(4)(a) DORA requires the date and time the ICT incident was detected
detection_timestamp_formatdetection_timestamperrordetection_timestamp must be a valid datetime (YYYY-MM-DD or YYYY-MM-DDTHH:MM:SS) — Article 19(4)(a) DORA
early_warning_timestamp_requiredearly_warning_timestamperrorearly_warning_timestamp is required — initial notification per Article 19(4)(a) DORA; due within 24 hours of awareness (CDR (EU) 2025/301 Art 5)
early_warning_timestamp_formatearly_warning_timestamperrorearly_warning_timestamp must be a valid datetime (YYYY-MM-DD or YYYY-MM-DDTHH:MM:SS)
early_warning_timelineearly_warning_timestamperrorearly_warning_timestamp must be within 1 day (24 hours) of detection_timestamp — initial notification per Article 19(4)(a) DORA; due within 24 hours of awareness (CDR (EU) 2025/301 Art 5)
initial_notification_timestamp_requiredinitial_notification_timestamperrorinitial_notification_timestamp is required — Article 19(4)(b) DORA intermediate report — within 72 hours of submission of the initial notification (CDR (EU) 2025/301 Art 5); this template approximates the window from detection_timestamp
initial_notification_timestamp_formatinitial_notification_timestamperrorinitial_notification_timestamp must be a valid datetime (YYYY-MM-DD or YYYY-MM-DDTHH:MM:SS)
initial_notification_timelineinitial_notification_timestamperrorinitial_notification_timestamp must be within 3 days (72 hours) of detection_timestamp — Article 19(4)(b) DORA intermediate report — within 72 hours of submission of the initial notification (CDR (EU) 2025/301 Art 5); this template approximates the window from detection_timestamp
root_cause_required_if_majorroot_causeerrorroot_cause is required when incident_classification is major — Article 19(4)(c) DORA (final report follows completion of root cause analysis)
root_cause_required_if_significantroot_causeerrorroot_cause is required when incident_classification is significant — template-level rule ('significant' applies to cyber threats under Article 18(2) DORA; Article 19(4)(c) ties the final report to completion of root cause analysis)
final_report_date_required_if_post_reviewfinal_report_dateerrorfinal_report_date is required when remediation_status is post_incident_review — Article 19(4)(c) DORA; due within one month of the intermediate report (CDR (EU) 2025/301 Art 5); this template approximates the window from detection_timestamp
final_report_date_formatfinal_report_dateerrorfinal_report_date must be a valid date (YYYY-MM-DD)
final_report_timelinefinal_report_dateerrorfinal_report_date must be within 30 days of detection_timestamp — Article 19(4)(c) DORA; due within one month of the intermediate report (CDR (EU) 2025/301 Art 5); this template approximates the window from detection_timestamp
remediation_status_requiredremediation_statuserrorremediation_status is required — track the current state of incident remediation per Article 17(3) DORA
remediation_status_validremediation_statuserrorremediation_status must be one of: investigating, contained, resolved, post_incident_review
remediation_date_required_if_resolvedremediation_dateerrorremediation_date is required when remediation_status is resolved — record when the incident was resolved per Article 17(3) DORA
remediation_date_formatremediation_dateerrorremediation_date must be a valid date (YYYY-MM-DD)
reviewed_by_requiredreviewed_byerrorreviewed_by is required — record who reviewed this incident report for DORA compliance
review_date_requiredreview_dateerrorreview_date is required
review_date_formatreview_dateerrorreview_date must be a valid date (YYYY-MM-DD)

Run your own data against this contract in the free trial — drop a CSV in the dashboard, no code, no credit card. Start free trial →