How Infrastructure as Code Helps You Meet NIS2 Technical Requirements

NIS2 Article 21 mandates specific technical measures for cloud infrastructure. Infrastructure as Code makes those measures auditable, repeatable, and continuous, without a separate compliance process.

Tags: NIS2, Compliance, Infrastructure as Code, Azure, Governance, Security

NIS2 is live: what it means for cloud teams

The NIS2 Directive (EU 2022/2555) entered into force in January 2023 and required EU member states to transpose it into national law by October 2024. It now applies to approximately 160,000 entities across the EU, a tenfold increase from NIS1, covering essential and important entities in sectors including energy, transport, finance, health, digital infrastructure, and manufacturing.

Article 21 is the core technical obligation. It requires entities to take "appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems." The directive is deliberately non-prescriptive about specific tools, but it does enumerate the categories of measures that must be addressed.

NIS2 does not tell you which tools to use. It specifies outcomes: risk management, access control, incident handling, supply chain security, cryptography, business continuity. Infrastructure as Code is not a NIS2 requirement, but it is the most practical way to implement and evidence most of them.

Article 21 mapped to infrastructure patterns

Here is how the Article 21 technical measures map to concrete infrastructure patterns you can implement as code.

Policy-as-Code equals continuous compliance

The most significant shift NIS2 demands is treating compliance as a continuous state, not a point-in-time audit. Azure Policy-as-Code makes this practical. Every policy initiative (deny open NSGs, require private endpoints, enforce encryption, enforce tagging for cost and ownership attribution) is declared in Terraform and deployed through CI/CD. Violations are detected and reported automatically. New resources that do not meet policy standards are denied before they are created.

When your compliance posture is encoded in policy and enforced continuously, the evidence for an audit exists in your Git history and your Azure Policy compliance reports. There is no separate compliance workflow; the engineering workflow is the compliance workflow.

Azure Policy effect "Deny" blocks non-compliant resources at the ARM API level, before any data reaches them. This is stronger than detection-based compliance: you cannot create a non-compliant resource even if you try.

Audit trails via Git and Azure Policy

NIS2 Article 21 includes explicit requirements for audit logging and evidence of controls. Git provides the infrastructure audit trail: every change to every resource is a pull request with a reviewer, a timestamp, and a merge record. Azure Activity Logs provide the API-level audit trail for what was actually deployed. Combined, they answer the core compliance question: who changed what, when, and was it reviewed?

1. Change authored in Terraform
2. PR opened, security scan runs (Trivy)
3. Peer review and approval
4. Merge triggers CI pipeline
5. Terraform apply to target environment
6. Azure Activity Log records deployment
7. Azure Policy evaluates new resources
8. Sentinel ingests audit events

This pipeline produces an unbroken chain of custody from intent (the PR) to deployment (the apply) to operational state (the policy compliance report). That chain is what a NIS2 auditor or your national supervisory authority will want to see.

Supply chain security in CI/CD

NIS2 Article 21(2)(d) explicitly covers supply chain security. For cloud infrastructure, this translates to how you manage dependencies and access across your delivery pipeline. Three patterns address this directly: first, OIDC-based authentication for CI/CD pipelines eliminates stored credentials entirely; pipelines authenticate via short-lived tokens, not secrets. Second, Trivy or Checkov runs on every Terraform plan, blocking critical security misconfigurations before they reach any environment. Third, Dependabot or Renovate keeps Terraform provider versions and module dependencies current, reducing exposure to known vulnerabilities in your supply chain.

From assessment to implementation

The practical path to NIS2 cloud compliance starts with knowing where you stand. A structured assessment maps your current infrastructure controls against the Article 21 categories, identifies gaps, and prioritises them by risk and effort. From there, implementation follows a layered sequence: identity and access first (highest risk, clearest standards), then monitoring and logging (required for incident detection), then supply chain controls and policy enforcement.

We cover both the advisory and the delivery side of this. If you need to understand your current posture and build a remediation roadmap, our Advisory service provides structured assessments and architecture decision records. If you need the infrastructure built and the controls implemented as code, our Builders service delivers the Terraform modules, CI/CD pipelines, and Azure Policy initiatives. Both services lead to the same outcome: cloud infrastructure that is NIS2-ready and stays that way.