Data breaches present a significant and growing operational risk for organisations across all industries. In South Africa specifically, the average cost of a data breach reached R49.45 million in 2023, with the financial sector experiencing the highest average at R73.1 million, according to IBM's Cost of a Data Breach Report. Common vectors include phishing attacks, insider threats, website and server compromises, and cloud misconfigurations.
Many organisations concentrate security investment on perimeter defenses while overlooking vulnerabilities introduced through the code of their proprietary websites, mobile apps, APIs, and custom software. This six-step checklist covers how to respond when a breach does occur, and how to position your development practices to reduce the likelihood of one.
The full No Access Checklist is available as a downloadable PDF reference for use in incident response planning.
What Are Data Breaches?
A data breach is an incident in which sensitive, protected, or confidential data has been accessed, viewed, stolen, or used by an individual without authorisation. Breaches may expose personal health information, financial records, authentication credentials, or other private data.
The consequences are immediate and long-lasting: financial penalties and legal liability under frameworks like South Africa's Protection of Personal Information (POPI) Act, reputational damage with customers and partners, and operational disruption. Once data is in the hands of unauthorised parties it can be used for identity theft, fraud, extortion, or sold to further attackers. The average time to identify and contain a breach runs to several months in most organisations, which is why a pre-planned response process is significantly more effective than an improvised one.
Step 1: Detection and Analysis
Breaches that are not detected quickly cause disproportionately more damage. Most organisations without active monitoring discover breaches weeks or months after the initial compromise, giving attackers extended access to systems and data.
- Implement intrusion detection systems (IDS) and SIEM (security information and event management) tools to monitor networks and applications continuously for anomalous activity
- Establish baseline behaviour for systems and users so that deviations trigger alerts rather than requiring manual review to identify
- When an anomaly is flagged, investigate immediately: analyse log files to determine where, when, and how a potential breach may have occurred
- Identify the types of data involved and estimate how many individuals may be affected before any external communication
- Document findings in real time so the incident record is accurate and defensible for legal and regulatory purposes
Early detection is the single highest-leverage action in breach response. Every hour of undetected access increases both the volume of data exposed and the complexity of the remediation.
Step 2: Containment
Once a breach is confirmed, the immediate priority is limiting further data loss. Speed matters: a well-rehearsed containment procedure executed in minutes is far more effective than a thorough but slow response.
- Isolate affected systems immediately by removing them from the network or placing them behind tighter access controls to block further data exfiltration
- Remove or quarantine compromised files, services, or devices that may still be actively leaking data
- Reset all credentials that may have been exposed: passwords, encryption keys, API tokens, session tokens, and service account credentials
- Apply temporary firewall rules or access restrictions to limit lateral movement within the network while investigation proceeds
- Preserve affected systems in a forensically sound state where possible: containment and preservation are not mutually exclusive if the response process is well-designed
Containment decisions involve trade-offs between speed of protection and operational continuity. A containment plan made before an incident is significantly better than one made under pressure during one.
Step 3: Notification
Regulatory and legal notification requirements are not optional. Under South Africa's POPI Act and equivalent frameworks in other jurisdictions, organisations have defined obligations to notify affected individuals and authorities when personal information has been compromised.
- Alert all individuals whose personal information may have been compromised, in accordance with the regulatory timeframes and communication requirements applicable to your jurisdiction
- Notify the Information Regulator (in South Africa) and any other applicable regulatory bodies within required timeframes
- Contact legal counsel, insurers, and key business partners who may be affected by or liable for the breach
- Prepare clear, factual communication that describes what happened, what data was involved, what the organisation has done, and what affected individuals should do
- Avoid speculative or incomplete notifications: a second notification correcting the first amplifies reputational damage
Regulatory notification timelines vary by jurisdiction and breach severity. Know your obligations before an incident occurs. Post-breach is the wrong time to be reading compliance requirements for the first time.
Step 4: Investigation
A thorough investigation establishes the root cause, the full scope of the breach, and the evidence needed for legal, regulatory, and remediation purposes. This step requires careful coordination between technical, legal, and communications teams.
- Assemble an incident response team with defined roles: investigation lead, communications coordinator, legal liaison, and technical forensics
- Secure all relevant evidence: logs, system images, network captures, and access records in a manner that preserves their legal admissibility
- Establish the full timeline of the breach from initial compromise through detection and containment
- Determine the root cause: was the vector a phishing attack, credential compromise, misconfiguration, insider access, or a code-level vulnerability?
- Engage third-party forensic specialists where the breach is complex, the root cause is unclear, or regulatory requirements call for independent verification
The investigation report serves multiple purposes: it feeds the recovery planning, satisfies regulatory requirements, and informs the post-breach changes that reduce future risk. A forensic record that is incomplete or inconsistent creates additional legal exposure.
Step 5: Recovery
Recovery restores affected systems and data to a secure state. The goal is not just to return to operational status but to return to a more secure operational status than existed before the breach.
- After root cause analysis confirms the breach vector is understood and contained, begin systematic restoration of affected systems from clean backups
- Patch the specific vulnerabilities that were exploited, and audit adjacent systems for the same or related weaknesses
- Apply configuration hardening to systems being restored: do not restore systems to the same configuration that allowed the breach
- Test all security controls extensively before bringing systems back to full production operation
- Monitor restored systems at heightened intensity for at least 30 days post-recovery to detect any indicators of recompromise
Rushing recovery to minimise downtime at the cost of thorough security validation risks a second breach from the same vector. A phased return to operation with staged security checks is slower but more defensible.
Step 6: Post-Breach Evaluation
The post-breach evaluation is where the organisation converts the breach into durable improvement rather than just a recovery. Most organisations that experience repeat breaches share one characteristic: they treated the first as an event to close rather than a process to learn from.
- Conduct a formal breach debrief with all teams involved in the response: identify what worked, what failed, and what was missing
- Review the incident response plan against what actually happened and update it to reflect what the breach revealed
- Identify systemic vulnerabilities in development, infrastructure, and access control that the breach exposed, and address them with prioritised remediation
- Assess whether monitoring and alerting infrastructure detected the breach in a reasonable timeframe, and improve it where it did not
- Document the lessons and share them across development, security, and operations teams so the learning is organisational rather than individual
The post-breach evaluation closes the loop between incident response and ongoing security improvement. Organisations that conduct structured post-incident reviews consistently reduce both the frequency and the severity of subsequent incidents.
Building Security In from the Start
This six-step checklist covers what to do when a breach occurs. But the most effective security investment is in preventing the breach conditions from existing in the first place. Many of the breach vectors described here, including credential compromise, cloud misconfiguration, and API vulnerabilities, originate in software development decisions rather than in perimeter attacks.
Embedding security earlier in the development lifecycle, often called shifting security left, reduces the cost of finding and fixing vulnerabilities and builds applications that are structurally harder to breach. The No Access Checklist is a response tool; a secure development practice is what reduces the need to use it.
Frequently Asked Questions
What is the No Access Checklist?
The No Access Checklist is a structured six-step framework for responding to data breaches in software-dependent organisations. It covers detection and analysis, containment, notification, investigation, recovery, and post-breach evaluation. The checklist is designed to be worked through in sequence when a breach is confirmed or suspected, and as a planning tool to prepare incident response capabilities before a breach occurs. The full checklist is available as a downloadable PDF.
What does the POPI Act require when a data breach occurs in South Africa?
The Protection of Personal Information Act (POPIA) requires organisations that process personal information of South African residents to notify the Information Regulator and affected data subjects when a breach of security involving personal information has taken place. The notification must be made as soon as reasonably possible after discovery of the compromise. The notification should describe the nature of the breach, the categories and number of records involved, and the steps taken or proposed in response. Failure to notify carries regulatory penalties and can compound civil liability.
What is the difference between containment and recovery in breach response?
Containment stops the breach from spreading further: isolating affected systems, blocking attacker access, and resetting compromised credentials. It is the immediate response step that limits total damage. Recovery restores affected systems to a secure operational state after the breach has been contained and the root cause identified and addressed. Containment happens under time pressure; recovery happens more deliberately after the investigation has established what happened and why. Attempting recovery before containment is complete risks restoring systems that are still compromised.
How long does a typical data breach investigation take?
Investigation timelines vary based on the complexity of the breach, the quality of the logging and monitoring infrastructure, and whether external forensic specialists are engaged. Simple breaches with good audit trails may be investigated in days. Complex breaches involving sophisticated attackers, multi-system compromise, or insufficient logging can take weeks or months to fully characterise. The average time to identify and contain a breach across industries is measured in months according to IBM research, which is why pre-planned investigation protocols and forensic-ready logging infrastructure significantly reduce this timeline.
How does secure software development reduce the risk of data breaches?
Many data breaches originate in exploitable vulnerabilities in custom software: SQL injection, broken authentication, insecure API endpoints, and exposed credentials in code repositories. Secure development practices including static code analysis, dependency scanning, security-focused code review, and penetration testing before deployment catch these vulnerabilities when they are cheapest to fix. A breach that originates from a code-level vulnerability is a development process failure, not just an operational one. The most cost-effective breach prevention is in the software development lifecycle, not in the incident response plan.
