In this article

Sign up for our newsletter

Share this article

Once you start collecting consumers’ data, it becomes a real challenge to keep that data all in one place. After all, you’re not just collecting data to collect data; you want to do something with it. Usually, that means sending customer data to some other system or vendor. That way, you can use it to gain marketing insights, to process transactions, to ship products, advertise more effectively, and a thousand other activities.

The trouble is, data privacy regulations give consumers the right to say what they want you to do with their data. So, when you send their data to dozens of different third parties, it’s really difficult to actually fulfill a consumers’ request.

Data subject access rights (DSAR) requests are a particular challenge. It’s already difficult to handle DSARs entirely in-house. When you transfer consumer data to third parties, however, it’s exponentially more difficult to fulfill.

In this blog, we’ll cover everything you need to know about interorganizational DSAR requests—from which laws hold you liable for vendor mismanagement to practical tips when handling DSARs of this scope. If you’re not familiar with DSAR requests in general, then you’ll want to review our DSAR guide first to ensure you’re up to date on this crucial aspect of data privacy compliance. Let’s jump in.

The laws behind interorganizational DSARs

Certain data privacy laws require you to collaborate with your vendors when fulfilling DSARs.

The GDPR is the most notable one, as it holds both you and your vendor liable for failing to fulfill a DSAR request. That’s right; you could do everything right and still be fined if your downstream data processors fail to act on a consumer’s DSAR.

The CCPA/CPRA is a bit more forgiving, though there is still plenty of opportunity for noncompliance to fall through the cracks. Under the CCPA/CPRA, so long as you and your vendor have the appropriate contractual safeguards in place, you won’t be held liable if they fail to uphold their part of the DSAR process unless you have reason to know they might not be living up to their obligations. 

However, you still need to get those contractual provisions in place, and you have to carry out the activities that those provisions obligate you to, such as taking the appropriate technical and organizational measures to set up a DSAR process that works across your vendors’ organization and your own.

That’s why it’s essential that you pick vendors with a good data privacy track record. This can be tough to assess from the outside, but there are vendor monitoring tools you can use to get a better sense of how potential vendors will treat your consumers’ data.

The challenge

Building trust

Within your own organization, you can engage in all sorts of activities to make the DSAR process work more smoothly. But once you need to start working with another organization, your options become severely limited.

At best, you can communicate a plan of action at the start of your relationship and then notify your vendor of their responsibilities when you receive a DSAR request. After that, you just have to wait and hope that they’re fulfilling their duties. Similarly, if you’re the downstream vendor to another organization and you receive a DSAR request from one of their customers, there’s little you can do besides notify your client organization and wait for instructions.

In either case, there needs to be a degree of trust between the two parties; you have to be confident that your partner will take care of their responsibilities.

To lay the foundations for that trust, it’s essential to establish DSAR responsibilities at the start of a relationship so requests can be fulfilled within the 30- or 45-day timeframe provided for by law. Data privacy laws require you to put certain contractual provisions in place with vendors who handle your customers’ personal information, so you’ll have to have a conversation around compliance anyhow.

However, these laws leave a lot of the specifics up to you and your contractual counterparty. Make sure you have a policy in place that enables you to lay out a specific DSAR workflow and that your vendors understand they are beholden to that workflow.

Managing vendor creep

Even if your team has a really solid vendor onboarding process and DSAR process in place, you’ll still face challenges fulfilling interorganizational DSARs. Specifically, other functional leaders in your organization may procure vendor relationships and tools without consulting compliance or legal.

This is where vendor creep starts to come in. One day, you might look at the different scripts running on your website and realize you have no idea what half of them are doing or where the data they’re collecting is being sent. We’ll cover some strategies and tips to cut down on vendor creep and identify which vendors receive personal information later on in this article.

Practical tips on managing interorganizational DSARs

Start off on the right foot and manage your vendor relationship

Building a strong vendor relationship requires a strong foundation and on-going maintenance. Here’s a few strategies to make your working relationship with your vendors productive and compliant.

Optimize your vendor onboarding process

The CPRA states:

A service provider or contractor that collects personal information pursuant to a written contract with a business shall be required to assist the business through appropriate technical and organizational measures in complying with [DSAR requests].

Not only should you set up your contracts appropriately when onboarding vendors, also take the opportunity to discuss what “technical and organizational measures” your vendors should employ when fulfilling DSAR requests. If you have tools, templates, or processes that you already use to manage DSAR requests, this could be a good opportunity to make recommendations.

Monitor and review vendor compliance

The CPRA also states that a business is permitted:

to monitor the contractor’s compliance with the contract through measures, including, but not limited to, ongoing manual reviews and automated scans and regular assessments, audits, or other technical and operational testing at least once every 12 months.

So, if you’re subject to the CPRA, make use of these reviews that the law provides for you. And like the CPRA, the GDPR also gives data controllers the right to audit their processors. Ask about the status of their compliance activities, inclusive of their DSAR workflow, and if you see any gaps, you can request that they make changes.

