Tag Archives: EU Cybersecurity

KRITIS and NIS2 Compliance on AWS: A Technical Implementation Guide

AWS, Cloud Security, Compliance, Regulatory, , , , , , , ,

Germany’s energy sector got a rude awakening in February 2022 when the Rosneft Deutschland oil subsidiary – operator of refineries supplying roughly 12% of German fuel capacity – suffered a cyberattack that took down IT systems and disrupted supply chain visibility for weeks. The attackers had been inside the network for months. The incident triggered a formal BSI KRITIS notification under § 8b BSIG and illustrated exactly the gap that NIS2 was designed to close: critical infrastructure operators with sophisticated physical security and negligible cyber maturity, running IT architectures that no serious security team would have approved in 2015.

If you operate critical infrastructure in Germany, or run digital services that touch essential service operators, you are now subject to two overlapping regulatory frameworks: the German KRITIS regulation (the critical infrastructure provisions of the BSIG – Gesetz über das Bundesamt für Sicherheit in der Informationstechnik) and the EU NIS2 Directive (2022/2555, which replaces the original NIS Directive 2016/1148). Both are in force. Both carry material penalties. And unlike GDPR, where enforcement was slow to start, the BSI has been actively issuing compliance orders and escalating to fines for KRITIS-regulated entities that fail to demonstrate adequate technical measures.

This post documents how to implement the required controls using AWS-native services – not because AWS is the only valid answer, but because it is the platform I have done this on, and the mapping between regulatory obligations and AWS service capabilities is both specific and non-obvious enough to be worth documenting in full.

The Regulatory Landscape: What You Are Actually Dealing With

NIS2: The EU Baseline

NIS2 entered into force in January 2023. Member states had until 17 October 2024 to transpose it into national law. Germany missed that deadline – the domestic political calendar disrupted the legislative process and the draft NIS2UmsuCG stalled in the Bundestag. The European Commission issued a reasoned opinion against Germany on 7 May 2025, the formal step before infringement proceedings. The NIS2UmsuCG (NIS-2-Umsetzungs- und Cybersicherheitsstärkungsgesetz) was eventually passed by the Bundestag on 13 November 2025, amending the BSIG and several related statutes. The amended BSIG came into force on 6 December 2025. The BSI’s reporting portal went live on 6 January 2026, and the registration deadline for newly in-scope entities was 6 March 2026 – giving the roughly 29,500 entities newly captured by the expanded scope less than three months to register. If you read earlier analyses (including a previous version of this post) that placed transposition in “late 2024”, that timeline was the target; the actual German implementation landed more than a year late.

NIS2 creates two tiers of regulated entities:

  • Essential entities (EE): Energy, transport, banking, financial market infrastructure, health, drinking water, wastewater, digital infrastructure (IXPs, DNS providers, TLD registries, cloud providers, data centre operators, CDN providers, managed service providers, managed security service providers), public administration, and space. Thresholds: medium or large enterprises (≥50 employees or ≥€10M turnover) operating in these sectors.
  • Important entities (IE): Postal and courier services, waste management, chemicals manufacturing, food production, manufacturing of medical devices/computers/electronics/machinery/motor vehicles, digital providers (online marketplaces, search engines, social networks), and research organisations. Same size thresholds apply.

The practical distinction matters: essential entities face stricter supervision, mandatory incident notifications with tighter timelines, and higher maximum fines.

Article 21 is the core technical obligations article. It requires entities to implement “appropriate and proportionate technical, operational and organisational measures” across ten specific domains:

  1. Risk analysis and information system security policies
  2. Incident handling
  3. Business continuity (backup management, disaster recovery, crisis management)
  4. Supply chain security (including security in supplier and service provider relationships)
  5. Security in network and information systems acquisition, development and maintenance (including vulnerability handling and disclosure)
  6. Policies and procedures to assess the effectiveness of cybersecurity risk-management measures
  7. Basic cyber hygiene practices and cybersecurity training
  8. Policies and procedures on cryptography and, where appropriate, encryption
  9. Human resources security, access control policies and asset management
  10. Multi-factor authentication or continuous authentication solutions

Article 23 mandates incident notification:

  • Early warning to the national CSIRT (BSI in Germany) within 24 hours of becoming aware of a significant incident
  • Incident notification with initial assessment within 72 hours
  • Intermediate report (for ongoing incidents)
  • Final report within one month of incident notification

A “significant incident” is one that has caused or is capable of causing severe operational disruption, financial loss, or impact on other persons. The BSI has published guidance indicating that any incident affecting the availability or integrity of essential services qualifies.

Penalties under NIS2 / NIS2UmsuCG:

  • Essential entities: up to €10 million or 2% of global annual turnover, whichever is higher
  • Important entities: up to €7 million or 1.4% of global annual turnover
  • Management liability: Directors and senior management can be held personally liable for non-compliance – a provision that has no equivalent in GDPR.

KRITIS: The German Layer

KRITIS is the set of obligations in the BSIG (primarily §§ 8a–8f) that apply to operators of critical infrastructure – a definition distinct from NIS2’s “essential entities,” though there is substantial overlap.

The BSI’s KRITIS regulation (BSI-KritisV) sets sector-specific thresholds based on service delivery capacity. For example:

  • Energy: Operators of electricity generation/distribution above 420 MW installed capacity; natural gas supply above 1,580 MW; oil supply above 420 MW
  • Water: Drinking water supply to more than 500,000 people
  • Health: Hospitals with more than 30,000 inpatient cases per year; pharmaceutical manufacturers above defined production thresholds
  • Digital infrastructure: Internet exchange points with more than 1 Tbps throughput; DNS operators; PKI providers; data centres above 5 MW IT load

KRITIS operators face obligations beyond NIS2:

  • Must implement state-of-the-art technical and organisational measures (§ 8a BSIG) – verified against BSI’s own published standards and the BSI IT-Grundschutz compendium
  • Must audit and demonstrate compliance every two years, submitting evidence to the BSI (§ 8a(3) BSIG) – this is active auditing, not self-certification
  • Must register with the BSI and designate a point-of-contact available 24/7 (§ 8b BSIG)
  • Must report significant incidents to the BSI, initially anonymously if desired, within defined timeframes
  • Sanctions: fines up to €20 million for KRITIS-specific obligations under the amended BSIG

