January 15, 2020

Building a Layered Approach to Data Management, Part III: How to Associate Third Parties with the Data Subjects They Process

PKWARE
Building a Layered Approach to Data Management, Part III: How to Associate Third Parties with the Data Subjects They Process

Part 3 of a Three-Part Blog Series

If you’ve been following this blog series, you know that we’re building a layered approach to data management founded on visibility into data subjects and the ability to protect personal information through data obfuscation and deletion. But these foundational steps aren’t much good unless they can stand up in a complex, interconnected world of third-party vendors and other partners most organizations rely on today.

Accountability and Security Around Third-Party Access to Data

The California Consumer Privacy Act (CCPA), and the General Data Protection Regulation (GDPR) require companies to know what third parties have received data that falls under their scope. This requirement is important from a contractual perspective—bringing needed accountability to third parties in the effort to provide an accurate notice to data subjects and, in cases involving updates or deletions of data subjects, to ensure third parties follow suit for the relevant data subjects.

As reasonable as these requirements may seem, they touch on one of the biggest weaknesses in privacy and data protection. Simply stated, companies have a hard time knowing who all their third parties are and what data they process.

In fact, it’s only in the last 15 years that companies outside of the financial services field started looking more closely at the third parties they share data with. The push for that came from the various state breach notification regulations that started coming up after California first passed stronger regulations in 2003. Breach notification elucidated the notion that accountability cannot be outsourced and therefore breaches that happen because of third parties are still the responsibility of the company.

This evolution in understanding and controlling disclosures was important, but it often focused on who the third parties were and if they got any financial information, or focused on the regulations that apply to the data in general (HIPAA, EU Directive before 2018, etc.). Companies did not concern themselves with tracking what data subjects are shared with different third parties.

A Road Map for Third-Party Accountability

The good news from a data management perspective is that there are plenty of “footprints” across the enterprise that allow companies to find out how data is being shared, even down to the data subject level. There are four aspects for tracking the disclosures of the specific data subject; two of them are easier to solve from a data management perspective, and two are more complex.

Let’s start with the low hanging fruits for tracking disclosures to third parties: email and user access. Much of the personal information that companies share with third parties is done by providing third-party users with access to systems and by emailing that information to them. While many companies are not yet trying to explore disclosure data from these sources, the information is in fact readily available. Access rights can be compared with active directory and HR systems to regularly determine when users are not employees of the company and what third party they represent; this process can be easily automated.

When it comes to personal information that leaves the organization, often via email, many companies already have experience in determining whether sensitive identifiers such as Social Security numbers are shared. There are plenty of Data Loss Prevention (DLP) tools used for detecting such sensitive information, but they’re not always suited for identity-level detection. Thankfully, technologies that are adept at finding identities in unstructured data can do a better job at this task, and correlate identities with the domains of the third parties that they are sent to.

Orchestrating Third-Party Data Management

The more complex disclosure tracking use cases typically have to do with batch transfers and the identification of downstream processors. The term “batch transfers” refers to the large volume of data that are commonly and regularly sent between companies—updated list of employees to benefits providers, lists of customers for a marketing vendor, and so on. It can be a challenge identifying who in the organization is making these disclosures in the first place, not to mention when and how. That’s because it’s rarely the case anymore that such batch transfers are centralized by IT.

The information security tools that are now commonly available in support of the secure transfer of large files allow users across the organization to make such disclosures. With that convenience comes gaps in data management and an inability to detect such transfers without resorting to surveys and questionnaires. Known batch transfers can be scanned for the data subjects they include, so the relevant third party can be associated with them.

Part of the solution involves solving the challenge of identifying how personal information flows from one third party to the next. A company’s third parties have their own third parties that take part in the processing of the data. Although it is common (and often legally required) for third parties to list their downstream processors, in reality, these lists are often incomplete or downright inaccurate. The challenge here is twofold: First, how to detect such downstream processors; second, once those processors are identified, how to track which data subjects they process so that regulatory and contractual requirements can flow down to the relevant third parties and their service providers.

Fortunately, tracking disclosures of identities to third parties rarely needs to happen in real time. The purpose, for the most part, is to keep an accurate inventory of the third parties with access to personal information, tracking the identities they receive and the obligations that corresponds to each identity (e.g., CCPA-impacted data subject below the age of 16). It is that sense of inter-company distrust that brought about the CCPA in the first place that will lead companies to require this degree of visibility into their disclosures in the near future.

Catch up on the first two articles of the blog series:

Share on social media
  • Blog Data Breach Report Oct 2024

    PKWARE November 14, 2024
  • Data Breach Report: September 2024 Edition

    PKWARE October 9, 2024
  • Data Breach Report: August 2024 Edition

    PKWARE September 6, 2024
  • Where Are the Keys? Managing Encryption in the Cloud

    PKWARE August 7, 2024
  • Blog Data Breach Report Oct 2024
    PKWARE November 14, 2024
  • Data Breach Report: September 2024 Edition
    PKWARE October 9, 2024
  • Data Breach Report: August 2024 Edition
    PKWARE September 6, 2024