A sub-processor list names the other companies a vendor uses to handle your data, such as hosting, email or support tools. Review it for what each one does, what data it sees, where it runs, and how you hear about changes. A list with no purposes or regions is not enough to judge risk.
What the GDPR sets as a baseline
Under Article 28, a processor may not engage another processor without prior specific or general written authorisation from the controller. With general authorisation, the processor must tell the controller about intended additions or replacements, giving the controller a chance to object. The processor must also bind the sub-processor to the same data protection obligations, and stays fully liable to the controller if the sub-processor fails. This is general information, not legal advice. Your counsel decides what applies to you.
Columns a useful list contains
| Column | Why you want it |
|---|---|
| Name and legal entity | So you can check who they are |
| Purpose | Hosting, support tickets, email, analytics, payments |
| Data involved | Findings, account data, logs, nothing from your tenant |
| Location | Region where data is stored and where staff can access it |
| Applies to | Which product tiers or features use it |
| Date added | So you can see the change history |
If the vendor publishes only names, ask for the rest under the contract.
Five checks to run
- Does each entry have a reason? An analytics or marketing tool that receives customer tenant data is a flag. Marketing tools should see account contacts at most.
- Does any entry hold code or findings? Those are the sensitive ones. Focus your questions there.
- Where is the data, and where can people reach it from? Storage in one region with support access from another can matter to your policy.
- Is the chain flowed down? Ask how the vendor binds its sub-processors to the same terms.
- Is there an AI model provider on the list? If so, ask what data goes to it and under what retention terms. See AI features in an appsec tool: contract questions.
Change notices
Ask how you will learn of changes. Good practice is a written notice, by email to a named contact, a set number of days before the change, with a right to object. Ask what happens if you object: can you stay on the old setup, or must you leave? Put a named mailbox on the contract, not a person who may move on.
Subscribing to an RSS feed or a status page is not a notice. A notice reaches you without you checking.
Keep your own record
Save a dated copy of the list at signature and at each review. When the vendor's list changes, compare, record the decision and note who approved. If you are asked at audit how you vet third parties, this record is the evidence. For a wider vendor review, see appsec vendor security review before you buy.
How Safeguard fits
Where the answer to "who else sees our data" needs to be "nobody", a self-hosted setup helps. Safeguard deploys as SaaS, private VPC, on-prem or air-gapped. The free scan lets you review outputs before you commit data.
Quick check
Do I need to approve every sub-processor?
Not necessarily. Many contracts use general authorisation with notice and a right to object. Decide which one you want before signing.
Is a short list better than a long one?
Not by itself. A long list with clear purposes can be safer than a short one that hides a key provider. Judge by data and purpose.
Sources
Last reviewed: 19 October 2026.
