Sovereign Principles
The following seven principles form the foundation of the Sovereign pillar in WAF++. They are formulated in a provider- and technology-agnostic manner.
SP1 – Sovereignty is Evidence-Based
Sovereignty without proof is a claim.
Every sovereignty requirement must be translatable into verifiable evidence: configuration data, audit logs, runbooks, contractual artefacts or automated IaC checks.
Implication: "We believe our data is located in Germany" is not evidence. A Terraform provider with region validation and a CloudTrail log showing that no deployment outside the EU has occurred is evidence.
Related Controls: WAF-SOV-010, WAF-SOV-020
SP2 – Explicit Jurisdiction & Data Boundaries
Permitted regions and data classes must be explicitly defined and technically enforced.
Implicit assumptions or conventions without technical enforcement mechanisms are not sovereignty-compliant. Every data class requires a documented jurisdiction assignment.
Implication: "We normally deploy to eu-central-1" is not region pinning. A Terraform variable with a validation block and an OPA policy gate in CI is region pinning.
Related Controls: WAF-SOV-010, WAF-SOV-020, WAF-SOV-030, WAF-SOV-040
SP3 – Own Your Keys
Whoever does not control the key does not control the data.
For sensitive data categories (PII, health data, financial data), keys must be owned by the organization – not the cloud provider. Key rotation and deletion must be governed and auditable.
Implication: Encryption at rest with AES256 (SSE-S3) means AWS manages the key. CMK (Customer Managed Key) means the organization controls the key. HYOK (Hold Your Own Key) with an external HSM means: AWS never has access to the key material.
Related Controls: WAF-SOV-050
SP4 – Control the Control Plane
Privileged accesses are the core of sovereignty.
Break-glass, admin actions, delegation, IAM configuration changes – all these actions must be logged, attributed and periodically reviewed. Zero Standing Privilege is the target state; JIT access is the pragmatic step towards it.
Implication: A developer with AdministratorAccess can disable all Sovereign controls at once. Separation of Duties prevents that.
Related Controls: WAF-SOV-060, WAF-SOV-070
SP5 – Know and Control Your Supply Chain
All dependencies are part of the sovereign system – or a gap in it.
A monitoring agent that sends logs to a US provider, a CI/CD platform that knows production secrets, a Terraform module from an unknown source – each of these dependencies is a potential sovereignty violation.
Implication: A subprocessor inventory is not a formality. It is the attack surface atlas of sovereignty.
Related Controls: WAF-SOV-080
SP6 – Egress is the Last Line of Sovereign Defense
When all other controls fail, egress control prevents data loss.
Even with compromised credentials, a faulty IAM policy or a 0-day vulnerability in an application – without egress control, data cannot cross the sovereignty boundary.
Implication: Default-deny egress with VPC endpoints for cloud-internal services is not optional for sovereign workloads. It is the safety net.
Related Controls: WAF-SOV-090
SP7 – Exit is a Sovereign Right, not a Project
Portability and exit capability are not nice-to-have features.
Whoever cannot leave their cloud provider has no sovereignty – regardless of all technical controls. Exit drills, documented exit plans and IaC portability are regular operational tasks.
Implication: The exit planning document belongs in the repository, not in a drawer. The annual exit drill is as important as a disaster recovery test.
Related Controls: WAF-SOV-100