Belgian DPA recommends taking 13 steps now

The Belgian DPA (hereafter referred as CPP, to reflect its official name, Commission for the Protection of Privacy) has issued GDPR-preparation recommendations in the form of 13 guidelines for companies processing personal data. The English-language summary below is taken from a law-firm website (link) (the originals were issued in French (link) and Dutch (link) only).

The good news is that the CPP has now set some priorities, giving data controllers and processors an idea of what the auditors will be looking for in the early days after the GDPR’s effective date. The bad news, at least as I see it, is not only is the guidance mostly vague, but also that there seems to be an embedded assumption that all of this is feasible within a short time frame.

What follows is the 13 steps as presented in English (link), plus my comments, if any. The first thing that I will note is that, as I have asserted before (link), data-protection authorities generally (and the CPP in particular) will be looking at compliance primarily as a question of creating and following processes that are well-calculated to produce compliance. (The sole exception is Guideline number 8, which I discuss below.)

Indented sections below are from the website of DLA Piper (link); un-indented text is my comments.

The Privacy Commission will also create a GDPR-themed section on its website where data controllers and processor can consult additional guidelines, instruments and frequently asked questions.

Now we have our first (non-numbered) guideline: follow the CPP’s website to stay abreast of the CPP’s current thinking (link). It’s your best guide to what is expected by the regulators.

The 13 steps forming the roadmap for ensuring GDPR compliance by 25 May 2018 are:

1. Raising awareness

Inform key figures and policymakers on upcoming changes. They will have to assess the impact of the GDPR for the organisation.

Thinking in process terms, you need:

  • some way to decide who needs to be informed
    • the level of detail to provide, which might depend on the person’s background and anticipated role in the compliance effort
    • you may not yet have identified all of the stakeholders who need informing
    • you may not have even filled all the needed roles, and cannot neglect the awareness step as new members join the compliance teams
  • a record of having informed them, which may be tricky
    • some may be reluctant to acknowledge, given that it subjects them to added responsibility and uncertainty
    • what tangible form this record should take (e.g., attending a seminar, acknowledging an email, passing a comprehension test)
    • completion of a data-privacy impact assessment (DPIA) would be the most convincing evidence of awareness, since this is the goal of the awareness process, but it’s not clear that Guideline 1 is actually requiring this; in any case, the DPIA cannot be done before the Data mapping (Guideline 2, which I have called data inventory in previous posts (link)) is largely complete.
  • an archive of records providing convincing evidence that the foregoing was done, as part of your compliance history (link)

The same need-to-document requirement applies to all compliance efforts, including those below. If you can’t show that you’ve put a compliance structure into place, claims that you have done so are not convincing, especially after an incident.

2. Data mapping

Document which personal data you manage, where it comes from and with whom it has been shared. Map your data processing activities. You may potentially have to organize an information audit.

Having proposed a basic data-mapping approach in other posts (link), I will only add that my proposed structure can readily accommodate a matching of processing activities to individual data-element instances.

3. Communication

Evaluate your existing privacy policy and plan necessary changes in view of the GDPR.

This is a kind of chicken-or-egg problem: how do you know what your policies are before you know what is even feasible, and how do you know what is feasible before you’ve done several other of these steps? I would argue that you should skip this step until you’re mostly done with steps 4 through 9.

4. Rights of the data subject

Verify whether the current procedures within your organisation provide all the rights granted by the GDPR to the data subject. Check how personal data can be erased or how personal data will be communicated electronically.

Well, if you’ve satisfied this step, you’re mostly compliant. “all the rights granted by the GDPR” is easy to say, isn’t it?

In fact, this is a technically enormous requirement, which I would be willing to bet that very few organizations have implemented at this time. I call this a huge requirement because (among other things):

  • you must know where all of the data subject’s data is stored
  • you must not confuse this subject’s data with another subject (e.g., identical names), meaning that you’ll likely need an entreprise-wide identifier for each person
  • you will likely need to keep at least some of the requesting subject’s data (for example, to show that you received and carried out the deletion request), and you’ll need to establish your legal basis for doing so
  • there will be gray areas; one example that comes to mind concerns the parent of a child data-subject. What if the parent requests deletion; can you keep some of parent’s information using the justification that it grants consent to process the child’s data?
  • finally, the elephant in the room, which applies to almost all GDPR requirements: how do you back-fit this requirement onto existing applications? It is difficult enough to roll in (relatively) minor changes to many older applications, let alone sweeping changes that will impact the application from top to bottom.

5. Access requests

Update your existing access procedures and think about how you will process future access requests under the new GDPR terms.

“think about how you will process” ? OK, I thought about it, job done. Now how do I document that?

But seriously, I believe that the access requests will involve the same data as the purging requests (above), with only the addition of how and why you’re holding it, what you do with it, and whom you’ve shared it with.

6. Legal basis for processing personal data

Document the various types of data processing by your organisation and identify the legal basis for each of them.

