Building a history of compliance efforts

Suppose it’s your first day on the job as a new GDPR consultant at a company. So far most of the company hasn’t done any preparation, but you’ve met with the legal team and found that they’ve studied the legislation and guidance. How can they help you at this early stage?

For one thing, your legal team can help you define what kind of artefacts (IT slang for any tangible piece of evidence; it can be any sort of file, email, paper document, etc.) will be useful in demonstrating a good-faith effort to comply with the legislation. What can you create that will be useful for your legal team?

You might want to draw some hypothetical scenarios, such as:

the DPA (data-protection authority) notifies you that you will be audited

there has been a data breach by your company and

the press and officials are asking questions

data subjects are trying to find out whether they’ve been exposed

one or more data subjects files a complaint against you, claiming, for example:

you exposed their personal data and caused harm to them in some way

you failed to provide an export of their data within the allowed time

you failed to provide a statement of what data you hold about them, the purposes of the processing, and the sharing of that data with others

they are unable to get their data corrected in your databases

What kind of evidence or documentation would be helpful to the legal team in defending this kind of claim or, in the case of negative publicity, in crafting public statements to try and re-assure all stakeholders that the company has a solid compliance effort in place? The legal team’s answer, likely to be a list of things, is one of the work products that your GDPR team must aim for.

As you do for the legal team, so should you do for marketing, public relations, management, and any other group that may have to deal with the fallout from a data-privacy-related incident. If there is a problem, staff in these areas (and perhaps others) will benefit greatly by having an action plan and by knowing how to quickly locate all available materials that will be helpful in managing the incident and defending the company’s interests. At the very least, this effort will get the needed parties thinking and talking about privacy and the part that they need to play in the process.

A DPA audit

The first contingency, the audit, is different from the others in that it’s not exactly an incident. Data controllers and processors should expect to be audited from time to time, but the need for plans and preparation is the same. This is the contingency I will cover here.

Privacy by design

Privacy by design (PBD), a key GDPR requirement, is like the old IT phrase “easy to use”; it’s easy to say, and hard to implement. I will argue here that PBD means that every stage of the development process, from the first requirements to the final shutdown and retirement of the application, needs not only a privacy plan, but also:

specific measures to be taken at the each stage

reviews and/or testing to ensure that the planned measures have been verified

milestones showing that development has reached a particular stage, with all compliance measures in place, reviewed, tested, and signed off

I think that it is understood by everyone in IT, and by the DPAs, that no software installation will be 100% compliant at all times; complex software simply does not lend itself to such certainty. I think that what the DPA will be looking for is a development process that is

a good-faith effort

reasonably calculated to produce data privacy

with no obvious privacy measures neglected (‘obvious’ here meaning those covered in standard textbooks, ISO, published best practices, etc.)

Requirements

Strictly speaking, requirements are not part of application design, but they should at least not contain any requirements that imply violation of data privacy. When I first started to read about the GDPR, I assumed that compliance review would start with design, but it turns out that many firms have requirements that include sharing or selling data. (see, e.g., Sweden, link (French), link (Dutch))

For example, plans to garner revenue by selling data to other companies, sharing data with partners, or carrying out marketing based on personal data must be reviewed by legal team for compliance risks. The requirements should also state clearly where personal data must appear (that is, which business functions need it) and where it may not appear (for example, in reports distributed to analysts, investors, etc.

Considering that GDPR is now a requirement, in parallel to your business requirements, what are your required planning and compliance documents, and how will this compliance dossier be stored for easy search and retrieval? How will the dossier be protected against tampering or destruction?

Designs and models

What privacy measures are in the design of your software architecture, your data models, your planned reports, and your user interfaces? What do you require in the way of testing for these measures, and who will perform and sign off on the results?

Are you planning to take advantage of a packaged system (see, for example, my earlier post on Oracle’s offering (link))? If so, do you have test plans to verify that the system’s features work as anticipated?

Are you relying on a cloud solution? If so, are the requisite legal assurances, such as a conforming contract, in place? If the cloud provider is not based in the EU, does it have the required EU representation, and does its home country have EU-approved privacy regulation? Who will keep this under review, given that either the GDPR or the home-country’s regulations may change in the future? All of these questions should be part of your compliance plan.

Implementation

All I can say here is that the implementation should match the design, plus include any well-known best practices for whatever programming language, business-intelligence product, database, framework, etc. that you are using. Much will depend on the specifics, but some practices will be universal:

mapping — each program element should connect to the design element that it implements, and vice-versa

review — code review of privacy measures should be performed as part of all milestones

testing — all the implemented measures should be accompanied by test plans and code

milestones — all code review and test results should be captured, signed off, and recorded in the compliance dossier

Infrastructure

Here I use the term infrastructure to describe those compliance elements that are not specific to any development stage, but span the entire effort. I use the term infrastructure, but some shops call these requirements non-functional, transversal, or orthogonal. What follows are 2 examples of this dimension of compliance.

Document management

Your project will need a document database for storing the hundreds (or more) of documents in your dossier. This database will also need to be searched effectively, accommodating flexible searches like wildcard, fuzzy, regular-expression, and stemmed searches, with logical connectives. The only such system that I have used is Oracle Text, whose features I have started demonstrating (here).

All of your dossier’s elements will be more convincing if you have in place a system to record these actions as they happen, in such as way as to allay suspicions that documents were back-dated in response to an audit notice or other event. The most convincing is a system that is difficult or impossible to falsify, such as an audit trail, perhaps even a blockchain-style ledger.

Downstream risks: backup/recovery files

Normal databases and operating systems constantly generate large files (such as backups, logs, and journals) that either contain PII (personally-identifiable information) or provide information that could be used to obtain PII. There are also files used in bulk transfers, say, from operational databases to data warehouses and reporting applications. You’ll need a plan in place to guard these files as well.

All of these files must be safeguarded, preferably by encryption, in such a way that their theft is unlikely to result in a data breach. Not only must these measures be taken, but they must be accompanied by a (periodically tested) process for de-crypting them in case a recovery is required.

My guess is that the auditor will not be looking for such thorough measures, especially not in the early days of GDPR, but demonstrating these safeguards will help to impress him or her that your organization is well above average in its efforts.

By itself, compliance is not enough

Compliance efforts need to be demonstrable. If you are not keeping records of these efforts, how will you show that you are making them, and what they consist of?

This is where your legal team can help you, and you them. Get started now, before the wolf is at the door.

Post navigation

Step 9 of the Belgian Privacy Commission’s guide to getting started with GDPR compliance concerns detecting, analyzing, and dealing with the fall-out of a data breach. The recent recall and re-issue of Estonia’s smartcard IDs brought home to me that public relations (PR) planning is an essential part of breach preparation, not to protect the […]