The BSI C5 Testat (Cloud Computing Compliance Criteria Catalogue) is the BSI’s cloud-specific audit framework. AWS holds a C5 Testat for its Frankfurt and Ireland regions, which you can download from AWS Artifact. This covers AWS’s side of the shared responsibility model – your workloads are your problem.

The relationship between the two frameworks is: NIS2 establishes the EU-wide floor; KRITIS extends that floor for the subset of operators that meet the size thresholds in the BSI-KritisV. Most KRITIS operators are also NIS2 essential entities. The applicable obligations are the union of both sets, and where they conflict, the stricter obligation applies.

Control Domain Mapping

Before diving into the AWS implementation, let me be explicit about what the regulatory frameworks actually require at the control level. The following maps NIS2 Article 21 obligations and KRITIS § 8a requirements to concrete control domains, then maps those to AWS services.

Risk Management and Asset Inventory

What NIS2/KRITIS require: A maintained inventory of information assets, regular risk assessments, documented security policies, and evidence that risks drive control selection.

AWS has no native “asset inventory” product, but you can build one from AWS Config and Systems Manager:

# Enable AWS Config in all accounts via Organizations
aws organizations enable-aws-service-access \
  --service-principal config.amazonaws.com

# Create a conformance pack that enforces REQUIRED_TAGS rule
# (forces asset classification tagging on all resources)
aws configservice put-conformance-pack \
  --conformance-pack-name "kritis-asset-tagging" \
  --template-s3-uri "s3://your-config-bucket/kritis-conformance-pack.yaml"

The Config conformance pack below enforces the tagging taxonomy required for an accurate asset register. KRITIS auditors expect resources to be classified by criticality, data classification, and owning business unit:

# kritis-conformance-pack.yaml (excerpt)
Resources:
  RequiredTagsRule:
    Type: AWS::Config::ConfigRule
    Properties:
      ConfigRuleName: required-tags-kritis
      Source:
        Owner: AWS
        SourceIdentifier: REQUIRED_TAGS
      InputParameters:
        tag1Key: DataClassification
        tag1Value: PUBLIC,INTERNAL,CONFIDENTIAL,RESTRICTED
        tag2Key: CriticalityTier
        tag2Value: KRITIS,HIGH,MEDIUM,LOW
        tag3Key: BusinessOwner
        tag4Key: ComplianceScope
        tag4Value: NIS2,KRITIS,BOTH,OUT-OF-SCOPE

Systems Manager Inventory gives you OS-level visibility – installed software, running processes, network configuration – which feeds into the asset register and is required for the vulnerability management programme:

# Query all instances for software inventory via SSM
aws ssm list-inventory-entries \
  --instance-id i-0abc123def456789 \
  --type-name "AWS:Application" \
  --query 'Entries[].{Name:Name,Version:Version}' \
  --output table

For the formal risk register, AWS Audit Manager lets you build a custom assessment framework that maps control objectives to AWS Config rules, CloudTrail events, and Security Hub findings, generating continuous evidence that risk assessments drive control decisions.

Incident Detection and Response

What NIS2/KRITIS require: Continuous monitoring capabilities, detection of security events, and a documented incident response process with the ability to notify the BSI within 24 hours.

The detection stack I build on AWS for KRITIS-scoped environments has three components that must all be active:

GuardDuty is the baseline. Enable it across all accounts via Organizations and ensure all three data source categories are active – CloudTrail management events, S3 data events, and DNS query logs. For Kubernetes workloads, enable EKS Runtime Monitoring. For EC2 workloads, deploy the GuardDuty agent. The default 90-day finding retention is insufficient for KRITIS audit purposes – configure findings to flow to a Security Hub in a dedicated Security account.

# Terraform: enable GuardDuty org-wide with all data sources
resource "aws_guardduty_detector" "main" {
  enable = true

  datasources {
    s3_logs {
      enable = true
    }
    kubernetes {
      audit_logs {
        enable = true
      }
    }
    malware_protection {
      scan_ec2_instance_with_findings {
        ebs_volumes {
          enable = true
        }
      }
    }
  }

  finding_publishing_frequency = "FIFTEEN_MINUTES"
}

resource "aws_guardduty_organization_configuration" "auto_enable" {
  auto_enable_organization_members = "ALL"
  detector_id                      = aws_guardduty_detector.main.id

  datasources {
    s3_logs {
      auto_enable = true
    }
    kubernetes {
      audit_logs {
        enable = true
      }
    }
    malware_protection {
      scan_ec2_instance_with_findings {
        ebs_volumes {
          auto_enable = true
        }
      }
    }
  }
}

Security Hub aggregates findings from GuardDuty, Inspector, Macie, Config, and third-party tools into a single pane. Enable the CIS AWS Foundations Benchmark standard (v1.4 or v3.0) and the AWS Foundational Security Best Practices standard. Both are mapped to NIS2 Article 21 obligations in AWS’s published compliance mapping document, available from AWS Artifact.

The critical Security Hub configuration for KRITIS environments is enabling finding aggregation across all regions into a single aggregation region (eu-central-1 for Germany-primary deployments):

resource "aws_securityhub_finding_aggregator" "central" {
  provider     = aws.security_account
  linking_mode = "ALL_REGIONS"
}

# Enable both standards in every account
resource "aws_securityhub_standards_subscription" "cis" {
  standards_arn = "arn:aws:securityhub:::ruleset/cis-aws-foundations-benchmark/v/1.4.0"
}

resource "aws_securityhub_standards_subscription" "fsbp" {
  standards_arn = "arn:aws:securityhub:eu-central-1::standards/aws-foundational-security-best-practices/v/1.0.0"
}

Business Continuity and Disaster Recovery

