GDPR and POPIA: Data breach

Missed the previous articles?  Read them here: Article 1 | Article 2 | Article 3 | Article 4 | Article 5 | Article 6 | Article 7 | Article 8

Breaches happen, and they will happen to you.  In the ninth and final article of this series, we look at how GDPR and POPIA treat data breaches. Read on:

• “Our system was compromised”
• Breach procedures are clear
• Notify them - it is the right thing to do
• Measuring risk and time limits
• Go with the strictest requirements
• All's well that ends well
• You want this poster
• SAP Knowledge Sidebar

"Our system was compromised"

You stare at the email, reading the subject out loud: “Please reset your password.”  The rest of the email goes on to explain that your cloud storage service was hacked, possibly allowing the attackers to access your personal data.

You think back to your date at the zoo and “the incident” that led to the demise of your young relationship.  It was a tough week. “Why don’t you just back it up to the cloud?” they said that day. And now you have to tell them that their information might have been stolen by hackers.  This is going to be an interesting phone call.

Despite our best efforts and intentions, data breaches happen.  Sometimes it is the result of a weakness in our systems, and sometimes human error.  Whatever the cause, as custodians of personal data, we have to take responsibility as GDPR and POPIA require a clear and unambiguous response to security incidents.

Breach procedures are clear

Strict breach procedures are spelled out by GDPR and POPIA that must be integrated into company policies and systems.

Notify them - it is the right thing to do

GDPR requires breach notifications towards both the regulatory authority as well as the data subject.  Article 33, Par. 1 states: “In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.”  The rest of the article provides further details on how the procedure must be executed.

In Article 34, Par. 1 we read the following: “When the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall communicate the personal data breach to the data subject without undue delay.”

In Section 2 of POPIA we come across similar directives: “(1) Where there are reasonable grounds to believe that the personal information of data subject has been accessed or acquired by any unauthorised person, the responsible party must notify (a) the Regulator; and (b) subject to subsection (3), the data subject, unless the identity of such data subject cannot be established.(2) The notification in subsection (1) must be made as soon as reasonably possible after the discovery of the compromise…”

Measuring risk and time limits

There are two key differences between GDPR and POPIA when it comes to breach notifications:

1. GDPR is less clear about how to measure the risk to data subjects in the case of a breach.  POPIA clearly states an exception to breach notifications if the identity of data subjects can’t be established.
2. POPIA does not enforce a time limit on when a breach notification should be sent out.  GDPR requires that notifications are sent out within a 72-hour window.

Go with the strictest requirements

Data breach policies will require updating as follows:

1. They need to clearly state the steps to be taken when a data breach occurs
2. Notifications to the applicable regulator need to be incorporated
3. Notifications to the data subject need to be incorporated
4. A deadline for breach notifications should be included, POPIA’s lack of specificity regardless
5. A process for identifying the cause of notification delays, with the aim of providing such reasons to regulators, should be considered

The challenge here is the management of both the notification process and a potential public relations fallout as eloquently as possible.  It is worth considering a unified strategy that includes the PR process for data breaches.

All's well that ends well

“Well, it was partly my fault.  I told you to back it up on the cloud after all.  Thanks for letting me know.” You didn’t quite expect this response.  Maybe, just maybe…

“Hey, would you like to have some coffee tomorrow?  I know a good place. Ha ha.” You can feel your heart beating in your ears.

“Umm.  Sure. As long as it isn’t the zoo!”

Success!

The key to any relationship is open communication, even when you have to talk about something bad.  When it comes to breach notifications the rule of thumb is this: being well prepared to respond takes the sting out of the process – be open, clear and provide next steps as a way to empower data subjects.

You want this poster

POPIA compliance is a challenge.  We created this free flowchart poster to help you figure it out.  Click below to download your copy.

Download your poster today

SAP Knowledge Sidebar

People often think narrowly of SAP security as roles and authorizations. But wait. There’s more! Breaches in SAP security can happen in a myriad of other ways, like unpatched systems, bad Basis and systems configuration parameters, custom code, and  “debug hacks” that most seasoned ABAPers know about. You can have the best roles and authorizations money can buy, but it won’t protect you from any of the other vulnerabilities. The attacker has many possible paths, and only needs one to work to be successful.

Companies need to do a comprehensive information security risk analysis on their SAP landscapes and understand the full spectrum of vulnerabilities. Once this is done, the most vulnerable areas can be prioritized for remediation.

The analysis should take into account Preparation, Detection, Response, and Recovery strategies. While it’s easy to focus on Preparation, i.e. preventing breaches, early detection, a co-ordinated, practised response and efficient recovery could ultimately mean the difference between a minor and catastrophic incident. GDPR and POPIA’s breach disclosure requirement are a sobering reminder that you need to think about post-breach activities before the breach happens. In the SAP world, you can think about the following:

• Detection:
• Are your SAP systems integrated with your organization’s Security Information and Event Management (SIEM) systems?
• Does your organization’s cybersecurity team understand SAP?
• Do you have a mechanism to detect when data loss happens, for example when someone downloads an unusual amount of sensitive data, even if they are authorized to do so?
• Response:
• Do you have a security incident response plan that is tested on a regular basis?
• Can your legal team, SAP technical experts and cybersecurity blue team work in an integrated and efficient way to respond to SAP-related incidents?
• Do you know how to report incidents to data protection authorities?
• Recovery:
  Slow incident recoveries can hurt organizations tremendously. This is no different from any other unplanned downtime. Due to the uncertainty and stakes involved, security incident recoveries typically take much longer than recovery from other types of technical incidents. You have to plan, practice and improve. There is no shortcut.

Find out more about securing your sensitive data and systems.