76 lines
4.5 KiB
Markdown
76 lines
4.5 KiB
Markdown
# 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](data_classification_policy.md)) — 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](logging_monitoring_policy.md) 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](authentication_policy.md).
|
|
- 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](authentication_policy.md) 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 |
|
|
|
|
---
|
|
|
|
## 5. References
|
|
- **[NIST SP 800-61 Rev. 3, Incident Response Recommendations (CSF 2.0 Profile)](https://csrc.nist.gov/pubs/sp/800/61/r3/final)**
|
|
- **[ENISA Digital Identity and Data Protection](https://www.enisa.europa.eu/topics/digital-identity-and-data-protection)**
|