GRC Tuesdays: How Accountable Is Your Business for GDPR?

Having recently attended a two-day conference during which GDPR was a frequent presentation topic, I have to admit to a developing sense of concern over discussion topics. And dismay for organisations casting around for answers to meet the GDPR needs. So today I want to take a closer look at the GDPR’s definition of accountability, and offer tips on how organizations can ‘get clean’, ‘stay clean,’ and ‘show clean.’

One of the big differences between the current data protection acts and GDPR is the concept of accountability.

There are others such as joint responsibility of data controller and data processor, but that is more of a binary 0/1 fact—now that you know about it you have to comply. How do you comply? Take a look at accountability.

In one of the earlier ICO “guidance to the GDPR” documents, they make the point:

The most significant addition is the accountability principle. The GDPR requires you to show how you comply with the principles – for example documenting the decisions you take about processing activity.

You must implement appropriate technical and organisational measures that ensure and demonstrate that you comply.

A recent Gartner publication considers the “Top 5 Priorities to Prepare for EU GDPR” to be:

1. Determine your role under the GDPR
2. Appoint a data protection officer
3. Demonstrate accountability in all processing activities
4. Check cross-border data flows
5. Prepare for data subjects exercising their rights

So after (1) determining how GDPR affects you (for example, are you a data processor, a data controller, or both;  do you have dealings with the EU or EU resident’s data) and (2) determining if you need to appoint a DPO, the next most critical thing to do is (3) demonstrate accountability of processing activities.

The GDPR itself specifically talks about accountability in Article 5 paragraph 2, “The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 (‘accountability’).”

This paragraph refers to the six principles of GDPR, which for the sake of brevity in this blog I’ll highlight only the phrasing at the end of each principle:

1. ‘Lawful, fairness & transparency’
2. ‘Purpose limitation’
3. ‘Data minimisation’
4. ‘Accuracy’
5. ‘Storage limitation’
6. ‘Integrity & confidentiality’

Article 30 paragraph 3 requires that data controllers and processors shall record their duties and responsibilities in writing, including in electronic form.

The Gist of the Regulations

In other words, the supervising authority requires that in order for you to avoid an audit and potential financial sanctions and/or reprimands, you are to be both responsible for and demonstrate how you comply with the six principles above. And you must record your duties as a data processor and/or controller in writing—including in electronic form, which would be the most cost effective and repeatable, reportable, reliably auditable way of doing that.

Rolling out some encryption, pseudonymisation or blocking and data deletion technology, for example, is necessary and good. They’re obviously useful and in some cases essential. But on its own, this is not necessarily demonstrating accountability.

In other words, they don’t answer the bigger GDPR compliance question— showing how you comply with the principles such as recording decisions about processing, recording the decisions, and mitigating actions put in place after a DPIA is carried out.

Something more is required both in approach and tooling.

So one could adopt a 3-stage approach:

1. Roll out technical tools—‘get clean’
2. Embed process governance on top of stage 1—‘stay clean’
3. Use the previous 2 stages + executive engagement and smart reporting for legal compliance —‘show clean’

1)Technical Tools (‘Get Clean’)

This gives you technical measures to technical GDPR problems. It’s necessary and will form the foundation for whatever GDPR program you put in place. It certainly seems prudent to be able to deliver an end-to-end encryption capability and to be able to include pseudonymisation for sensitive line of business processes. Article 17 describes the context of data erasure related to data processing, consent, purpose, and so on, which indicates this isn’t optional.

However, the GDPR is completely underpinned by the assumption that business and IT processes will change to respect the level of risk to data subjects as a consequence of companies processing personal data. If that sounds simple just read the GDPR definitions of processing (Article 4 paragraph 2) and data breach (Article 4 paragraph 12) to see how far this reaches.

Technical tools are a starting point on the journey to ‘get clean.’ But it isn’t the completion or the ability to ‘stay clean,’ or demonstrate ‘show clean’ to the supervising authority or DPO.

2)Process Governance (‘Stay Clean’)