What NIS2/KRITIS require: Documented RTO/RPO objectives, tested backup procedures, and crisis management capability. For KRITIS operators, availability guarantees are a legal obligation – the BSI can require specific RTO targets.

AWS Backup provides centralised backup management across EC2, EBS, RDS, DynamoDB, EFS, FSx, and S3. For KRITIS environments, configure backup plans with cross-region copies to eu-west-1 (Ireland) as the DR region:

resource "aws_backup_plan" "kritis_critical" {
  name = "kritis-critical-tier"

  rule {
    rule_name         = "daily-backup-critical"
    target_vault_name = aws_backup_vault.primary.name
    schedule          = "cron(0 2 * * ? *)"
    start_window      = 60
    completion_window = 180

    lifecycle {
      cold_storage_after = 30
      delete_after       = 2557  # 7 years (KRITIS audit retention)
    }

    copy_action {
      destination_vault_arn = aws_backup_vault.dr_region.arn

      lifecycle {
        cold_storage_after = 30
        delete_after       = 2557
      }
    }
  }

  # Continuous backup for point-in-time recovery (RDS)
  rule {
    rule_name         = "continuous-pitr"
    target_vault_name = aws_backup_vault.primary.name
    schedule          = "cron(0 * * * ? *)"
    enable_continuous_backup = true
  }
}

resource "aws_backup_vault_lock_configuration" "kritis" {
  backup_vault_name   = aws_backup_vault.primary.name
  changeable_for_days = 3
  max_retention_days  = 2557
  min_retention_days  = 7
}

The aws_backup_vault_lock_configuration resource enables Vault Lock – WORM protection for backup data that prevents any principal, including the root account, from deleting backups before the minimum retention period. This is a hard requirement when auditors need to verify that backup integrity was maintained.

For DR testing, document actual RTO measurements. BSI auditors will ask for evidence of tested DR procedures, not just documented procedures. Automate DR drills with AWS Fault Injection Simulator (FIS) and capture the results as Audit Manager evidence.

Supply Chain Security

What NIS2/KRITIS require: Assessment of security risks in the supply chain, including software supply chain risks. Article 21(2)(d) explicitly requires entities to address security in supplier and third-party service provider relationships.

The software supply chain controls in an AWS environment focus on three areas:

Container image integrity: Use Amazon ECR with image scanning enabled (both basic scanning for OS CVEs and enhanced scanning powered by Inspector). Enforce signed images using AWS Signer and OPA/Gatekeeper policies in EKS that reject unsigned images:

# Configure ECR enhanced scanning on push
aws ecr put-registry-scanning-configuration \
  --scan-type ENHANCED \
  --rules '[{"repositoryFilters":[{"filter":"*","filterType":"WILDCARD"}],"scanFrequency":"CONTINUOUS_SCAN"}]'

# Generate SBOM for an ECR image (Inspector exports to S3)
aws inspector2 create-sbom-export \
  --resource-filter-criteria '{"ecrImageTags":[{"comparison":"EQUALS","value":"prod"}]}' \
  --report-format CYCLONE_DX_1_4 \
  --s3-destination '{"bucketName":"sbom-archive","keyPrefix":"2026/05/"}'

Package dependency management: Route all package manager traffic through AWS CodeArtifact. This gives you a proxy that caches approved packages, blocks typosquatting attacks, and lets you enforce version pinning for KRITIS-critical services:

# Create a CodeArtifact upstream proxy for PyPI
aws codeartifact create-repository \
  --domain kritis-domain \
  --repository pypi-proxy \
  --upstreams '[]'

aws codeartifact associate-external-connection \
  --domain kritis-domain \
  --repository pypi-proxy \
  --external-connection public:pypi

Third-party vendor assessment: Build a supplier security questionnaire process in Audit Manager. Map your critical suppliers (cloud sub-processors, software vendors with privileged access) to custom controls, and use Audit Manager’s evidence collection to track questionnaire responses and annual assessments. NIS2 Art. 21(2)(d) requires you to document these assessments – Audit Manager gives you a structured, auditable record.

Access Control and Identity Management

What NIS2/KRITIS require: Access control policies, MFA for all privileged access, and (for KRITIS) privileged access management. Article 21(2)(i) explicitly mentions MFA and continuous authentication.

The identity architecture for KRITIS environments should be built on three layers:

AWS Organizations + Service Control Policies (SCPs): SCPs are the last line of defence against insider threats and compromised management accounts. They operate on every API call regardless of identity – you cannot grant a permission that violates an SCP even with AdministratorAccess. Critical SCPs for KRITIS compliance:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDisableCloudTrail",
      "Effect": "Deny",
      "Action": [
        "cloudtrail:DeleteTrail",
        "cloudtrail:StopLogging",
        "cloudtrail:UpdateTrail"
      ],
      "Resource": "*"
    },
    {
      "Sid": "EnforceEUDataResidency",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "eu-central-1",
            "eu-west-1",
            "eu-west-2",
            "eu-west-3",
            "eu-north-1",
            "eu-south-1"
          ]
        }
      }
    },
    {
      "Sid": "DenyLeaveOrganization",
      "Effect": "Deny",
      "Action": [
        "organizations:LeaveOrganization"
      ],
      "Resource": "*"
    },
    {
      "Sid": "RequireMFAForSensitiveActions",
      "Effect": "Deny",
      "Action": [
        "iam:DeleteRole",
        "iam:DeletePolicy",
        "iam:AttachRolePolicy",
        "kms:ScheduleKeyDeletion",
        "kms:DisableKey"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

The EnforceEUDataResidency SCP is critical for GDPR compliance (data residency) and for KRITIS operators whose authorisation to use cloud infrastructure may be conditioned on EU data residency. The list of EU regions is exhaustive as of 2026 – verify this against AWS’s current region list when implementing.

IAM Identity Center with phishing-resistant MFA: Configure IAM Identity Center (formerly AWS SSO) as the single entry point for all human access. Integrate with your corporate IdP (Okta, Azure AD, or similar) via SAML 2.0 or SCIM. Enforce phishing-resistant MFA at the Identity Center level – FIDO2 security keys (YubiKey, etc.) not TOTP – for all KRITIS-scoped accounts.

IAM Access Analyzer is your continuous least-privilege enforcement tool. Run it in all accounts and in your Organizations management account. The external access analyser flags resource policies (S3, KMS, IAM, SQS, Lambda) that grant access to external principals. The unused access analyser generates periodic reports of IAM roles and users that have granted permissions not exercised in the review period – the raw material for quarterly access reviews:

# List unused access findings (roles with permissions not exercised in 90 days)
aws accessanalyzer list-findings \
  --analyzer-arn arn:aws:access-analyzer:eu-central-1:ACCOUNT:analyzer/unused-access \
  --filter '{"status": {"eq": ["ACTIVE"]}, "findingType": {"eq": ["UnusedPermission"]}}' \
  --query 'findings[].{Resource:resource,Principal:principal,LastAccess:updatedAt}' \
  --output table

Encryption and Data Protection

What NIS2/KRITIS require: Cryptography and encryption policies (Art. 21(2)(h)). For KRITIS, the BSI TR-02102 technical guidelines specify approved algorithms and key lengths. For personal data, GDPR Article 32 adds an encryption obligation.

All data at rest in a KRITIS environment must be encrypted with customer-managed KMS keys (CMKs), not AWS-managed keys. This distinction matters: with CMKs, you control the key policy, you can restrict which IAM principals can use the key, and you have audit visibility into every encryption/decryption operation via CloudTrail. With AWS-managed keys, you do not.

resource "aws_kms_key" "kritis_data" {
  description             = "KRITIS data encryption key - production"
  key_usage               = "ENCRYPT_DECRYPT"
  customer_master_key_spec = "SYMMETRIC_DEFAULT"
  enable_key_rotation     = true  # Annual automatic rotation

  deletion_window_in_days = 30  # Maximum protection against accidental deletion

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "EnableIAMUserPermissions"
        Effect = "Allow"
        Principal = {
          AWS = "arn:aws:iam::${var.account_id}:root"
        }
        Action   = "kms:*"
        Resource = "*"
      },
      {
        Sid    = "AllowKRITISApplicationUse"
        Effect = "Allow"
        Principal = {
          AWS = var.application_role_arns
        }
        Action = [
          "kms:Decrypt",
          "kms:GenerateDataKey",
          "kms:DescribeKey"
        ]
        Resource = "*"
      },
      {
        Sid    = "DenyKeyDeletionWithoutMFA"
        Effect = "Deny"
        Principal = {
          AWS = "*"
        }
        Action = [
          "kms:ScheduleKeyDeletion",
          "kms:DisableKey"
        ]
        Resource = "*"
        Condition = {
          BoolIfExists = {
            "aws:MultiFactorAuthPresent" = "false"
          }
        }
      }
    ]
  })
}

For KRITIS operators with hardware key control requirements (some energy and finance sector regulators mandate HSM-backed keys), use AWS CloudHSM with the EXTERNAL_KEY_STORE (XKS) feature. This keeps key material in an HSM you control, while retaining native AWS KMS integration. The latency penalty is approximately 3–5ms per crypto operation – evaluate this against your application performance requirements before committing.

Data in transit: enforce TLS 1.2 minimum, TLS 1.3 preferred, across all internal and external communication paths. AWS Certificate Manager manages certificates. Use an SCP to deny the creation of HTTP listeners on load balancers:

{
  "Sid": "DenyHTTPLoadBalancerListeners",
  "Effect": "Deny",
  "Action": "elasticloadbalancing:CreateListener",
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "elasticloadbalancing:Protocol": "HTTP"
    }
  }
}

Amazon Macie runs continuous classification jobs against your S3 buckets, identifying objects that contain PII, PHI, financial data, or credentials. For KRITIS-scoped S3 buckets, run daily Macie jobs and pipe findings to Security Hub. Any Macie finding indicating sensitive data in an unencrypted or public bucket should trigger an automated remediation via EventBridge and Lambda – the regulatory exposure from unencrypted personal data is compounded by GDPR if the data relates to individuals.

Vulnerability Management and Patching

What NIS2/KRITIS require: Vulnerability handling and disclosure policies (Art. 21(2)(e)). In practice: you need a continuous vulnerability scan, a documented process for prioritising and remediating findings, and evidence of timely patching.

Amazon Inspector v2 provides continuous vulnerability scanning for EC2 instances, ECR container images, and Lambda functions – no agent required for EC2 beyond the SSM agent. Inspector uses both CVE databases and a proprietary reachability analysis to produce an “Inspector score” that combines CVSS base score with environment-specific factors (internet exposure, presence of known exploit code).

The EPSS (Exploit Prediction Scoring System) integration in Inspector v2 is particularly useful for KRITIS prioritisation: it gives the probability of exploitation in the wild within 30 days. Prioritise vulnerabilities with EPSS > 0.1 (10%) regardless of CVSS score – CVSS measures theoretical severity, EPSS measures actual attacker interest.

# List CRITICAL findings across all accounts with EPSS > 0.1
aws inspector2 list-findings \
  --filter-criteria '{
    "findingStatus":[{"comparison":"EQUALS","value":"ACTIVE"}],
    "severity":[{"comparison":"EQUALS","value":"CRITICAL"}],
    "findingType":[{"comparison":"EQUALS","value":"PACKAGE_VULNERABILITY"}]
  }' \
  --query 'findings[?epss.score>`0.1`].{
    Resource:resources[0].id,
    CVE:packageVulnerabilityDetails.vulnerabilityId,
    CVSS:packageVulnerabilityDetails.cvss[0].baseScore,
    EPSS:epss.score,
    Title:title
  }' \
  --output table

For patching, AWS Systems Manager Patch Manager is the operational layer. Define patch baselines that specify: which packages require patching, the severity threshold (Critical and Important for KRITIS, not just Critical), and the maximum allowed time between patch availability and application. For KRITIS environments, I configure a 72-hour maximum for critical patches on internet-exposed systems, 14 days for all other critical patches.

