Wombat

WAF-SOV-100 – Exit Plan & Portability Tested

Pillar: Sovereign | Severity: Medium | Category: Logging Monitoring | Automatable: High

Description

A documented exit plan MUST exist covering data export procedures, IaC portability strategy, dependency replacement mapping, timeline, and cost estimates. Exit/restore drills MUST be performed at least annually to validate that the exit plan is executable. IaC must use open standards and provider-agnostic patterns where feasible to reduce proprietary lock-in. S3 bucket lifecycle policies MUST be configured to support data retention and deletion requirements.

Rationale

Risk Description

Risk

Missing exit plans lead to data lock-in and blocked cloud migrations.

Risk

Undocumented export procedures extend migration time and increase regulatory risk.

Requirements

  • A documented exit plan MUST exist covering data export procedures, IaC portability strategy, dependency replacement mapping, timeline, and cost estimates.

  • Exit/restore drills MUST be performed at least annually to validate that the exit plan is executable.

  • IaC must use open standards and provider-agnostic patterns where feasible to reduce proprietary lock-in.

  • S3 bucket lifecycle policies MUST be configured to support data retention and deletion requirements.

Implementation Guidance

  1. Document the requirement in a version-controlled policy or standard.

  2. Assign ownership and establish a review cadence (e.g., quarterly).

Maturity Levels

Level Name Criteria

L1

Ad hoc – control not consistently applied

* Manual evidence exists for some workloads, but coverage is unknown.

L2

Standardised – policy defined and communicated

* A version-controlled policy, ADR, or standard describes the requirement.

L3

Integrated – automated validation in CI/CD

* Terraform checks run automatically on pull requests and report results.

L4

Auditable – metrics and exceptions tracked

* Control coverage, failures, and approved exceptions are reported quarterly.

L5

Optimised – continuous improvement based on data

* Control effectiveness is measured and iteratively improved.

Checks

waf-sov-100.tf.aws.s3-lifecycle-policy-defined

Engine: terraform | Provider: aws | Automated: Yes

S3 buckets storing sovereign data must have lifecycle policies

S3 buckets containing sovereign data must have lifecycle rules defined to enforce data retention, transition to cheaper storage tiers, and scheduled deletion per the data residency policy.

Scope: resource — aws_s3_bucket

Assertions: * id has associated resource — S3 bucket has no lifecycle configuration. Data retention and deletion cannot be automated.

Remediation: Create an aws_s3_bucket_lifecycle_configuration resource defining transition and expiration rules consistent with your data retention policy.

Compliant
resource "aws_s3_bucket_lifecycle_configuration" "sovereign_data" {
  bucket = aws_s3_bucket.data.id
  rule {
    id     = "sovereign-retention-policy"
    status = "Enabled"
    transition {
      days          = 90
      storage_class = "STANDARD_IA"
    }
    transition {
      days          = 365
      storage_class = "GLACIER"
    }
    expiration {
      days = 2555  # 7 years for financial data
    }
  }
}
Non-Compliant
resource "aws_s3_bucket" "data" {
  bucket = "sovereign-data"
  # No lifecycle configuration
}

waf-sov-100.tf.aws.s3-versioning-for-data-portability

Engine: terraform | Provider: aws | Automated: Yes

S3 buckets with sovereign data should have versioning enabled

S3 bucket versioning supports data portability by preserving historical versions of objects, enabling point-in-time exports during exit procedures.

Scope: resource — aws_s3_bucket_versioning

Assertions: * versioning_configuration.status equals Enabled — S3 bucket versioning must be Enabled for sovereign data portability.

Remediation: Enable versioning on S3 buckets containing sovereign data.

waf-sov-100.tf.any.resource-tag-portability

Engine: terraform | Provider: any | Automated: Yes

Data resources should have portability metadata tags

Data resources should be tagged with 'portability-class' and 'data-export-enabled' to support automated export orchestration during exit procedures.

Scope: resource — aws_s3_bucket, aws_rds_instance, aws_rds_cluster, aws_dynamodb_table, azurerm_storage_account, azurerm_sql_database, google_storage_bucket, google_sql_database_instance, stackit_container_registry, stackit_mysql_instance, stackit_opensearch_instance, stackit_redis_instance, ovh_cloud_project, ovh_vps, hcloud_server, hcloud_volume

