DORA, reviewed in the pull request.
The Digital Operational Resilience Act makes ICT resilience a legal duty for EU banks, insurers, investment firms, and the providers they depend on. A lot of resilience is architecture and process, but the part that erodes quietly lives in code: the backup you disabled, the retry you removed, the third-party service you wired in without a register entry. Those are diff decisions with an article behind them.
No single change looks like a resilience failure.
DORA is the framework where the dangerous change is the one that looks like a cleanup. A retry that seemed redundant, a backup that seemed expensive, a dependency that seemed convenient. Each is reasonable on its own, and together they thin out the operational resilience the regulation requires an entity to be able to demonstrate. heygrc reads each change against the relevant article and names the resilience duty it touches, so the erosion is visible at the PR rather than at the next disruption or supervisory test.
The DORA duties a review can actually catch.
Each row is a real article reference and the kind of change that trips it. heygrc cites the article on the finding, not a vague resilience note.
- Art. 9protection and prevention
An access control, encryption setting, or network boundary protecting an ICT system is weakened or removed in the change.
- Art. 10detection
A pull request deletes the logging, alerting, or anomaly detection an entity relies on to notice an ICT problem promptly.
- Art. 11response and recovery
A retry, circuit breaker, failover, or recovery path is removed or disabled, eroding the ability to keep operating through and recover from a disruption.
- Art. 12backup and restoration
Backup scope, frequency, or restore tooling is reduced, or a new critical data store ships with no backup path at all.
- Art. 17ICT incident management
A change removes the classification, timestamping, or audit trail an entity needs to manage and later report an ICT-related incident.
- Art. 28ICT third-party risk
A new external ICT provider or critical dependency is wired in without the contractual and register controls the chapter requires.
- Art. 28(3)register of information
A change introduces or swaps a third-party ICT service that the register of contractual arrangements is supposed to track, with no entry.
A removed backup that weakens Art. 12.
A pull request drops a nightly backup step from a scheduled job to cut storage cost. The data it protected is operational ICT data the entity is expected to be able to restore.
jobs:
reconcile: { schedule: "0 2 * * *" }
- backup: { schedule: "0 3 * * *", target: ledger-db }- verify: { schedule: "0 4 * * *", target: ledger-db }This removes both the backup and its restore-verification for the ledger database. Art. 12 (backup and restoration) expects backup policies and tested restoration for ICT data like this, and Art. 11 covers the recovery it supports. If the cost is the concern, reduce frequency or move tiers rather than dropping the backup and its verification entirely.
A review, not a resilience programme.
heygrc flags changes that touch a DORA obligation and cites the article so the fix happens in the pull request. It does not run your ICT risk management framework, file your incident reports, or stand in for your resilience testing and governance. It catches the change early so a resilience gap is closed in code review instead of found under supervision. heygrc is in early access.