WAF++ WAF++
Back to WAF++ Homepage

Design Principles

The following design principles translate the Sovereign Principles into architectural decision guidelines for cloud engineers and architects.

DP1 – Sovereignty by Design, not by Retrofit

Retrofitting sovereignty is expensive and error-prone.

Every architectural decision must answer the question: "How do I preserve control over jurisdiction, keys and dependencies?"

In practice this means:

  • Regions and data classes are defined before the first deployment

  • IaC modules contain region validation from the start

  • Encryption configuration is part of the base stack, not an add-on

DP2 – Policy-as-Code beats PDF-Policy

Policies that exist only as documents are not continuously enforced.

Every sovereign requirement that can be technically expressed must exist as code:

  • Terraform variable validation for region constraints

  • OPA/Sentinel policies for deployment guardrails

  • AWS Service Control Policies / Azure Policy / GCP Org Policy

Document-based policies only apply to requirements that cannot be technically expressed (e.g. contractual clauses, DPA obligations).

DP3 – Least Privilege by Default, JIT for Exceptions

Every identity – human or technical – starts with minimal permissions.

Human identities:

  • No standing privilege for production access

  • JIT activation with ticket binding and time limit

  • MFA mandatory for all production accesses

Technical identities (service accounts, CI/CD):

  • No long-lived access keys

  • Workload identity / OIDC for CI/CD pipelines

  • Service account permissions limited to the specific task

DP4 – Encrypt Everything, Own the Keys for Sensitive Data

Encryption is standard. Key ownership is a decision.

Data Category Minimum Recommended

Public / non-sensitive

Provider-Managed Key (PMK)

CMK

Operational / internal

Customer-Managed Key (CMK)

CMK with key policy restrictions

PII / personal data

CMK

BYOK or HYOK with HSM

Health / finance / classified

BYOK (customer key, cloud-managed HSM)

HYOK (key never in cloud provider)

Key rotation and key deletion policies are mandatory for all categories.

DP5 – Default-Deny Egress, Explicit Allow-List

Outgoing connections must be explicitly approved.

Network level:

  • Security Groups: no 0.0.0.0/0 egress without documentation

  • Network Firewall / Azure Firewall with domain allow-list

  • DNS egress via controlled resolver

Service level:

  • VPC endpoints for all used cloud services (S3, KMS, ECR, …​)

  • No data flows to non-inventoried destinations

Data pipeline level:

  • All external data exports explicitly configured and approved

  • Log shippers and monitoring agents: only to DPA-secured destinations

DP6 – Open Standards reduce Lock-in Risk

Proprietary services without alternatives are sovereignty risks.

Prefer:

  • PostgreSQL over proprietary DB engines (Spanner, Cosmos DB)

  • OpenTelemetry over proprietary agents

  • Open Container Initiative (OCI) over proprietary container formats

  • Standard IaC (Terraform) over proprietary deployment tools

Document:

  • Every proprietary service requires an entry in the dependency register with a replacement strategy

  • Proprietary services with high lock-in risk must be addressed in the exit plan

DP7 – Immutable Audit Trail

Audit logs are the foundation of sovereignty evidence.

Requirements for sovereign audit trails:

  • Immutable: Object Lock / Log File Validation / WORM storage

  • Complete: All privileged actions, all key accesses, all region deployments

  • Available: Readable even in incident scenarios (separate storage account, separate region)

  • Retention-compliant: Retention periods from the data protection policy observed

  • Sovereignly stored: Log destination is in an approved region

DP8 – Test What You Plan to Rely On

Sovereign architecture is proven through tests, not through documentation.

  • Restore tests for all backup categories (at least annually)

  • Exit drills: data export and redeployment in alternative environment

  • Break-glass tests in non-production environment

  • Region enforcement tests: deployment attempt outside allowed regions

"Tested once is more valuable than documented twice."