Quick answerThird-party privacy risk is the risk that an external party processing personal data on your behalf fails to meet your obligations under privacy law. Under GDPR, POPIA and most modern privacy regimes, the controller remains responsible for processor compliance – making third-party privacy oversight a controller obligation, not an optional courtesy.
Where it shows up
- Processors and sub-processors – entities processing personal data on the controller’s behalf
- Cloud and SaaS providers – including productivity, CRM, marketing, support
- Marketing, advertising and analytics partners
- Outsourced HR, finance and IT functions
- Contractors and consultants with personal-data access
- AI vendors processing personal data through inference, training or fine-tuning
- Sub-processor cascades – the third parties your third parties use
The controller-processor model
Under GDPR Article 28 (and equivalents in POPIA, LGPD, DPDPA), a controller using a processor must ensure the processor provides ‘sufficient guarantees’ to implement appropriate technical and organisational measures. The controller-processor relationship must be governed by a written contract addressing the processing scope, security obligations, sub-processor arrangements, data subject rights assistance, breach notification and return or deletion of data at end. The controller remains accountable for the processor’s compliance – the processor is not a parallel duty-holder; it is acting on the controller’s instructions.
What good privacy oversight looks like
- Processor inventory – who processes what data, for what purpose, under what contract
- Privacy-specific due diligence – DPA in place, security measures documented, sub-processors disclosed
- DPA tracking – clauses present, signed, dated, retained
- Sub-processor traceability – at least one level down, ideally more for tier-1 processors
- Data flow documentation – what data moves, where, on what basis
- Transfer Impact Assessments where transfers leave the originating jurisdiction
- Incident notification obligations and tested response procedures
- Periodic reassessment – annual minimum for tier-1 processors
Common failure modes
- Treating processors as standard vendors without DPA-specific clauses
- Sub-processor blindness – the contract lists ‘sub-processors may be added’ without active tracking
- Annual reassessment that consists of re-sending the same questionnaire and stapling the response
- Transfer Impact Assessments performed once at contract signing and never reviewed
- Breach-notification clauses that no one operationalises
- AI vendor processors assessed with generic privacy questionnaires
The processor-as-controller risk
Some ‘processors’ act as controllers in practice – making decisions about data they shouldn’t be making, using it for their own purposes (model training, analytics, marketing). Privacy due diligence should test for this: what does the processor’s privacy notice say about its own purposes, what training opt-outs exist, what marketing flag-fields are in their platform. A ‘processor’ that is secretly a controller is a regulator problem waiting to happen.
How PrivIQ supports third-party privacy risk
PrivIQ tracks processors and sub-processors against the data map and ROPA. DPA presence and renewal dates are first-class fields. Sub-processor cascades are visible. Privacy-specific due diligence templates are pre-configured. Transfer Impact Assessments link to the relevant processor records, so transfers are not assessed in isolation.
- The controller remains accountable for processor compliance – privacy due diligence is a controller obligation.
- Sub-processor blindness is the single most common failure mode.
- Some ‘processors’ act as controllers in practice. Privacy due diligence should test for it.
- Transfer Impact Assessments need reviewing – they aren’t one-and-done.
PrivIQ helps organisations and consultants put this into practice — with policies, controls, evidence, tasks, registers and reporting that survive audit.
More on Third-Party Risk.
Do I need a DPA with every processor?
Yes. GDPR Article 28 requires a written contract addressing processing scope, security, sub-processors, rights assistance, breach notification and end-of-contract data handling. POPIA and most modern regimes require equivalents.
What about my CRM, my email provider, my Slack?
All are processors under GDPR. They all need a DPA, sub-processor disclosure and the standard privacy oversight.
How deep does sub-processor traceability need to go?
At least one level for tier-2 and tier-3 processors. For tier-1 (significant data exposure, large scale, sensitive data), aim for two or more levels – particularly where the third-party’s underlying providers (cloud, AI model) are themselves material.
What if a processor changes its sub-processors?
Most DPAs require advance notice – typically 30 days – with the controller’s right to object. In practice, controllers rarely object unless the new sub-processor introduces a clear new risk. The decision should be documented.
Can I rely on the processor’s privacy notice?
Read it carefully. Look for language about the processor’s own use of the data (model training, analytics, marketing). Where present, this either means the entity is acting as a controller in addition to a processor, or it indicates a contract that should be revisited.