If you write software inside a bank, insurer, investment firm, payment institution, or another financial entity covered by DORA (the Digital Operational Resilience Act, Regulation (EU) 2022/2554), the regulation is already in force for your organisation. If you sell ICT services those entities use, the picture is more precise: DORA directly oversees designated critical ICT third-party service providers, while other providers mainly meet DORA-driven duties through the contracts and due-diligence their financial-entity customers pass through. Either way, a lot of the public write-up treats DORA as a board and risk-function problem: ICT risk frameworks, resilience testing, incident reporting to supervisors, key contractual provisions. That reading is correct for most of the regulation. It is incomplete for the part an engineer actually ships.
The incomplete part is the set of resilience decisions that live in the repository: a circuit breaker removed as "dead code," a backup retention cut to save storage, a new fraud API wired into the payments path with no register entry, a health-check or alert rule deleted because it was noisy. Each looks like ordinary engineering. Each thins out an obligation DORA names at the article level. This guide is for developers who need to know which articles show up in a pull request, what shape those changes take, and how to catch them without turning every review into a legal memo.
Who this is for (and who it is not)
You are in the audience if your code supports a financial entity covered by DORA, or if your product is an ICT service those entities use in production (whether you are a designated critical ICT third-party provider under direct oversight, or a provider bound mainly through customer contracts). Scope and designation under the regulation are legal and entity-classification questions, not something a code review decides. If your compliance or legal team has already told you DORA applies (directly or by contract), this guide is about the engineering half of that duty. If you are unsure whether you are in scope, stop here and ask them: the wrong answer is either under-investing in a real obligation or over-fitting a regulation that does not apply.
This is not a substitute for an ICT risk management framework, a resilience testing programme, an incident-reporting process, a third-party register, or key contractual provisions with ICT providers. heygrc does not run any of those. It is built to surface the moment a change in a pull request weakens or introduces a resilience-relevant control that those programmes assume still exist.
The articles that actually show up in a diff
Most of DORA will never appear as a line of application code. What does tend to land in a pull request clusters in a short list of articles. Art. 9 (protection and prevention): a change weakens access control, encryption, network segmentation, or another measure that keeps a critical ICT function isolated. Art. 10 (detection): logging, alerting, or anomaly detection that an entity relies on to notice an ICT problem promptly is removed or disabled. Art. 11 (response and recovery): a retry, circuit breaker, failover, timeout, or recovery path that kept a critical function alive through a disruption is deleted as cleanup. Art. 12 (backup and restoration): backup scope, frequency, or restore tooling is reduced, or a new critical store ships with no backup path. Arts. 17 to 19 (ICT-related incident management, classification, and reporting): a change strips identifying, tracking, logging, or recording of ICT-related incidents (Art. 17), or removes fields and signals the classification process (Art. 18) and major-incident reporting path (Art. 19) depend on. Art. 28 (general principles for ICT third-party risk), including the register of information under Art. 28(3): a new contractual arrangement for an ICT service is wired into production without being recorded on the register that is supposed to cover all such arrangements. Art. 30 (key contractual provisions): the arrangement is treated as "just another SaaS client" with no pointer to the contractual provisions chapter for ICT services, which is a separate duty from the Art. 28 register and governance work.
Those glosses are plain-English summaries for engineers, not the regulation's text. The framework deep dive at /frameworks/dora walks the resilience articles with the change shapes that trip them. The control-in-code pages for Art. 9 (protection and prevention) and Art. 11 (response and recovery) show worked diffs for flattened segmentation and a removed circuit breaker. This guide focuses on the article cluster that most often surprises product engineers: Art. 28 and Art. 30, when a convenient SaaS call becomes a production ICT dependency.
Worked example: a clean client that becomes an untracked ICT third party
A payments team wants faster fraud decisions. An engineer opens a pull request that replaces a slow internal rules path with a typed HTTP client to a new external "FraudScore" API. The client has timeouts, retries with backoff, structured error mapping, and a feature flag. Tests cover happy path and 5xx. The review comments are all about latency budgets and whether the flag defaults on or off. Nothing about the diff looks wrong as software: it is a well-formed integration.
What the PR does not include is any update to the register of information on contractual arrangements for ICT services (Art. 28(3)), or any pointer to the Art. 30 key contractual provisions that apply to ICT service arrangements generally (Art. 30(1) and (2)). Neither of those waits for someone to decide the call is "critical." Separately, if this fraud check sits on the path that authorises payments, the arrangement may support a critical or important function, which can trigger additional duties, including the Art. 28 exit-strategy requirements and Art. 29 concentration-risk assessment, and the enhanced contractual provisions in Art. 30(3). Shipping the client first and filing the register entry "later" is how a production dependency becomes invisible to the programme that is supposed to track every ICT service arrangement.
This is the shape a compliance-aware review is built to catch: not "is the HTTP client correct," but "did this change introduce or swap an ICT third-party service whose contractual arrangement Art. 28(3) expects on the register." A finding that cites Art. 28 / Art. 28(3) (and Art. 30 where contractual provisions are the gap) does not approve the vendor, draft the contract, classify criticality, or decide concentration risk. It makes the third-party duty visible while the author still has the PR open, so the register, classification, and contract steps can move with the code instead of weeks after production traffic depends on the new provider.
What to look for in review without becoming a DORA lawyer
When a change adds or swaps an outbound dependency that will run in production for a financial function, ask three engineering questions: is the contractual arrangement for this ICT service already recorded on our register of information (Art. 28(3)), including how the service is classified and whether it supports a critical or important function; does an outage of this call degrade a financial service enough that criticality and exit-plan work may apply; and does the same PR (or a linked change) update whatever internal checklist or ticket your risk team uses when a new ICT arrangement lands, including Art. 30 contractual-provision work if that is how your org tracks it. If the register answer is "no" or "unknown," the feature is incomplete from a DORA third-party standpoint even when it is complete as code. Criticality changes how much additional work follows; it does not decide whether the arrangement belongs on the register.
For resilience safeguards you already own, the tell is different: a PR whose summary is "cleanup," "remove dead code," or "reduce cost" that deletes retries, failovers, backups, isolation rules, or detection hooks on a critical path. Ask whether the system still meets the resilience property that safeguard was providing. Art. 9, 10, 11, 12, and the incident-management cluster in Arts. 17 to 19 are the usual citations when the answer is no. You do not need to quote the regulation. You need to name the property and refuse to merge until someone owns either restoring the safeguard or documenting an accepted change through your real change process.
Where heygrc fits, and the honesty boundary
heygrc is built to read each pull request against the frameworks you selected, including DORA when you have it enabled, and to name the article a change appears to touch (for example Art. 28(3) on a new ICT service arrangement missing from the register, Art. 11 on a removed recovery path). The finding is a review comment with the clause attached so the author and reviewer can decide with full information. It does not certify DORA compliance, replace your ICT risk framework, run your resilience tests, file your incident reports, maintain your third-party register, or draft Art. 30 contractual provisions. Those remain human and organisational duties. A green heygrc review is not a supervisory sign-off; it is an earlier, clause-grounded signal that a change moved something those programmes care about.
If your team already uses a bug or quality reviewer on the same pull request, keep it. Those tools ask whether the code is correct and safe. DORA questions are about operational resilience and ICT third-party duty. The FraudScore client above can be clean, typed, and well-tested and still leave Art. 28(3) unfinished. Run both layers; neither replaces the other.