GDPR, another hype!?

Feb. 22, 2018
"Now let everything fall out of your hands!!!". It is 2002 and the management of a large company where I am working at the time is giving this as an instruction to the entire audit department. Startled, indeed, everyone dropped everything from their hands and looked around frantically. The new Sarbanes Oxley Act had to be implemented immediately, or else....

We start looking for what on earth needs to be done, how big and how deep? Two weeks later, when these questions have been asked and no clear answer echoed back the usual audit planning is resumed. SOX turned out to be hype, still echoing in time. Now there is yet another new hype: GDPR, the new European data protection law. And once again feral looks at companies and twinkling eyes at consultants.

We - auditors, risk managers - seem to have a rational profession with many binary considerations. Since that - for me - first time in 2002, I have seen a lot of hypes in the risk management field: besides SOX, Basel II and III, Solvency II, in 1999 there was the Millennium Bug, and I am sure I am forgetting quite a few. Basel IV is coming up.

There is also fashion: every few years, things seem to have to be different within organizations. The Balanced Score Card, shared service centers, outsourcing, Prince2, ISO certifications, Scrum, DevOps, Corporate Social Responsibility, and so on. All of these things impact what we do on a daily basis and pose the question of how to deal with them every time.

And that's what I want to talk to you about. We are often asked to help. In the project, as quality assurance, as auditor or maintenance of yet another new control framework. And our professional attitude (in part) determines how grand and compelling such a circus is rigged. The manager of an IT department at a large insurance company once told me that he has to spend a third of his time on compliance matters. Time not spent on innovation, caring for staff or increasing productivity.

For the past few years I have been working as a freelancer and being hired for such projects. Because I sell hours at a rate, it might be tempting to whisper in a solution that is "big and compelling" and therefore generates a lot of billable hours. And this is where something falters. Something about integrity, professionalism and, above all, feeling good about yourself. Personally, I especially want to be remembered by a client as "that guy we must have again next time.

Even as an audit or risk professional, there is a certain temptation to give weighty advice with all sorts of alarming hypothetical consequences like FINES!!! JAIL TIME!!! But you can sense that there is also such a thing as reasonableness and fairness.

On the other hand, an overly laconic attitude regarding privacy will potentially have consequences for a company or institution you work for. A consequence linked to the enforcement of the GDPR is then conceivable and we are bound to guard an organization from this. In short, where should we strike the balance?

At one end of the spectrum is the "better safe than sorry" attitude: maximum uncertainty reduction and therefore taking many measures. This often costs a lot of money and time and takes away many people's pleasure in their work. The other way around doesn't work well either, with all the associated risks. In short: let's try to rationalize and study what pragmatism can look like in a GDPR project.

My first thought: don't panic. Have confidence. The world is not going to end.

The second thought: start by identifying your risks. What exactly are we talking about? For GDPR, your CMDB (Configuration Management Database) is a great starting point that lists all your systems and applications and what they do. Possibly your CMDB (however rudimentary) is a good place to track your risk assessment - including for privacy-related issues. No CMDB yet? Great time to start doing that.

A third lesson I learned: explain the regulations to yourself and put it on paper - call it an "organizational file." It provides a rationalization of your change process and an explanation of your interpretation to potential supervisors, who will use it to force you to refute your rationale or go along with your explanation . If a supervisor comes in and only "checks off" regulations, you are vulnerable to that supervisor's interpretation. When your own interpretation is plausible (i.e., defensible), a nasty consequence is not likely to follow.

My fourth lesson, learned through trial and error, is that as a project manager/auditor/risk manager, you prefer not to define the measures. Who has never heard it, "That must be from audit"? If you want to get serious about something as an organization, the effect lies in those who actually implement the changed process. These people must therefore think about it themselves and come to a mode together.

And my fifth experience: keep it fun for everyone. If an organization sets a goal of embedding a new control framework, it's worth remembering that a control framework guards hygiene and does not bring in revenue or add anything to people's job satisfaction. So: use existing processes and systems as much as possible and try to make the existing processes compliant instead of piling additional processes on top of the existing ones.

Our goal should still be in line with that of the organization.

Marc van den Berg specializes in consulting on complex data-driven environments such as asset managers, actuarial environments and processors of marketing data. Marc performed several assignments in collaboration with ARC People.

ARC People connects three strong labels: AuditPeople, RiskPeople and CompliancePeople. Each of these labels focuses on its own specialized field. Clients are provided with the right people and knowledge from those specialties. www.arcpeople.nl