What is sub processor and how to manage it ?

Modern digital supply chains are complex and getting even more so every day. As specialist providers of niche services emerge to address almost every business requirement imaginable, it is becoming conceivable that organizations outsource almost everything except for their core functions.

This has major economic, cybersecurity, and privacy implications. Tracking the flow of personal data through complex information flows can be challenging. Being a key requirement of "privacy-by-design" as mandated by the European Union (EU) General Data Protection Regulation (GDPR) and other regulations, though, it isn't really optional.

We have previously written about the GDPR and California Consumer Privacy Act (CCPA) and we also went in-depth on some key definitions, such as data processor and controller. But in this post, we'll elaborate on one key aspect of complying with these and similar regulations: sub-processor management.

What is a data sub-processor?

A data sub-processor is an entity that processes personal data on behalf of a data processor, under the instruction of the data controller. The sub-processor essentially extends the data processing activities of the processor and is subject to the same data protection obligations.

The GDPR explicitly defines sub-processors and mandates that they must be governed by a contract that imposes the same data protection obligations as the data processor has with the data controller. The legislation also holds sub-processors accountable for any breaches or non-compliance, and they can be directly subject to fines.

The CCPA, however, does not explicitly define sub-processors. It does discuss "service providers," though, which function similarly. Liability for sub-processors is slightly less stringent because the primary liability often rests with the "business" (akin to the data controller in GDPR), not the service provider itself.

Generally, data sub-processors do not include open source libraries or similar collections of static code which do not, by themselves process any information.

Why should I worry about data sub-processors?

Specifically with respect to the GDPR, data processors can only leverage sub-processors that:

• Are authorized by the data controller.
 
• Themselves are able to comply with the GDPR.
 
• Implement sufficient technical and organizational security measures
 
• Provide data breach notifications in case personal data is stolen or exposed.
 
• Have a contract with the processor detailing the purpose and types of processing done.

Usually, these terms are covered by a data processing addendum (DPA) between the controller and processor, as well as the processor and its sub-processors.

The CCPA has slightly less stringent requirements for service providers, but still requires:

• Notification to consumers as to how their data is transferred and, if applicable, sold.
 
• Due diligence by the processor on all sub-processors it leverages.

Furthermore, Canada's Personal Information Protection and Electronic Documents Act (PIPEDA) includes the concept of accountability, whereby you are responsible for any personal information transferred to a third party. Brazil's Lei Geral de Proteção de Dados Pessoais (LGPD) requires all processing agents to "adopt security, technical and administrative measures able to protect personal data."

Thus, tracking sub-processors, their cybersecurity posture, and compliance with relevant data privacy laws is an absolute requirement for any business subject to these requirements.

How should I track and manage data sub-processors?

If you are a data processor, having a repeatable and consistent method for keeping an inventory of your sub-processors is key to staying compliant. Under GDPR, data controllers must consent to the use of new sub-processors, so being able to provide a consolidated list of them at any given moment is a hard requirement.

While controllers can provide general authorization to processors to start using new sub-processors, they must be notified and have the ability to object. This makes having a standard operating procedure for onboarding new vendors, and optimally a technology platform that does this automatically, key to staying within the bounds of the GDPR and similar rules.

Additionally, a best practice is to maintain a single source of truth for all sub-processors that is publicly-available and referenced by all existing documents and agreements. Conflicting and outdated lists can create confusion and create serious liability if you are unable to meet the requirements of applicable data privacy laws.

Using a structured format that is easily understandable can help to answer any questions current or prospective customers might have about your sub-processors. And in the future, organizations might even use software bills of material (SBOM) to track these lists in a machine-readable manner.

What special considerations are there when using data sub-processors deploying AI tools?

With the explosion in growth of artificial intelligence (AI) tools leveraging large language models (LLMs), adhering to data privacy regulations can become even more challenging. Optimally, you would restrict sub-processors from handling personal data as much as possible and only to the extent that it is absolutely necessary.

For example, if you are conducting a market research project using a tool like ChatGPT, sanitize any personal data like emails, phone numbers, and the like. Similarly, if you are creating a marketing blog post using Jasper.ai, it's unlikely you would need to prompt the tool with people's names or contact information.

Conclusion

The rapidly evolving data privacy landscape makes compliance a continuing challenge. As requirements change - or become clarified through regulatory action - organizations need to adapt quickly to comply. Similarly to cybersecurity risk, compliance risk is something that is difficult to eliminate entirely, but having the right tools in place can mitigate it greatly.

For example, you can automatically update your sub-processors using Scrut's smartGRC functionality. By pulling data from services connected to the Scrut platform, your Trust Vault will be seamlessly updated. By seamlessly identifying sub-processors and providing this information to interested parties, you can help to meet GDPR and related requirements. Additionally, since systematically measuring and managing vendor risk is a key step in building a security program mandated by these regulations, you'll be even better equipped from a compliance perspective.
Interested in seeing how Scrut Automation can make sub-processor management easier? Schedule a demo today.