What this control covers

This control requires testing the effectiveness of the incident response capability at defined intervals. Testing methods may include checklists, tabletop exercises, and simulations to identify weaknesses and assess the impact on operations, assets, and individuals. Both qualitative and quantitative data are used to evaluate incident response processes. This control supports the Incident Response Testing Mechanism capability within the Incident Response (3.6) family.

Why it matters

Risk is the language an executive team understands; this control connects technical reality to board-level decisions and budget allocation.

How to implement

AWS

Codify the policy intent as SCPs, AWS Config conformance packs, and Security Hub standards so the cloud enforces what the document says.

Azure

Codify in Azure Policy initiatives (built-in regulatory compliance for CIS, ISO 27001, SOC 2, HIPAA) and assign at management-group level.

GitHub

Subscribe to secret-scanning alerts and Dependabot security advisories; require triage SLAs by severity. For exposed secrets, rotate at the cloud provider FIRST then revoke at GitHub — order matters.

On-premises

Maintain a policy library with a documented review cadence (annual minimum); store in your GRC tool with attestation tracking. Map each policy to controls so an audit pull cites the exact policy clause.

Evidence to collect

  • policy_document — A signed, version-controlled policy stating leadership intent and the named owner.
  • infra_scan — See the iCompaas Evidence library for the canonical source for this evidence type.

Signed policy or standard documents the safeguard. Focus: Incident Response Testing.

Quick checklist

  • Response — Management / Checklists
  • Impact — Management / Checklists
  • Incident — Management / Checklists
  • Risk — Management / Checklists
  • Policy — Management / Checklists

Related articles on this site