WAF-REL-010 – SLA & SLO Definition Documented

Pillar: Reliability | Severity: Critical | Category: Logging Monitoring | Automatable: High

Description

Every production workload MUST have documented Service Level Objectives (SLOs) and Service Level Agreements (SLAs). SLOs must define availability, latency, error rate, and throughput targets with explicit measurement windows. SLAs must reference SLOs and define consequences of non-compliance. Both documents must be version-controlled, reviewed quarterly, and linked to monitoring dashboards with automated alerting when error budgets are consumed.

Rationale

Risk	Description
Risk	Workloads without documented SLOs cannot measure or communicate user impact.
Risk	Missing availability targets lead to inconsistent expectations between teams and stakeholders.

Risk

Description

Risk

Workloads without documented SLOs cannot measure or communicate user impact.

Risk

Missing availability targets lead to inconsistent expectations between teams and stakeholders.

Requirements

Every production workload MUST have documented Service Level Objectives (SLOs) and Service Level Agreements (SLAs).
SLOs must define availability, latency, error rate, and throughput targets with explicit measurement windows.
SLAs must reference SLOs and define consequences of non-compliance.
Both documents must be version-controlled, reviewed quarterly, and linked to monitoring dashboards with automated alerting when error budgets are consumed.

Implementation Guidance

Document the requirement in a version-controlled policy or standard.
Assign ownership and establish a review cadence (e.g., quarterly).
Implement the required configuration as code in Terraform or equivalent IaC.

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-010.tf.aws.cloudwatch-slo-alarm

Engine: terraform | Provider: aws | Automated: Yes

AWS CloudWatch alarm must be configured for SLO availability monitoring

An Amazon CloudWatch alarm must be defined to track availability and trigger when the error rate exceeds the SLO threshold. This acts as the automated enforcement of the SLO monitoring requirement.

Scope: resource — aws_cloudwatch_metric_alarm

Assertions: * alarm_name not empty — CloudWatch alarm must have a descriptive name. * metric_name not empty — CloudWatch alarm must specify the metric to monitor. * alarm_actions not empty — CloudWatch alarm must have at least one action configured. * threshold attribute exists — CloudWatch alarm must define a threshold value.

Remediation: Define a CloudWatch alarm that monitors the primary SLO metric (e.g., error rate, latency). Configure alarm_actions to notify SNS topics used by on-call rotation.

Compliant

resource "aws_cloudwatch_metric_alarm" "slo_error_rate" {
  alarm_name          = "slo-payment-service-error-rate"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 5
  metric_name         = "5XXError"
  namespace           = "AWS/ApiGateway"
  period              = 60
  statistic           = "Sum"
  threshold           = 10
  alarm_description   = "SLO: error rate > 0.1% over 5 minutes"
  alarm_actions       = [aws_sns_topic.oncall.arn]
  ok_actions          = [aws_sns_topic.oncall.arn]
  treat_missing_data  = "notBreaching"
}

Non-Compliant

resource "aws_cloudwatch_metric_alarm" "error_alarm" {
  alarm_name          = "errors"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 1
  metric_name         = "Errors"
  namespace           = "AWS/Lambda"
  period              = 300
  statistic           = "Sum"
  threshold           = 100
  # Missing: alarm_actions – no one is notified
}

waf-rel-010.tf.azurerm.monitor-metric-alert-slo

Engine: terraform | Provider: azurerm | Automated: Yes

Azure Monitor metric alert must be configured for SLO monitoring

An Azure Monitor metric alert must be configured for each production workload to track availability and latency against SLO targets.

Scope: resource — azurerm_monitor_metric_alert

Assertions: * name not empty — Monitor alert must have a descriptive name. * criteria attribute exists — Monitor alert must define alert criteria. * action attribute exists — Monitor alert must have at least one action group configured.

Remediation: Configure an azurerm_monitor_metric_alert with criteria referencing the SLO metric and an action block pointing to an azurerm_monitor_action_group that notifies on-call.

Compliant

resource "azurerm_monitor_metric_alert" "slo_availability" {
  name                = "slo-api-availability"
  resource_group_name = azurerm_resource_group.main.name
  scopes              = [azurerm_application_insights.main.id]
  description         = "SLO: availability < 99.9%"
  severity            = 1
  criteria {
    metric_namespace = "microsoft.insights/components"
    metric_name      = "availabilityResults/availabilityPercentage"
    aggregation      = "Average"
    operator         = "LessThan"
    threshold        = 99.9
  }
  action {
    action_group_id = azurerm_monitor_action_group.oncall.id
  }
}

Non-Compliant

