How Accountable Is Your Business for GDPR? Part 2

Neil Patrick

Part 2 of the “GDPR Accountability” series

In my first blog in this series, I pointed out that a major difference between the current data protection regulations and the GDPR is accountability. We pick up here looking at possible approaches.

Based on the “get clean,” “stay clean,” “show clean” principle, one could adopt a three-stage approach:

  1. Get clean: Roll out technical tools
  1. Stay clean: Embed process governance on top of stage 1
  1. Show clean: Use the previous two stages + executive engagement and smart reporting for legal compliance

1. Technical tools (“get clean”)

Taking technical measures to technical GDPR problems is 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 pseudonymization 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 that this isn’t optional.

However, the GDPR is completely underpinned by the assumption that business and IT processes will change to respect data subjects’ level of risk 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 they don’t complete it, nor enable you to to “stay clean” or demonstrate “show clean” to the supervising authority or data protection officer (DPO).

2. Process governance (“stay clean”)

Process governance enables you to demonstrate and electronically record the organizational 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 uptake
  • Privacy notices and evidence they are implemented
  • Lawful processing and recording decisions with regard to processing
  • Information security and cybersecurity updates (policy and underpinning technology)
  • Documenting owners of processes that are relevant to personal data
  • Integrating and recording the consequence of the data protection impact assessment (DPIA) into corporate decision making
  • Data breach management

To quote one of the recently updated WP29 guidance documents on DPIAs: “‘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 are required: both technical and organizational measures to ensure that 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 organization 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.

This is much closer to the exam question, but still doesn’t quite give you the GDPR “ask” of accountability.

3. Legal compliance (“show clean”’)

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 enrollment (for example) are good.

Bear in mind that 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, and reduce the impact of ongoing regulatory compliance pressures. Most organizations have many regulations they have to comply with, not just GDPR. Also, there are NIS and ePrivacy Directives (which may become regulations) on the very near horizon.

I would argue there is a far better return on investment in an integrated GRC tool that can cover the context of this blog and much more from a GDPR perspective. With the right technology, you can also address the plethora of other regulations and policies, risk and compliance frameworks, and best practices. And better still, your organization can demonstrate use of other codes of conduct and their contribution to the GDPR (for example, Article 41 monitoring of approved codes of conduct, 40 & 42, 24 paragraph 3).

Together, these three stages will show…

To recap, the first two stages gives you the technical and evidence of organizational measures. Together they document privacy by design and default, and help to demonstrate accountability – the third stage.

It is the low attention to the second and third stages above, and the complete lack of the overall approach, that concern me. 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
  • With the ability to leverage other operational programs throughout the business

I believe this is a desirable direction for a GDPR program, and one that will allow you to stand up in front of the supervising authority and show this is how my business is accountable for the GDPR.

This article originally appeared in its entirety in SAP Analytics and is republished by permission.

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

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.