resource "aws_ssm_patch_baseline" "kritis_linux" {
  name             = "kritis-rhel8-baseline"
  operating_system = "REDHAT_ENTERPRISE_LINUX"
  description      = "KRITIS patch baseline - 72h critical, 14d important"

  approval_rule {
    approve_after_days  = 3  # 72 hours
    enable_non_security = false

    patch_filter {
      key    = "CLASSIFICATION"
      values = ["Security"]
    }
    patch_filter {
      key    = "SEVERITY"
      values = ["Critical"]
    }
  }

  approval_rule {
    approve_after_days  = 14
    enable_non_security = false

    patch_filter {
      key    = "CLASSIFICATION"
      values = ["Security"]
    }
    patch_filter {
      key    = "SEVERITY"
      values = ["Important"]
    }
  }

  rejected_patches = []
  rejected_patches_action = "BLOCK"
}

Network Security and Segmentation

What NIS2/KRITIS require: Network security measures (Art. 21(2)(h)). The BSI IT-Grundschutz NET.1.1 building block specifies network architecture requirements including segmentation, monitoring, and filtering.

The architecture I implement for KRITIS environments uses a hub-and-spoke VPC model:

  • Inspection VPC: Centralised egress and east-west inspection via AWS Network Firewall. All traffic leaving any spoke VPC, and all cross-VPC traffic, passes through the inspection VPC. The Network Firewall uses Suricata-compatible rule groups – you can import commercial threat intelligence feeds directly.
  • DMZ VPC: Public-facing workloads only. Contains the load balancers, WAF, and CloudFront distributions. No direct database access from this VPC.
  • Application VPC(s): No internet route. All outbound AWS API calls via VPC interface endpoints (PrivateLink), eliminating internet egress for control plane traffic.
  • Data VPC: No route to the internet or to the application VPC except via specific, stateful security group rules. Contains all persistent data stores.

The critical Network Firewall configuration for KRITIS environments enforces known-bad domain blocking and anomalous protocol detection:

resource "aws_networkfirewall_rule_group" "kritis_domain_denylist" {
  capacity = 1000
  name     = "kritis-domain-denylist"
  type     = "STATEFUL"

  rule_group {
    rules_source {
      rules_source_list {
        generated_rules_type = "DENYLIST"
        target_types         = ["HTTP_HOST", "TLS_SNI"]
        targets = [
          ".tor2web.org",
          ".onion",
          # Import threat intel feed domains here
        ]
      }
    }

    stateful_rule_options {
      rule_order = "STRICT_ORDER"
    }
  }
}

For the data plane, VPC Flow Logs must be enabled on every VPC, capturing all traffic (not just rejected traffic). Store logs in S3 with Glacier lifecycle transitions, and make them queryable via Athena for incident investigation. BSI auditors will expect network traffic visibility during incident post-mortems.

Logging, Monitoring, and Audit Trails

What NIS2/KRITIS require: Audit trails that support incident investigation and compliance verification. The BSI IT-Grundschutz DER.2.1 (Incident management) building block requires event logs that cannot be manipulated by any account under investigation.

The logging architecture for tamper-evident audit trails:

CloudTrail must be configured as an org-wide trail with:

  • Log file validation enabled (SHA-256 hash chaining – detects any modification, deletion, or insertion of log files)
  • All management events, data events for S3 and Lambda, and CloudTrail Insights for anomalous API activity
  • Logs delivered to an S3 bucket in the dedicated Security/Audit account (member accounts have no write permission to this bucket)
  • S3 Object Lock on the destination bucket in compliance mode with a 7-year retention (required for KRITIS audit evidence)
# Enable CloudTrail Insights for anomaly detection on the org trail
aws cloudtrail put-insight-selectors \
  --trail-name org-trail-kritis \
  --insight-selectors '[
    {"InsightType": "ApiCallRateInsight"},
    {"InsightType": "ApiErrorRateInsight"}
  ]'

# Verify log file integrity for a specific time range
aws cloudtrail validate-logs \
  --trail-arn arn:aws:cloudtrail:eu-central-1:SECURITY_ACCOUNT:trail/org-trail-kritis \
  --start-time 2026-05-01T00:00:00Z \
  --end-time 2026-05-17T00:00:00Z \
  --verbose

S3 Object Lock is the critical tamper-proofing control. Once an object is locked in compliance mode, not even the AWS root account can delete or overwrite it before the retention period expires. This satisfies the KRITIS requirement that audit evidence cannot be manipulated by the entity being audited.

For real-time monitoring, Security Hub aggregates all findings and can forward them to your SIEM (Splunk, Microsoft Sentinel, IBM QRadar) via Kinesis Firehose. For KRITIS environments without an existing SIEM, you can build adequate monitoring using CloudWatch Logs Insights for ad-hoc queries and CloudWatch Metric Filters + Alarms for real-time alerting on specific conditions (console logins without MFA, root account usage, security group changes, etc.).

Physical Security (KRITIS-Specific)

KRITIS extends into physical security for on-premises systems and hybrid deployments. For pure-cloud KRITIS deployments, AWS’s physical security controls – documented in their ISO 27001 certification and C5 Testat – cover the data centre layer. You inherit these controls and document them as part of the shared responsibility model.

For hybrid environments where KRITIS-scoped systems connect to AWS, physical security of on-premises systems (network equipment connecting to AWS Direct Connect, HSMs in colocation facilities) remains the operator’s responsibility. Direct Connect is preferred over VPN for KRITIS-critical connections – it provides dedicated bandwidth, predictable latency, and does not traverse the public internet.

AWS Architecture for NIS2/KRITIS Compliance

The diagram below shows the full seven-layer reference architecture. Each layer maps to specific NIS2 Article 21 obligations and KRITIS § 8a control requirements.

