complianceiaCautomation

Automating Compliance Attestations in Sovereign Clouds with Policy-as-Code

UUnknown

2026-03-10

11 min read

Automate policy-as-code checks to produce signed, in-region attestations and immutable audit trails for EU sovereign workloads.

Automating Compliance Attestations in Sovereign Clouds with Policy-as-Code

Hook: If you run regulated workloads in EU sovereign regions, you know the pain: fragmented vendor controls, manual evidence collection for audits, and legal requirements that demand proof the data never left the EU. This article shows concrete policy-as-code patterns that automate evidence generation and produce cryptographically-signed attestations for workloads deployed with Terraform and CI/CD — all while keeping proofs and keys inside sovereign boundaries.

Why this matters in 2026

By 2026 cloud providers and regulators have doubled down on sovereignty. Major vendors rolled out EU-focused sovereign offerings in late 2025 and early 2026 to satisfy the European Data Act and national data protection demands. That means organizations must not only run workloads in EU sovereign regions, they must produce reliable, tamper-evident evidence of compliance on demand.

This is where policy-as-code meets automated attestations: treat governance checks as software, run them in CI/CD, emit structured evidence artifacts, sign them with keys held inside the sovereign cloud, and store the audit trail in an immutable, access-controlled location.

Executive summary — quick wins and patterns

Enforce and evaluate policies as code (OPA/Rego) during Terraform plan/apply and as a CI gate.
Generate structured evidence (JSON attestation) that captures resource metadata, policy decisions, timestamps, and pipeline provenance.
Sign attestations with keys in a sovereign HSM (or Sigstore/Cosign integrated with a local Rekor-like transparency log) so auditors can verify integrity without accessing your private keys.
Store evidence immutably inside the EU sovereign region — object storage with object lock / WORM or an append-only ledger service — and link evidence to resource IDs and change sets.
Expose an auditable API & dashboard so auditors and internal compliance teams can query attestations, retention, and key provenance.

Architecture pattern — components and data flow

Below is a compact, vendor-neutral reference architecture for automated attestations in a sovereign cloud:

Developer pushes IaC (Terraform) and app code to a repository.
CI/CD (GitHub Actions/GitLab CI) runs Terraform plan, then invokes OPA/Conftest checks against the plan output.
OPA produces a decision and structured evidence (JSON) summarizing checks, reasons, and metadata.
CI/CD signs the evidence using a key whose private portion resides in a sovereign HSM or KMS. Optionally publish the signature to an internal transparency log (Rekor-like) deployed in-region.
Signed attestation + plan output are uploaded to immutable object storage in the EU sovereign region and registered in a compliance index.
Deploy proceeds only if policy decisions and attestation uploads succeed (enforced by pipeline gates and IaC pre-commit hooks).

Why each piece matters

OPA/Rego lets you express regulatory constraints (data residency, encryption, approved services) as code and run evaluations reproducibly.
Signed attestations provide non-repudiable evidence that a policy check ran and what it returned.
In-region keys & storage preserve sovereign requirements: evidence never leaves EU boundaries and keys are under EU control.

Concrete patterns and code examples

Below are practical, copy-paste-ready patterns illustrating policy-as-code evaluation, attestation creation, signing with Cosign (or a KMS/HSM), and storing evidence. These examples use Terraform plan JSON output, OPA (Rego), GitHub Actions CI/CD, Cosign for signing, and an in-region object store.

1) Rego policy: enforce EU sovereign region, encryption, and tags

Save as policy/sovereign.rego. This policy evaluates Terraform plan JSON and emits a decision object suitable for inclusion in an attestation.

package sovereign

# Allowed sovereign regions (example identifiers — replace per provider)
allowed_regions = {"eu-sovereign-1", "eu-sovereign-2", "eu-central-1"}

# Required tags and encryption attributes
required_tags = ["data-classification", "owner"]

deny[msg] {
  resource := input.resource_changes[_]
  resource.type == "aws_s3_bucket"
  not resource.change.after.server_side_encryption_configuration
  msg = sprintf("S3 bucket %s must have server-side encryption", [resource.address])
}

deny[msg] {
  resource := input.resource_changes[_]
  resource.change.actions[_] == "create"
  resource.change.after.location != null
  not allowed_regions[resource.change.after.location]
  msg = sprintf("Resource %s created in non-sovereign region %s", [resource.address, resource.change.after.location])
}

deny[msg] {
  resource := input.resource_changes[_]
  resource.change.after.tags == null
  msg = sprintf("Resource %s missing tags", [resource.address])
}

# Produce a structured result summarizing denies and metadata
result := {
  "evaluated_at": time.now_ns(),
  "deny_count": count(deny_msgs),
  "deny_messages": deny_msgs,
  "summary": summary_text,
}

deny_msgs[msg] {
  msg = deny[msg]
}

