
Data Breach Triage and the Insurer’s first 72 hours
By Jodi Poswelletski | Director
For insurers, the question is no longer whether a data incident is possible. The more useful question is whether the organisation knows what it will do when personal information may already be at risk. This is the premise behind “data breach triage”.
The term borrows from emergency medicine. A hospital emergency unit cannot predict when it will be inundated by patients after a major accident. It can, however, prepare for the moment. It can decide how severity will be assessed, who must be called, which cases require immediate intervention and how decisions will be made under pressure.
Insurers require the same discipline in their response to data breaches, cyber incidents, supplier failures and employee-driven leaks. The aim is not to create the impression that every incident can be prevented. It is to ensure that, when an incident occurs, the business is not inventing its response while the risk is unfolding.
That distinction is becoming more important as insurance operations become more data-intensive and more dependent on interconnected service providers. Claims administration, underwriting, investigations, broker relationships, digital customer channels, payment systems and outsourced support functions all rely on the collection and processing of personal information. If that personal information is exposed, the consequences may extend well beyond an IT department.
A cyber incident may be technical. A data breach is also legal.
PROTETCION OF PERSONAL INFORMATION ACT 4 OF 2013 “POPIA” changes the nature of the response
When a possible data breach is identified, the first legal question is not only how the incident occurred. It is whether personal information may have been accessed or acquired by an unauthorised person.
That question places the incident squarely within the Protection of Personal Information Act, Act 4 of 2013 (“POPIA”). POPIA requires the organisation to look at the personal information involved, the persons and / or organisations affected, the role of the parties, the security safeguard measures in place, and the possible need for notification to the Information Regulator and affected data subjects.
For insurers, this assessment is rarely simple. A single claims file, may contain identity numbers, banking details, health information, vehicle or asset information, forensic reports, fraud indicators, broker correspondence and third-party material. Some of that information may be ordinary personal information. Some may be special personal information. Some may create immediate fraud risk if it reaches the wrong hands.
This is why the response cannot be treated as a technical fault alone. A breach may start with a system, but it quickly becomes an issue of legal compliance, customer protection, contractual responsibility, reputation and governance.
Responsibility must be established early
One of the first questions in any triage process should be whether the insurer is the responsible party, the operator, or one of several parties in a wider processing chain.
The responsible party determines the purpose and means of processing personal information. The operator processes personal information on behalf of the responsible party. In the insurance sector, this distinction is often complicated by the number of third parties involved in ordinary business operations. Brokers, assessors, repair networks, claims administrators, investigators, IT providers, call centres and other suppliers may all handle personal and special personal information at some point in the value chain.
When an incident occurs in a supplier’s environment, the immediate instinct may be to regard it as the supplier’s problem. That may be commercially understandable, but it is not always a sound POPIA response.
The Dis-Chem and Grapevine matter illustrates the point. Grapevine was the operator. Dis-Chem was the responsible party. Grapevine’s database was hacked, customer names, identity numbers and contact details were exposed, and the Information Regulator issued an enforcement notice to Dis-Chem.
The lesson for insurers is direct. A data breach that occurs through an operator may still create responsible-party risk. The triage process must therefore require immediate answers about the affected system, the personal information involved, the number of data subjects, the status of containment, the contractual obligations of the operator, the preservation of evidence and the responsibility for any notification.
Without that structure, valuable time is lost while the business tries to determine who owns the problem.
The purpose of triage is proportionate escalation
A useful triage process does not treat every incident as a crisis. It also does not allow serious incidents to drift while facts are still incomplete. The purpose is proportionate escalation.
A practical model separates incidents into green, amber and red categories.
Green incidents are contained and appear to present a low level of risk. The exposure may be limited, quickly corrected and involve a small number of data subjects. There may be no evidence of onward sharing of personal information and no sign of fraud or malicious conduct.
A green classification does not mean that the incident disappears. It should still be recorded. The facts should still be checked. The organisation should still be able to explain why it did not escalate the matter further. In a POPIA context, a decision not to notify or escalate should be a decision that can be justified, not an assumption that was never tested.
Amber incidents are more difficult. They may involve personal information such as customer, claimant or employee data. An operator or supplier may be involved. It may be unclear who accessed the personal information or whether it was shared further. The number of affected people may be uncertain. The need for notification may still be under assessment.
These are the incidents in which organisations are most likely to make poor decisions. Overreaction can create alarm before the facts are known. Delay can cause the business to lose control of the response. Amber incidents therefore require structured speed. Legal and the Information Officer should be involved. IT or forensic support may be required. Operator agreements should be reviewed. Communications should be controlled. Evidence should be preserved.
Red incidents are critical. These may involve large-scale exposure of personal information such as identity numbers, banking details, health information and could also involve fraud risk, dark web risk, media attention, Information regulatory scrutiny, cybercrime indicators, possible SAPS involvement or board-level concern.
At red level, the breach response team should already know what to do. Legal advice must be obtained urgently. The exposure must be contained. Evidence must be preserved. Regulatory notification must be assessed. Law enforcement reporting may need to be considered. Senior management must be briefed and communications must be managed with care.
A red incident is not an IT ticket. It is a business-critical event.
Scale, sensitivity and secondary fraud risk
The Experian breach showed how scale changes the response. Once millions of people may be affected, the issue extends beyond compliance. It may require customer warnings, industry coordination, fraud prevention measures, information regulator engagement and a public communication strategy.
For insurers, however, scale is only one part of the analysis. Sensitivity can be just as important. A smaller incident involving personal information such as identity document details, banking details, health information or fraud investigation material may require a faster and more careful response than a larger incident involving less sensitive information.
The assessment should also consider secondary risk. A breach may not end with exposure. It may create the conditions for further fraud.
The FlySafair incident is useful in this regard. A technical issue during a high-traffic online sale reportedly exposed customer email addresses. The incident also created an opportunity for scammers and fake communications. For insurers, that pattern should be familiar. Once customers are anxious, criminals may exploit the uncertainty through phishing, impersonation or AI-generated messages that appear credible.
Communication is therefore part of containment. Customers may need to know which channels are legitimate, what warning signs to look for and what the insurer will never ask them to do. Poor communication can increase the very risk the organisation is trying to manage.
Internal conduct remains a major risk
Data breach discussions often focus on external cyber threats. Insurers should also consider internal conduct.
Employees may copy files, forward personal information to personal email accounts, save documents to external devices, retain personal information after resignation or share confidential material with competitors. These incidents may involve employment law, confidentiality obligations, POPIA, urgent evidence preservation and possible court proceedings.
In serious cases, legal remedies may include interdicts, Anton Piller applications and forensic IT support.
This is why POPIA training, confidentiality undertakings, addendum to employment agreements, IT policies, access controls and offboarding procedures should not be treated as administrative housekeeping. They form part of the organisation’s ability to respond when information leaves the business without authority.
The first 24 to 72 hours
The first 24 to 72 hours after a breach are often decisive. Not because every fact will be known. In most cases, they will not. The period is decisive because early decisions shape the legal, regulatory and reputational path that follows.
The first response should focus on confirming what happened, containing the exposure, preserving evidence, identifying the personal information involved, identifying affected data subjects, establishing whether an operator is involved, assessing notification duties, controlling internal and external communication, and documenting decisions.
A decision log is particularly important. It records what the organisation knew, when it knew it, who was involved, what steps were taken and why particular decisions were made. That record may later become important if the matter is scrutinised by the Information Regulator, customers, a court, the media or the board.
The breach response team should also be agreed before the incident occurs. It should include legal, the Information Officer, IT or cybersecurity, digital forensics, operations, communications, senior management, the affected business unit, supplier or operator representatives and, where required, law enforcement.
During a live incident, the organisation should not still be trying to determine who may speak to the Information regulator, who may instruct forensic specialists, who holds the operator agreement, who approves customer communications or who briefs the board.
A governance issue, is not only a compliance issue
Insurers should approach breach readiness as a governance discipline.
At minimum, this means having a security incident breach policy, an incident classification matrix, a breach response team, operator agreements, POPIA training records, employee confidentiality undertakings, IT and AI usage policies, notification templates, Information regulator contact details, supplier escalation contacts and a communications approval process.
These measures will not prevent every breach. That is not their purpose. Their purpose is to reduce confusion when judgement, speed and accountability matter.
Insurers do not need to become cybercrime experts to improve their response to personal information risk. They need a legally informed triage process that helps them classify incidents, involve the right people, preserve evidence, assess notification duties and communicate responsibly.
When personal information is at risk, speed matters. Structured speed matters more.
A breach response is not judged only by the breach itself. It is judged by what the insurer did next.

