Operationalizing Sovereignty: What Changes for IT and Legal

Executive Summary

Sovereign cloud is not a one-time project — it is ongoing operations. After migration to the AWS European Sovereign Cloud, the real work begins: new routine processes for IT teams, changed obligations for legal and data protection officers, restrictions on third-party vendors, and new governance requirements. This article explains concretely what changes in day-to-day operations: access logging, key management lifecycle, third-party compliance, and which governance templates and runbooks DACH enterprises need. Target audience: IT operations managers, CISOs, data protection officers, and legal teams who want to understand what sovereign cloud means in steady-state — not just at build time.

The Difference Between Build and Operate

In migration projects, focus is on technology: build the Landing Zone, migrate workloads, configure controls. That is the exciting part — and the one most articles and presentations cover. But sovereignty is not a state that is reached once and then remains stable.

Sovereign cloud requires continuous management. Keys must be rotated. Access rights must be regularly reviewed. New third-party vendors must be assessed for ESC compatibility before onboarding. Government access requests must be handled through a defined process. BSI audits require current evidence — not evidence from a migration sprint 18 months ago.

This article divides the operational changes into four dimensions: access logging and control, key management lifecycle, third-party restrictions, and governance framework.

Dimension 1: Access Logging and Control

CloudTrail as Sovereign Memory

AWS CloudTrail records every API call, every management console access, and every resource access in the ESC. In sovereign operations, CloudTrail is not optional — it is the foundation of all compliance evidence. CloudTrail logs must be stored in an S3 bucket with Object Lock (Compliance Mode) that prevents accidental or malicious deletion. Retention: at least 3 years (BSI C5 requirement), 7 years recommended for NIS2.

Privileged Access Management (PAM)

Every administrative access to ESC resources must go through AWS IAM Identity Center with Just-in-Time (JIT) privileged access. This means: no permanently open admin access. Instead, every privileged session is explicitly requested, approved, time-limited, and fully logged. When the session expires, permissions are automatically revoked. PAM logs are the most important evidence documents in BSI audits.

Anomaly Detection and Response

AWS GuardDuty monitors all ESC activity for anomalies: unusual access times, geographic anomalies (access from non-EU regions), bulk downloads, API calls outside normal operational patterns. GuardDuty findings must be integrated into the SOC workflow — not just as email alerts, but as ticket-based escalation with defined SLAs (e.g., Critical finding: response within 4 hours).

Quarterly Access Review

All IAM permissions in ESC accounts must be reviewed at minimum quarterly. Process: automated report of all active permissions via AWS IAM Access Analyzer, manual review by the Data Protection Officer and responsible system owner, revocation of all no-longer-needed permissions within 5 business days. This process must be documented in the operational agreement.

Government Access Request Process

In sovereign operations, a defined process must exist for the scenario where an authority — domestic or foreign — demands access to ESC data. This process includes: immediate notification of the Data Protection Officer and legal team, legal assessment of the request's lawfulness, escalation to executive management, documentation of the decision. Without this process, response to a government demand is improvised — carrying significant liability risk.

Dimension 2: Key Management Lifecycle

Key management is the technical heart of sovereign cloud. Customer Managed Keys (CMKs) give customers full control — but they also create full responsibility. A lost or corrupted key means permanent data loss. An expired key can bring production systems down.

Key Rotation Policy

All CMKs must have automatic rotation — at minimum annually, semi-annually for highly sensitive systems. AWS KMS supports automatic key rotation natively. Rotation must be traceable in CloudTrail and recorded in the internal key register. Important: rotation means old key material remains available for decrypting old data — there is no data loss risk from rotation.

Key Lifecycle Management

Every key has a defined lifecycle: creation, activation, rotation, deactivation, deletion. Deleting a CMK has a minimum waiting period of 7 to 30 days in AWS — a safety buffer against accidental deletion. Key deletions must be approved through a four-eyes process and documented with tickets in the ITSM system.

CloudHSM Maintenance