The architecture flows top-to-bottom through the security layers:

  1. Perimeter (L1): All inbound traffic passes through CloudFront (TLS termination), AWS WAF (application-layer filtering), and Shield Advanced (DDoS absorption). Route 53 DNS Firewall blocks malicious domain resolution.
  2. Network (L2): Inside the perimeter, Network Firewall applies stateful deep-packet inspection and east-west controls. A strict subnet segmentation model separates public, application, and data tiers. VPC endpoints eliminate internet egress for AWS API calls. VPC Flow Logs capture all ENI traffic.
  3. Identity (L3): SCPs enforce hard guardrails at the Organizations level. Identity Center provides centralised, MFA-enforced human access. IAM Access Analyzer continuously detects over-privileged policies. KMS with CMKs controls all encryption operations.
  4. Detection (L4): GuardDuty, Security Hub, Inspector, Config, Macie, and SSM Patch Manager run continuously across all accounts. Security Hub aggregates findings centrally.
  5. Logging (L5): CloudTrail org-wide trail with log file validation feeds into Object Lock-protected S3 storage. Audit Manager collects evidence. AWS Artifact provides AWS’s compliance documentation (C5 Testat, ISO 27001, SOC 2).
  6. Response (L6): The NIS2 24-hour reporting workflow – GuardDuty → Security Hub → EventBridge → Step Functions → SNS – automates the first response steps and produces a notification-ready incident record within minutes.
  7. Business Continuity (L7): AWS Backup with cross-region copies, Elastic Disaster Recovery, and supply chain controls (CodeArtifact, ECR scanning, SBOM generation).

The NIS2 24-Hour Incident Notification Workflow

Article 23 NIS2 is one of the most operationally demanding provisions. Within 24 hours of becoming aware of a significant incident, you must submit an early warning to the BSI. “Becoming aware” is not defined as “concluding your investigation” – it means the moment you identify that an incident has occurred. In practice, this means your detection-to-notification pipeline must work automatically and must not depend on an analyst being available.

The automated workflow I implement:

GuardDuty (T+0: finding detected)
    ↓  [all HIGH/CRITICAL findings]
Security Hub (T+1min: severity enriched, deduplicated)
    ↓  [ASFF event to EventBridge]
EventBridge Rule (T+2min: pattern matched on severity + KRITIS account tag)
    ↓  [state machine input]
Step Functions (T+2-15min: IR state machine)
    ├── Lambda: Triage (classify finding type, map to KRITIS asset)
    ├── Lambda: Containment (isolate EC2, revoke temporary credentials)
    ├── Lambda: Evidence (EBS snapshot, CloudTrail export, VPC flow log preservation)
    └── Lambda: Notification assembly (populate BSI report template)
    ↓
SNS (T+15min: alert to CSIRT on-call + Jira ticket created)
    ↓
Human analyst: review notification draft, approve BSI submission
    ↓
BSI MELDEPFLICHT portal: submit (T < 24h from detection)

The EventBridge rule pattern that triggers the KRITIS notification workflow:

{
  "source": ["aws.guardduty", "aws.securityhub"],
  "detail-type": [
    "GuardDuty Finding",
    "Security Hub Findings - Imported"
  ],
  "detail": {
    "findings": {
      "Severity": {
        "Label": ["HIGH", "CRITICAL"]
      },
      "Resources": {
        "Tags": {
          "ComplianceScope": ["KRITIS", "BOTH"]
        }
      }
    }
  }
}

The tag condition is critical: it ensures the notification workflow fires specifically for KRITIS-tagged resources, not for every HIGH/CRITICAL finding across all accounts. Without this scope filter, non-KRITIS workloads flood the notification pipeline and cause alert fatigue that defeats the purpose.

The notification assembly Lambda generates a pre-populated BSI incident notification template:

import boto3
import json
from datetime import datetime, timezone

def handler(event, context):
    finding = event['finding']
    
    # Map GuardDuty finding type to BSI incident category
    incident_category_map = {
        "UnauthorizedAccess": "unbefugter Zugriff",
        "CryptoCurrency": "Cryptomining / Ressourcenmissbrauch",
        "Backdoor": "Backdoor / persistenter Zugriff",
        "Trojan": "Schadprogramm",
        "Recon": "Aufklärung / Scanning",
        "Policy": "Richtlinienverletzung",
    }
    
    finding_type_prefix = finding['Type'].split(':')[0]
    bsi_category = incident_category_map.get(finding_type_prefix, "Sonstiges")
    
    bsi_report = {
        "meldezeitpunkt": datetime.now(timezone.utc).isoformat(),
        "ersterkennungszeitpunkt": finding['CreatedAt'],
        "betroffene_anlage": {
            "bezeichnung": finding['Resources'][0].get('Tags', {}).get('Name', 'unbekannt'),
            "kritis_sektor": finding['Resources'][0].get('Tags', {}).get('KRITISSektor', 'unbekannt'),
            "aws_account": finding['AccountId'],
            "aws_region": finding['Region'],
        },
        "vorfallkategorie": bsi_category,
        "schweregrad": finding['Severity']['Label'],
        "beschreibung": finding['Description'],
        "betroffene_dienste": "wird ermittelt",
        "massnahmen_ergriffen": "Isolation initiiert via AWS Step Functions IR-Workflow",
        "meldepflichtig_nach": "§ 8b BSIG / NIS2 Art. 23",
    }
    
    # Store report in S3 and send to SNS
    s3 = boto3.client('s3')
    s3.put_object(
        Bucket='kritis-incident-reports',
        Key=f"bsi-report-draft-{finding['Id']}.json",
        Body=json.dumps(bsi_report, ensure_ascii=False, indent=2),
        ContentType='application/json'
    )
    
    sns = boto3.client('sns')
    sns.publish(
        TopicArn='arn:aws:sns:eu-central-1:ACCOUNT:kritis-csirt-alerts',
        Subject=f"[KRITIS MELDEPFLICHT] {bsi_category} - {finding['Severity']['Label']} - {finding['AccountId']}",
        Message=json.dumps(bsi_report, ensure_ascii=False, indent=2)
    )
    
    return {"status": "notification_dispatched", "report_id": finding['Id']}

