LGPD and Supply Chain: The Liability Nobody Wants to Accept
In August 2021, the ANPD published its first condemnatory administrative decision. The case involved a company that transferred personal data of data subjects to a business partner without adequate legal basis and without contractual protection clauses. The controlling company was held liable — not the partner who actually processed the data inadequately.
This principle is at the heart of the LGPD: the controller is accountable for the processors it hires. The law is clear in Art. 42 — whoever causes damage through a violation of the legislation is responsible for it, regardless of who operationally processed the data.
The real problem: do you know what your vendors do with the data?
Most organizations have some form of privacy due diligence at contracting: DPA (Data Processing Agreement) clauses, security questionnaires, required certifications. The problem starts afterward.
An HR vendor that only had access to employee data starts processing customer data as well after a scope expansion. A digital marketing partner begins using data subprocessors in countries with no LGPD adequacy. A customer service system is migrated to a new cloud infrastructure without prior notification.
None of these scenarios is hypothetical — they are recurring patterns identified in privacy audits. And in all of them, the controlling company is the first to be held liable.
What the law requires — and what practice ignores
The LGPD requires the controller to: (1) establish contracts with data protection clauses with all processors; (2) verify that processors adopt adequate technical and administrative measures; (3) restrict data processing to the minimum necessary for the contracted purpose; and (4) maintain records of processing activities that include the processors involved.
In practice, many organizations have point 1 reasonably covered — contracts exist. Points 2, 3, and 4 are where most fail. Verifying that processors adopt adequate measures is not a one-time action: it is a continuous process that must be auditable.
Building privacy governance in the supply chain
The starting point is an inventory of vendors with access to personal data — separating by data category (common personal data, sensitive data, children's data) and by volume and criticality of processing. It is not necessary to treat all with the same rigor: a vendor that only accesses corporate emails has a different profile from a partner that processes customer financial data.
The second step is to structure a specific privacy assessment process — different from technical security assessment — that covers: legal basis for processing, adequacy of security measures, subprocessor policy, data location, retention period, and incident response process involving personal data.
The third step — and where most programs stop — is to create a continuous monitoring mechanism that detects relevant changes: new subprocessors, infrastructure changes, reported security incidents. Without this, the initial due diligence is merely a formal compliance exercise.
The DPO as orchestrator — not executor
In organizations with dozens or hundreds of vendors, the DPO cannot be the operational owner of each privacy assessment. Their role should be one of architecture and supervision: defining the criteria, processes, and escalation triggers. Execution needs to be distributed — but records need to be centralized.
This distinction between architecture and execution is fundamental to scaling a privacy program without proportionally increasing headcount — and this is where third-party risk management platforms with privacy dimension support make a real difference.