WAF-SEC-100 – Incident Response Readiness

Pillar: Security | Severity: Medium | Category: Identity Access | Automatable: High

Description

An incident response (IR) plan MUST exist, be documented, version-controlled, and tested at least annually via tabletop exercises or simulated incident drills. SNS topics or equivalent alerting channels MUST be configured to receive security findings from GuardDuty, Security Hub, and CloudTrail metric alarms. Security-relevant CloudWatch log groups MUST retain logs for a minimum of 365 days. S3-based CloudTrail and VPC Flow Log archives MUST be retained for at least 12 months. The incident response plan MUST define roles and responsibilities, escalation paths, communication templates, and steps for evidence preservation, containment, eradication, and recovery.

Rationale

Risk	Description
Risk	Missing incident-response plans extend reaction times and worsen the impact of security incidents.
Risk	Untested IR processes lead to wrong decisions and missed regulatory reporting obligations in a real event.

Risk

Description

Risk

Missing incident-response plans extend reaction times and worsen the impact of security incidents.

Risk

Untested IR processes lead to wrong decisions and missed regulatory reporting obligations in a real event.

Requirements

An incident response (IR) plan MUST exist, be documented, version-controlled, and tested at least annually via tabletop exercises or simulated incident drills.
SNS topics or equivalent alerting channels MUST be configured to receive security findings from GuardDuty, Security Hub, and CloudTrail metric alarms.
Security-relevant CloudWatch log groups MUST retain logs for a minimum of 365 days.
S3-based CloudTrail and VPC Flow Log archives MUST be retained for at least 12 months.
The incident response plan MUST define roles and responsibilities, escalation paths, communication templates, and steps for evidence preservation, containment, eradication, and recovery.

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-sec-100.tf.aws.sns-security-alerts

Engine: terraform | Provider: aws | Automated: Yes

SNS topic for security alerts must be provisioned

An aws_sns_topic resource for security alerting must exist in the account. This topic should be subscribed to GuardDuty and Security Hub EventBridge rules, and must have at least one active subscription routing to an on-call system.

Scope: resource — aws_sns_topic

Assertions: * name attribute exists — An SNS topic for security alerts must be provisioned with a defined name.

Remediation: Create an aws_sns_topic resource named 'security-alerts' or similar. Add subscriptions (aws_sns_topic_subscription) pointing to PagerDuty, OpsGenie, or a Slack webhook endpoint. Configure EventBridge rules targeting this topic for GuardDuty findings with severity >= 7 and Security Hub CRITICAL findings.

Compliant

resource "aws_sns_topic" "security_alerts" {
  name              = "security-alerts"
  kms_master_key_id = aws_kms_key.sns.id
  tags = {
    owner       = "security-team"
    environment = "production"
  }
}
resource "aws_sns_topic_subscription" "pagerduty" {
  topic_arn = aws_sns_topic.security_alerts.arn
  protocol  = "https"
  endpoint  = var.pagerduty_endpoint
}

Non-Compliant

# No aws_sns_topic resource for security alerts present
# WAF-SEC-100 violation: security alerting channel not provisioned in IaC

waf-sec-100.tf.aws.cloudwatch-log-retention-security

Engine: terraform | Provider: aws | Automated: Yes

Security-relevant CloudWatch log groups must retain logs for at least 365 days

CloudWatch log groups used for security-relevant data (application logs, VPC flow logs ingested into CloudWatch, Lambda security function logs) must have retention_in_days set to at least 365 to satisfy forensic and regulatory retention requirements.

Scope: resource — aws_cloudwatch_log_group

Assertions: * retention_in_days greater than or equal 365 — Security-relevant log groups MUST retain logs for at least 365 days to support forensic investigation and regulatory compliance.

Remediation: Set retention_in_days = 365 (or higher) on all security-relevant aws_cloudwatch_log_group resources. For CloudTrail and VPC Flow Logs with higher volume, consider using S3-based retention with lifecycle policies (Standard for 12 months, Glacier for 7 years) rather than CloudWatch to optimize cost.

Compliant

