WAF-REL-100 – Reliability Debt Register & Quarterly Review

Pillar: Reliability | Severity: Medium | Category: Reliability Design | Automatable: High

Description

All known reliability risks, deferred reliability improvements, and technical decisions that reduce system resilience MUST be tracked in a version-controlled Reliability Debt Register. Each entry MUST include: description, workload affected, severity (P1–P4), estimated remediation effort, business risk if deferred, owner, and target remediation date. The register MUST be reviewed quarterly by engineering leadership. Reliability debt created by deliberate architecture decisions MUST be accepted in writing with a remediation plan.

Rationale

Risk	Description
Risk	Service outages impact users and revenue when redundancy is missing.
Risk	Recovery from failures is slower without tested runbooks or automated rollback.

Risk

Description

Risk

Service outages impact users and revenue when redundancy is missing.

Risk

Recovery from failures is slower without tested runbooks or automated rollback.

Requirements

All known reliability risks, deferred reliability improvements, and technical decisions that reduce system resilience MUST be tracked in a version-controlled Reliability Debt Register.
Each entry MUST include: description, workload affected, severity (P1–P4), estimated remediation effort, business risk if deferred, owner, and target remediation date.
The register MUST be reviewed quarterly by engineering leadership.
Reliability debt created by deliberate architecture decisions MUST be accepted in writing with a remediation plan.

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-rel-100.tf.aws.config-conformance-pack

Engine: terraform | Provider: aws | Automated: Yes

AWS Config conformance packs must be deployed for reliability compliance tracking

AWS Config conformance packs for reliability controls should be deployed to automatically track compliance status of reliability requirements across accounts.

Scope: resource — aws_config_conformance_pack

Assertions: * name not empty — Config conformance pack must have a name. * template_body attribute exists — Config conformance pack must define template_body or template_s3_uri.

Remediation: Deploy aws_config_conformance_pack with a template covering reliability rules: rds-multi-az-support, elasticache-replication-group-multi-az-enabled, backup-plan-min-frequency-and-min-retention-check.

Compliant

resource "aws_config_conformance_pack" "reliability" {
  name = "reliability-conformance-pack"

  template_body = <<-EOT
    Parameters: {}
    Resources:
      RDSMultiAZ:
        Type: AWS::Config::ConfigRule
        Properties:
          ConfigRuleName: rds-multi-az-support
          Source:
            Owner: AWS
            SourceIdentifier: RDS_MULTI_AZ_SUPPORT
      BackupRecoveryPoint:
        Type: AWS::Config::ConfigRule
        Properties:
          ConfigRuleName: backup-recovery-point-minimum-retention-check
          Source:
            Owner: AWS
            SourceIdentifier: BACKUP_RECOVERY_POINT_MINIMUM_RETENTION_CHECK
  EOT
}

Non-Compliant

# No AWS Config conformance pack configured
# Reliability compliance status not tracked automatically
# WAF-REL-100 violation

waf-rel-100.tf.azurerm.policy-assignment-reliability

Engine: terraform | Provider: azurerm | Automated: Yes

Azure Policy assignments must cover reliability compliance requirements

Azure Policy assignments should enforce reliability controls at the subscription or management group level to automate compliance tracking.

Scope: resource — azurerm_subscription_policy_assignment, azurerm_management_group_policy_assignment

Assertions: * name not empty — Policy assignment must have a name. * policy_definition_id not empty — Policy assignment must reference a policy definition ID. * display_name not empty — Policy assignment must have a descriptive display name.

Remediation: Create azurerm_subscription_policy_assignment referencing built-in reliability policies (zone-redundant databases, geo-redundant backup, etc.)

Compliant

resource "azurerm_subscription_policy_assignment" "reliability_zone_redundant" {
  name                 = "require-zone-redundant-databases"
  subscription_id      = var.subscription_id
  policy_definition_id = "/providers/Microsoft.Authorization/policyDefinitions/00000000-0000-0000-0000-000000000001"
  display_name         = "Reliability: Require zone-redundant databases in production"
  description          = "Enforces WAF-REL-030: Multi-AZ/zone-redundant deployment for databases."
  enforce              = true
  location             = "westeurope"
  identity { type = "SystemAssigned" }
}

Non-Compliant