This gives you the ability to demonstrate and electronically record the organisational measures necessary to meet the GDPR. It provides the internal ‘channel’ for embedding cultural change. It provides the tooling to roll out a ‘tone at the top’ framework for changes such as:

• A GDPR policy with evidence of distribution and take-up
• Privacy notices and evidence they are implemented
• Lawful processing and recording decisions with regard to processing
• Information security and cyber security updates (policy and underpinning technology)
• Documenting owners of processes that are relevant to personal data
• Integrating and recording the consequence of the DPIA into corporate decision-making
• Data breach management

To quote one of the recently updated WP29 guidance documents on DPIA’s : “‘pseudonymization and encryption of personal data’ (as well as data minimization, oversight mechanisms, etc.) are not necessarily appropriate measures. They are only examples. Appropriate measures depend on the context and the risks, specific to the processing operations.”

A broader context and oversight of the technical tools within how the business operates and the level of risk to data subjects is required: both technical and organisational measures to ensure processing meets the GDPR need to be in place. This is necessary for the GDPR, but as importantly, this embeds a sustainable cost-effective business change within the organisation to continue to deliver the GDPR. It provides a link between technical compliance tools and business change for the good of the business, not ‘just’ compliance.

In other words, all the efforts companies are striving for now can be maintained as business as usual activities, with their appropriate contribution to the GDPR documented, along with ownership and documented decision-making.

Which is much closer to the exam question but still doesn’t quite give you the GDPR ‘ask’ of accountability.

3)Legal Compliance (‘Show Clean’)

By the way, in this context, Microsoft Excel is not the most robust electronic form for an ongoing ‘business as usual’ program of this criticality. Take a look at the EuSpRiG list of horror stories on spreadsheet use. Niche tools for DPIAs and process enrolment (for example) are good.

Bear in mind, the GDPR will be around for the foreseeable future. IT and business are trying to reduce the number of tools in use, reduce the complexity of multi-vendor tooling integration, reduce the impact of on-going regulatory compliance pressures. Most organisations have many regulations they have to comply with, not just GDPR. Also there is NIS and ePrivacy Directives (which may become Regulations) on the very near horizon.

How SAP Process Control Fits the Bill

I would argue there is a far better return on investment in the GRC tool, SAP Process Control. It will cover the context of this blog and much more from a GDPR perspective. It will also help address the plethora of other regulations and policies, risk and compliance frameworks, and best practices. And better still: SAP Process Control will allow your organisation to demonstrate use of other codes of conduct and their contribution to the GDPR (e.g. Article 41 monitoring of approved codes of conduct, 40 & 42, 24 paragraph 3).

Integrated within a GDPR cockpit such as the thin Fiori dashboard below provides a very concise and intuitive view for the DPO, and low time requirement required from the business to engage in the GDPR process.

If I were a DPO and saw these three tiers in place in an organisation I think I would start to have a smile of sorts on my face. Even if all the technical measures weren’t fully in place for all parts of the business by May next year, I would be able to demonstrate a good understanding of the GDPR and the business response, and the intention to meet them. I would be able to substantiate that an infringement was not intentional or negligent (Article 83 paragraph 2(b) dealing with examples of application of sanctions).

I would have a technical framework and a business change program to demonstrate accountability. Because accountability is not a ‘thing,’ it is not a tool, it is a process.

Together These 3 Stages Will Show…

To re-cap, the first two stages gives you the technical and evidence of organisational measures. Together they document privacy by design and default, and help to demonstrate accountability—the third stage.

It was the low attention to the second and third stages above, and the complete lack of the overall approach, that gave me my concerns at the recent GRC event.

And furthermore, this is not ‘just’ about GDPR compliance —if you do this properly you’ll also end up running your business:

• more efficiently
• more effectively
• with a much lower total cost of program
• and with the ability to leverage other operational programs throughout the business

I believe this is a desirable direction of travel for a GDPR program, your ‘this is what good looks like.’ I believe you’ll be able to stand up in front of the supervising authority and show, This is how my business is accountable for the GDPR.

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.