Controller, Processor Roles
In GDPR terms, a Data Processing Agreement (DPA) assigns responsibilities between parties that handle personal data. The contract language matters because GDPR obligations attach to roles, not job titles. A controller decides the purposes and means of processing, while a processor processes personal data on the controller’s behalf. A subprocessor is a processor that another processor hires for part of the processing chain.
For health-related data, the role mapping often gets messy because multiple organizations touch the same records: clinics, labs, insurers, app vendors, hosting providers, and analytics firms. A DPA helps separate “who decides” from “who performs,” which affects duties like data subject rights handling, security measures, breach notifications, and cross-border transfer steps.
Example: a clinic uses a cloud platform to store appointment data. The clinic typically decides why the data is processed (care operations) and how (workflow and access rules). The cloud vendor usually processes on the clinic’s behalf, making it a processor. If the cloud vendor uses an infrastructure provider to run storage, that infrastructure provider becomes a subprocessor in the chain.
Main Role Confusions
People often mislabel roles because the contract uses vague terms like “service provider” or “partner.” GDPR does not treat those labels as decisive. The practical test looks at decision-making: who determines the purposes and the essential means of processing, and who just carries out instructions.
Another common mistake is treating “processor” as a blanket safety label. A processor still has GDPR duties, including implementing appropriate technical and organizational measures, supporting data subject rights, and cooperating with supervisory authorities. If a vendor decides additional purposes, such as using data for its own marketing or product improvement beyond the controller’s instructions, that vendor can become a controller for those separate purposes.
Subprocessors add another dependency layer. A processor’s ability to hire subprocessors affects how quickly responsibilities flow. If the processor cannot show which subprocessors are involved, the controller cannot assess risks or verify contractual safeguards. Many DPAs also rely on a “list plus updates” approach, where subprocessors change over time and the controller receives notifications—this works only if the notification and objection mechanics are clear, and the processor actually follows them.
Supporting technologies shape the role analysis too. If a vendor runs a decision model that selects which patients receive outreach, the vendor’s role depends on who set the outreach purpose and the targeting logic. If the vendor only hosts and transmits data without deciding outcomes, the processor framing fits more naturally.
How To Draft and Review
Map Purposes and Means
Start by writing down the processing activities in plain language: what data categories are involved, what operations occur (store, transmit, analyze, delete), and what the controller’s purpose is. Then compare that to what the vendor controls. If the controller sets the workflow, access rules, retention schedule, and reporting outputs, the vendor usually acts as a processor for that scope. If the vendor decides additional purposes or uses data outside the controller’s instructions, the DPA should reflect separate roles or separate clauses.
A practical method is to attach a “processing description” exhibit to the DPA. Many teams use a one-page table with fields like data type, operation, system component, and who decides. I’ve seen teams do this in a spreadsheet versioned as “v1.3” and update it during onboarding; it reduced contract churn because both sides referenced the same exhibit during security reviews.
Control Subprocessor Flow
For subprocessors, the DPA should state how the processor handles new subprocessors: whether it provides advance notice, how long the controller has to object, and what happens if the controller objects. The contract should also require that subprocessors receive the same data protection obligations as in the DPA. A common operational pattern is a published subprocessor list plus email notifications for changes, but the DPA should specify the timing and the controller’s rights.
Look for a clear objection window. Some agreements use a short period for operational reasons, which can be frustrating for controllers that need internal review cycles. If the objection window is too short to assess impact, the controller may end up with a “no practical choice” situation, and that weakens the contract’s real-world value.
Set Security and Breach Steps
GDPR requires appropriate security measures, and the DPA should describe the baseline expectations without turning into a vague promise. Many DPAs reference security frameworks or standards, such as ISO/IEC 27001 or SOC 2 reports, but the contract should still tie measures to the processing context: encryption in transit, access controls, logging, and incident response. For breach notification, the DPA should specify timelines and the information the processor must share so the controller can meet its GDPR duties.
As a concrete check, ask whether the processor will provide enough details for the controller’s Article 33 notification: nature of the breach, categories and approximate number of data subjects and records, likely consequences, and mitigation measures. If the DPA only says “notify promptly” without minimum content, teams often end up in a back-and-forth during incidents, which delays the controller’s response.
Document Transfers and Rights
If data leaves the EEA/UK, the DPA should address international transfer mechanisms. For GDPR, this often involves Standard Contractual Clauses (SCCs) and a transfer risk assessment, depending on the scenario. The DPA should also clarify who performs which steps and how the parties cooperate. For data subject rights, the DPA should explain how the processor assists the controller with access, rectification, erasure, restriction, and objection requests, including practical timelines.
In health contexts, rights requests can be time-sensitive because records may be needed for care decisions. A DPA that lacks response coordination can create operational gaps, especially when the processor holds data in multiple systems. I’ve seen teams add a “request intake” workflow in the annex, including who receives the request and where the processor logs actions, and that reduced missed deadlines.
Case Examples With Real Constraints
Scenario 1: Clinic + Analytics Vendor. A clinic uses a vendor’s analytics dashboard to monitor appointment no-show rates. The clinic defines the purpose (care operations) and provides the dataset. The vendor configures the dashboard but also offers a separate feature that uses aggregated insights to improve its own product. In the DPA, the clinic treats the vendor as a processor for dashboard processing, while the vendor’s product improvement feature needs separate contractual terms and role clarity. If the vendor cannot show that product improvement stays within the controller’s instructions or uses anonymized data with no personal data linkage, the controller should treat that feature as a separate purpose and negotiate accordingly.
Scenario 2: Telehealth App + Hosting Chain. A telehealth provider uses a cloud hosting service. The hosting provider uses an infrastructure subprocessor for storage and a support vendor for monitoring. The telehealth provider signs a DPA that includes a subprocessor list and a notification process for changes. During review, the provider notices the DPA’s objection window is 5 business days, while internal legal review takes 3 weeks. The provider negotiates a longer objection period or a termination right tied to material changes. This is not a theoretical issue; it affects whether the controller can respond to subprocessor changes without violating contract timelines.
Subprocessor Checklist and Table
The table below helps you compare what to look for in a DPA when subprocessors are involved. It focuses on decision support, not vendor scoring.
| Item | Controller View | Processor View | What To Verify |
|---|---|---|---|
| Role clarity | Purposes and means are set by controller | Processing stays within controller instructions | DPA scope matches processing description exhibit |
| Subprocessor list | Knows who touches data | Can change vendors with controls | List exists and updates are tracked |
| Objection mechanism | Can respond to material changes | Maintains service continuity | Timing is realistic for internal review |
| Flow-down obligations | Same safeguards as DPA | Subprocessors sign equivalent terms | Contract requires equivalent protections |
| Security and breach | Receives enough incident details | Notifies per agreed timeline | DPA specifies content and response steps |
Step-by-step checklist for subprocessors:
- Write the processing chain: controller systems, processor systems, and each subprocessor component (storage, support, monitoring).
- Confirm the DPA scope matches the chain. If the DPA says “hosting only” but the vendor also runs analytics, the scope needs alignment.
- Check whether the subprocessor list is annexed or published. If it is published, verify the update method and the controller’s access to it.
- Review the objection window and termination rights. If the window is shorter than your review cycle, negotiate a workable process.
- Verify flow-down obligations: the processor must impose equivalent data protection terms on subprocessors.
- Confirm breach notification content requirements so the controller can meet GDPR notification steps.
Common Mistakes That Erode Trust
One frequent mistake is treating the DPA as a one-time signature event. Subprocessors change, security controls evolve, and processing activities expand. If the DPA lacks a change-management mechanism for subprocessors and processing scope, the contract stops reflecting reality.
Another issue is overreliance on generic “processor” language without a processing description. When the DPA does not specify what the processor does, controllers struggle to test whether the vendor stayed within instructions. This becomes a problem during audits or incident investigations, where teams need evidence of what was actually processed.
Some agreements also blur breach timelines by using ambiguous terms like “without undue delay” without defining what “delay” means operationally. During incidents, teams need a shared understanding of when notifications start, what minimum details are required, and how updates are handled.
Finally, controllers sometimes accept subprocessor lists that are too broad to be actionable. A list that names only the top-level vendor without identifying material subprocessors for storage, support, or monitoring makes it hard to assess risk. A subprocessor chain should be detailed enough to support internal governance, even if it does not list every subcontractor down to the smallest component.
FAQ
What makes a party a Controller?
A controller decides the purposes and the essential means of processing. In practice, that means it sets why personal data is processed and the core workflow choices, such as access rules and retention goals.
When does a Processor become a Controller?
A processor can become a controller for processing it performs for its own separate purposes, such as using personal data beyond the controller’s instructions. The DPA should separate those activities and role assignments.
Do subprocessors need their own DPA?
Under GDPR, the processor must impose equivalent data protection obligations on subprocessors through contract. Whether that contract is called a DPA varies, but the obligations must match the controller-processor agreement.
How should subprocessor changes be handled?
The DPA should describe advance notice or a publication mechanism, the controller’s objection rights, and what happens if the controller objects. The timeline should match the controller’s internal review capacity.
What should a DPA say about breach notices?
The DPA should specify the notification timeline and the minimum information the processor must share so the controller can assess risk and meet GDPR notification duties. It should also define how follow-up updates are handled.
Author's Insight
GDPR role classification turns on decision-making, not on contract labels. A careful DPA review treats the processing description as the anchor document, then checks whether the contract clauses match that description. Subprocessor governance is where many agreements fail in practice because objection windows, notification mechanics, and flow-down obligations get written in ways that do not match operational reality. For health-related data, teams should also align DPA terms with their incident response workflow and data subject rights handling process, since those are the parts that get tested under time pressure.
Key Takeaways
- Controller means deciding purposes and essential means; processor means processing on the controller’s behalf.
- Subprocessors are processors in the chain, and the DPA must govern how they are added, changed, and contractually bound.
- Role clarity improves when the DPA includes a processing description exhibit that both sides reference.
- Security and breach clauses should specify operational details, not only general commitments.
- Review the objection and notification mechanics for subprocessors against your internal review timelines, or the rights become theoretical.