Again, a good reference data for the data mapping/inventory. Be alert for the appearance of new legal bases as time goes on and new guidance and court decisions add to, clarify, or remove legal bases.

7. Consent

Evaluate your way of requesting, obtaining and registering consent. Modify where necessary.

Request, obtain, register: each of these is tricky;

  • you have to balance between making your terms brief and easy to understand and covering everything that you do or may do with the data
  • what if you change your terms; must that invalidate all previous consents?
  • you have to balance between necessary consent (e.g., what you must have to perform the user’s desired action) and optional consent (what you’d like the user to consent to that isn’t strictly necessary)
  • registering consent: how much is enough? You might capture the technical data object emitted by the user’s affirmative action (e.g., the return value of a button click, showing things like date, time, IP address), but what if the user is using a VPN, is behind a corporate firewall, thus making it impossible to link the returned IP address to that user?
  • retaining evidence of consent. must you purge the user’s consent history after a purge request, or must you retain it (say, to show that you did in fact have user consent during a particular time period)?

8. Minors

Develop systems to verify the age of the individual concerned and request parental or custodial consent when processing personal data of minors.

How can this be done reliably? It’s one thing to say “develop systems” and another to do it. If the age of majority is 16, there is no objective difference in a person the day before their 16th birthday and the day after. A person’s age can only be determined from their date of birth, which itself must be verifiable.

While I wholeheartedly support the aims of the GDPR, I find it depressing that both statute and guidance appear to be written by people with no experience of building or maintaining such systems. Can you even point to a company that is doing this successfully?

Anyone can click a button saying “I am over the age of 15” or whatever, but how can you be sure? The only thing that comes to mind immediately is something like a token system (similar to what banks have), only multi-site instead of single-site. This would be cumbersome and unlikely to be popular with users or controllers.

If such a thing were easily done, the big social-media sites would already have it to prevent, for example, adults posing as children online in order to socialize (and worse) with minors.

9. Data breaches

Foresee adequate procedures to detect, report and investigate personal data breaches.

At least there’s lots of precedent by now on how not to handle a breach, for example (link) (link) (link). Some of it is easy, at least in principle: for one thing, don’t try to cover it up.

Also, don’t say anything to the effect that you had no process for preventing the cause(s) of the breach. In the Equifax case, for example, the CEO stated to the U.S. Congress that a single employee was tasked with patching the vulnerability following an alert from the Apache Foundation, and for some reason didn’t do so (link).

This is tantamount to admitting that Equifax had no process (e.g., multiple eyes, auto-generated and escalated trouble tickets) for handling critical updates. What if the employee in question was out sick, lying in the hospital? The first attacks using the (patched) vulnerability started in just 3 days (link), a very small window for most shops, which prefer to patch during a scheduled downtime, usually at the slowest time of the week.

So you have a 3-day (probably less in the future) window between you and disaster, and you rely on a single person to be responsible for it? This process need only miss oce for your company’s reputation to be ruined (not to mention the lawsuits). Do you really want to have to admit that you took that risk so casually?

As far as features to detect a breach, that is even more of a problem, given that in principle an attacker can cover or falsify his tracks, leading to delay in discovery or underestimation of breach size.

There is a proverb “an ounce of prevention is worth a pound of cure”. In data breaches, there’s no cure; prevention is all there is. Data, once escaped, is beyond control. Yes, you need to warn your data subjects as soon as possible, with the knowledge that you may get a lot of deletion requests in short order (one reason not to rely on manual deletion).

If I were the CPP, I would have added breach prevention and mitigation (such as encryption, rapid patching, and limiting large data transfers). Maybe that’s included by default in privacy-by-design.

10. Privacy by design and privacy impact assessment

Get acquainted with terms such as “privacy by design” and “privacy impact assessment” and verify how you can implement these concepts in your organisation’s day to day operations.

As I’ve pointed out before, “privacy by design” implies that you have a design at all (link). If some of your projects have no design, probably the best you can do is to reverse-engineer a design out of the existing artifacts (code, old documents). Hopefully whatever comes out will not be too resistant to re-factoring. (link)

11. Data protection officer

If necessary, appoint a data protection officer or someone responsible for ensuring compliance with data protection laws. Evaluate how this person will function within the management of your organisation.

I’ve covered this one already (link).

12. International

Determine who is your supervisory data protection authority if your organisation is active in multiple jurisdictions.

I haven’t yet unraveled the rules around this, but I wonder whether it’s the same in all cases. What if you’re based in Belgium and have a lot of data subjects in Bulgaria. Will the Bulgarian or Belgian local standards and derogations apply? What if you’re based outside the EU; can you choose to have your representative in the friendliest country?

13. Existing contracts

Evaluate your existing contracts – mainly with processors and subcontractors – and adopt the necessary changes in a timely manner.

Can one party simply change a contract unilaterally? Any significant contractual change shifts the risks and obligations between the parties, not the least of which is how the costs of compliance will be allocated among the parties. It might be helpful for the CPP to publish model contracts.

Leave a Reply