# No Azure Policy assignments for reliability
# Reliability compliance manually tracked or not tracked at all
# WAF-REL-100 violation

waf-rel-100.tf.google.org-policy-reliability

Engine: terraform | Provider: google | Automated: Yes

GCP Organization policies should enforce reliability constraints

GCP organization policies should enforce constraints relevant to reliability such as requiring deletion protection on production databases.

Scope: resource — google_org_policy_policy, google_project_organization_policy

Assertions: * name not empty — Organization policy must have a name. * spec attribute exists — Organization policy must define spec.

Remediation: Define google_org_policy_policy resources enforcing reliability constraints at the project or organization level.

Compliant

resource "google_project_organization_policy" "sql_deletion_protection" {
  project    = var.project_id
  constraint = "constraints/sql.restrictAuthorizedNetworks"

  list_policy {
    deny {
      all = true
    }
  }
}

Non-Compliant

# No GCP organization policies for reliability enforcement
# Reliability controls rely on team convention only
# WAF-REL-100 violation

waf-rel-100.tf.stackit.disaster-recovery-tested

Engine: terraform | Provider: stackit | Automated: Yes

All known reliability risks, deferred reliability improvements, and… for stackit

All known reliability risks, deferred reliability improvements, and… must be documented in IaC via a disaster-recovery-tested tag/label on stackit_project. This validates the control is tracked as code.

Scope: resource — stackit_project

Assertions: * labels key exists — stackit_project is missing the disaster-recovery-tested tag/label.

Remediation: Add a disaster-recovery-tested tag/label to the stackit_project resource to show the stackit implementation of WAF-REL-100 is tracked in IaC.

Compliant

resource "stackit_project" "example" {
  labels = {
    disaster-recovery-tested = "true"
  }
}

Non-Compliant

resource "stackit_project" "example" {
  # Missing disaster-recovery-tested labels
}

waf-rel-100.tf.ovh.disaster-recovery-tested

Engine: terraform | Provider: ovh | Automated: Yes

All known reliability risks, deferred reliability improvements, and… for ovh

All known reliability risks, deferred reliability improvements, and… must be documented in IaC via a disaster-recovery-tested tag/label on ovh_cloud_project. This validates the control is tracked as code.

Scope: resource — ovh_cloud_project

Assertions: * tags key exists — ovh_cloud_project is missing the disaster-recovery-tested tag/label.

Remediation: Add a disaster-recovery-tested tag/label to the ovh_cloud_project resource to show the ovh implementation of WAF-REL-100 is tracked in IaC.

Compliant

resource "ovh_cloud_project" "example" {
  tags = {
    disaster-recovery-tested = "true"
  }
}

Non-Compliant

resource "ovh_cloud_project" "example" {
  # Missing disaster-recovery-tested tags
}

waf-rel-100.tf.hcloud.disaster-recovery-tested

Engine: terraform | Provider: hcloud | Automated: Yes

All known reliability risks, deferred reliability improvements, and… for hcloud

All known reliability risks, deferred reliability improvements, and… must be documented in IaC via a disaster-recovery-tested tag/label on hcloud_server. This validates the control is tracked as code.

Scope: resource — hcloud_server

Assertions: * labels key exists — hcloud_server is missing the disaster-recovery-tested tag/label.

Remediation: Add a disaster-recovery-tested tag/label to the hcloud_server resource to show the hcloud implementation of WAF-REL-100 is tracked in IaC.

Compliant

resource "hcloud_server" "example" {
  labels = {
    disaster-recovery-tested = "true"
  }
}

Non-Compliant

resource "hcloud_server" "example" {
  # Missing disaster-recovery-tested labels
}

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
ISO 27001:2022	* A.17.1 – Information security continuity * 6.1.2 – Information security risk assessment
ITIL 4	* Problem Management * Continual Improvement
SRE Book (Google)	* Chapter 5 – Eliminating Toil * Chapter 6 – Monitoring Distributed Systems

Framework

Controls

ISO 27001:2022

* A.17.1 – Information security continuity * 6.1.2 – Information security risk assessment

ITIL 4

* Problem Management * Continual Improvement

SRE Book (Google)

* Chapter 5 – Eliminating Toil * Chapter 6 – Monitoring Distributed Systems