What this policy is
Defines what counts as a security incident, the response phases (detect, triage, contain, eradicate, recover, learn), and the role each function plays at each phase.
Why every organization needs one
Every regulator and every customer security questionnaire asks for a documented incident-response process. Untrained ad-hoc response is what turns incidents into headlines.
What a competent Incident Management Policy typically contains
- Purpose and scope
- Roles and responsibilities
- Definitions
- Incident classification + severity
- Response-team roles
- Containment authority + criteria
- Lessons-learned + post-mortem requirement
- Review cadence (typically annual) and version control
- Approval, sign-off and effective date
How iCompaas tracks this policy
The icompaas policy-doc producer manages this document through an 8-state lifecycle: draft → generated → internal_qa → customer_review → in_review → approved → signed (with rejected as a terminal side-state). The producer publishes a policy_doc_incident_management_policy_signed compliance finding once at least one document of this kind reaches the signed state for the account being assessed; the finding then rolls up into every compliance framework that references this policy (see the table below).
Compliance frameworks that reference this policy
The icompaas compliance controls library links every policy document to the controls in each framework that require, evidence, or otherwise rely on it. Below: every control across every framework in the iCompaas catalogue that names this policy as part of its evidence base. Each control links to its own dedicated page with auditor-view content + implementation guidance.
| Framework | Control | Title | Component |
|---|---|---|---|
| ISO/IEC 27001:2022 | A.5.24 | Information security incident management planning and preparation | Organizational controls |
| ISO/IEC 27001:2022 | A.5.25 | Assessment and decision on information security events | Organizational controls |
| ISO/IEC 27001:2022 | A.5.26 | Response to information security incidents | Organizational controls |
| ISO/IEC 27001:2022 | A.5.27 | Learning from information security incidents | Organizational controls |
| ISO/IEC 27001:2022 | A.6.8 | Information security event reporting | People controls |
| ISO/IEC 27001:2022 | A.8.16 | Monitoring activities | Technological controls |
| ISO/IEC 27701:2025 | A.1.5.4 | Records of transfer | PII sharing, transfer & disclosure |
| ISO/IEC 27701:2025 | A.3.12 | Response to incidents | Security considerations |
| ISO/IEC 27701:2025 | A.3.24 | Information backup | Security considerations |
| ISO/IEC 42001:2023 | A.3.3 | Reporting of concerns | Organizational controls |
| ISO/IEC 42001:2023 | A.8.3 | External reporting | Organizational controls |
| ISO/IEC 42001:2023 | A.8.4 | Communication of incidents | Organizational controls |
| ISO/IEC 42001:2023 | A.10.4 | Customers | Organizational controls |
13 controls across 3 frameworks reference this policy.
About this page
This article is part of the iCompaas Policy Documents library — one page per signed-document type the icompaas policy-doc producer tracks for customer accounts. The article is intentionally framework-agnostic: a customer signing a policy of this kind gets the same regulatory benefit across every framework that references it.