GRC Tuesdays: Your GDPR ‘Duties of Proof’ and Liability

Burden of Proof

In the typical application of legislation one is assumed innocent until proven guilty. There are some exceptions—in many countries health and safety is an example. Companies are assumed guilty until proven innocent if there is a fall and injury—the question is asked, What could they have reasonably done to prevent it?

While the European Union (EU) General Data Protection Regulation (GDPR) doesn’t have a full reverse burden of proof, Article 82 (Right to compensation and liability) paragraph 3 states “A controller or processor shall be exempt from liability under paragraph 2 if it proves that it is not in any way responsible for the event giving rise to the damage.”

This means liability for any damage caused by non-compliant processing, and in severe cases implies a data subject receives effective compensation. The apportionment of liability will most likely depend on the degree of processing responsibility between data controllers and data processors.

The ‘damage’ outlined in paragraph 2 of Article 82 relates to processing activities of a data controller and data processor and whether this processing is not compliant with the GDPR (as well as fulfilling lawful instruction of a data controller if you are a data processor).

So what does this processing burden of proof look like?

Processing of Personal Data

Drilling further into the regulation, we learn that processing of personal data is defined as “collection, recording, organisation, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction.” Pretty much anything and everything to do with ‘touching’ personal data.

The GDPR also requires that processing is specific to a purpose—the business reason why the personal data is being processed. Companies in essence need to attach a defined purpose to their specific processing of personal data, and they need to demonstrate they are processing the data with appropriate responsibility for that purpose only. Without lawful processing acquired (consent, contract, legal obligation, and so on), without a defined purpose (marketing a specific offering for example), processing should not be done.

If processing is taking place, the company must demonstrate by design and by default it is being done in accordance with GDPR; in other words, prove it.

Further (but not exhaustive) duties when processing personal data include:

• The amount of data processed is to be “adequate, relevant and limited to what is necessary for the purposes”
• Data subjects “should be made aware of risks, rules, safeguards and rights in relation to the processing of personal data”
• It should be “in a manner that ensures appropriate security and confidentiality of the personal data, including for preventing unauthorised access to or use of personal data and the equipment used for the processing”
• The “period for which the personal data are stored is limited to a strict minimum”

Security of Processing Personal Data—Data Breach

In addition to procedures around processing of personal data, there is also a burden of reporting breaches to the supervising authority, in the case of failures of security relating to processing of personal data.

The GDPR defines a data breach as “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed.” We come back to processing of personal data once again, this time adding breaches of security.

Data controllers have 72 hours (or less if required in that EU member state) to report becoming aware of a data breach. Data processors have a duty to inform a data controller of a data breach.

The extent of risk to data subjects (number of records breached, type of data breached, nature of exposure for example) will significantly impact fines, corrective measures, and so on that a supervising authority may consider imposing.

Clearly the GDPR takes processing of personal data seriously, as well as managing the security of processing.

What to Do?

How do we prove we are “not in any way responsible for the event giving rise to the damage”?

This is non-trivial.

I am not a lawyer and cannot give legal advice, so this is my own personal thoughts: Build a digital ‘paper trail’ of how you have implemented the GDPR in your organisation and what measures you have in place to manage processing of personal data—and start as soon as possible.

Implementing an access governance tool (for example) is one of the aspects to manage security when processing personal data. But as with any technology and evidence-based regulation, you have to show that the technology (as a control) is fit for purpose (design effectiveness) and has been rolled out properly and is being used (operating effectiveness).

The same holds with policies (data encryption, 2-factor authentication, or even your GDPR policy).  Creating the best policy in the world is excellent and admirable, but if it isn’t implemented throughout the organisation and you don’t have a record of it being accepted by the recipients, you have not complied with GDPR.

Bottom Line

Even if you don’t have all the technical measures in place, it will be a really good thing if you have a documented GDPR program in place with both:

• Executive sponsorship (accountability)
• Evidence of it being successfully rolled out throughout your organisation (which of course requires that it has been rolled out)

This can help you build evidence that you have done all that you can that is reasonably possible to:

• Use state-of-the-art technologies
• Have technical and organisational measures in place
• Have privacy by design and by default

Learn More

• Visit SAP’s GDPR compliance webpage for more information and education about GDPR
• Check out the GDPR product webpage for resources about which SAP solutions and services could help you govern your GDPR program and manage and protect your data for sustainable GDPR compliance
• Read our other GDPR-specific blogs

NOTE: The information contained in this blog represents the author’s personal opinion and is for general guidance only and provided on the understanding that SAP is not herein engaged in rendering legal advice. As such, it should not be used as a substitute for legal consultation. SAP SE accepts no liability for any actions taken as response hereto. It is the customer’s responsibility to adopt measures that the customer deems appropriate to achieve GDPR compliance.