Assertions: * tags key exists — Resource is missing 'portability-class' tag needed for exit orchestration.

Remediation: Add 'portability-class' tag with values: portable | proprietary-limited | proprietary-locked. Aim to eliminate 'proprietary-locked' resources or document their alternatives.

Compliant
resource "aws_rds_instance" "app" {
  tags = {
    portability-class    = "portable"          # PostgreSQL – open standard
    data-export-enabled  = "true"
    data-residency       = "eu-only"
  }
}
Non-Compliant
resource "aws_rds_instance" "app" {
  tags = {
    environment = "production"
    # No portability metadata
  }
}

waf-sov-100.tf.any.no-proprietary-lock-in-patterns

Engine: terraform | Provider: aws | Automated: Yes

Flag use of high-lock-in proprietary data services

Certain AWS services have limited or no export capability and represent high lock-in risk. Their use should be flagged for review and documented in the dependency replacement map.

Scope: resource — aws_cloudsearch_domain, aws_mq_broker, aws_redshift_cluster

Assertions: * tags key exists — High-lock-in service used without documented exit strategy. Add 'exit-strategy-documented' tag.

Remediation: Add an 'exit-strategy-documented' tag referencing the exit plan section covering this service. Maintain a documented replacement alternative.

waf-sov-100.tf.aws.rds-deletion-protection

Engine: terraform | Provider: aws | Automated: Yes

RDS production instances must have deletion protection enabled

RDS instances tagged as production must have deletion_protection = true to prevent accidental destruction of sovereign data during exit procedures or infrastructure changes.

Scope: resource — aws_db_instance, aws_rds_cluster

Assertions: * deletion_protection is true — RDS deletion_protection must be enabled to prevent accidental data loss.

Remediation: Set deletion_protection = true on all production RDS instances and clusters.

Compliant
resource "aws_db_instance" "sovereign" {
  deletion_protection = true
  # ...
}
Non-Compliant
resource "aws_db_instance" "sovereign" {
  deletion_protection = false  # Data can be deleted without confirmation
}

waf-sov-100.config.azurerm.azurerm-logging-monitoring

Engine: config | Provider: azurerm | Automated: Yes

A documented exit plan MUST exist covering data export procedures, IaC…​

A version-controlled policy document must exist at docs/sovereign/waf-sov-100-azurerm-logging-monitoring.md and document the Azure implementation of this control. The checker validates that the file exists and contains a normative requirement statement (MUST/SHALL/required/mandatory).

Scope: file — docs/sovereign/waf-sov-100-azurerm-logging-monitoring.md

Assertions: * content matches pattern (?i)MUST|SHALL|required|mandatory|enforced|documented — Policy file docs/sovereign/waf-sov-100-azurerm-logging-monitoring.md must contain a normative requirement statement.

Remediation: Create or update docs/sovereign/waf-sov-100-azurerm-logging-monitoring.md. State the requirement, how it is implemented for Azure, the review cadence, and the owner.

Compliant
docs/sovereign/waf-sov-100-azurerm-logging-monitoring.md:
- The Azure implementation of WAF-SOV-100 is documented.
- Implementation status and owner are recorded.
- Review cadence is defined (e.g. quarterly).
Non-Compliant
# `docs/sovereign/waf-sov-100-azurerm-logging-monitoring.md` is missing or does not contain a normative requirement.
# WAF-SOV-100 violation: Azure control is not documented

waf-sov-100.config.google.google-logging-monitoring

Engine: config | Provider: google | Automated: Yes

A documented exit plan MUST exist covering data export procedures, IaC…​

A version-controlled policy document must exist at docs/sovereign/waf-sov-100-google-logging-monitoring.md and document the GCP implementation of this control. The checker validates that the file exists and contains a normative requirement statement (MUST/SHALL/required/mandatory).

Scope: file — docs/sovereign/waf-sov-100-google-logging-monitoring.md

