Your processor list is longer than you think

A quick confession before we start. In the previous posts in this series I deliberately stayed away from technical implementation detail, because when it comes to actual engineering I am about as useful as a chocolate soldering iron. I can tell you why something matters. The how I leave to people who actually went to the right classes.

This post is different. Sub-processors and data flows are one of the very few technical areas where I genuinely know what I am talking about. I have spent years auditing these things, arguing about them with vendors, and explaining them to regulators. So for once, consider me briefly competent.

Right. On with it.

At some point in the last year, someone on your team added an SDK. Then another one. A webhook to a third-party service. An error monitoring agent. A session recording tool. An AI API where you pipe user input and get output back.

Each of those felt like a tool decision. Each of them is also a data governance decision. And the two things rarely happened in the same conversation.

Here is the problem: under GDPR, every third party that handles your users' personal data on your behalf is a data processor. You are legally responsible for them. You need a contract with them that says specific things. If they are outside the EU, you need a legal mechanism to send data there. And if something goes wrong, regulators will ask you to account for the full chain, not just your own code.

Most teams cannot do that. Not because they are careless, but because the integrations accumulated faster than the documentation did. This is how you fix it.

Step one: find everything that touches personal data

Do not start with a spreadsheet. Start with your network traffic.

Pull every outbound destination your application connects to. Your cloud provider's network logs, your egress firewall, your monitoring tool if it has network visibility. This is the ground truth. Everything else is documentation that may or may not match what is actually running.

Then walk the codebase. Every third-party SDK initialised at startup. Every API key in your config. Every webhook endpoint registered somewhere. Every place you call an external service with a payload that contains a user identifier, an email address, user-generated content, a name, a device ID, a session token, an IP address, or anything that could be linked back to a specific person.

Make a list. You will find things you forgot about. Everyone does.

Common places builders miss:

• Your error monitoring tool. Stack traces often contain PII - email addresses in exception messages, user IDs, request bodies logged on error. Sentry, Datadog, Rollbar, all of them. Check what you are sending.
• Your AI model API. If you are forwarding user input to OpenAI, Anthropic, or any other model provider, that input probably contains personal data. Their DPA terms have evolved significantly over the last two years. The version you accepted at signup may not reflect current terms. Check again.
• Staging and dev environments. They are often connected to the same third-party tools as production, sometimes with less oversight. The data in staging is sometimes copied from production. Both matter.
• Libraries with embedded analytics. Some SDKs phone home by default. Read the changelog when you update. This is not paranoia; it has happened with widely used packages, and "we did not know the library was doing that" is not a sentence that lands well in front of a regulator.

Step two: for each integration, ask three questions

Once you have the list, go through it systematically.

Does this integration receive personal data?

If yes, it is in scope. If it only receives anonymised, aggregated data with no link back to individuals, you can deprioritise it. When in doubt, treat it as in scope.

Do you have a Data Processing Agreement with this vendor?

A DPA is a contract that establishes the rules: the vendor can only process data on your instructions, they cannot use it for their own purposes (including model training unless you agreed), they have to tell you about a breach fast enough that you can meet your own 72-hour notification deadline, and they have to delete your data when the contract ends. Most major vendors have a standard DPA you can sign or click-through. Find it, sign it, keep a copy.

Two things to actually read in the DPA before you accept it: whether the vendor can use your data to improve their own product or train their models, and what they do with your data when you stop paying. Both are frequently worse than you would assume from the marketing copy.

Where is the data being processed?

If the vendor is based outside the EU, or if they use infrastructure outside the EU, you have a cross-border transfer. For US vendors, check whether they are certified under the EU-US Data Privacy Framework - most major ones are, and it is searchable on the DPF list. The DPF survived a court challenge at the EU General Court in September 2025 and is currently valid, though an appeal to the Court of Justice is pending. If you are processing sensitive data categories, keeping Standard Contractual Clauses in your DPA alongside DPF certification is sensible given the history of this particular framework. For non-US vendors not covered by an adequacy decision, SCCs are the standard mechanism. The practical check: is there a transfer mechanism documented in the DPA, and is it current? Pre-2021 SCCs have been invalid since December 2022. If your DPA is old enough to reference those, it needs updating.

Step three: triage what you find

You will not fix everything at once. That is fine. Nobody has ever fixed everything at once. Some of those people are still trying. What matters is knowing what you have.

High priority: integrations receiving names, email addresses, user-generated content, behavioural data, or anything from a special category like health, financial, or location data. These need a current DPA and a documented transfer mechanism before anything else.

Medium priority: integrations receiving pseudonymised identifiers like internal user IDs, session tokens, or device fingerprints. Still in scope, but lower urgency if there is no direct path back to an individual without additional data.

Out of scope for now: integrations receiving only fully anonymised aggregate data with no re-identification risk. Document that you have assessed them and why they are out of scope.

For anything high priority where you do not have a DPA, find it today. Most vendors publish them in their legal or privacy section. If a vendor refuses to sign a DPA, that is a significant red flag. Personal data flowing to a processor with no DPA is a GDPR violation, not a gap you can close later.

Step four: write it down

GDPR requires most organisations to maintain a Record of Processing Activities. What you just built is the foundation of that record. For each integration: what data goes to it, why, under what legal basis, where it is processed, and what the safeguards are.

This document has two audiences. The first is a regulator, if you ever need to demonstrate your compliance posture. The second is your enterprise customers, who will ask for your sub-processor list as part of vendor due diligence. Every company selling into regulated industries will get this request. Having the answer ready is the difference between a smooth procurement process and a delayed one.

Keep it current. Add a step to your integration checklist: every time a new third-party tool goes in, the processor review goes with it. It takes twenty minutes per integration when you do it at the time. It takes considerably longer when you are doing it retrospectively across three years of accumulated tools under time pressure.

The honest version of why this matters

Regulators are not auditing most startups. The immediate enforcement risk for a small company is real but not the primary reason to do this.

The primary reason is that a breach involving data you did not know was being processed by a vendor you had not mapped is a different category of problem than a breach you can fully account for. One is an incident. The other is evidence that your data governance does not exist. Regulators, lawyers, and enterprise customers treat those very differently.

Do the audit. It is a few days of uncomfortable discovery and then you know what you actually have. That is worth considerably more than a privacy policy nobody reads.