
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
GDPR, UK GDPR, and South Africa's POPIA all expect appropriate technical measures, but the enforcement bodies and breach-notification specifics differ. What that means for scoping a security test.
"Appropriate technical and organisational measures" is the phrase, or something close to it, at the center of GDPR, UK GDPR, and South Africa's POPIA alike. All three data protection regimes expect real, evidenced security controls, not a policy document alone. But the enforcement bodies, breach-notification specifics, and practical expectations differ enough that scoping a security test the same way for all three is a mistake worth avoiding.
The EU's GDPR requires controllers and processors to implement "appropriate technical and organisational measures" to protect personal data, evaluated against the state of the art, implementation cost, and the actual risk to data subjects, deliberately not a fixed checklist. Enforcement sits with each member state's own supervisory authority, and Article 33 sets a firm 72-hour window to notify that authority after becoming aware of a qualifying breach. A penetration test is one of the clearer, more concrete ways to evidence Article 32 compliance in practice, see GDPR.eu for the regulation's own text and guidance.
Post-Brexit, the UK retained GDPR's substance as UK GDPR, enforced domestically by the Information Commissioner's Office (ICO) rather than an EU supervisory authority. Article 32's "appropriate technical and organisational measures" language and the 72-hour breach notification window both carry over largely unchanged, the practical security bar is the same, but reporting now goes to the ICO specifically, and UK-specific guidance (including the ICO's own security expectations) is worth reading alongside the shared EU text rather than assuming EU guidance transfers automatically.
South Africa's POPIA imposes a comparable duty to secure personal information against loss, damage, and unauthorized access, enforced by the Information Regulator. Where POPIA genuinely differs is breach notification: the Act's own text requires notification "as soon as reasonably possible" after discovery, not a fixed statutory number of hours. The Information Regulator has since pointed to 72 hours as a practical benchmark in its own guidance, but that's regulator guidance layered on top of a more flexible statutory standard, a meaningfully different legal posture than GDPR and UK GDPR's hard-coded 72-hour deadline, even though the two end up looking similar in practice.
The technical security bar, real, evidenced controls protecting personal data, ends up close to identical across all three regimes, which is why the same rigorous testing methodology genuinely applies everywhere. What changes is what a report needs to speak to: which regulator's specific language and notification framework the client will actually be judged against, and which breach-response timeline their incident response plan needs to be built around. A report written generically for "GDPR compliance" doesn't automatically read correctly to a POPIA-scoped client or vice versa, even when the underlying testing is identical.
This is exactly the reasoning behind scoping engagements by actual jurisdiction rather than a one-size-fits-all template, see our UK, EU, and South Africa pages for how each is scoped in more depth. It runs on the same methodology behind our core Security Consulting service, applied with the specific regulatory framework in mind from the start. A breach affecting personal data is also very often traced back to a compromised third party, not a first-party control failure, see our piece on third-party and supply chain risk for what a review of that specific exposure covers.
Tell us about your environment and goals, we'll help you scope the right engagement.