resource "aws_cloudwatch_log_group" "app_security" {
  name              = "/security/application-events"
  retention_in_days = 365
  kms_key_id        = aws_kms_key.logs.arn
  tags = {
    owner       = "security-team"
    data-class  = "operational"
  }
}

Non-Compliant

resource "aws_cloudwatch_log_group" "app_security" {
  name              = "/security/application-events"
  retention_in_days = 30  # WAF-SEC-100 violation: below 365-day minimum
}

waf-sec-100.manual.any.incident-response-plan

Engine: manual | Provider: any | Automated: Yes

Incident response plan must exist, be version-controlled, and tested annually

A formal incident response plan must be documented, stored in version control, and tested via tabletop exercise or live drill at least once per year. The plan must cover roles, escalation paths, GDPR breach notification workflow, and playbooks for the top incident types relevant to the workload.

Scope: terraform

Assertions: * ir_plan_version_controlled is true — Incident response plan must be stored in version control (e.g., Git repository under /docs/security/ir-plan.md).

Remediation: 1. Draft an incident response plan covering: Preparation, Detection & Analysis,\n Containment, Eradication, Recovery, and Post-Incident Review phases.\n2. Define RACI matrix for each phase including external communication and\n GDPR DPA notification responsibility.\n3. Create runbooks for top 5-10 incident types (credential compromise, data exfiltration,\n ransomware, privilege escalation, supply chain attack).\n4. Store the IR plan in a version-controlled repository with mandatory review. 5. Schedule annual tabletop exercise; document results and track action items.

Compliant

# IR plan stored at: docs/security/incident-response-plan.md (version-controlled)
# Last tested: 2025-11-15 via tabletop exercise (ref: IR-DRILL-2025-001)
# Runbooks available at: docs/security/runbooks/
# GDPR DPA notification workflow: docs/security/gdpr-breach-notification.md

Non-Compliant

# No incident response plan exists in the repository.
# WAF-SEC-100 violation: IR plan is a mandatory governance artifact.

waf-sec-100.config.azurerm.azurerm-identity-access

Engine: config | Provider: azurerm | Automated: Yes

An incident response (IR) plan MUST exist, be documented,…

A version-controlled policy document must exist at docs/security/waf-sec-100-azurerm-identity-access.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/security/waf-sec-100-azurerm-identity-access.md

Remediation: Create or update docs/security/waf-sec-100-azurerm-identity-access.md. State the requirement, how it is implemented for Azure, the review cadence, and the owner.

Compliant

docs/security/waf-sec-100-azurerm-identity-access.md:
- The Azure implementation of WAF-SEC-100 is documented.
- Implementation status and owner are recorded.
- Review cadence is defined (e.g. quarterly).

Non-Compliant

# `docs/security/waf-sec-100-azurerm-identity-access.md` is missing or does not contain a normative requirement.
# WAF-SEC-100 violation: Azure control is not documented

waf-sec-100.config.google.google-identity-access

Engine: config | Provider: google | Automated: Yes

An incident response (IR) plan MUST exist, be documented,…

A version-controlled policy document must exist at docs/security/waf-sec-100-google-identity-access.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/security/waf-sec-100-google-identity-access.md

Remediation: Create or update docs/security/waf-sec-100-google-identity-access.md. State the requirement, how it is implemented for GCP, the review cadence, and the owner.

Compliant

docs/security/waf-sec-100-google-identity-access.md:
- The GCP implementation of WAF-SEC-100 is documented.
- Implementation status and owner are recorded.
- Review cadence is defined (e.g. quarterly).

Non-Compliant

# `docs/security/waf-sec-100-google-identity-access.md` is missing or does not contain a normative requirement.
# WAF-SEC-100 violation: GCP control is not documented

waf-sec-100.config.stackit.stackit-identity-access

Engine: config | Provider: stackit | Automated: Yes

STACKIT incident response plan must be documented and tested

A version-controlled policy document must exist at docs/security/waf-sec-100-stackit-identity-access.md and document the STACKIT implementation of this control. The checker validates that the file exists and contains a normative requirement statement (MUST/SHALL/required/mandatory).

