What to do first

Confronted with the enormity of an effective compliance effort, you are likely to be overwhelmed. For one thing, your resources are likely to be meager. For another, the typical objective at this point is merely informational (“look into it”, “impact assessment”, “cost estimate”). From management’s point of view, this is a reasonable request. From your point of view, it’s not; the information is not lying around, but must be must be collected from dozens or hundreds of applications, databases, filesystems, and more. 

Gathering, assembling, classifying (PII, not-PII, maybe-PII), and unifying your data across silos is an enormous undertaking. What’s more, it will be ongoing, given that new applications are constantly created, and new data items are sometimes added to old applications.

Your duties do not stop at constructing a unified view of your data holdings; you will produce a great deal of data of your own in the form of GDPR-mandated documentation and record-keeping. A quick glance at the GDPR (e.g., Art. 25) shows that you must not only catalog your data holdings, but also set out what business purpose is served by keeping this data, how it is used, who it goes to, and how long it is to be retained.

Eventually you will be required to show that you have taken reasonable measures to identify PII (personally-identifiable data, the subject of the GDPR), protect it from exposure (which can be accidental or due to a security breach), give a copy of it to the data subject (the person described by the data) upon request, and even to purge it from your system (e.g., if the data is no longer needed, or if the data subject requests the purge).

There’s lots more, but that partial enumeration should be enough to convince you that even something as basic as preparing impact, cost, and schedule estimates will require a great deal of work on your part. It will even require development; in addition to collecting all this stuff, you’ll need a database to store things like the name of each data item, its location(s), and perhaps other information such as the PII category and sensitivity of the data. You’ll also need a (searchable) document repository to store all the processes, decisions, reviews, internal audits, and checklists that you’ll be generating.

Pick your guidelines

Before tackling any big efforts, think about what you can accomplish in a short time frame. Suppose you’re leading a small team assigned to look into GDPR and report to management. Where do you invest your precious effort if you want to show quick results? You will likely have no choice but to focus on what you can do quickly and cheaply; give preference to creating project assets that you can re-use in later stages.

Things you can do quickly

  1. Compile a list of business-critical applications. These are probably silos, that is, vertically separate pieces of functionality and data storage. These are not necessarily your biggest GDPR risks, but they will help to focus management’s attention on the issue and secure support for the necessary effort.
  2. Compile a list of horizontal infrastructure functions for your critical applications. These are the activities that span multiple silos, including encryption, backup & recovery, data-quality assurance, and archival. Upper management likely has little awareness of the risk these areas pose; this is an opportunity to put it onto their radar.
  3. Create an inventory of the data used on, say, the 2 or 3 applications that present the clearest risk, for example, because their data is sensitive or because they are exposed to the internet or sent outside of the EU. Track the effort required to perform this mini-inventory, then extrapolate to provide a rough-and-ready estimate for the mission-critical applications.
  4. Make an outline of the processes and steps explicitly required by the GDPR for all development and send it to the project managers for each existing application and get their estimates on impact, time, cost, and so forth to comply. (You can later re-use this outline as the basis for a workflow or checklist to ensure that the steps are being carried out.) The managers’ estimates will not necessarily be accurate, but they will give you a basis for the impact assessment that you present to your stakeholders.

Things you can do cheaply

  • Ask around among your peers at similar companies. What are people doing about GDPR? (OK, some might consider this proprietary information, but everyone needs to comply, and there’s not a competitive angle.) Try social media and web searches for resources (like this blog). Compile a searchable database of ideas (MS Office’s OneNote works well for this).
  • Look for packaged solutions, such as a data-profiling tool that can extract information from the catalog and try to identify PII. Will the vendor give you a free trial? Can the vendor provide references to customers you can contact?
  • A packaged solution is particularly helpful if your company has many different database products, because such software can typically connect to data stores from different vendors and consolidate their catalogs.
  • If you have no budget for a packaged tool, you can write your own profiling tool using SQL. To keep things simple, target one database product (preferably one used by some of your business-critical applications). The result need not be professional or perfect; at this point you’re trying for a high-level estimate of your PII. Your custom profiler can not only give you this information, but also demonstrate the value of profiling itself.

Things you can re-use in later stages

I mentioned above that the development-process outline can be re-used later, saving you some time and effort, plus making it worthwhile to make the outline more of a prototype than a throw-away. The same goes for the list of critical applications and the data inventory. Together they will be part of the core of your compliance effort.

Things that constitute visible progress

Over the years I’ve seen several projects that, months or years after kicking off, have only slideshows and perhaps a few vague documents to show for it. Anyone who’s done much development knows that such artefacts are worse than none at all, for they testify to wasted time and money.

Let’s face it: A project needs to show results to its stakeholders, who otherwise might justifiably doubt whether anything useful is being done. Not only do you need to show your work, but also to explain why it’s needed and how it will be useful down the road. Make it easy for your sponsors to justify their support for you to their bosses.

This is especially true for the GDPR, which tells us what we must do, but not how to do it. It’s a set of requirements, if you will, which we must ponder and solve, each IT shop in its own way.

To summarize: get the most value for your efforts by focusing initially on what you can do quickly and/or cheaply, what you can re-use, and what you can show to your stakeholders as tangible progress.


Leave a Reply