WAF-SOV-080 – Dependency & Subprocessor Inventory

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

Description

An inventory of all dependencies and subprocessors MUST be maintained: managed cloud services, third-party SaaS tools, CI/CD platforms, observability providers, and data processors. Changes to this inventory MUST be version-controlled, reviewed, and approved. Provider version constraints in Terraform MUST be pinned to prevent silent upgrades. Module sources MUST reference approved registries with version-locked references.

Rationale

Risk	Description
Risk	Incomplete sub-processor inventories violate processor transparency obligations.
Risk	Missing dependency assessments complicate exit management and emergency planning.

Risk

Description

Risk

Incomplete sub-processor inventories violate processor transparency obligations.

Risk

Missing dependency assessments complicate exit management and emergency planning.

Requirements

An inventory of all dependencies and subprocessors MUST be maintained: managed cloud services, third-party SaaS tools, CI/CD platforms, observability providers, and data processors.
Changes to this inventory MUST be version-controlled, reviewed, and approved.
Provider version constraints in Terraform MUST be pinned to prevent silent upgrades.
Module sources MUST reference approved registries with version-locked references.

Implementation Guidance

Document the requirement in a version-controlled policy or standard.
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.

Level

Name

Criteria

Ad hoc – control not consistently applied

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

Standardised – policy defined and communicated

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

Integrated – automated validation in CI/CD

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

Auditable – metrics and exceptions tracked

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

Optimised – continuous improvement based on data

* Control effectiveness is measured and iteratively improved.

Checks

waf-sov-080.tf.any.required-providers-version-pinned

Engine: terraform | Provider: any | Automated: Yes

All required_providers must have version constraints pinned

Every entry in the terraform required_providers block must specify a version constraint. Unpinned providers allow silent upgrades that may change behavior, introduce breaking changes, or alter sovereign controls without review.

Scope: terraform

Assertions: * version attribute exists — One or more required_providers entries are missing version constraints. * version not matches pattern ^>= 0\\.0\\.0$ — Provider version constraint is too broad (>= 0.0.0). Use a tightly bounded constraint.

Remediation: Add version constraints to all required_providers using the ~> operator for compatible version pinning (e.g., ~> 5.0 for AWS provider v5.x).

Compliant

terraform {
  required_version = ">= 1.6.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.40"
    }
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.100"
    }
  }
}

Non-Compliant

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      # No version constraint – any version accepted
    }
  }
}

waf-sov-080.tf.any.required-terraform-version

Engine: terraform | Provider: any | Automated: Yes

Terraform required_version must be set

The 'terraform' block must include a required_version constraint to ensure reproducible behavior across environments and prevent use of incompatible Terraform versions.

Scope: terraform

Assertions: * required_version attribute exists — terraform block is missing required_version constraint.

Remediation: Add required_version = ">= 1.x.x" to the terraform configuration block.

Compliant

terraform {
  required_version = ">= 1.6.0, < 2.0.0"
}

Non-Compliant

terraform {
  # No required_version set
}

waf-sov-080.tf.any.module-source-version-pinned

Engine: terraform | Provider: any | Automated: Yes

Terraform module sources must reference a pinned version

Terraform modules sourced from the Terraform Registry must specify a 'version' attribute. Git-sourced modules must reference a specific tag or commit hash, not a branch reference.

Scope: module

Assertions: * version matches pattern \?(ref|version)= — Registry module must specify a pinned 'version'. * source not matches pattern \\?ref=main|\\?ref=master|\\?ref=develop — Git module source must reference a specific tag or commit hash, not a branch.

Remediation: Pin module versions explicitly. For registry modules: use version = "x.y.z". For git modules: use ?ref=v1.2.3 with a semver tag.

Compliant

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.5.3"
}
module "internal_module" {
  source = "git::https://git.example.com/modules/vpc.git?ref=v2.1.0"
}

Non-Compliant

module "vpc" {
  source = "terraform-aws-modules/vpc/aws"
  # No version pinned
}
module "internal_module" {
  source = "git::https://git.example.com/modules/vpc.git?ref=main"
  # Branch reference – mutable
}

waf-sov-080.tf.any.no-untrusted-registry-modules

Engine: terraform | Provider: any | Automated: Yes

Terraform module sources must use approved registries or internal git

Module sources must reference the official Terraform Registry (registry.terraform.io), an approved internal module registry, or a verified internal git repository. Arbitrary public git repositories without version pinning are not permitted.

Scope: module

Assertions: * source not matches pattern ^github\\.com/(?!hashicorp/).*\\.git$ — Module source references an unapproved public GitHub repository without registry validation.

Remediation: Migrate to official Terraform Registry modules (registry.terraform.io) or publish internal modules to your private registry.

waf-sov-080.tf.stackit.required-provider-version

Engine: terraform | Provider: stackit | Automated: Yes

StackIT provider must have pinned version constraint

The StackIT (SchwarzIT) Terraform provider must have a version constraint pinned to prevent silent upgrades.

Scope: terraform

Assertions: * version attribute exists — StackIT provider must have version constraint pinned. * version not matches pattern ^>= 0\\.0\\.0$ — StackIT provider version constraint is too broad.

Remediation: Add version constraint to the StackIT provider in required_providers block.

Compliant

terraform {
  required_version = ">= 1.6.0"
  required_providers {
    stackit = {
      source  = "SchwarzIT/stackit"
      version = "~> 2.0"
    }
  }
}

Non-Compliant

