Deep-dive · Foundations 1.3
Controller, processor, sub-processor: the role each party plays decides who signs the contracts, who notifies on a breach, and who answers data-subject requests. Get it wrong and the wrong party carries the obligation. Scroll to follow the chain.
Before any architecture, settle who is who. The role each party plays is what decides who signs the data processing agreements, who must notify on a breach, and who answers a data-subject access request.
The controller sets the purpose and the means. For your own product, that is usually you. Engineers often assume they are a processor when the architecture actually makes them a controller.
A processor handles personal data on the controller's behalf and nothing more: no enriching, profiling, or deriving features from customer data unless the contract allows it. Your SaaS vendors sit here.
A sub-processor is anyone the processor brings in to help. Your cloud provider is one. So is the processor's own SaaS stack. The chain has to be visible all the way down.
Every arrow needs a DPA. Map each external system to a role, keep a per-product sub-processor registry (AWS, Datadog, Sentry, Stripe, OpenAI), and run a change-notification process: many DPAs require 30 days' notice before adding one.
AWS, GCP and Azure are sub-processors the moment they store or process customer personal data. Treating them as plumbing is how they fall off the registry and out of the RoPA.
Drop Google Analytics or a Meta Pixel onto pages handling customer data and you may become a joint controller, sharing the purpose with the third party (CJEU Fashion ID). That brings shared liability you did not plan for.