Data fiduciary vs processor

Audience: founders, operators, vendor reviewers · Last reviewed: March 2026

See also: Compliance portal · Official resources · Guides index

Teams often blur these roles and then make bad assumptions about responsibility. The cleanest practical question is simple: who is deciding the purpose and means of processing, and who is acting within that workflow on a narrower operational basis?

Practical distinction

A data fiduciary is usually the business making the important choices. A processor is usually handling data on behalf of that business inside a more limited role. Real-world setups can still be messy, so the safest move is to review contract language, product configuration, access scope, and the actual workflow rather than relying on labels alone.

Questions that help clarify the role

• Who decided the purpose of the processing?
• Who chose the tools, data fields, and retention pattern?
• Can the vendor reuse the data for its own purposes?
• Who handles user-facing notices, complaints, and requests?
• If something goes wrong, who has to explain the workflow to the user or regulator?

Common business examples

• A SaaS company collecting customer account information for service delivery usually acts as the data fiduciary for that workflow.
• An email platform, cloud host, support tool, or CRM vendor may operate as a processor in parts of that workflow, depending on the facts and contract structure.
• If a vendor is using the data for broader independent purposes, the analysis may be less straightforward and should not be waved away casually.

Why the distinction matters

• It affects who must get notices, consent, and rights handling right.
• It shapes vendor due diligence and contract review.
• It clarifies who should maintain records, controls, and escalation paths.
• It prevents the common mistake of treating third-party tools as a responsibility shield.

Related guides