DataMapping — FAQ

The term DataMap is possibly one of the most overused and misused terms in the industry — I feel most people claiming to build a DataMap do not truly understand what it is.

Attributes of typical efforts to build a DataMap include one-off efforts, involvement of external consultants and short-term perspectives. Another attribute of these efforts is that they mostly fail — the DataMap is stale immediately after it is issued. Following such efforts, companies become reluctant for a while to invest in a DataMap until they realize they do not have a good handle on their data and the process repeats.

I spent many years at KPMG and before helping customers reactively deal with Data related issues. I have realized it is much more sustainable for companies to adopt a proactive approach to understanding and managing their data. I also realized it is important for companies to build internal capabilities for key aspects of their Data and Privacy programs including around Data Mapping. Our customers, including many large companies, have successfully built DataMaps that get used daily. We have helped them improve their Privacy compliance by leveraging these DataMaps.

DataMaps requires a deliberate and thoughtful approach to be successful. DataMaps require a combination of technology and crowd sourcing of information from all parts of the organization to not become stale. 100% technology-based approaches or 100% manual approaches do not work. Efforts needed from individuals to maintain the DataMap must be kept to a minimum as this is often not their main business focus. Finally, the DataMap needs to be an integral part of your overall processes — for example if the DataMap underpins critical privacy or compliance related initiatives the organization has an incentive to keep it current.

In addition to these observations, I wanted to share some questions I have been asked frequently regarding Data Maps.

Should one completely inventory all data?

The answer is a qualified Yes. Cover all your data, but calibrate the detail captured for any system based on needs. Take a top-down approach to build a complete inventory and then adopt a bottom-up approach in certain key areas to capture a more detailed inventory.

To illustrate this with a couple of examples: More detail may be needed for POS or CRM systems. This would be needed to understand PI locations, how PI is transmitted inside and outside the organization. i.e. it is needed for Privacy compliance. Another example, you may identify zoom is used in meetings but there may be no need to track how often it is used etc. But if zoom calls are recorded — ensuring security and timely deletion of recordings can become important.

An effective DataMap needs to combine the nuances and provide meaningful visibility to the data for the organization. The DataMap will also look different for different stakeholders — for example security might be interested in a security centric view, whereas the records management department might be more interested in how the data is retained and deleted within the organization.

Discrepancies within the DataMap and how to manage them?

When you pull information from multiple sources to build a comprehensive DataMap, sometimes there are discrepancies in the information. Often the discrepancies reflect blind spots or gaps in either understanding or policies within the organization.

It might be very critical for the company to resolve these discrepancies as these may help to reduce risks. The process of addressing the discrepancies also can enable more communication amongst the various stake holders within the organization and help to foster a commitment to maintaining the DataMap current.

How can a DataMap be made sustainable? Current approaches to build a DataMap require a lot of effort, but the DataMap is outdated the day it is issued

It is important to why companies end up with DataMaps that are not sustainable. Primary reasons for this are

• Not designed right and often with no specific use case
• Built in isolated efforts (e.g., one-off consultant led).
• Many elements get built repeatedly and often frequently in various parts of the organization but never get integrated or maintained in a comprehensive manner.
• Focus is on technology and automation to collect substantial amounts of data about Data. This limits the use of the DataMap for business decision making

These one-off and fragmented efforts require significant spend. In these situations, DataMap is treated as an artifact and sustainability becomes an issue.

But when DataMaps are built for specific purposes and are constantly used and updated during use, sustainability becomes a non-issue. The cost of the one-off and partial builds on the fly far exceeds the actual cost of building and sustaining a holistic DataMap. But companies often seem to patch or band-aid solutions to fix an immediate pain point rather than taking a step back to develop a more sustainable solution.

We have proven that DataMaps can be sustained without a high level of manpower or resources in large and complex organizations. The DataMap does not require a large investment but needs a vision and commitment from the organization and key stakeholders.

A decentralized, community led approach to building a DataMap is usually successful. It is also important to ensure the Datamap is not an afterthought but an integral part of everyday workflows. Usefulness drives adoption and adoption drives sustainability.

How often do you update the DataMap

The DataMap needs to be current and relevant. But that does not mean refreshing all aspects of the DataMap constantly. Things that are constantly evolving need updates on a regular basis. Different parts of the DataMap will have different update cadences ranging from refreshes once a month or quarter or once a year (this could even be real-time in some rare cases).