What Is a Data Processor?
Introduced in Chapter 03: an entity that processes personal data on a Data Fiduciary's behalf, under contract, rather than for its own independent purposes. A payment gateway processing a transaction, a cloud host storing your database, and an email delivery service sending your transactional emails are all typically acting as Processors in relation to the personal data your business hands them.
Data Fiduciary vs. Data Processor
LawThe distinction turns on who decides the purpose and means of processing. If a vendor is executing your instructions for your stated purpose (send this email, store this data, process this payment), it's a Processor. If it's using the same data for its own independent purpose (say, an analytics vendor that also builds its own aggregate industry benchmarks from client data), it may be acting as an independent Fiduciary for that separate purpose — a distinction worth pinning down explicitly in the contract rather than leaving ambiguous.
Vendor Management
PracticeUnder Section 8(1), the Fiduciary remains responsible for compliance regardless of what a Processor does or fails to do — so vendor management isn't a procurement nicety, it's a direct extension of your own compliance obligations. Every vendor touching personal data belongs in the data inventory from Chapter 07, with its own record of what data it accesses, why, and under what contractual terms.
Due Diligence
- What personal data will this vendor access, and is that the minimum necessary for the service?
- What security safeguards does the vendor have in place, proportionate to the data involved?
- Does the vendor use its own sub-processors, and if so, are they disclosed and similarly vetted?
- Where is the data stored or processed — does this raise any cross-border considerations relevant to Significant Data Fiduciary obligations (Chapter 13)?
- What's the vendor's breach-notification commitment, and does it give you enough time to meet your own 72-hour reporting timeline (Chapter 10)?
Contracts
PracticeSection 8(2) requires a valid contract for engaging a Processor. In practice, a data-protection-adequate contract goes beyond a generic service agreement to specifically address: the scope and purpose of processing permitted, security obligations, sub-processor disclosure and consent, breach-notification timelines to you (fast enough for you to meet your own downstream obligations), assistance with rights requests that touch data the vendor holds, and data return or deletion obligations at the end of the relationship.
Signing a vendor's standard terms of service without reviewing whether they address data protection at all, on the assumption that "everyone uses this tool, it must be fine." A popular SaaS tool's default terms are written for their broadest customer base, not tailored to your specific DPDP obligations — the data-protection terms are usually negotiable or available as a separate addendum, but only if you ask.
Data Sharing
Sharing data with a vendor is itself processing requiring a lawful basis (Chapter 06) — if the sharing wasn't within the scope of what a Data Principal was told and consented to (or wasn't covered by an applicable legitimate use), sharing it with a new vendor for a new purpose needs its own basis, not a free pass because a contract exists.
Third-Party Processors
PracticeWhere your Processor itself uses sub-processors (a common pattern with cloud infrastructure and SaaS tools), your due diligence needs to extend one layer further — disclosure of who those sub-processors are, and confirmation they're held to comparable standards, rather than trusting your direct vendor's own assurances alone.
Cloud Providers and SaaS Vendors
These are Processors in the overwhelming majority of cases, and worth treating with the same rigour as any other vendor relationship — the fact that a cloud provider is large and well-known doesn't substitute for confirming their specific configuration (data residency, access controls, your own account's security settings) is appropriate for what you're storing with them.
Vendor Monitoring and Offboarding
PracticeDue diligence at onboarding is only half the picture — vendor relationships should be periodically reviewed (has their security posture changed, is the data they access still the minimum necessary), and offboarding needs its own checklist: confirming data is returned or genuinely deleted (not just that your subscription ended), and revoking any access credentials or API keys the vendor held. An old, unused API integration with standing access to personal data is a quiet, commonly overlooked risk.