resource "azurerm_monitor_metric_alert" "alert" {
  name                = "alert"
  resource_group_name = azurerm_resource_group.main.name
  scopes              = [azurerm_application_insights.main.id]
  criteria {
    metric_namespace = "microsoft.insights/components"
    metric_name      = "requests/failed"
    aggregation      = "Count"
    operator         = "GreaterThan"
    threshold        = 100
  }
  # Missing: action – no notification configured
}

waf-rel-010.tf.google.monitoring-alert-policy-slo

Engine: terraform | Provider: google | Automated: Yes

GCP Monitoring alert policy must be configured for SLO tracking

A Google Cloud Monitoring alert policy must be configured to track SLO compliance and notify on-call when error budget burn rate exceeds thresholds.

Scope: resource — google_monitoring_alert_policy

Assertions: * display_name not empty — Alert policy must have a descriptive display name. * conditions not empty — Alert policy must define monitoring conditions. * notification_channels not empty — Alert policy must have notification channels configured.

Remediation: Define a google_monitoring_alert_policy with conditions referencing the SLO metric and notification_channels pointing to configured channels (PagerDuty, email, etc.).

Compliant

resource "google_monitoring_alert_policy" "slo_burn_rate" {
  display_name = "SLO Error Budget Burn Rate – Payment API"
  combiner     = "OR"
  conditions {
    display_name = "Fast burn: >14x for 1h"
    condition_threshold {
      filter          = "select_slo_burn_rate(\"projects/${var.project}/services/payment-api/serviceLevelObjectives/availability\", 3600)"
      comparison      = "COMPARISON_GT"
      threshold_value = 14.4
      duration        = "0s"
    }
  }
  notification_channels = [google_monitoring_notification_channel.oncall.name]
  alert_strategy {
    notification_rate_limit { period = "300s" }
  }
}

Non-Compliant

resource "google_monitoring_alert_policy" "errors" {
  display_name = "Errors"
  combiner     = "OR"
  conditions {
    display_name = "Error count"
    condition_threshold {
      filter          = "metric.type=\"logging.googleapis.com/user/errors\""
      comparison      = "COMPARISON_GT"
      threshold_value = 100
      duration        = "60s"
    }
  }
  # Missing: notification_channels – alert fires silently
}

waf-rel-010.tf.stackit.availability-slo-defined

Engine: terraform | Provider: stackit | Automated: Yes

Every production workload for stackit

Every production workload must be documented in IaC via a availability-slo-defined 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 availability-slo-defined tag/label.

Remediation: Add a availability-slo-defined tag/label to the stackit_project resource to show the stackit implementation of WAF-REL-010 is tracked in IaC.

Compliant

resource "stackit_project" "example" {
  labels = {
    availability-slo-defined = "true"
  }
}

Non-Compliant

resource "stackit_project" "example" {
  # Missing availability-slo-defined labels
}

waf-rel-010.tf.ovh.availability-slo-defined

Engine: terraform | Provider: ovh | Automated: Yes

Every production workload for ovh

Every production workload must be documented in IaC via a availability-slo-defined 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 availability-slo-defined tag/label.

Remediation: Add a availability-slo-defined tag/label to the ovh_cloud_project resource to show the ovh implementation of WAF-REL-010 is tracked in IaC.

Compliant

resource "ovh_cloud_project" "example" {
  tags = {
    availability-slo-defined = "true"
  }
}

Non-Compliant

resource "ovh_cloud_project" "example" {
  # Missing availability-slo-defined tags
}

waf-rel-010.tf.hcloud.availability-slo-defined

Engine: terraform | Provider: hcloud | Automated: Yes

Every production workload for hcloud

Every production workload must be documented in IaC via a availability-slo-defined 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 availability-slo-defined tag/label.

Remediation: Add a availability-slo-defined tag/label to the hcloud_server resource to show the hcloud implementation of WAF-REL-010 is tracked in IaC.

Compliant

resource "hcloud_server" "example" {
  labels = {
    availability-slo-defined = "true"
  }
}

Non-Compliant

resource "hcloud_server" "example" {
  # Missing availability-slo-defined 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 * A.17.2 – Redundancies
ITIL 4	* Service Level Management * Service Continuity Management
SRE Book (Google)	* Chapter 4 – Service Level Objectives * Chapter 5 – Eliminating Toil

Framework

Controls

ISO 27001:2022

* A.17.1 – Information security continuity * A.17.2 – Redundancies

ITIL 4

* Service Level Management * Service Continuity Management

SRE Book (Google)

* Chapter 4 – Service Level Objectives * Chapter 5 – Eliminating Toil