Insights / Privacy & Security Law Blog

X Marks the Spot Where the Personal Information is Stored: Avoiding Common Mistakes in Data Mapping

By Rachel R. Marmor

05.22.19

"Go to the room with the wires and a quiet hum. Personal information, you're likely to find some."

With new global privacy laws requiring consumer access to specific pieces of personal information and documentation of processing generally, organizations are now finding themselves having to go on treasure hunts for buried personal information within the company. Between the explosion of cheap electronic storage methods and expansion of the definition of personal information in new laws, these "data mapping" exercises often feel as cryptic and fabled as a treasure hunt.

Conducting a fruitful data mapping exercise requires strategic planning, partnership between legal teams and IT, and a toolbox of technological tools designed to facilitate the process. Even then, the clues may be difficult to decode. DWT can help you avoid these five common mistakes:

1. Buying Technology Before Hiring a Law Firm

The first step in creating a privacy compliance program should be to define the legal requirements that the company needs to meet. Technology may well be critical to meeting those requirements; but there is no guarantee the peg will fit the hole if you don't first drill down and then measure the hole.

Before you meet with the technology sales people you should determine what your desired output looks like and what data fields the law requires you to track or locate. Putting privilege around the exercise, where appropriate, is also critical, as you may discover some bones (such as abandoned stores of social security numbers or credit cards) while digging around.

Further, don't underestimate the amount of time and cost required to to integrate technology into your privacy compliance process. A human being will have to decide how the company will conduct the mapping risk assessment, administer a survey, and analyze results. Some tools offer excellent model questionnaires, but you will have to customize them to your organization's culture and systems. And someone will have to communicate the instructions to the system owners and follow up to insure complete responses are received. All of this will take twice as long as you think it will.

2. Relying Too Heavily on Manual Surveys

Most organizations start data mapping with surveys asking system owners to report on the data processed by their systems. But unless the organization has a strict policy of requiring systems to have individual "owners," there often is no one to send the survey requests to or, alternatively, the requests are overlooked. Further, individuals are not well equipped to sit and list hundreds of metadata fields that may be in a particular tool, and questions such as "where is this tool accessed from" do not have easily knowable answers.

While a fully manual survey process isn't the answer, technology has limitations as well. Most data discovery tools require you to point them at the systems you want to search. The tools are quite effective at telling you if the five systems you know about contain social security numbers versus credit card numbers, but ineffective at telling you that there is a sixth system that you don't know about. Therefore, it's best to use a multi-pronged approach to bolster survey questions. This allows you to compare responses to available systems records, such as IT tickets and invoices for software and licensing, to ensure that a complete list of the company's information assets is available for mapping.

3. Designing a One-Time Only Process

In the big data age, the way in which your organization stores and analyzes its customer information is likely changing weekly. If your data mapping is done through a one-time survey, it will be out of date within a week of being completed—which means your disclosures could be inaccurate, placing you at risk of regulatory enforcement.

Surveys should be designed to be repeated annually. But more importantly, you will need to implement governance measures to ensure that the privacy risks of new programs or processing activities are considered upfront. The appropriate measures may vary by company, but could include requiring a Privacy Impact Assessment as part of the procurement process and placing your Chief Privacy Officer on the committee that approves technology purchases.

4. Ignoring the Cloud

Organizational use of the "Cloud" has exploded in recent years, particularly when accessing a program on someone else's Cloud server is significantly easier than bringing it behind your own firewall. The Cloud, however, creates significant challenges for data mapping and records management generally, as it's easy to forget about the data when it's no longer on servers maintained by your organization. How data that has moved to the Cloud will be discovered needs to be a part of your strategic planning discussion, and you should challenge technology vendors on their Cloud discovery capabilities before purchasing their software.

5. Forgetting About Unstructured Data

Rarely does a business unit or IT department control or even track the data that is placed on unstructured network (or Cloud) drives. In many organizations, individuals can create less secure drives on the fly; and even where they cannot, records of purpose and content are not typically detailed. This poses a serious challenge when an organization must state that it has identified all data related to a particular person, or certify to a regulator that its list of the manner and purposes for which data is processed and stored is complete.

The best defense against unstructured data is a good offense. Policies should clearly instruct employees not to store personal information on drives (where security features may be more limited); but training is needed to make employees aware of such policies, and technology is needed to detect violations.