The nature of these audits is largely left up to you, so you can opt for a more informal check-in if you don’t want to be too disruptive. You can also use a tool like Osano’s Vendor Monitoring, which updates you when a vendor’s policies change or when they become subject to a lawsuit. Regardless, because you have these monitoring rights, you’re certainly better off exercising them than not.

Download our guide - Managing privacy rights: Roadmap to a mature DSAR program.

Avoid vendor creep

There are a few strategies you can deploy to minimize the chances that different teams transmit your consumers’ personal information to vendors without first consulting legal and compliance.

Keep a RoPA

For one, make sure you keep and maintain a Record of Processing Activity (RoPA) or an equivalent document.

If you’re subject to the GDPR, you’ll already have to have a RoPA in place, but even if you aren’t, keeping a document that inventories all of the data you collect and where that data lives will make compliance a significantly easier process. If you update this document every time you onboard a vendor who handles personal information, you’ll reduce the odds that data is being transferred without you knowing about it.

Send out questionnaires to different functional leads

Every quarter or so, consider sending out a compliance questionnaire to different teams across your organization. Ask whether they’ve started to handle personal information in a new way since the last time you checked in, whether they’ve changed their processes, or whether they have started using a new tool or vendor that works with personal information.

This way, you’ll be proactively seeking out information, rather than hoping that functional leads realize they need to report to you. If you hear about a new way that your colleagues are processing personal information, record that in your RoPA and take any additional steps necessary for compliance.

Always review new tools with legal and compliance

Even if it’s something small, if a new tool requires your customers’ personal information to function, you need to check in with your legal and/or compliance department. This is especially true if that tool is free—in that case, it’s likely they’re monetizing the data you provide. Make sure your colleagues understand this, too, and that your coworkers in legal and compliance have the capacity they need to swiftly review new vendors.

Ensure your IT/development team documents personal information collection

IT and development teams often have control over the organization’s website, and they may not be familiar with all of the requirements around technologies that collect personal information. Make sure they’re informed about compliance requirements and know to document when a new technology collects personal information and how that technology uses personal information.

Identify who is receiving personal information

By the time many businesses realize they need to be keeping an eye on where they’re sending consumers’ personal information, there are often already multiple data flows that haven’t been accounted for. Sometimes, this can get pretty tangled—some businesses might decide to audit their website and realize there are dozens of scripts collecting personal information and sending it to unaccounted-for third parties.

If you’ve become subject to vendor creep and aren’t sure about all of the places that you send your consumers’ personal information, there are a few approaches you can take to identify which vendors are subject to DSARs and other compliance requirements.

  • Check your privacy policy. If your privacy policy is compliant with data privacy regulations, it will state what sorts of data you collect, the reasons why you collect it, and whether you transfer that data to other organizations. It may hold some clues to help direct your search.
  • Consult your IT/development team. It may be the case that your IT and/or development team already documents where data is transferred and which technologies on your website transfer data. Even if that isn’t part of their process, they’ll be better positioned to audit your website to see what technologies are transitioning data out of the organization.
    • Look at your cookies and scripts. You can take a look directly on your website for active cookies and scripts. We’ve written about how to classify cookies and scripts in our blog “5 ways to identify cookies and scripts.” 
  • Run a report with BuiltWith. keeps a database of over 60,000 web technologies. Enter a keyword, technology name, or website, and access relevant information about that particular technology.
  • Check with your finance department. If you’re paying a vendor for their product or services, your finance department will know about it. See where you’re spending money, and identify vendors who are potential recipients of personal information.
  • Use a CMP. Many consent management platforms (CMPs), like Osano, automatically classify the cookies and scripts running on your website, quickly giving you insight into which are transferring data to third parties. Furthermore, Osano calls out niche or unique cookies and scripts that can’t be automatically identified, ensuring you know what to investigate. This reduces the chances you’ll let methods of data transfer slip through the cracks.

Most importantly: Set up a scalable DSAR process

The advice in this article will ensure that you can keep track of where you send customer data so that you can manage DSARs that require vendor collaboration. But even if you follow all of this guidance, it won’t amount to much if you treat each DSAR on a case-by-case basis.

Vendor onboarding, RoPA updates, communicating with functional leads, and the like—these activities should be conducted in parallel with the creation of a repeatable, scalable DSAR program. If you don’t know where to start with formalizing your DSAR process or suspect that your current process could use an upgrade, start with our “Setting up a DSAR process” checklist. 

The checklist walks you through the individual steps you need to take to develop a DSAR process. That way, you’ll have the foundation in place to handle more complicated DSAR requests, such as those that require vendor collaboration.

roadmap to a mature DSAR program ebook

Schedule a demo of Osano today

Privacy Policy Checklist

Are you in the process of refreshing your current privacy policy or building a whole new one? Are you scratching your head over what to include? Use this interactive checklist to guide you.

Download Now
Frame 481285
Share this article