Organizations using CloudHSM carry additional operational responsibility: HSM cluster management, key ceremony documentation, regular backup tests of HSM content. CloudHSM backups must be stored encrypted in German S3 buckets (ESC) with Object Lock. Key ceremony documentation (key generation under witnesses) is a BSI audit requirement for high-security key material.

Key Access Control (Key Policies)

Key Policies in AWS KMS define who may use a key, who may manage it, and who may delete it. In sovereign operations, key policies must be restrictive: only explicitly named IAM roles may access CMKs, no account root access to key material. Key policy changes must go through a change management process with at minimum two-person authorization.

Key Emergency Process

What happens if a key has been compromised? The emergency process must be defined: immediate deactivation of the affected key, rotation to new key material, re-encryption of all affected data sets (AWS KMS provides the ReEncrypt API call for this), incident documentation for the BSI audit report. This process must be tested at least annually — as a "Key Compromise Drill."

Dimension 3: Third-Party Restrictions

Sovereign cloud applies not only to your own infrastructure — it applies to every third-party vendor that accesses sovereign workloads. This is one of the most common operational stumbling blocks: organizations migrate their own infrastructure to the ESC but forget that integrated SaaS services, monitoring tools, and support systems often have their own data paths outside the EU.

Categories of Problematic Third-Party Vendors

US-Based SaaS Services with EU Data

Categories: CRM systems (Salesforce, HubSpot), collaboration (Slack, Teams US instance), ITSM (ServiceNow US), support systems (Zendesk US). Problem: these systems often process customer data or system data that falls under GDPR. They must either be replaced with EU-compliant variants or configured through technical measures so that no personal data is stored outside the EU.

Monitoring and Observability Tools

Many popular monitoring services (Datadog, New Relic, Splunk Cloud US) send metrics and logs to cloud backends outside the EU. In sovereign operations, this is impermissible when the metrics contain personal data or system configurations classified as requiring protection. Alternatives: AWS-native monitoring (CloudWatch, X-Ray), EU-compliant instances of these tools, or self-hosted solutions on the ESC.

CDN and Edge Services

Content Delivery Networks with global PoP infrastructure (Cloudflare, Fastly) cache content on servers outside the EU. For static, non-personal content (CSS, JS, images), this is usually non-critical. For dynamic content with customer data or session tokens, it is a GDPR third-country transfer issue. Solution: AWS CloudFront with origin on the ESC and restriction to EU PoPs.

Support and Remote Access Tools

When external service providers (software vendors, MSPs) provide remote support on ESC systems, that access must be controlled: only via AWS Systems Manager Session Manager (no direct SSH/RDP), complete logging in CloudTrail, time-limited access grant via JIT-PAM, exclusively EU-resident support staff of the provider for sovereign workloads.

Third-Party Compliance Assessment as an Ongoing Process

Every new third-party vendor accessing ESC workloads or processing their data must complete a compliance assessment before approval. Checklist for the assessment process:

• Where does the vendor store data? (Data storage location proof required)
• Which law governs the vendor? (CLOUD Act risk with US parent entity)
• What certifications does the vendor hold? (ISO 27001, BSI C5 or equivalent)
• Is there a Data Processing Agreement (DPA) per GDPR Art. 28?
• Is support access restricted to EU-resident staff?

Dimension 4: Governance Framework for Sovereign Steady-State Operations

Sovereign operations without a governance framework is unstable. Technical controls are only as good as the processes surrounding them. The following governance elements are necessary for the sustainable operation of a sovereign cloud environment:

Operational Governance Documents

Data Sovereignty Policy

A binding document defining the organization's data sovereignty requirements: which data must be sovereign, which technical controls are mandatory, which third-party requirements apply, and who is responsible for enforcement. Must be approved by the board and reviewed at minimum annually.

Key Management Manual

Documentation of all CMKs and CloudHSM keys: purpose, assigned workloads, rotation frequency, key policy, responsible party, backup process, and emergency procedure. Must be updated on every change. Access restricted to authorized key custodians only.

Incident Response Plan (Sovereignty Incidents)

