A data subprocessor is a third party your vendor brings in to help process personal data, even though your company never deals with that party directly. Its existence is easy to miss, since it rarely appears in the main contract, yet it still touches the same data.
HelpNet Security reports that third-party involvement in data breaches has nearly doubled in a year, from 15% to almost 30%. Most vendor oversight programmes stop at the first layer, even though the real risk often sits one layer deeper.
The trouble is that data subprocessor liability is often treated as settled the moment a contract with the main vendor is signed. This article explains why that assumption is wrong and how to manage the risk properly.
What Is a Data Subprocessor?
A subprocessor appears when the vendor you appoint directly, a “data processor” in the PDP Law’s terminology, brings in another party to help with part of the work. The email marketing provider you use, for example, might store its data on a separate cloud service you’ve never heard of.
Another common example is a customer service vendor using a third-party AI chatbot tool, or a payroll vendor handing off part of its processing to a separate data-handling company. In every one of these cases, the personal data you originally entrusted to one vendor ends up flowing to a party you never appointed yourself.
A concrete version of this shows up in everyday Indonesian business practice: an online store using Midtrans or Xendit as its payment gateway, both well-known Indonesian fintech companies, is actually handing off part of its transaction data processing to card-issuing banks and payment networks the store never deals with directly.
A similar pattern shows up in logistics, where an e-commerce business using a major courier sometimes doesn’t realise deliveries in certain areas get passed to a local courier partner that also handles the recipient’s data.
Why Liability Doesn’t Stop at the First Vendor
Legally, the relationship between a controller and a processor is governed by Articles 51 to 54 of Indonesia’s Law No. 27 of 2022 on Personal Data Protection (the “PDP Law”), which confirms that processing carried out by a processor remains the controller’s responsibility.
As with the PDP Law’s other obligations, this applies extraterritorially, and while the PDP Law doesn’t use the term “subprocessor” explicitly, the same accountability principle logically extends even once data has moved one layer further from your main vendor.
By comparison, the GDPR addresses this far more explicitly through Article 28(2), which requires a vendor to obtain the controller’s prior written authorisation before engaging any subprocessor. Indonesia’s law doesn’t spell this out as firmly, but adopting the same practice is still worth doing as a precaution, not just a contract formality.
How to Find Out if Your Vendor Uses Subprocessors
Most companies only discover a subprocessor after an incident happens, even though this information can usually be dug up much earlier. Here are 3 of the most practical ways to find it.
- Ask the vendor to provide a written list of the subprocessors it uses, rather than a verbal explanation during a sales pitch.
- Check the vendor’s privacy policy or trust page, since many SaaS providers already publish their subprocessor list openly.
- Ask specific questions during due diligence, such as which cloud system stores the data or which party handles technical support behind the scenes.
4 Steps to Manage Subprocessor Risk
Managing subprocessor risk follows 4 steps in order: require notification, pass down the same contract clauses, establish a right to object, and audit regularly. Each step is explained below.
1. Require Notification Before a New Subprocessor Is Added
Add a clause requiring the vendor to notify you before adding a new subprocessor, not after that subprocessor is already actively processing data. Advance notice gives you room to assess the risk before data actually starts flowing to that new party.
2. Pass the Same Contract Clauses Down to Subprocessors
Make sure your contract requires the vendor to flow down the same data protection clauses to its subprocessors, rather than letting them operate under looser standards. Without this, the security standard can weaken every time data moves one layer further down the chain.
3. Establish the Right to Object
Your company should have the right to reject a specific subprocessor if its risk assessment looks inadequate. This matters most for sensitive data, where the risk is higher if it moves to a party with no known track record.
4. Audit the Subprocessor Chain Regularly
Schedule a review of the subprocessor list at least once a year, since a vendor can change or add subprocessors without you noticing. Regular audits stop the list you approved early on from going stale without your knowledge.
Conclusion
Data subprocessors are easy to overlook because they never appear in the main contract, yet responsibility for the data that flows to them still sits with your company. Notification clauses, consistent contract flow-down, and regular audits are what decide whether this risk is genuinely managed or just waiting to become a problem.
The longer the vendor chain gets, the bigger the blind spot a company has to keep watching. Trusting your main vendor completely without ever asking about its subprocessors just leaves that gap open without anyone noticing.
Ready to Manage Privacy Compliance as a Business Risk?
See how GRC helps map personal data risks, monitor compliance with the PDP Law, and prepare companies for audits without complicated manual processes.
FAQ
Not as explicitly as the GDPR does, but requesting written consent is still recommended as an added precaution.
Your company as the controller can still be held accountable, and the main vendor as processor also shares responsibility for the subprocessor it appointed.
There’s no explicit legal requirement to do so in Indonesia, but including that clause in a contract makes disclosure a contractual obligation even without a statutory one.
Yes, and this chain can run more than one layer deep. The same principle should still apply, with contract clauses and notification duties ideally flowing down to every additional layer.
That refusal is worth treating as a serious factor before continuing the relationship, especially for sensitive data. A genuinely transparent vendor usually has no issue disclosing this when asked in writing.
