What are our obligations when a vendor uses subprocessors we never approved?

From a data controller's perspective, discovering an unapproved subprocessor necessitates immediate action. The initial step involves reviewing the existing data processing agreement (DPA) with the vendor to ascertain the specific clauses governing subprocessor engagement. GDPR Article 28 mandates that processors obtain prior specific or general written authorisation from the controller. If general authorisation is granted, the processor must inform the controller of any intended changes concerning the addition or replacement of subprocessors, allowing the controller to object. Failure to adhere to these terms constitutes a breach of contract and potentially a violation of data protection regulations, placing the controller at increased risk of non-compliance and associated penalties. Controllers must maintain a clear record of approved subprocessors and regularly audit or request assurances from their processors regarding compliance.

Practitioners often overlook the critical importance of robust contractual language and ongoing vendor management. A common pitfall is relying on vague DPA terms that do not explicitly define the subprocessor approval process or the controller's right to object. For DPDPA, while not explicitly mirroring GDPR's 'prior written authorisation' for subprocessors, the Data Processor is bound to process personal data strictly in accordance with the Data Fiduciary's instructions. Therefore, the Data Fiduciary's instructions, typically embedded in the contract, should explicitly address subprocessor use. Controllers should implement a vendor risk management programme that includes due diligence on all subprocessors, flow-down of data protection obligations, and clear incident response protocols for unapproved subprocessor discovery. This proactive stance is essential to mitigate legal, reputational, and financial risks associated with third-party data processing.