tm_back/docs/security/policies/incident-response-plan.md

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 | Risk Assessment Matrix

---

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 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).

---

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