A controller decides why and how personal data is processed, while a processor handles data on the controller’s behalf. Under the TDPSA, controllers carry the main compliance burden, but processors still have duties to support those obligations. That distinction matters because vendor contracts, assessments, and response workflows should reflect each party’s role.
Why the TDPSA Draws a Hard Line Between Decision-Maker and Data Handler
The controller and processor roles are not just labels, they determine who owns the privacy decision, who documents the legal basis and purpose of processing, and who must answer regulators or consumers when something goes wrong. Under the TDPSA, that distinction is especially important in vendor relationships because the controller cannot outsource accountability simply by outsourcing processing.
Practically, the difference shows up in how you structure contracts, notices, and operational controls. A controller sets the purpose and essential means of processing, so it is the party that must be able to explain the data use. A processor only acts on instructions, which means its compliance posture is measured by how faithfully and securely it carries out those instructions.
That is why controller-processor terms should be mapped to the actual data flow, not to whichever party is the most visible in the transaction. If the vendor determines why data is collected or reuses it for its own purposes, it is functioning as a controller for at least part of the activity. If it only processes data for the customer’s defined purpose, it is operating as a processor.
For practitioners, the most useful test is whether the party can independently decide the purpose of processing or merely execute a documented instruction set. That distinction also affects how you review subprocessors, assess retention, and determine whether a vendor’s security obligations are contractual, operational, or both.
How That Role Split Changes Contracts, Assessments, and Incident Handling
The TDPSA distinction matters because it changes what you expect each party to do. Controllers need to own privacy notices, request handling, retention decisions, and the overall accountability model. Processors need to follow instructions, keep processing within scope, support deletion or access workflows, and help the controller meet its obligations through appropriate safeguards.
Vendor contracts should therefore be written to reflect role-specific duties, not generic security language. A well-drafted processor agreement should constrain use of personal data, define subprocessing terms, and set expectations for incident notification, deletion, and assistance with data subject requests. If those clauses are missing, the organisation may have control gaps even when the vendor is technically secure.
Assessments should also be role-aware. A processor review should focus on instruction fidelity, access limitation, subprocessor governance, and evidence that the vendor can support the controller’s compliance duties. A controller assessment should go further and test whether the business can justify collection, govern downstream uses, and prove it is not over-collecting or over-retaining personal data.
That role split becomes visible during incident response. The controller usually owns external communications and remediation decisions, while the processor must preserve evidence, notify according to contract, and cooperate quickly enough for the controller to meet its legal timelines. Slow role recognition is a common reason privacy response work stalls.
Risk and Threat Considerations
The biggest risk is role confusion: organisations treat a processor like a neutral utility, then let it make decisions that belong to the controller. That can create unauthorized processing, weak contractual control, and response failures when a breach, complaint, or deletion request arrives.
Failure mechanism: The vendor starts determining purposes, reusing data beyond instruction, or subcontracting without sufficient oversight, which breaks the controller-processor model and weakens accountability.
Impact: The organisation can face compliance exposure, harder incident containment, and disputes over who must notify, remediate, and evidence the decision trail.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-03 — Risk Management Strategy | TDPSA role split affects governance, accountability, and vendor risk ownership. |
| Recommendation — Assign role-specific privacy risk ownership and document how controller and processor duties differ. | ||
| CIS Controls v8 | 15.1 — Service Provider Management | Controller-processor relationships are operationalised through third-party contracts and oversight. |
| Recommendation — Map service-provider obligations to the processing role and verify contract terms match actual data handling. | ||
| NIST SP 800-63 | 1.4 — Identity Proofing and Registration | Privacy role assignment depends on who governs collection, use, and lifecycle of personal data. |
| Recommendation — Tie registration and lifecycle decisions to the party that sets processing purpose and means. | ||
Practitioner Guidance
What to verify: Confirm that each material data flow has a named controller, a named processor where applicable, and a contract that matches the actual processing reality. If the vendor influences purpose, retention, or reuse, reclassify the relationship before you rely on processor wording.
Decision rule: If a control failure would require the vendor to explain why the data was processed, you are looking at controller responsibility; if the vendor can only explain how it executed your instructions, you are in processor territory. Use that distinction to drive clause review, assessment depth, and escalation paths.
Practitioner takeaway: The key question is not who touches the data, but who decides its purpose and essential means, because that is what determines where accountability, evidence, and response ownership must sit.
Related resources from NHI Mgmt Group
- What is the difference between controller obligations and processor obligations under state privacy laws?
- What is the difference between a data controller and a data processor under GDPR?
- What is the difference between attack surface management and NHI governance?
- What is the difference between reviewing human access and reviewing NHIs?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