Scope: file — docs/security/waf-sec-100-stackit-identity-access.md

Remediation: Create or update docs/security/waf-sec-100-stackit-identity-access.md. State the requirement, how it is implemented for STACKIT, the review cadence, and the owner.

Compliant

docs/security/waf-sec-100-stackit-identity-access.md:
- The STACKIT implementation of WAF-SEC-100 is documented.
- Implementation status and owner are recorded.
- Review cadence is defined (e.g. quarterly).

Non-Compliant

# `docs/security/waf-sec-100-stackit-identity-access.md` is missing or does not contain a normative requirement.
# WAF-SEC-100 violation: STACKIT control is not documented

waf-sec-100.config.ovh.ovh-identity-access

Engine: config | Provider: ovh | Automated: Yes

OVHcloud incident response plan must be documented and tested

A version-controlled policy document must exist at docs/security/waf-sec-100-ovh-identity-access.md and document the OVHcloud implementation of this control. The checker validates that the file exists and contains a normative requirement statement (MUST/SHALL/required/mandatory).

Scope: file — docs/security/waf-sec-100-ovh-identity-access.md

Remediation: Create or update docs/security/waf-sec-100-ovh-identity-access.md. State the requirement, how it is implemented for OVHcloud, the review cadence, and the owner.

Compliant

docs/security/waf-sec-100-ovh-identity-access.md:
- The OVHcloud implementation of WAF-SEC-100 is documented.
- Implementation status and owner are recorded.
- Review cadence is defined (e.g. quarterly).

Non-Compliant

# `docs/security/waf-sec-100-ovh-identity-access.md` is missing or does not contain a normative requirement.
# WAF-SEC-100 violation: OVHcloud control is not documented

waf-sec-100.config.hcloud.hcloud-identity-access

Engine: config | Provider: hcloud | Automated: Yes

Hetzner Cloud incident response plan must be documented and tested

A version-controlled policy document must exist at docs/security/waf-sec-100-hcloud-identity-access.md and document the Hetzner Cloud implementation of this control. The checker validates that the file exists and contains a normative requirement statement (MUST/SHALL/required/mandatory).

Scope: file — docs/security/waf-sec-100-hcloud-identity-access.md

Remediation: Create or update docs/security/waf-sec-100-hcloud-identity-access.md. State the requirement, how it is implemented for Hetzner Cloud, the review cadence, and the owner.

Compliant

docs/security/waf-sec-100-hcloud-identity-access.md:
- The Hetzner Cloud implementation of WAF-SEC-100 is documented.
- Implementation status and owner are recorded.
- Review cadence is defined (e.g. quarterly).

Non-Compliant

# `docs/security/waf-sec-100-hcloud-identity-access.md` is missing or does not contain a normative requirement.
# WAF-SEC-100 violation: Hetzner Cloud 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
ISO 27001:2022	* A.5.24 – Information security incident management planning * A.5.25 – Assessment and decision on information security events * A.5.26 – Response to information security incidents * A.5.27 – Learning from information security incidents * A.5.28 – Collection of evidence
ISO 27017	* CLD.16.1 – Information security incident management in cloud
CIS Controls v8	* CIS 17 – Incident Response Management
CSA STAR	* CCM SEF-01 – Security Incident Management Policy * CCM SEF-04 – Incident Response Testing
PCI DSS v4.0	* Req 12.10 – Incident response plan and testing
SOC 2 Type II	* CC7.4 – Detection of security events * CC7.5 – Incident response
GDPR	* Art. 33 – Breach notification within 72 hours * Art. 34 – Communication of breach to data subject
NIS2	* Art. 21(2)(b) – Incident handling * Art. 23 – Reporting obligations (24/72 hour notifications)
DORA	* Art. 13 – ICT incident reporting * Art. 17 – Testing of ICT tools and systems
EUCS (ENISA)	* OPS-07 – Security incident management * BCR-01 – Business continuity
BSI C5:2020	* SIM-01 – Security incident management * SIM-02 – Security information and event management * BCM-02 – Business continuity
IT-Grundschutz	* DER.2 – Behandlung von Sicherheitsvorfällen * DER.3 – Sicherheitsprüfungen
TISAX	* Information security – Incident response and management
ANSSI SecNumCloud	* Domain – Incident response and crisis management
BIO	* BIO – Incidentmanagement en respons
ENS High	* op.exp.7 – Gestión de incidentes
UK NCSC CAF	* D1 – Response and recovery planning * D2 – Lessons learned
UK GDPR	* Art. 33 – Breach notification * Art. 34 – Communication to data subject
NIST SP 800-53	* IR-1 – Incident Response Policy * IR-4 – Incident Handling * IR-6 – Incident Reporting * IR-8 – Incident Response Plan
NIST CSF 2.0	* RS.MA – Incident Management * RS.AN – Incident Analysis * RC.RP – Recovery Plan
FedRAMP	* IR-1, IR-4, IR-6, IR-8 (Moderate/High baseline)
HIPAA	* § 164.308(a)(6) – Security incident procedures * § 164.408 – Notification of breach
CMMC 2.0	* IR.L2-3.6.1 – Establish incident handling capability * IR.L2-3.6.2 – Track, document and report incidents
IRAP	* ISM – Cyber security incident management
CCCS PBMM	* IR-4, IR-8 – Incident handling and response plan
MAS TRM	* Ch.10 – Security incident management
ISMAP	* Incident response and reporting
FISC	* Operational measures – Incident response and reporting