The human analyst receives the pre-populated BSI report, verifies the details against the incident investigation, and submits via the BSI’s MELDEPFLICHT portal or the ENISA reporting system. The automated workflow ensures the 24-hour deadline is structurally reachable – it does not guarantee it if your CSIRT is unresponsive, but it eliminates the scenario where a finding sat in a queue unnoticed.

AWS Audit Manager: Building a Custom NIS2 Framework

AWS Audit Manager lets you create custom assessment frameworks that map NIS2 Article 21 obligations to specific AWS control evidence. This is the operational backbone of your BSI compliance submission.

The framework structure maps NIS2 control domains to AWS evidence sources:

# Boto3: create a custom NIS2 control set in Audit Manager
import boto3

auditmanager = boto3.client('auditmanager', region_name='eu-central-1')

# Create a control for NIS2 Art. 21(2)(i) - MFA enforcement
control = auditmanager.create_control(
    name='NIS2-Art21-2i-MFA-Enforcement',
    description='Verify MFA is enforced for all IAM users and Identity Center users',
    testingInformation='Check Security Hub FSBP.IAM.6 and CIS 1.10 findings. Verify IAM Identity Center MFA settings.',
    actionPlanTitle='Enable MFA for non-compliant users',
    actionPlanInstructions='Enforce FIDO2 MFA via Identity Center. Apply SCP to deny console access without MFA.',
    controlMappingSources=[
        {
            'sourceName': 'SecurityHub-MFA-Check',
            'sourceDescription': 'Security Hub check for MFA on IAM users',
            'sourceSetUpOption': 'System_Controls_Mapping',
            'sourceType': 'AWS_Security_Hub',
            'sourceKeyword': {
                'keywordInputType': 'SELECT_FROM_LIST',
                'keywordValue': 'arn:aws:securityhub:::controls/aws-foundational-security-best-practices/v/1.0.0/IAM.6'
            },
            'troubleshootingText': 'Navigate to Security Hub → Standards → FSBP → IAM.6'
        },
        {
            'sourceName': 'CloudTrail-Console-SignIn-No-MFA',
            'sourceDescription': 'CloudTrail events for console sign-ins without MFA',
            'sourceSetUpOption': 'Procedural_Controls_Mapping',
            'sourceType': 'MANUAL',
            'troubleshootingText': (
                'Query CloudTrail: filter ConsoleLogin events where '
                'additionalEventData.MFAUsed = No'
            )
        }
    ]
)

Each NIS2 Article 21 sub-clause becomes a control set in the framework. Audit Manager collects evidence automatically from Config rules, Security Hub findings, and CloudTrail events. Manual evidence (third-party audit reports, vendor security questionnaires, penetration test results) is uploaded directly. The result is an auditor-ready assessment report that maps every control to its evidence – exactly what a BSI audit engagement requires.

AWS Artifact: Leveraging AWS’s Compliance Documentation

AWS holds numerous third-party certifications that cover the infrastructure layer. For KRITIS compliance, the most relevant documents available from AWS Artifact are:

  • BSI C5 Testat (Cloud Computing Compliance Criteria Catalogue): Covers eu-central-1 (Frankfurt) and eu-west-1 (Ireland). This is the BSI’s own cloud security standard, and AWS holding this testat means auditors can rely on AWS’s controls for the infrastructure layer without re-auditing the data centre.
  • ISO 27001 Certificate: Covers all commercial AWS regions. Required baseline for most KRITIS auditors.
  • SOC 2 Type II Report: Documents AWS’s security, availability, and confidentiality controls with semi-annual independent auditor verification.
  • ISO 27017 (Cloud-specific security controls) and ISO 27018 (PII protection in cloud) certificates.
# Download AWS Artifact agreements programmatically
aws artifact list-reports \
  --query 'reports[?category==`Certifications`].{Name:name,Period:period}' \
  --output table

# Accept the NDA for a specific report and get download URL
aws artifact get-report-url \
  --report-id <report-id> \
  --report-version <version>

The key message for auditors: AWS’s C5 Testat covers the infrastructure layer. Your organisation’s controls must cover the application and configuration layer. The two together constitute the complete compliance picture under shared responsibility.

Practical Implementation Roadmap

Starting a NIS2/KRITIS compliance programme on AWS from scratch is daunting. The following phased roadmap reflects what I have learned deploying this in practice – what you actually need to do in what order to avoid compliance gaps and rework.

Phase 0: Scoping and Inventory (Week 1–2)

Before you configure a single AWS service, you need to know what you are protecting:

  1. Determine whether you qualify as an essential entity or important entity under NIS2. If you are in Germany, also check whether you exceed the BSI-KritisV sector thresholds for KRITIS designation.
  2. Register with the BSI via the KRITIS portal if you meet KRITIS thresholds. Failure to register is itself a violation.
  3. Identify all AWS accounts, regions, and services in scope. Tag all KRITIS-critical resources with ComplianceScope: KRITIS.
  4. Map your data flows – which data enters your KRITIS-scoped systems, where it is stored, and which third parties have access.

Phase 1: Quick Wins (Days 1–30)

These controls have low implementation effort and high compliance impact. They also satisfy the most scrutinised controls in BSI audits:

ControlAWS ServiceTime to Implement
Enable GuardDuty across all accountsAWS Organizations + GuardDuty2 hours
Enable Security Hub + CIS/FSBP standardsSecurity Hub2 hours
Enable CloudTrail org-wide trail with validationCloudTrail4 hours
Enable S3 Object Lock on log bucketsS31 hour
Deploy MFA enforcement SCPAWS Organizations2 hours
Enable AWS Config with conformance packsConfig4 hours
Enable Inspector v2 across all accountsInspector1 hour
Enable VPC Flow Logs on all VPCsVPC2 hours
Enable Macie on KRITIS S3 bucketsMacie2 hours
Rotate all long-lived IAM access keysIAM4–8 hours
Enable AWS Backup for critical resourcesAWS Backup4 hours
Download C5 Testat from AWS ArtifactAWS Artifact30 minutes

