The Bot In The Room: Does Automated Access Trigger POPIA's Breach Notification?

Section 22 of the Protection of Personal Information Act, 2013 ("POPIA") states that organisations must notify the Information Regulator and affected data subjects when "there are reasonable grounds to believe that the personal information of a data subject has been accessed or acquired by any unauthorised person". But what do these concepts actually mean? POPIA does not define "accessed", "acquired", "reasonable grounds to believe", or "unauthorised person”. Neither the Information Regulator nor the South African courts have clarified them. We must therefore look to established cybersecurity frameworks and digital forensics practices to give these terms meaningful content.

In this article, we examine these concepts and consider how they apply to modern cyber-attacks, drawing on both POPIA and the Cybercrimes Act, 2020. We do not take a definitive view, but instead, we outline the key considerations organisations should consider when determining whether notification is required.

"Accessed" versus "Acquired"

Section 22 uses the phrase “accessed or acquired”. These are two separate triggers – you only need to meet one.

• "Access" means any unauthorised entry into, querying of, or ability to reach personal information. A human does not need to have actually read the data. Forensic signs of access include unusual login activity, privilege escalation, movement into network areas containing personal information, database queries, or data being staged for extraction. The Cybercrimes Act supports this reading — it criminalises "unlawful access" to data and systems, and recognises that access can happen through software, hardware, and automated processes.
• "Acquisition" sets a higher bar: the unauthorised person must have obtained, copied, downloaded, or taken control of the information. Typical evidence includes outbound data transfers, data appearing on dark-web sites, or ransomware operators publishing proof of theft.

Because “accessed” and “acquired” are alternatives, an organisation cannot delay notification just because it has not confirmed data was actually taken. Evidence of access alone is enough to trigger the duty to notify.

If data was staged for extraction but the transfer was stopped, the "accessed" test is likely met even if "acquisition" is unclear. The test is whether there are reasonable grounds to believe access occurred — not forensic certainty.

Cybersecurity frameworks further reinforce this distinction between access and acquisition, treating the unauthorised transfer of information from a system as conceptually and operationally separate from access to that system. The concept of a "breach" under cybsecurity frameworks are broader than just a “security compromise” under POPIA but still instructive: "the loss of control, compromise, unauthorised disclosure, unauthorised acquisition or a similar occurrence where a person other than an authorised user accesses or potentially accesses personally identifiable information". This definition is instructive for several reasons. First, it confirms that mere access, or even potential access, is sufficient to constitute a breach. Acquisition is one possible element of the definition but is by no means a prerequisite. Similarly, a data breach has been defined as a cybercrime "where information is accessed or stolen by a cybercriminal without authorisation", reinforcing the principle that access alone, without theft or exfiltration, is enough to constitute a breach.

The operational reality of cyberattacks further supports this distinction. Access and exfiltration are separate and sequential phases of an attack. An attacker first gains access to a network or system and only thereafter attempts to exfiltrate data. This sequencing is important to this discussion because many attacks are interrupted between these stages, detected and contained after access has been achieved but before any data has been removed.

From a digital forensics’ perspective, the artefacts that evidence access are fundamentally different from the artefacts that evidence exfiltration. Access is typically evidenced by login records, privilege escalation logs, database queries, and lateral movement traces. Exfiltration, by contrast, is evidenced by outbound data transfers, data staging for extraction, compression of large datasets and data subsequently appearing on dark-web sites or adversary infrastructure.

"Reasonable grounds to believe"

If the available evidence, includingmonitoring, forensics, threat intelligence, or a third-party tip-offwould lead a reasonable person to believe access or acquisition occurred, the notification clock starts. Organisations cannot wait indefinitely for a final forensic report. On the other hand, a blocked attack, failed login, or unpatched vulnerability with no sign of exploitation probably does not meet the threshold.

"Any unauthorised person" and technology

An “unauthorised person” is anyone who does not have authority to process the relevant information. This includes individuals, criminal groups, insiders, state-backed hackers, or contractors who exceed their access rights.

A more complex question is whether automated tools — malware, bots, AI — can themselves be the "person". We think there is a strong argument that these tools are instruments of an unauthorised person, not persons themselves. The Cybercrimes Act supports this view: it treats unlawful acts using “software or hardware tools” as the responsibility of the person who deployed them.

Cybersecurity frameworks lend considerable weight to the view that automated tools function as instruments of an unauthorised person rather than as independent actors in their own right. The most comprehensive catalogue of security controls in use globally consistently defines access as being performed by "a user (or a process acting on behalf of a user)". Automated processes are not treated as autonomous agents under these frameworks, rather, they are regarded as extensions of the human user who initiated or directed them.

But edge cases exist. What about malware that spreads on its own without ongoing control? Or a self-replicating worm that touches data by accident? Or an AI agent that acts beyond its original instructions? In these situations, the link between a human "person" and the access event is weaker. Organisations will need to assess, on the facts, whether the connection is strong enough to attribute the access to an identifiable person. Reasonable people may disagree. In most cases, this approach avoids an absurd outcome – that because "only" malware accessed a system, no "person" was involved and section 22 does not apply. But each incident must be judged on its own facts.

Threat-actor toolchains and the kill chain

Modern cyber attacks use layers of automation: automated scanning to find targets, mass phishing campaigns, tools that map out networks, and high-speed data extraction. The question is not whether a human was present at every step, but whether an unauthorised person started or directed the process that led to the access – and whether that link is close enough on the facts. In a typical ransomware attack, no human actually "reads" the personal information, yet humans have directed every stage. Usually, automation does not break the chain between the person and the breach. But the strength of that chain depends on how much human direction there was, whether the specific data accessed was foreseeable, and how close the link is between what the attacker did and the final access event.

Conclusion

Section 22 is deliberately broad and technology-neutral, but how it applies will depend on the facts of each case. In most situations, treating automated access as real access — and tools as extensions of the attacker — will best serve POPIA's purpose of protecting data subjects. This also aligns with the Cybercrimes Act. Until we get clearer guidance from the Regulator or courts, organisations should lean towards a purposive reading of the law. But ultimately, the specific facts, including how much human direction there was and what kind of automated process was involved, will determine whether section 22 applies.