A subprocessor is a third party that a processor uses to help it deliver the service. If you (the controller) hire Stripe (the processor) to handle payments, and Stripe uses AWS to host its infrastructure, AWS is a subprocessor. If Stripe also uses Twilio to send fraud-alert SMS messages, Twilio is a subprocessor. The chain can run several levels deep.
GDPR Article 28(2) requires that the processor have prior written authorisation from the controller before engaging a subprocessor — either specific (named in the DPA) or general (notified in advance, with a right to object). In practice, almost every B2B SaaS vendor uses general authorisation and publishes a subprocessor list at a stable URL.
Why subprocessors matter for monitoring
The subprocessor list is the most operationally volatile artefact in a vendor's privacy stack. Where the privacy policy might change once a year and the DPA might change once every two years, a subprocessor list often changes monthly — sometimes silently. New analytics provider added. CDN swapped out. A regional support contractor brought on. Each of these changes potentially:
- Adds new countries where your data is processed.
- Adds new entities with their own breach exposure and security posture.
- Triggers a re-evaluation of the transfer impact assessment if the new subprocessor is in a non-adequate jurisdiction.
Most DPAs grant the customer a window — commonly 14 to 30 days — to object to a new subprocessor. If you don't notice the addition, the window passes, and you've implicitly accepted it.
Practical handling
Subprocessor lists come in three shapes:
- A clean HTML table with columns for entity name, location, and purpose. (Slack, Notion, Linear.)
- A PDF, sometimes 50+ pages. (Stripe's was 97 pages last we checked.)
- A buried paragraph inside the privacy policy or DPA itself, with no canonical URL. (Older or smaller vendors.)
The third case is a yellow flag during vendor selection — without a stable URL, you can't actually monitor changes.