4.5 KiB
4.5 KiB
Incident Response Policy
Document owner: [Owner/Role]
Approved by: [Steering Committee / CISO]
Effective date: [YYYY-MM-DD]
Review cadence: [Annually]
1. Purpose & Scope
This policy establishes mandatory requirements for detecting, responding to, and learning from security incidents at [Organization]. It applies to all employees, contractors, vendors, and systems.
2. Roles & Responsibilities
- Incident Response Lead: Owns the response, coordinates the IR team, declares severity.
- IR Team: Technical responders (security, IT, relevant system owners).
- Communications/Legal: Owns external notification and regulatory reporting.
- All Users: Must report suspected incidents immediately via the designated channel.
3. Policy Statements
3.1 Incident Classification
| Severity | Criteria | Example |
|---|---|---|
| SEV1 (Critical) | Kill-chain system compromise, confirmed breach of TLP:RED data, ransomware | Domain admin credential compromise |
| SEV2 (High) | Confirmed unauthorized access to TLP:AMBER+STRICT data, significant service outage | Break-glass account misuse |
| SEV3 (Medium) | Contained incident, limited scope, no confirmed data loss | Isolated phishing click, malware on one endpoint |
| SEV4 (Low) | Suspicious activity requiring investigation, no confirmed impact | Failed login anomaly |
Incident details must be handled at the TLP level of the data involved (per Data Classification Policy) — most active investigations default to TLP:RED.
3.2 Detection & Reporting
- Suspected incidents must be reported within 1 hour of discovery via the designated channel.
- Automated alerts from Logging, Monitoring & Retention Policy §2.4 feed directly into triage.
3.3 Response Lifecycle
[Organization] follows the NIST incident response lifecycle: Preparation → Detection & Analysis → Containment, Eradication & Recovery → Post-Incident Activity.
- Containment decisions must balance evidence preservation against stopping active damage; kill-chain systems favor immediate isolation.
3.4 Notification Requirements
- Regulatory breach notification (e.g., GDPR Art. 33) must be assessed within 72 hours of becoming aware of a personal data breach.
- Affected customers/partners must be notified per contractual and legal obligations, coordinated through Legal/Communications.
3.5 Structural Post-Mortem Mandate
- Every SEV1/SEV2 incident must produce a blameless post-mortem with at least one structural change (policy, architecture, or control) within 30 days, per Authentication Policy §2.12.
- Findings must be tracked to closure; a recurring root cause without a structural fix is itself a policy violation.
3.6 Exercises
- Tabletop exercises must be run at least semi-annually.
- Exercises must follow the calibrated-dose principle: non-production before production scope, a bounded blast radius, and a pre-agreed abort condition — see Authentication Policy §2.13 for the same principle applied to break-glass drills.
3.7 Enforcement
- Failure to report a known incident may result in disciplinary action.
4. Antifragility Alignment
This policy is built to the five pillars of the organization's internal Antifragile Enterprise Manifest.
| Pillar | Applied In | How |
|---|---|---|
| 1. Structural Decoupling | §3.3 | Containment favors isolating the affected system over hoping the blast radius stays small on its own |
| 2. Optionality Preservation | §3.3 | Evidence preservation vs. containment is a deliberate trade-off, not a forced default that removes options later |
| 3. Stress-to-Signal Conversion | §3.5, §3.6 | This is the pillar's home policy: every SEV1/2 forces a structural fix; drills are dosed, bounded, and abortable |
| 4. Sovereign Intelligence | §2 | Named IR Lead and team; incident knowledge captured in post-mortems, not lost when responders move on |
| 5. Asymmetric Payoff Design (Barbell) | §3.1 | Severity tiers concentrate response urgency and TLP:RED confidentiality on kill-chain/critical incidents |