You Probably Have More Personal Data, in More Systems, Than You Think

There’s lots of guides on the internet to consent and so-forth, but relatively few that dive into hands-on implementation details. DataGrail is happy to describe two less-discussed aspects of a compliant GDPR programme: Data inventory and mapping and operationalizing GDPR requests.

Data inventory and mapping

When speaking to companies, we’ve observed confusion surrounding how to perform  data mapping and inventory. Often, legal teams possess a strong understanding of regulatory requirements and the goals of company operations but they don’t share the same knowledge of systems and data movements implemented across marketing and sales.

As a modern business, it’s likely that you store more personal data, in more systems, than you’re aware of. This guide will help locate all of it.

A straightforward manner of building a comprehensive and automated data mapping is:

1. Start with your vendors list from accounts payable
2. Use software surveys to classify vendors
   1. For Marketing: Martech 5000.
   2. For Advertising: AdTech Lumascape.
   3. For Business Systems: G2 Crowd.
3. For each system, have the actual purchaser inside your organization describe what they’re doing with the system and the associated data flows

Pay close attention to these classes of high-risk systems:

• Sales data systems: Used to enrich contacts you already have, and sometimes, to discover contact data. Be clear about which uses are allowed, and what consents are required.
• Analytics / Conversion Rate Optimization tools: Used to monitor what people are doing on your site or in your application. Be very careful about what data is pushed into them, what actions are tracked, and what data movements are allowed per your Data Processing Agreement.
• Lists: Purchasing lists is now a very high risk activity. Generally, you will want to avoid commingling data your company consented, data another company consented on your behalf, and unconsented data.

Be aware that many companies — like Salesforce, Adobe, Google, and Oracle — offer suites of tools for marketing and sales. Carefully track down the exact subsets of their tools your company uses and create a process for authorizing (with your legal team) any new usage or data flows.

It is a best practice, even if you aren’t a SOC 2 or similarly certified organization, to establish a mandatory vendor evaluation process, including legal, before any new software is purchased or new data flows are implemented. Otherwise, your mapping may be out of date within months.

Implementing a data subject intake and response process

With your data inventory exercise complete, you’re ready to craft your GDPR / CCPA data request intake and response process.

• Article 12 requires providing information in a “concise, transparent, intelligible and easily accessible form, using clear and plain language.”
• Recital 59 requires providing a means for request to be made electronically.

With this in mind, it’s a best practice to have a dedicated GDPR section in your privacy policy with an email address for requests. Consider hosting a dedicated data subject request portal, but it shouldn’t be behind a login barrier, because prospects, former customers, and customers all have the right to make requests.

You also need an internal request intake method, so that GDPR requests directed to your sales or marketing teams aren’t dropped. Train your teams to never ignore these requests — and if there is any doubt about what is being requested — to notify legal to handle disposition. These requestors are often annoyed by a sales or marketing communication, making careful handling crucial.

Below is a 3-step process for efficiently handling data requests.

Step 1: Receiving and initially responding to a request

After receiving a request, send the requestor an automated receipt. Your goal here is twofold:

• Satisfy your obligations under the law;
• Prevent someone (who may already be annoyed) from becoming even more agitated, thus reducing the likelihood of a complaint to a regulator.

Once you have a request in hand, and an acknowledgement sent, classify the requestor as a customer, former customer, or a prospect. This informs what identity verification you need to perform and what systems will have to be searched for data. Depending on the request intake modality, you should also verify control of the email address for which the request was submitted and perform identity verification, if necessary.

Step 2: Compiling and organizing request data

Now you must search all the systems identified above for personal data related to this subject; here, the rule of thumb is that a company with a £100 million turnover will have approximately 75 systems that contain personal data. If you have identified fewer, it is very likely your inventory has missed some of the systems.

After extracting all the data, we suggest providing it in two forms: a properly formatted human-readable extract, and an Article 20 structured, machine-readable format. This allows a single internal process to satisfy Article 15 and 17 data subject rights, as well as Article 20 portability rights.

Providing a properly formatted and structured summary of the data is crucial to avoid any confusion, as you want the requestor to clearly understand what data you have, why you have it, and what you’re doing with it.

Step 3: Completing a request

Finally, send the data you have gathered to the requestor. And make sure you respond to all requests, even those you deem invalid or for which you can’t surface any personal data. It’s a best practice to send your response to the requestor in some way that affirmatively confirms receipt.

A delivery receipt is important both so you can resend in case the requestor misses your communication, and to substantiate your efforts in case of any regulator complaint. If you don’t publicly provide it in your privacy policy, this is an ideal place to include a description of your processing activities as described in Article 30.

Keep a work diary, both to inform the further evolution of your internal GDPR handling process and to supply to regulators in case of any complaint.

At the end of this process, you will have successfully completed a GDPR request!

Article originally published on GDPR:Report