NIS2 technical controls for AWS, Azure and Kubernetes

Who NIS2 can apply to

NIS2 is Directive (EU) 2022/2555. A directive is implemented through national law, so what applies to you depends on three things: your sector, your size, and the member state (or states) where you operate. Some organisations are classed as essential entities and others as important entities, and the obligations, supervision and detail can differ between countries. Some suppliers and managed service providers are also pulled in indirectly, because their customers must manage supply chain risk.

We do not decide scope, and we would be wary of anyone who gives you a confident answer without reading your corporate structure. Confirm with your legal or compliance adviser first. Once you know which measures apply, the technical work is something we can scope clearly. If you are mapping several frameworks at once, our pages on GDPR and EU data residency, DORA and SOC 2 and ISO 27001 readiness cover the overlap. The compliance hub lists them all.

What Article 21 asks for, in engineering terms

Article 21 requires appropriate and proportionate technical, operational and organisational measures to manage risks to network and information systems. It lists minimum areas. The table below translates the ones that land in cloud and Kubernetes work, with the evidence each produces. Your adviser confirms the exact list for your national law.

Incident handling and logging for reporting readiness

NIS2 contains incident reporting obligations, with staged notifications to the competent authority or CSIRT. Who reports, what counts as significant and when are legal questions for your organisation and its advisers. The engineering question is narrower: when something happens, can your team reconstruct it fast and trust the answer?

That depends on a few things we build and check:

• Audit logs on by default. CloudTrail (AWS) or the Azure Activity Log, plus Kubernetes API audit logging, sent to a separate account or workspace that engineers cannot edit.
• Application and platform logs shipped to a central store such as Grafana Loki or your existing SIEM, with retention set by policy rather than by default.
• Metrics and alerting with Prometheus and Alertmanager, routed to a named on-call rotation. See monitoring with Grafana and Prometheus.
• Runtime detection with Falco, which flags suspicious behaviour inside containers such as unexpected shells or sensitive file reads.
• Consistent timestamps and identifiers, so events from the cloud control plane, the cluster and the application can be lined up on one timeline.

We write this into a runbook and test it: pick a past event, rebuild the timeline from logs alone, and note what was missing. For on-call process, see SRE and incident response and the observability and on-call setup package.

Business continuity, backup and recovery

A backup that has never been restored is an assumption. We configure backups for databases, volumes and cluster state, keep copies in a separate account or region you choose, and schedule restore tests that write a result you can file. In Kubernetes this typically means a tool such as Velero for cluster resources and volumes, plus native snapshots or point-in-time recovery for managed databases.

Recovery time and recovery point targets are business decisions. We help you measure what your current setup achieves and design to the targets you set. More detail is in backup and disaster recovery.

Supply chain security, secure development and vulnerability handling

Supplier risk in NIS2 includes the software you build on. In practice, that means knowing what is in your images and who provides your services.

# GitHub Actions step: fail the build on serious findings
- name: Scan image
  uses: aquasecurity/[email protected]
  with:
    image-ref: ${{ env.IMAGE }}
    severity: HIGH,CRITICAL
    exit-code: "1"
    ignore-unfixed: true

Trivy scans images, dependencies and infrastructure code in CI, and results are kept per build as evidence. We pair this with branch protection, mandatory pull request review, pinned base images and a documented patch cadence. We also build a simple supplier register: which SaaS tools, registries and cloud services touch production, and in which region. The CI/CD rebuild package is the usual route if your pipeline cannot enforce these gates today. Scanning finds known issues only, so it does not replace threat modelling or code review.

Access control, cryptography and MFA

Least privilege is the control auditors ask about first. On the cloud side we replace long-lived keys with roles and short-lived credentials, split production and non-production accounts, and remove unused permissions. Inside the cluster we use Kubernetes RBAC with namespaced roles, network policies to restrict pod traffic, and admission policies that block privileged workloads. Our Kubernetes production readiness review checks these on an existing cluster, and Kubernetes consulting covers fixes.

For cryptography we enable encryption at rest with managed keys, enforce TLS in transit and keep secrets in HashiCorp Vault or the cloud secret manager rather than in Git. MFA is enforced at the identity provider for console, CI/CD and administrative access. Key management choices (customer managed keys, rotation periods) are policy decisions we implement once you set them.

Evidence that comes from the system

Evidence collected by hand before an audit is slow and easy to dispute. We prefer evidence the system produces: infrastructure in Terraform with history in Git, pull request approvals, scan reports saved per build, backup and restore logs, and access exports on a schedule. We index them against each control so your team can answer a request without searching. A landing zone is a good foundation if your account structure is the gap, and the Cloud DevOps health check is a low-commitment first step.

What we do not do

• We do not interpret the Directive or decide whether you are in scope.
• We do not act as your regulator contact, submit incident notifications or hold the CISO role.
• We do not write board-level policies, risk assessments or training programmes.
• We do not provide an auditor’s opinion, certification or a statement that you comply.
• We do not copy production data to our systems.

Hire a specialist consultancy or lawyer for scope, governance and policy. You can read how we handle access and data in the Trust Center.

Common misunderstandings

• “Buying tooling makes us compliant.” Tools produce signals and evidence. Compliance also needs ownership, policy and review.
• “NIS2 is only about incident reporting.” Reporting is one part. Article 21 also covers prevention, continuity and supply chain.
• “One framework fits every country.” National implementation varies, so check each member state where you operate.
• “Backups are enough for continuity.” Only tested restores, with known recovery times, count.
• “Scanning solves supply chain risk.” It covers known vulnerabilities, not supplier governance.

If you want to talk through where your environment stands, book a consultation or see managed DevOps plans for ongoing operation of these controls.

References

• NIS2 Technical Implementation Guidance, ENISA
• NIS2 Directive: securing network and information systems, European Commission
• Cybersecurity Framework, NIST