DORA and NIS2 Compliance for Infrastructure as Code: A Practical Guide

DORA (the EU Digital Operational Resilience Act) and NIS2 (the Network and Information Systems directive) both ask regulated organisations to manage ICT risk with "appropriate and proportionate technical measures," and both expect evidence, not just a policy document. For teams running infrastructure on Terraform, the practical question is: which pull request checks actually satisfy an auditor, and how do you produce evidence for them without a separate compliance project on top of your existing pipeline?

Both frameworks converge on the same underlying controls, even though the legal text differs:

• Change management — every infrastructure change went through a controlled, reviewed process, not an ad-hoc console edit.
• ICT risk assessment — changes were checked against known risk categories (misconfiguration, exposure, access control) before they went live.
• Resilience / operational continuity — the actual running state of infrastructure matches what was approved, so nothing has quietly drifted into a riskier configuration.
• Incident linkage — when something does go wrong, there's a record connecting the incident back to the change (or drift) that caused it.

DORA's change-management and ICT-risk articles are satisfied by gating every infrastructure pull request through the same review pipeline, rather than a separate compliance-only process:

• A Checkov security misconfiguration scan plus a policy gate runs on every change — this is your ICT risk assessment, evidenced per PR instead of per quarterly audit.
• Live-state drift detection proves the Terraform plan matches the real infrastructure before merge — this is the resilience/continuity control, checked continuously instead of sampled.
• Semantic recall surfaces prior incidents linked to the same resources at review time — this is the incident-linkage control, made visible to the reviewer instead of buried in a ticketing system.

NIS2 Article 21 requires "appropriate and proportionate technical measures" to manage risk — deliberately broad language, which in practice means auditors look for consistent, enforced controls rather than a specific tool:

• Checkov plus the policy engine flag misconfigurations before merge — the technical risk-management measure.
• A required GitHub Check gates merges, and drift detection blocks stale plans from being approved against — the enforcement measure that makes the control non-optional.
• An audit log records every decision (allowed, blocked, overridden) for later assessment — the accountability measure.

Passing a check is not the same as being able to prove, months later, that the check ran and what it found. Each pull request should produce a signed evidence record — the finding, the resource affected, the outcome (blocked or allowed), and a reference to which compliance article it maps to — so an audit becomes "export the evidence log for this period" instead of "reconstruct what happened from Slack and Git history." See the DORA evidence docs and NIS2 compliance docs for the config that turns this on.

Automated PR-time checks satisfy the technical-control layer of DORA and NIS2 — they don't substitute for the governance layer: risk registers, third-party risk assessments, incident reporting to regulators, and the rest of what a compliance program actually requires. Treat this as making the infrastructure-change portion of that program evidence-complete by default, not as compliance-in-a-box.