terraform {
  required_providers {
    stackit = {
      source = "SchwarzIT/stackit"
      # No version constraint
    }
  }
}

waf-sov-080.tf.ovh.required-provider-version

Engine: terraform | Provider: ovh | Automated: Yes

OVH provider must have pinned version constraint

The OVH Terraform provider must have a version constraint pinned to prevent silent upgrades.

Scope: terraform

Assertions: * version attribute exists — OVH provider must have version constraint pinned. * version not matches pattern ^>= 0\\.0\\.0$ — OVH provider version constraint is too broad.

Remediation: Add version constraint to the OVH provider in required_providers block.

Compliant

terraform {
  required_version = ">= 1.6.0"
  required_providers {
    ovh = {
      source  = "ovh/ovh"
      version = "~> 1.0"
    }
  }
}

Non-Compliant

terraform {
  required_providers {
    ovh = {
      source = "ovh/ovh"
      # No version constraint
    }
  }
}

waf-sov-080.tf.hcloud.required-provider-version

Engine: terraform | Provider: hcloud | Automated: Yes

Hetzner Cloud provider must have pinned version constraint

The Hetzner Cloud Terraform provider must have a version constraint pinned to prevent silent upgrades.

Scope: terraform

Assertions: * version attribute exists — Hetzner Cloud provider must have version constraint pinned. * version not matches pattern ^>= 0\\.0\\.0$ — Hetzner Cloud provider version constraint is too broad.

Remediation: Add version constraint to the Hetzner Cloud provider in required_providers block.

Compliant

terraform {
  required_version = ">= 1.6.0"
  required_providers {
    hcloud = {
      source  = "hetznercloud/hcloud"
      version = "~> 1.0"
    }
  }
}

Non-Compliant

terraform {
  required_providers {
    hcloud = {
      source = "hetznercloud/hcloud"
      # No version constraint
    }
  }
}

waf-sov-080.config.aws.aws-logging-monitoring

Engine: config | Provider: aws | Automated: Yes

An inventory of all dependencies and subprocessors MUST be maintained:

A version-controlled policy document must exist at docs/sovereign/waf-sov-080-aws-logging-monitoring.md and document the AWS 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-080-aws-logging-monitoring.md

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

Compliant

docs/sovereign/waf-sov-080-aws-logging-monitoring.md:
- The AWS implementation of WAF-SOV-080 is documented.
- Implementation status and owner are recorded.
- Review cadence is defined (e.g. quarterly).

Non-Compliant

# `docs/sovereign/waf-sov-080-aws-logging-monitoring.md` is missing or does not contain a normative requirement.
# WAF-SOV-080 violation: AWS control is not documented

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

Engine: config | Provider: azurerm | Automated: Yes

An inventory of all dependencies and subprocessors MUST be maintained:

A version-controlled policy document must exist at docs/sovereign/waf-sov-080-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-080-azurerm-logging-monitoring.md

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

Compliant

docs/sovereign/waf-sov-080-azurerm-logging-monitoring.md:
- The Azure implementation of WAF-SOV-080 is documented.
- Implementation status and owner are recorded.
- Review cadence is defined (e.g. quarterly).

Non-Compliant

# `docs/sovereign/waf-sov-080-azurerm-logging-monitoring.md` is missing or does not contain a normative requirement.
# WAF-SOV-080 violation: Azure control is not documented

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

Engine: config | Provider: google | Automated: Yes

An inventory of all dependencies and subprocessors MUST be maintained:

A version-controlled policy document must exist at docs/sovereign/waf-sov-080-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-080-google-logging-monitoring.md

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

Compliant

docs/sovereign/waf-sov-080-google-logging-monitoring.md:
- The GCP implementation of WAF-SOV-080 is documented.
- Implementation status and owner are recorded.
- Review cadence is defined (e.g. quarterly).

Non-Compliant

# `docs/sovereign/waf-sov-080-google-logging-monitoring.md` is missing or does not contain a normative requirement.
# WAF-SOV-080 violation: GCP control is not documented

Evidence

Kind Required Description

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.

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. 28 – Processor * Art. 30 – Records of processing activities * Art. 44-46 – Transfers to third countries
BSI C5:2020	* SCA-01 – Supply chain management * OPS-04 – Data management
BSI C3A:2026	* Dimension 6 – Supply Chain: Software inventory (SBoM) * Dimension 6 – Supply Chain: Hardware inventory * Dimension 6 – Supply Chain: External service dependencies
EUCS (ENISA)	* SCA-01 – Supply chain * IAM-04 – Third-party access
ISO 27001:2022	* A.5.19 – Information security in supplier relationships * A.5.20 – Addressing information security in supplier agreements * A.5.21 – Managing information security in the ICT supply chain

Framework

Controls

GDPR

* Art. 28 – Processor * Art. 30 – Records of processing activities * Art. 44-46 – Transfers to third countries

BSI C5:2020

* SCA-01 – Supply chain management * OPS-04 – Data management

BSI C3A:2026

* Dimension 6 – Supply Chain: Software inventory (SBoM) * Dimension 6 – Supply Chain: Hardware inventory * Dimension 6 – Supply Chain: External service dependencies

EUCS (ENISA)

* SCA-01 – Supply chain * IAM-04 – Third-party access

ISO 27001:2022

* A.5.19 – Information security in supplier relationships * A.5.20 – Addressing information security in supplier agreements * A.5.21 – Managing information security in the ICT supply chain