This 30-day sprint addresses the most commonly cited deficiencies in BSI KRITIS audits and gives you an initial Security Hub compliance score to baseline against.

Phase 2: Architecture Hardening (Days 31–60)

  1. Network segmentation: Implement the hub-and-spoke VPC model with AWS Network Firewall in the inspection VPC. Migrate public-facing workloads to the DMZ VPC. Configure VPC endpoints for all AWS services used by application workloads.
  2. Identity hardening: Deploy IAM Identity Center with corporate IdP integration. Migrate all human IAM users to Identity Center. Enforce FIDO2 MFA. Delete all IAM users with console access. Run the IAM Access Analyzer unused access report and remediate.
  3. Encryption uplift: Identify all resources using AWS-managed keys and migrate to CMKs. Enable automatic key rotation on all CMKs. Implement KMS key policies with data classification separation.
  4. Patch management: Deploy SSM Patch Manager with KRITIS patch baselines. Enrol all EC2 instances in maintenance windows. Verify SSM agent coverage is 100% on KRITIS-scoped instances.
  5. IR automation: Deploy the EventBridge → Step Functions → SNS incident notification pipeline. Test with a synthetic GuardDuty finding (use GuardDuty’s sample findings feature). Verify the BSI notification draft is generated correctly.

Phase 3: Compliance Operationalisation (Days 61–90)

  1. Audit Manager framework: Create the custom NIS2 assessment framework. Assign it to all KRITIS-scoped accounts. Review the initial evidence collection and remediate gaps.
  2. Vulnerability management process: Define CVSS/EPSS thresholds and SLA targets. Integrate Inspector findings with your ticketing system. Run the first patch compliance report and remediate all CRITICAL findings.
  3. Supply chain controls: Implement CodeArtifact proxies for all package managers. Enable ECR enhanced scanning. Define and implement an SBOM generation process for KRITIS-critical container images.
  4. DR testing: Execute a DR drill – recover a KRITIS-scoped RDS instance from cross-region backup to eu-west-1. Document RTO achieved vs. RTO target. Store drill evidence in Audit Manager.
  5. Penetration test: Commission an external penetration test of KRITIS-scoped systems. BSI auditors expect an annual penetration test as evidence of proactive risk management. The test results – including remediated findings – become Audit Manager evidence.
  6. Documentation package: Prepare the BSI audit submission: security concept, risk register, technical measures list mapped to BSI IT-Grundschutz building blocks, ISMS documentation, and the Audit Manager assessment report.

Ongoing: Compliance-as-Operations

The steady state is not a project – it is a continuous operational programme:

  • Weekly: Review Security Hub compliance score trends. Triage new Inspector findings.
  • Monthly: Run IAM Access Analyzer unused access report. Review CloudTrail Insights anomalies.
  • Quarterly: Access review for all KRITIS-scoped IAM roles. Key policy review. Supplier security questionnaire follow-up.
  • Annually: External penetration test. BSI KRITIS evidence submission (every 2 years, alternating years for internal audit).
  • Continuously: GuardDuty monitoring, EventBridge incident workflow, Patch Manager compliance, Config rule evaluation.

What AWS Does Not Cover

Being precise about the gaps in the AWS-native approach saves you the embarrassment of discovering them in a BSI audit:

SOC processes: AWS services generate telemetry and findings. They do not analyse them. You need human analysts who understand the alerts, can distinguish true positives from false positives, and can conduct incident investigations. If you do not have an internal SOC capability, you need a MSSP – and under NIS2, your MSSP relationship is itself a supply chain security obligation (Art. 21(2)(d)) requiring formal security assessment.

Penetration testing: AWS Config rules and Security Hub findings do not substitute for penetration testing. Config rules check configuration; they do not test whether a determined attacker can chain multiple findings into a breach. Annual penetration tests of KRITIS-scoped systems are a BSI expectation.

Physical security for hybrid environments: If you have on-premises systems that feed into AWS (Direct Connect, VPN, on-premises processing that feeds S3), those physical systems are outside the shared responsibility model. Their physical and logical security is entirely your obligation.

Employee security training: NIS2 Art. 21(2)(g) requires cyber hygiene training for all personnel handling KRITIS-relevant systems. AWS has no service for this. This is a human process.

ISMS documentation: NIS2 requires documented security policies, risk management processes, and governance structures. AWS services generate evidence that you can point to. They do not write your ISMS for you.

Conclusion

KRITIS and NIS2 compliance on AWS is tractable, but it is not a checkbox exercise. The regulatory frameworks are specific enough that vague architectural statements – “we use encryption” or “we have monitoring” – will not survive a BSI audit. Auditors want to see the KMS key policy, the CloudTrail log validation output, the Patch Manager compliance dashboard showing 100% coverage, and the tested DR recovery time.

The AWS service landscape maps cleanly onto the NIS2 Article 21 control domains, with a few important caveats: you need CMKs (not AWS-managed keys) for encryption, you need Object Lock (not just versioning) for tamper-proof logs, and you need an org-wide CloudTrail (not account-level trails) for comprehensive audit coverage. These distinctions are not obvious from the service documentation but they are the ones that matter in an audit.

The 24-hour incident notification requirement in Art. 23 is the operational forcing function that makes the entire detection-to-response pipeline non-optional. If you cannot reliably get from “GuardDuty finding detected” to “BSI notification submitted” in under 24 hours without depending on an analyst being awake and available, you are non-compliant. Building the EventBridge → Step Functions notification workflow is not optional for KRITIS operators – it is the minimum automation needed to make the legal obligation structurally achievable.

Finally: if you are not registered with the BSI and you meet the KRITIS thresholds, fix that first. Unregistered KRITIS operators are easy to identify (sector-specific threshold checks are not secret) and face the same penalties as registered operators who are non-compliant with technical measures – plus additional penalties for the failure to register. The registration obligation is independent of and prior to any technical implementation work.

References