Assertions: * content matches pattern (?i)MUST|SHALL|required|mandatory|enforced|documented — Policy file docs/sovereign/waf-sov-100-google-logging-monitoring.md must contain a normative requirement statement.

Remediation: Create or update docs/sovereign/waf-sov-100-google-logging-monitoring.md. State the requirement, how it is implemented for GCP, the review cadence, and the owner.

Compliant
docs/sovereign/waf-sov-100-google-logging-monitoring.md:
- The GCP implementation of WAF-SOV-100 is documented.
- Implementation status and owner are recorded.
- Review cadence is defined (e.g. quarterly).
Non-Compliant
# `docs/sovereign/waf-sov-100-google-logging-monitoring.md` is missing or does not contain a normative requirement.
# WAF-SOV-100 violation: GCP control is not documented

waf-sov-100.tf.stackit.exit-plan-tag

Engine: terraform | Provider: stackit | Automated: Yes

STACKIT workloads must have an exit plan tag

STACKIT workloads must have an exit plan tag. This check validates the Terraform configuration uses the expected resource and attribute.

Scope: resource — stackit_project

Assertions: * labels.exit-plan key exists — STACKIT project is missing the 'exit-plan' label.

Remediation: Review the Terraform configuration for the listed resource types and ensure the required attribute or tag is present. See the control narrative for provider-specific guidance.

Compliant
# Example resource meets the requirement.
resource "stackit_project" "example" {
  # required attribute/tag/label present
}
Non-Compliant
# Example resource does not meet the requirement.
resource "stackit_project" "example" {
  # Missing required attribute/tag/label
}

waf-sov-100.tf.ovh.exit-plan-tag

Engine: terraform | Provider: ovh | Automated: Yes

OVHcloud workloads must have an exit plan tag

OVHcloud workloads must have an exit plan tag. This check validates the Terraform configuration uses the expected resource and attribute.

Scope: resource — ovh_cloud_project

Assertions: * tags.exit-plan key exists — OVHcloud project is missing the 'exit-plan' tag.

Remediation: Review the Terraform configuration for the listed resource types and ensure the required attribute or tag is present. See the control narrative for provider-specific guidance.

Compliant
# Example resource meets the requirement.
resource "ovh_cloud_project" "example" {
  # required attribute/tag/label present
}
Non-Compliant
# Example resource does not meet the requirement.
resource "ovh_cloud_project" "example" {
  # Missing required attribute/tag/label
}

waf-sov-100.tf.hcloud.exit-plan-tag

Engine: terraform | Provider: hcloud | Automated: Yes

Hetzner Cloud workloads must have an exit plan tag

Hetzner Cloud workloads must have an exit plan tag. This check validates the Terraform configuration uses the expected resource and attribute.

Scope: resource — hcloud_server

Assertions: * labels.exit-plan key exists — Hetzner Cloud server is missing the 'exit-plan' label.

Remediation: Review the Terraform configuration for the listed resource types and ensure the required attribute or tag is present. See the control narrative for provider-specific guidance.

Compliant
# Example resource meets the requirement.
resource "hcloud_server" "example" {
  # required attribute/tag/label present
}
Non-Compliant
# Example resource does not meet the requirement.
resource "hcloud_server" "example" {
  # Missing required attribute/tag/label
}

Evidence

Kind Required Description

iac

Required

Terraform configuration implementing the control.

governance

Required

Policy, ADR, or standard documenting the requirement.

config

Optional

Cloud console or API output confirming runtime state.

Related Controls

Framework Controls

GDPR

* Art. 17 – Right to erasure (must be able to delete data) * Art. 20 – Right to data portability * Art. 28 – Processor obligations including data return/deletion on termination

BSI C5:2020

* PRO-01 – Portability and interoperability * OPS-06 – Exit management

BSI C3A:2026

* Dimension 7 – Technology: Source code backup and recovery * Dimension 7 – Technology: EU-based backups within 24 hours

EUCS (ENISA)

* PRO-01 – Portability * PRO-02 – Interoperability

GAIA-X

* Sovereign Cloud – Reversibility requirements

ISO 27001:2022

* A.5.20 – Addressing information security in supplier agreements (including exit) * A.8.10 – Information deletion