# Incident Response Plan

| Field | Value |
|-------|-------|
| **Document ID** | POL-003 |
| **Version** | 1.0 |
| **Status** | Draft — Pending approval |
| **Owner** | Information Security Officer (ISO) |
| **Effective Date** | _Pending approval_ |
| **Review Cycle** | Annual (+ after every P1/P2 incident) |
| **ISO 27001 Reference** | A.5.24–A.5.28 — Incident management |

Related: [Information Security Policy](./information-security-policy.md) | [Risk Assessment Matrix](../RISK_ASSESSMENT_MATRIX.md)

---

## 1. Purpose

This plan defines how the organization detects, responds to, contains, and recovers from information security incidents affecting the Tender Management System. It ensures consistent handling, timely notification, and post-incident improvement.

---

## 2. Scope

Covers security incidents involving:

- Unauthorized access to TM systems or data
- Data breaches (PII exposure)
- Malware or ransomware
- Denial of service affecting production
- Secret/credential leakage
- Insider threats
- Third-party service compromises affecting TM

---

## 3. Incident Classification

| Severity | Label | Criteria | Response Time |
|----------|-------|----------|---------------|
| **P1** | Critical | Active data breach; production down; credential leak in public repo | Acknowledge ≤ 1 h; escalate immediately |
| **P2** | High | Suspected breach; partial outage; unpatched critical CVE exploited | Acknowledge ≤ 4 h |
| **P3** | Medium | Failed attack attempt; non-production compromise; policy violation | Acknowledge ≤ 1 business day |
| **P4** | Low | Near-miss; informational alert; minor misconfiguration | Acknowledge ≤ 3 business days |

---

## 4. Incident Response Team (IRT)

| Role | Responsibility | Primary | Backup |
|------|----------------|---------|--------|
| **Incident Commander (IC)** | Overall coordination, decisions, communications | ISO | Engineering Lead |
| **Technical Lead** | Investigation, containment, remediation | DevOps Lead | Senior Backend Dev |
| **Communications Lead** | Internal/external notifications, status updates | Product Owner | Executive Sponsor |
| **Legal / DPO** | Regulatory notification, GDPR assessment | DPO | External counsel |
| **Scribe** | Timeline, evidence, post-incident report | Assigned per incident | — |

Contact list maintained separately (not in repository) with 24/7 reachability for P1/P2.

---

## 5. Response Phases

```
Detect → Triage → Contain → Eradicate → Recover → Learn
```

### 5.1 Detect & Report

**Anyone** who suspects an incident must report immediately via:

1. Direct message to ISO or DevOps Lead
2. Dedicated security channel (e.g. `#security-incidents`)
3. Email: `security@<company-domain>` (to be configured)

Do **not** discuss suspected breaches on public channels until IC approves.

**Automated detection sources (target state):**

- SIEM alerts (auth failure spikes, error rate anomalies)
- Secret scanning in CI
- Dependency vulnerability alerts
- Cloud provider security notifications
- User/customer reports

### 5.2 Triage

IC performs within response time SLA:

1. Confirm or rule out incident
2. Assign severity (P1–P4)
3. Activate IRT if P1/P2
4. Open incident ticket with unique ID: `INC-YYYY-NNN`
5. Begin incident timeline log

### 5.3 Contain

Short-term actions to limit damage:

| Scenario | Containment Actions |
|----------|---------------------|
| Compromised admin account | Disable account; revoke JWT; force password reset |
| Leaked API key / secret | Rotate credential; invalidate old tokens; audit access logs |
| Active data exfiltration | Block IP/rate limit; disable affected endpoint; snapshot logs |
| Ransomware / malware | Isolate affected hosts; preserve forensic images |
| DDoS | Enable WAF/CDN rules; rate limiting; contact provider |

Preserve evidence: do not delete logs; snapshot affected systems before remediation where feasible.

### 5.4 Eradicate

- Remove attacker access (patch vulnerability, close misconfiguration)
- Scan for persistence (backdoors, unauthorized accounts)
- Verify root cause is addressed

### 5.5 Recover

- Restore services from clean backups if needed
- Monitor for recurrence (enhanced logging, 72-hour watch period)
- Confirm normal operation with smoke tests
- Communicate all-clear to stakeholders

### 5.6 Post-Incident Review (Learn)

Required for all P1/P2 incidents within **10 business days**:

- Timeline reconstruction
- Root cause analysis
- Control gaps identified
- Corrective/preventive actions with owners and dates
- Update [Risk Assessment Matrix](../RISK_ASSESSMENT_MATRIX.md) if new risks identified
- Tabletop or walkthrough if process gaps found

---

## 6. Communication Plan

### 6.1 Internal

| Severity | Notify |
|----------|--------|
| P1 | IRT, Executive Sponsor, all engineering — immediately |
| P2 | IRT, Engineering Lead, DevOps — within 4 h |
| P3 | ISO, relevant team lead — within 1 business day |
| P4 | ISO — log only |

### 6.2 External

| Condition | Action | Timeline |
|-----------|--------|----------|
| Personal data breach (GDPR) | Notify supervisory authority | ≤ 72 hours of awareness |
| Personal data breach (high risk to individuals) | Notify affected data subjects | Without undue delay |
| Contractual obligation | Notify affected customers | Per contract terms |
| Public disclosure | Press/ status page | IC approval only |

DPO assesses GDPR notification requirement for any incident involving customer/company PII (assets A-004, A-005).

---

## 7. Evidence Handling

- Logs exported and stored in tamper-evident location
- Chain of custody documented for forensic artifacts
- Incident records retained for **3 years** minimum
- Access to incident evidence restricted to IRT and Legal/DPO

---

## 8. Playbooks

### 8.1 Credential Leak in Git Repository

1. **Contain:** Revoke/rotate leaked secret immediately
2. **Eradicate:** Remove secret from git history (`git filter-repo` or BFG); force push with approval
3. **Investigate:** Audit usage logs for unauthorized access during exposure window
4. **Recover:** Deploy rotated credentials; verify services operational
5. **Learn:** Enable secret scanning in CI; review commit practices

*Applies to risk R-013; FCM keys and MinIO credentials are high priority.*

### 8.2 Suspected Unauthorized Admin Access

1. Disable affected admin account(s)
2. Blacklist active JWTs in Redis
3. Review `pkg/audit` logs for anomalous actions
4. Force password reset and enable MFA
5. RBAC audit of actions performed during compromise window

### 8.3 Production API Outage (Security-Related)

1. Determine if attack-related (DoS) vs. infrastructure failure
2. If DoS: enable rate limiting, WAF rules, scale resources
3. If compromise: isolate, preserve logs, follow containment playbook
4. Status communication via Communications Lead

---

## 9. Testing and Training

| Activity | Frequency |
|----------|-----------|
| Tabletop exercise (simulated P1) | Annual |
| Contact list verification | Quarterly |
| Playbook review | Annual or after P1/P2 |
| Security awareness (incident reporting) | Onboarding + annual |

First tabletop exercise target: **Q2 2026** (per [Risk R-023](../RISK_ASSESSMENT_MATRIX.md)).

---

## 10. Document Control

| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | 2026-06-11 | Engineering | Initial plan |

**Approval**

| Role | Name | Signature | Date |
|------|------|-----------|------|
| ISO | _Pending_ | | |
| Executive Sponsor | _Pending_ | | |