summary_text := sprintf("%d denies found", [count(deny_msgs)])

2) Terraform: produce plan JSON

Run a Terraform plan in CI and output JSON for OPA evaluation:

terraform init
terraform plan -out=tfplan.binary
terraform show -json tfplan.binary > tfplan.json

3) CI/CD workflow example (GitHub Actions)

This workflow runs Terraform plan, evaluates Rego with OPA, generates an attestation JSON, signs it using Cosign (or call a KMS/HSM-based signing API), and uploads the signed attestation and plan to in-region storage.

name: ci-terraform-sovereign
on: [push]

jobs:
  plan-and-attest:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v2

      - name: terraform init & plan
        run: |
          terraform init
          terraform plan -out=tfplan.binary
          terraform show -json tfplan.binary > tfplan.json

      - name: Install OPA
        run: |
          curl -L -o opa https://openpolicyagent.org/downloads/latest/opa_linux_amd64
          chmod +x opa

      - name: Evaluate policy
        run: |
          ./opa eval -i tfplan.json -d policy/sovereign.rego "data.sovereign.result" --format pretty > opa_result.json

      - name: Create attestation
        run: |
          python3 - <<'PY'
import json, time, os
plan = json.load(open('tfplan.json'))
opa = json.load(open('opa_result.json'))
attestation = {
  'schema': 'https://schemas.example.com/attestation/1.0',
  'generated_at': time.strftime('%Y-%m-%dT%H:%M:%SZ', time.gmtime()),
  'pipeline_run': os.getenv('GITHUB_RUN_ID'),
  'commit': os.getenv('GITHUB_SHA'),
  'opa_result': opa,
  'plan_summary': {'resources': len(plan.get('resource_changes', []))}
}
open('attestation.json','w').write(json.dumps(attestation, indent=2))
PY

      - name: Sign attestation with Cosign (or call KMS signer)
        env:
          COSIGN_PASSWORD: ${{ secrets.COSIGN_PASSWORD }}
        run: |
          # For sovereign compliance, the private key used by cosign must be stored in-region.
          # Replace this step with your HSM/KMS-backed signing call if required.
          cosign sign-blob --key ${{ secrets.COSIGN_KEY }} attestation.json > attestation.sig

      - name: Upload attestation & plan to sovereign object storage
        run: |
          # Use provider CLI or API that targets the EU sovereign object store
          sovereign-cli upload --bucket compliance-evidence --file attestation.json --meta pipeline=${{ github.run_id }}
          sovereign-cli upload --bucket compliance-evidence --file attestation.sig --meta pipeline=${{ github.run_id }}
          sovereign-cli upload --bucket compliance-evidence --file tfplan.json --meta pipeline=${{ github.run_id }}

Notes: In production you should replace cosign local keys with a KMS/HSM-backed signer that never exports the private key. Major providers now offer in-region HSMs or KMS instances with sovereign tenancy. By 2026 it’s common to run a Rekor-compatible transparency log inside the sovereign environment, or to use a provider's managed transparency service that guarantees EU residency.

Attestation format recommendations

Design attestations for automated verification and long-term auditability. Include:

Provenance: git commit, pipeline run ID, actor identity
Time metadata: generated_at with UTC timestamp
Policy snapshot: the Rego module hash or policy version used
Decision details: pass/fail, list of denies with resource addresses
Resource snapshot: trimmed plan output or resource IDs and attributes relevant to the policy
Signature metadata: signer key ID, signature method, and transparency log entry if used

Example attestation (JSON)

{
  "schema": "https://schemas.example.com/attestation/1.0",
  "generated_at": "2026-01-17T12:34:56Z",
  "pipeline_run": "12345",
  "commit": "a1b2c3d4",
  "policy_version": "v1.2.3",
  "opa_result": {
    "deny_count": 0,
    "deny_messages": []
  },
  "plan_summary": {
    "resources": 12,
    "resource_ids": ["aws_s3_bucket.foo", "aws_db_instance.bar"]
  },
  "signature": {
    "method": "cosign",
    "key_id": "projects/xyz/locations/eu/keyRings/kr/cryptoKeys/k",
    "transparency_log_entry": "rekor://eu-01/entries/abcd"
  }
}

Storing evidence securely and immutably

Compliance evidence must be tamper-evident and retained according to regulation. Use these controls:

In-region object storage with server-side encryption using a KMS key that is itself stored in an in-region HSM.
WORM / Object lock (append-only) to prevent deletion for the retention period required by auditors.
Access control & monitoring: least-privilege RBAC for who can read evidence. Log all access attempts and store those logs in the same sovereign region.
Transparency log: publish metadata to an internal Rekor-like transparency log so anyone with read access can verify signature inclusion without having the private key.

Operationalizing and scaling

As you scale this pattern across teams and projects, pay attention to these operational concerns:

Policy versioning: Pin policies in the pipeline and record the policy module checksum in each attestation so older attestations remain verifiable.
Testing & drift detection: Include unit tests for Rego policies and regularly run policy evaluations against live inventory to detect drift.
False positives: Triage process for policy denies — attach remediation steps to attestations so teams can resolve and re-attest evidence after fixes.
Cost control: Storing every plan and attestation indefinitely can be expensive. Implement retention tiers and summarize older attestations while keeping essential signatures and hashes immutable.
Auditor UX: Provide query endpoints and a dashboard that accepts resource identifiers and returns the attestation chain, signatures, and policy snapshots to simplify audits.

Case study: EU fintech with regulated data

Consider a European fintech that migrated sensitive workloads to an EU sovereign cloud in late 2025. The compliance team was asked to prove that no PII buckets were created outside the sovereign region and that all storage used customer-managed keys in an in-region HSM.

They implemented the patterns above: Rego policies that detect bucket region and KMS key location, CI/CD gates that block merges when policies fail, attestation generation and signing with an HSM-backed KMS, and an internal transparency log deployed in-region. During a 2026 audit, the team produced signed attestations for the last 18 months within minutes. Auditors validated signatures against the transparency log and confirmed key provenance. The result: reduced auditor hours and improved trust without exposing internal systems.

Advanced strategies and 2026 innovations

Recent trends in late 2025 and early 2026 influenced these advanced patterns:

In-region transparency logs: Deploying Rekor-compatible logs inside sovereign clouds became common to preserve evidence locality while enabling verifier transparency.
KMS/HSM federation: New federation features let organizations hold root key material in national HSMs while delegating operational keys to provider-managed KMS—useful for cross-border governance when allowed by law.
Standards alignment: Attestation formats that align with SLSA and in-toto are now best practice for software supply chain attestations and are being extended for infrastructure attestations.
Policy-as-data: More teams treat policy artifacts (allowlists, region lists) as data in a secured datastore that can be audited and versioned independently from code.

Checklist: Implementing automated attestations in a sovereign cloud

Identify compliance controls that can be evaluated automatically (data residency, encryption, KMS location, approved services).
Encode controls in OPA/Rego and version them in a secure policy repo.
Integrate policy evaluation into CI/CD (plan time + pre-apply gates).
Design an attestation schema and include policy version, pipeline provenance, and timestamps.
Sign attestations with keys kept in-region using an HSM/KMS or compliant signer.
Store signed attestations and plan outputs in immutable in-region storage with proper RBAC and logging.
Provide an API/dashboard for auditors and implement a retention and archival policy.
Run continuous policy checks against running resources to detect configuration drift.

Common pitfalls and how to avoid them

Using exportable keys: Never export or persist private keys outside the sovereign boundary. Use HSM-backed signing or an in-region cosign key managed in a KMS.
Partial evidence: Attestations that miss policy version, signer identity, or pipeline provenance are weak—include the metadata.
Uncontrolled access: If auditors download evidence to a non-sovereign environment, you may violate policy. Provide read-only, in-region verifier access or anonymized extracts per legal advice.
Lack of retention planning: Define retention and deletion rules up front and implement object lock where regulations demand it.

Verification workflow for auditors

Claim: Auditor requests proof for resource X and date range.
Response: System returns attestation(s), signature(s), policy version hashes, plan JSON, and transparency log entries.
Verify: Auditor checks signature(s) against the public key, confirms transparency log inclusion, and validates the policy version hash against the policy git repo snapshot.
Confirm: Auditor confirms the resource attributes in the plan match deployed resource state (expected to be recorded in live inventory).

Final thoughts — what to prioritize in 2026

In 2026, sovereignty is a baseline expectation for regulated European workloads. The conversation has shifted from "are we in the right region" to "can we reliably prove policy compliance over time in a tamper-evident way?" Build for reproducibility: codify policies, version them, sign attestations with in-region keys, and store evidence immutably. That combination reduces audit friction, lowers legal risk, and frees engineering teams to innovate securely.

Policy-as-code isn’t just about blocking bad changes — it’s about producing verifiable, repeatable evidence that you did the right thing when it mattered.

Actionable next steps

Start by identifying 3 compliance checks you can evaluate automatically and write Rego policies for them.
Implement a CI pipeline that emits plan JSON, runs OPA, creates an attestation, and attempts to sign it using your in-region KMS.
Store the first signed attestations in your sovereign object store and practice verifying them with a colleague acting as an auditor.

Call to action: Ready to put this into practice? Clone your policy repo, add a Rego module from this article, and run a pipeline that produces your first signed attestation. If you need a checklist or a reference implementation, download the companion repo and step-by-step scripts tailored for EU sovereign regions (HSM/KMS examples included).

Unknown

Contributor

Senior editor and content strategist. Writing about technology, design, and the future of digital media. Follow along for deep dives into the industry's moving parts.