🚨 INCIDENT RESPONSE PLAYBOOK

TechStackBase – Admin & Platform

1️⃣ PURPOSE

To ensure rapid, controlled, auditable response to security incidents involving:

Personal data (POPIA)

System access

Data integrity

Availability

This playbook aligns with:

ISO 27001 A.16 (Information Security Incident Management)

POPIA Section 22 (Security Compromise Notification)

2️⃣ INCIDENT DEFINITION

An incident includes (but is not limited to):

Unauthorised access to admin or API

Suspicious admin actions

Data leakage or exfiltration

Credential compromise

Audit log anomalies

Malware or defacement

System misuse by privileged users

3️⃣ ROLES & RESPONSIBILITIES
Role	Responsibility
Incident Lead	Owns response, decisions
Technical Responder	Investigates & contains
Compliance Officer	POPIA & legal assessment
Communications	User / client notifications
Auditor Liaison	Evidence preparation

⚠️ One person may fulfil multiple roles in small teams.

4️⃣ INCIDENT SEVERITY CLASSIFICATION
🔴 Severity 1 — Critical

Personal data exposed

Admin credentials compromised

Audit log integrity threatened

Response time: Immediate (≤ 1 hour)

🟠 Severity 2 — High

Suspicious admin behaviour

Failed access attempts indicating attack

Partial service disruption

Response time: ≤ 4 hours

🟡 Severity 3 — Medium

Minor misconfiguration

Non-sensitive system anomaly

Response time: ≤ 24 hours

5️⃣ IMMEDIATE RESPONSE (FIRST 30–60 MINUTES)
✅ Step 1 — Preserve Evidence (DO NOT PANIC)

❌ Do NOT restart servers

❌ Do NOT delete logs

❌ Do NOT “fix quietly”

Audit logs are immutable — this protects you.

✅ Step 2 — Identify Scope

Query audit logs:

SELECT *
FROM audit_logs
WHERE created_at >= NOW() - INTERVAL 48 HOUR
ORDER BY created_at DESC;


Look for:

Unusual actions

Unexpected IPs

Off-hours admin access

Repeated failed attempts

✅ Step 3 — Containment

Depending on incident:

Disable affected user accounts

Rotate compromised credentials

Temporarily restrict admin access

Enable maintenance mode (if needed)

All containment actions must generate audit logs.

6️⃣ INVESTIGATION (TECHNICAL)
Key Questions to Answer

Who accessed the system?

What actions were performed?

Which data was affected?

Was data altered, accessed, or exported?

Is the incident ongoing?

Evidence Sources (Authoritative Order)

audit_logs (primary)

audit_export_hashes

Authentication logs

Database access logs (if available)

Server access logs

7️⃣ POPIA LEGAL ASSESSMENT (MANDATORY)
POPIA Section 22 Trigger Test

You must notify if:

Personal information was accessed OR

There is reasonable belief it may have been accessed

Notification Requirements

Describe nature of compromise

Identify affected data

Describe measures taken

Provide contact details

Notification timeline:
👉 As soon as reasonably possible after discovery

8️⃣ COMMUNICATION & NOTIFICATION
Internal

Incident summary

Impact assessment

Mitigation steps

Next actions

External (If Required)

Affected clients

Information Regulator (South Africa)

⚠️ Never speculate. Use verified facts only.

9️⃣ RECOVERY

Patch vulnerabilities

Restore secure configuration

Validate system integrity

Monitor for recurrence

🔟 POST-INCIDENT REVIEW (REQUIRED)

Within 7 days:

Root cause analysis

Control failures identified

Improvements documented

Playbook updated if needed

1️⃣1️⃣ EVIDENCE PACKAGE (AUDITOR-READY)

Prepare and retain:

Incident timeline

Relevant audit log extracts

Export hashes (CSV + SHA-256)

Containment actions taken

Notifications sent

Lessons learned

Retention: ≥ 5 years

1️⃣2️⃣ TESTING & DRILLS (RECOMMENDED)

Annual tabletop exercise

Admin access compromise simulation

Export verification test

1️⃣3️⃣ WHAT THIS PROTECTS YOU FROM

✔ Regulatory penalties
✔ “No logs” liability
✔ Insider abuse denial
✔ Legal disputes
✔ Client trust erosion

✅ COMPLIANCE CHECK
Requirement	Status
ISO 27001 A.16	✅
POPIA s22	✅
Evidence integrity	✅
Forensic readiness	✅
Shared hosting safe	✅
📁 FILE TO CREATE (FINAL)
/docs/incident_response.md