Framework

Controls

ISO 27001:2022

* A.5.24 – Information security incident management planning * A.5.25 – Assessment and decision on information security events * A.5.26 – Response to information security incidents * A.5.27 – Learning from information security incidents * A.5.28 – Collection of evidence

ISO 27017

* CLD.16.1 – Information security incident management in cloud

CIS Controls v8

* CIS 17 – Incident Response Management

CSA STAR

* CCM SEF-01 – Security Incident Management Policy * CCM SEF-04 – Incident Response Testing

PCI DSS v4.0

* Req 12.10 – Incident response plan and testing

SOC 2 Type II

* CC7.4 – Detection of security events * CC7.5 – Incident response

GDPR

* Art. 33 – Breach notification within 72 hours * Art. 34 – Communication of breach to data subject

NIS2

* Art. 21(2)(b) – Incident handling * Art. 23 – Reporting obligations (24/72 hour notifications)

DORA

* Art. 13 – ICT incident reporting * Art. 17 – Testing of ICT tools and systems

EUCS (ENISA)

* OPS-07 – Security incident management * BCR-01 – Business continuity

BSI C5:2020

* SIM-01 – Security incident management * SIM-02 – Security information and event management * BCM-02 – Business continuity

IT-Grundschutz

* DER.2 – Behandlung von Sicherheitsvorfällen * DER.3 – Sicherheitsprüfungen

TISAX

* Information security – Incident response and management

ANSSI SecNumCloud

* Domain – Incident response and crisis management

BIO

* BIO – Incidentmanagement en respons

ENS High

* op.exp.7 – Gestión de incidentes

UK NCSC CAF

* D1 – Response and recovery planning * D2 – Lessons learned

UK GDPR

* Art. 33 – Breach notification * Art. 34 – Communication to data subject

NIST SP 800-53

* IR-1 – Incident Response Policy * IR-4 – Incident Handling * IR-6 – Incident Reporting * IR-8 – Incident Response Plan

NIST CSF 2.0

* RS.MA – Incident Management * RS.AN – Incident Analysis * RC.RP – Recovery Plan

FedRAMP

* IR-1, IR-4, IR-6, IR-8 (Moderate/High baseline)

HIPAA

* § 164.308(a)(6) – Security incident procedures * § 164.408 – Notification of breach

CMMC 2.0

* IR.L2-3.6.1 – Establish incident handling capability * IR.L2-3.6.2 – Track, document and report incidents

IRAP

* ISM – Cyber security incident management

CCCS PBMM

* IR-4, IR-8 – Incident handling and response plan

MAS TRM

* Ch.10 – Security incident management

ISMAP

* Incident response and reporting

FISC

* Operational measures – Incident response and reporting