What is a POPIA-compliant incident response plan?

An incident response plan is a documented, pre-agreed process for what your business does the moment a security incident, a breach, ransomware, or unauthorised data access, is discovered, covering containment, investigation, notification, and recovery. Under POPIA Section 22, businesses are legally required to notify the Information Regulator and affected individuals "as soon as reasonably possible" once a breach involving personal information is identified, which makes having a plan before an incident happens, rather than improvising during one, a genuine compliance requirement, not just good practice.

Why Improvising During an Actual Incident Goes Badly

An active security incident is chaotic, stressful, and time-pressured, exactly the conditions under which ad hoc decision-making tends to go wrong: critical steps get missed, notification deadlines slip, and the response itself sometimes causes additional damage (for example, powering off a compromised system in a way that destroys forensic evidence needed to understand what actually happened). A written, rehearsed plan removes much of this chaos by defining, in advance, who does what.

What a Proper Plan Actually Covers

• Who declares an incident, a clear, unambiguous decision-maker rather than confusion about whether something "counts" as a real incident
• Containment steps, immediate actions to limit further damage, isolating affected systems, revoking compromised credentials
• Investigation process, understanding scope: what was accessed, what data was involved, how the attacker got in
• Notification procedure, exactly how and when to notify the Information Regulator (via the eServices portal) and affected individuals, including what information the notification must contain
• External communication, who's authorised to speak publicly or to clients about the incident, avoiding conflicting or premature statements
• Recovery and post-incident review, restoring normal operations and identifying what needs to change to prevent recurrence

The POPIA Notification Requirement Specifically

Section 22 requires notification "as soon as reasonably possible" once you become aware personal information has been compromised, this isn't a vague suggestion, delayed or absent notification is itself treated as a separate compliance failure, stacked on top of the breach itself. Notification should include enough information for affected individuals to take protective action, what happened, what data was involved, and what you're doing about it.

A Plan Needs Contact Details That Actually Work After Hours

A surprisingly common gap: incident response plans that only list office-hours contact numbers, when many incidents are discovered or actively unfolding outside business hours. A genuinely usable plan includes after-hours contact information for key decision-makers and technical responders, not just a general office line.

Testing the Plan Before You Need It

A plan that's written once and never revisited tends to go stale, key contacts change roles, systems change, and untested plans often reveal gaps only when actually exercised. Running through the plan at least annually, ideally as a realistic tabletop exercise rather than just a document review, surfaces these gaps while there's time to fix them.

Our Approach

We help build a genuinely usable incident response plan specific to your systems and team, not a generic template, including the POPIA notification workflow and after-hours contact structure, and we act as part of your response capability itself when an incident does occur, since our SOC is already monitoring your environment and understands your specific setup.