Your GDPR "Duties Of Proof" And Liability

Neil Patrick

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?

Burden of proof

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 exists for any damage caused by noncompliant processing, and in severe cases implies that 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, organization, 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 that 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 unauthorized 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, unauthorized 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 not trivial.

I am not a lawyer and cannot give legal advice, so this is my own personal thought: Build a digital “paper trail” of how you have implemented the GDPR in your organization 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 must 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 organization and you don’t have a record of its 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 organization (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 organizational measures in place
  • Have privacy by design and by default

Learn more

  • Review these assets, including a Webinar, to find out more about how you can turn GDPR compliance into a growth opportunity.
  • Read the rest of our GRC Tuesday series blogs on GDPR.

Follow SAP Finance online: @SAPFinance (Twitter) | LinkedIn | Facebook | YouTube

This article originally appear on the SAP Analytics blog and is republished by permission.

Neil Patrick

About Neil Patrick

Dr. Neil Patrick is a Director of SAP Centre of Excellence for GRC & Security covering EMEA. He has over 12 years’ experience in Governance, Risk Management and Compliance (GRC) & Security fields. During this time he has been a managing consultant, run professional services delivery teams in the UK and USA, conducted customer business requirements sessions around the world, and sales and business development initiatives. Neil has presented core GRC and Security thought leadership sessions in strategic customer-facing engagements, conferences and briefing sessions.