Every organisation that uses external service providers to process personal data on its behalf — cloud hosting, payroll processing, email marketing, analytics, CRM, customer support tools — is a controller relying on processors. Article 28 imposes specific, non-negotiable requirements on the controller-processor relationship: the processing must be governed by a contract (the Data Processing Agreement), the processor must provide sufficient guarantees of compliance, and the controller bears ultimate accountability for ensuring those guarantees are real, not merely contractual representations.
Vendor management failures are among the most common findings in DPA investigations. Not because controllers deliberately avoid contracting with processors, but because procurement processes are not integrated with privacy compliance, DPAs are signed without understanding what they require, and processor oversight after contract signature is non-existent. This article provides the full framework for building a compliant, sustainable processor management programme.
Controller vs. Processor vs. Joint Controller
Before entering into any data sharing arrangement, the parties must correctly characterise their respective roles. The role determines the legal obligations, the contract required, and the accountability allocation. Getting the characterisation wrong — treating a joint controller as a processor, for example — produces the wrong contract and leaves a compliance gap that cannot be remedied by simply relabelling the arrangement.
ROLE CHARACTERISATION — DECISION FRAMEWORK
| Role | Definition | Test | Contract Required |
|---|---|---|---|
| Controller | Determines the purposes and means of processing | Does this party decide why and how the data is processed? | No DPA required for own processing; DPA as controller with processors |
| Processor | Processes personal data only on behalf of, and on the instructions of, the controller | Does this party process data solely because the controller instructed it to, with no independent purpose? | Article 28 DPA required; processor cannot process for own purposes |
| Joint controller | Two or more controllers jointly determine purposes and means | Do both parties influence the purpose or means of processing, not merely receive the output? | Article 26 joint controllership arrangement required; not a DPA |
| Independent controller | Receives data and processes it for own independent purposes | Does this party determine its own purposes independently, after receiving the data? | No DPA; data sharing agreement or transparency only; each party responsible for its own processing |
A common mischaracterisation is treating analytics providers, advertising platforms, and data brokers as processors when they are in fact independent controllers or joint controllers. Google Analytics, for example, operates as an independent controller for certain data it processes. Meta Pixel operates under a joint controller arrangement with the website operator. Characterising these as pure processors and executing Article 28 DPAs is incorrect and leaves the controller with an inaccurate compliance record.
Article 28 DPA: Mandatory Content
Article 28(3) specifies the minimum content that every DPA must contain. These requirements are not a checklist for negotiation — they are non-negotiable minimums. A DPA that omits any of these elements does not satisfy Article 28 regardless of how many other provisions it contains.
ARTICLE 28(3) — MANDATORY DPA CLAUSES
| Clause | What It Must Provide | Common Drafting Failure |
|---|---|---|
| Processing only on documented instructions | Processor processes personal data only on the controller’s documented instructions; processor notifies controller if instruction breaches GDPR | Clause allows processor to process for ‘legitimate business purposes’; no notification obligation for non-compliant instructions |
| Confidentiality obligations | Persons authorised to process personal data are under confidentiality obligations (contractual or statutory) | Confidentiality obligation does not extend to subcontractors; no mechanism to verify compliance |
| Security measures (Art. 32) | Processor implements appropriate technical and organisational measures per Article 32 | Generic ‘industry-standard security’ with no specifics; no obligation to demonstrate compliance on request |
| Sub-processor authorisation | Processor obtains prior specific or general written authorisation from controller for sub-processors; same obligations flow down to sub-processors | General authorisation with no notification requirement; no obligation to impose equivalent obligations on sub-processors |
| Assistance with data subject rights | Processor assists controller to fulfil data subject rights obligations; provides data for SAR fulfilment | No mechanism for processor to respond to rights requests or provide data in accessible format |
| Assistance with security, DPIAs, DPA consultation | Processor assists controller with security obligations, breach notification, DPIA requirements, and DPA consultations | Assistance is discretionary or subject to additional charges; no SLA for breach notification |
| Deletion or return at end of contract | At end of services, processor deletes or returns all personal data and certifies deletion | Option to retain data not clearly limited; certification of deletion not required |
| Audit rights and information provision | Processor provides all information necessary to demonstrate compliance; allows audits and inspections by controller or mandated auditor | Audit right limited to questionnaire responses; third-party audits prohibited; no inspection right |
Sub-Processor Management
Article 28(2) and (4) govern sub-processors — third parties that the processor engages to carry out processing activities on behalf of the controller. The controller must either specifically authorise each sub-processor or give general written authorisation (allowing the processor to engage sub-processors subject to notification obligations). Either way, the processor must ensure that sub-processors are bound by the same data protection obligations as the processor itself.
SUB-PROCESSOR AUTHORISATION MODELS
| Model | How It Works | Controller Obligation | Risk Profile |
|---|---|---|---|
| Specific authorisation | Controller approves each named sub-processor individually before engagement | Maintain approved sub-processor list; update with each change | Lowest risk; maximum control; operationally demanding for rapidly changing processors |
| General written authorisation with notification | Controller gives blanket approval subject to processor notifying any changes; controller has right to object within notice period (typically 14–30 days) | Monitor sub-processor change notifications; exercise objection right when warranted | Commercially practical; maintains oversight if notification obligation is active and monitored |
| General authorisation without monitoring | Controller signs DPA with general authorisation clause but never monitors sub-processor changes or exercises objection rights | Technically has authorisation clause but no real oversight | High risk; controller is accountable for sub-processor compliance without awareness of who they are |
The practical standard for sub-processor management is that the controller should know, at any given time, the identity of all sub-processors engaged in processing its personal data. This requires maintaining a sub-processor register and ensuring that DPAs include an effective notification mechanism with a realistic objection window. Most major SaaS providers maintain public sub-processor lists — controllers should subscribe to update notifications from all key processors.
Vendor Assessment Process
Article 28(1) requires the controller to use only processors providing ‘sufficient guarantees’ of compliance with GDPR. This is not satisfied by the processor simply signing a DPA. The controller must conduct a genuine assessment of the processor’s technical and organisational measures before engaging them and on an ongoing basis thereafter.
VENDOR PRIVACY ASSESSMENT — EVALUATION CRITERIA
| Assessment Area | What to Evaluate | Evidence to Request |
|---|---|---|
| Security certifications | ISO 27001; SOC 2 Type II; penetration testing programme; vulnerability management | Current certificates; latest pen test report (redacted); scope of ISO certification |
| Data location and transfers | Where data is stored; which countries sub-processors operate in; transfer mechanisms for non-EEA locations | Data location documentation; list of countries; SCCs or adequacy reliance for any non-EEA transfers |
| Access controls and encryption | Who has access to customer data; encryption at rest and in transit; privileged access management | Access control policy; encryption standards documentation; privileged access management evidence |
| Breach notification capability | Ability to detect, investigate, and notify the controller of a breach within 24–48 hours (to allow controller to meet 72-hour DPA obligation) | Incident response procedure; historic breach record; SLA for controller notification |
| Data subject rights support | Ability to search for, extract, restrict, and delete an individual’s data in response to controller’s direction | Data subject rights tooling; export format; deletion verification capability |
| Sub-processor transparency | Published sub-processor list; change notification process; mechanism for specific authorisation if required | Current sub-processor list; notification mechanism; update frequency |
| DPA terms | Whether vendor’s standard DPA meets Article 28(3) requirements; willingness to negotiate non-standard terms | Vendor’s standard DPA; gap analysis against Art. 28(3) requirements |
Integrating Privacy into Procurement
The most effective way to ensure that vendor management is systematic rather than reactive is to integrate privacy assessment into the procurement process as a gate that must be cleared before contract signature. A procurement gate process ensures that no new vendor can be approved without a completed privacy questionnaire and a signed DPA.
PROCUREMENT PRIVACY GATE — PROCESS STAGES
| Stage | Activity | Privacy Team Role | Procurement Gate |
|---|---|---|---|
| Vendor identification | Business team identifies a new vendor or tool; raises procurement request | Notified of new vendor; initial categorisation (processor/controller/joint) | No gate yet; information gathering |
| Privacy questionnaire | Vendor completes privacy assessment questionnaire covering security, data location, sub-processors, breach notification, rights support | Sends questionnaire; reviews responses; follows up on gaps | Gate: questionnaire must be complete before evaluation proceeds |
| DPA review | Vendor’s standard DPA reviewed; gap analysis against Art. 28(3) conducted; negotiation initiated for gaps | Leads DPA review and negotiation; red-lines non-negotiable clauses | Gate: DPA must be executed before contract signature |
| Transfer mechanism assessment | If vendor processes data outside EEA, identify transfer mechanism; complete TIA where required | Assesses adequacy; reviews SCCs; completes TIA documentation | Gate: transfer mechanism must be in place before data sharing begins |
| Approval and registration | Vendor approved; added to processor register; DPA filed; sub-processor list recorded | Updates processor register; files DPA; notes review date | No further gate; monitoring begins |
| Ongoing monitoring | Annual review of vendor’s compliance documentation; sub-processor change notifications monitored; DPA reviewed at contract renewal | Schedules annual review; processes sub-processor notifications; flags any changes requiring reassessment | Annual review; renewal gate before contract extended |
Processor Register: The Accountability Record
The processor register is the accountability record of all processor relationships. It should be maintained as a living document — updated whenever a new processor is engaged, an existing processor is terminated, a DPA is renegotiated, or sub-processor arrangements change. The register feeds directly into the RoPA, which must identify processors for each processing activity.
PROCESSOR REGISTER — MINIMUM FIELDS PER ENTRY
| Field | Content |
|---|---|
| Processor name and legal entity | Full legal name; registered address; DPO contact where applicable |
| Service description | What service the processor provides; which processing activities it carries out for the controller |
| Data categories processed | Categories of personal data shared with the processor (linked to RoPA) |
| Data subjects affected | Categories of data subjects whose data the processor handles (customers, employees, users) |
| Processing location | Countries where data is stored and processed; cloud region if applicable |
| Transfer mechanism | Adequacy decision; SCCs (version and execution date); BCRs; or EEA-only processing |
| DPA status | Date executed; version; location of signed copy; renewal date |
| Sub-processor list reference | Link to or reference to the processor’s current sub-processor list; date last reviewed |
| Security certification | Current ISO 27001 / SOC 2 certification; expiry date; scope |
| Last review date | Date of most recent compliance review; outcome; next review due |
| BITLION INSIGHT | The most common processor management gap is not the absence of DPAs — it is the absence of a maintained processor register and ongoing oversight. Many organisations execute DPAs at contract signature and never look at them again. Sub-processor lists are not monitored. Security certifications expire without renewal checks. Breach notification SLAs are never tested. A processor management programme that is alive — with annual reviews, sub-processor monitoring, and renewal gates — provides genuine compliance assurance. One that is built once and filed away does not. |