Separate incident response plan specifically for sovereignty incidents: government access requests, key compromises, accidental third-country transfers, NIS2-reportable incidents. Includes: escalation paths, communication templates for BSI notification (24h/72h deadlines), responsibilities (CISO, legal, DPO, CEO), and post-incident review process.

Third-Party Register

Complete list of all third-party vendors with access to ESC workloads or their data: vendor name, service provided, data storage location, permitted access type, compliance status (last assessment), contract expiry. Must be reviewed quarterly and updated on every new addition.

Compliance Calendar

Annual plan for all compliance activities: BSI C5 evidence collection (monthly via Audit Manager), IAM access review (quarterly), third-party compliance assessment (semi-annually), key rotation review (annually), NIS2 self-assessment (annually), BSI audit (as needed). The compliance calendar prevents activities from being forgotten and ensures audit readiness is a continuous state rather than an ad-hoc effort.

RACI Matrix — Sovereign Operations

Clear responsibilities for all sovereign operations activities: who is Responsible (executes), Accountable (owns), Consulted (advises), and Informed for key rotation, government requests, third-party onboarding, incident response, and audit preparation. Without RACI, accountability gaps emerge — particularly at the interface between IT and legal.

What Changes for Legal and Data Protection Concretely

Sovereign cloud is not purely a technical matter — it has significant legal implications that require ongoing attention from legal and the Data Protection Officer.

Record of Processing Activities (ROPA)

The GDPR Art. 30 ROPA must be updated: for every sovereign workload, the ESC must be entered as the processing location, AWS as processor with ESC scope, and the technical protection measures (KMS, CloudHSM, SCPs) as technical and organizational measures (TOMs). On every workload migration or change to data processing, the ROPA must be updated within 30 days.

Data Processing Agreements (DPAs)

The standard AWS contract (AWS DPA) covers ESC specifics — but customizations are needed: scope must be explicitly limited to the ESC partition, the sub-processor list must be EU-only, and audit rights must align with BSI requirements. For all other third-party vendors with ESC data access, separate DPAs per GDPR Art. 28 must be established.

Government Request Management

When an authority — domestic or foreign — demands access to ESC data, a defined legal review process is necessary. Core questions: is the request lawful? Is it directed at the right party? Which data may be disclosed? AWS has an explicit policy on the ESC: AWS does not disclose customer data without first notifying customers and giving them the opportunity to seek legal relief — unless notification is legally prohibited.

NIS2 Reporting Obligations in Ongoing Operations

NIS2 mandates: security incidents must be reported to the BSI within 24 hours as an early warning, with the full report following within 72 hours. This process must be defined before the first incident — not after. Legal, CISO, and DPO must know what constitutes a NIS2-reportable situation and who submits the BSI notification.

Storm Reply: Operational Support After Migration

Storm Reply offers not only migration services but also Managed Compliance Services for DACH enterprises that want to keep their sovereign cloud environment secure and compliant over time. The steady-state service portfolio:

• Monthly compliance report: Automated BSI C5 evidence collection via AWS Audit Manager, Security Hub posture report, GuardDuty findings summary
• Quarterly access review: IAM permissions analysis, identification of over-entitlements, reduction recommendations
• Third-party compliance check: Assessment of new third-party vendors for ESC compatibility before approval
• Incident response retainer: 24/7 availability for sovereignty incidents, BSI notification support, key compromise response
• Annual sovereignty audit: Full-scope review of all sovereign controls, gap identification, pre-audit before the official BSI auditor engagement

Storm Reply is an AWS Premier Consulting Partner DACH with AWS Security Competency and part of the Reply Group with 16 AWS Competencies, 17 Service Deliveries, and 1,500+ AWS certifications. Storm Reply — AWS Premier Consulting Partner DACH. Learn more: reply.com/storm-reply

Sources and Further Documentation

1. AWS Documentation: AWS Key Management Service
2. AWS Documentation: AWS CloudHSM
3. AWS Documentation: AWS Audit Manager
4. AWS Documentation: AWS IAM Access Analyzer
5. BSI: BSI C5 Criteria Catalogue
6. BSI: NIS-2 in Germany — BSI
7. AWS: Europe Digital Sovereignty on AWS