Infrastructure as Code security for NIS2 compliance

How to secure Infrastructure as Code, eliminate configuration drift, and ensure a reliable audit trail for NIS2 compliance.

The NIS2 directive imposes requirements on critical infrastructure organizations that go beyond the mere existence of cyber defense systems. Today, regulators demand a continuous, transparent, and documented evidence base for security. Under these conditions, traditional approaches to infrastructure administration involving manual server and network configuration become a critical risk factor.

According to the ENISA Threat Landscape 2025 report, 4,875 incidents were analyzed between July 1, 2024, and June 30, 2025. Essential entities under NIS2 criteria accounted for 53.7% of all affected organizations during the reporting period. This underscores the need to transition to more manageable and automated protection methods. Adopting the Infrastructure as Code (IaC) paradigm is no longer just an engineering optimization, but a fundamental requirement for maintaining system integrity and passing future audits.

Why NIS2 makes configuration auditing a legal obligation

The foundation of NIS2 compliance is an organization's ability to promptly prove that its current IT infrastructure operates in accordance with approved security policies. Continuous auditing and incident reporting require visibility into every system component.

Modern security architecture is based on comprehensive frameworks covering dozens of control points. For example, the Cisco Cybersecurity Readiness Index 2025 methodology is based on implementing 31 solutions across five key pillars of cyber defense. This index, formed based on a double-blind survey of 8,000 cybersecurity leaders across 30 markets, confirms that resilience is only possible through an automated and standardized approach to managing the IT environment.

Risk anatomy: how manual settings and configuration drift undermine security

The greatest threat to infrastructure compliance is configuration drift. This phenomenon occurs when system administrators make changes directly through a cloud provider's console or a server terminal, bypassing versioning and automated deployment processes.

Without strict control of infrastructure code, problems arise that are incompatible with NIS2 requirements:

  • Inconsistency between policies and reality: Documented security rules diverge from actual firewall settings due to manual intervention, creating unauthorized access points.
  • Lack of audit trail: When access rights are updated manually, no reliable event trail is generated. The absence of information regarding who, when, and why a configuration was changed makes passing an audit impossible.
  • Environment discrepancies: Differences in configurations between test and production environments can lead to successfully verified security patches failing in real-world conditions, leaving vulnerabilities exposed.

IaC as a tool for integrity control and audit trail creation

Transitioning to infrastructure management as code allows for the description of network, computing resource, and database settings using templates (e.g., Terraform or Ansible), which are stored in a version control system. In this case, Git becomes the single Source of Truth.

This automatically generates an immutable audit trail for every action, as all changes pass through commits and a code review procedure. The necessity of this approach is confirmed by cloud provider standards. As noted in the Microsoft Azure Well-Architected framework, governance policies are essential to prevent uncontrolled resource growth and deviations from standards. In turn, AWS Well-Architected emphasizes that resource attribution via tags makes infrastructure changes visible and accountable. Thanks to IaC, these policies and tags are applied automatically and centrally.

Integrating security into the deployment pipeline: from static analysis to guardrails

Implementing IaC does not in itself eliminate human error, so the deployment pipeline (CI/CD) must contain automated verification mechanisms (DevSecOps):

  1. Static analysis (IaC scanning): Using automated tools during pull request creation to detect hardcoded secrets, overly broad access rights, or open ports before they are deployed.
  2. Guardrails: Implementing the Policy as Code concept (e.g., using Open Policy Agent) to block changes that violate corporate security requirements.
  3. Drift detection: Continuous monitoring of the infrastructure and its comparison with the code. If manual interventions are detected, the system notifies the security team or automatically reverts the configuration to the reference state.

UnityBase platform as a technological foundation for NIS2 compliance

Compliance with security standards requires combining infrastructure control with metadata management at the application level. Systems handling sensitive data require strict access separation (RBAC/RLS) and immutable event auditing.

The platform foundation for developing and modernizing such enterprise systems is UnityBase, a full-stack JavaScript low-code / model-driven platform. It is a joint development by companies within the Intecracy Group alliance (where InBase is a key, but not the only, developer). By using Domain metadata, UnityBase integrates data models, APIs, user interfaces, and access rules into a single managed architecture.

For critical infrastructure organizations, the platform provides key compliance mechanisms: REST API generation directly from models (eliminating risks of manual database intervention) and system operation auditing (DataHistory). For high-load projects or environments with elevated cybersecurity requirements, the platform's official page recommends using commercial Enterprise or Defence editions. Specifically, the Defence edition offers advanced features such as integration with certificate authorities (CRL/OCSP) and authentication via private/public keys.

Checklist for IaC infrastructure readiness for NIS2 audits

To assess the maturity of infrastructure deployment processes, organizations should focus on the following basic criteria:

  • Configuration versioning: All infrastructure changes are stored in a version control system (Git), which acts as the single Source of Truth.
  • Automated vulnerability scanning: Static analysis tools for IaC templates detect hardcoded secrets and open ports at the CI/CD stage.
  • Configuration drift detection: Continuous monitoring is configured with automatic alerts for any unauthorized or manual changes.
  • Immutable event log: Logging of all actions in the deployment pipeline occurs with the provision of an immutable audit trail.
  • Principle of least privilege: Direct administrator access to the production environment is strictly limited; infrastructure changes are made exclusively through code.

FAQ

How does Infrastructure as Code help pass a NIS2 compliance audit?

IaC transforms infrastructure deployment into formalized code within a version control system. This generates an automatic and immutable audit trail for every change, allowing auditors to verify that the actual state of the IT environment aligns with approved security policies.

What is configuration drift and why is it a critical security violation?

Configuration drift is the discrepancy between the reference infrastructure description and its actual state due to manual changes. From a NIS2 perspective, this is unacceptable as it destroys system transparency, creates shadow vulnerabilities, and complicates recovery after cyber incidents.

Which IaC automation tools integrate with critical infrastructure security requirements?

A combination of resource management tools (Terraform, Ansible), code security scanners (Checkov, Tfsec), and policy verification systems (e.g., OPA) is used. At the enterprise application and metadata management level, this infrastructure foundation is complemented by secure platforms such as UnityBase (Enterprise or Defence editions).

Data sources