GDPR Article 28: Processor Contracts and Vendor Vetting

Almost every organisation now processes personal data through someone else's infrastructure: a cloud provider, a ticketing SaaS, a managed SOC, a payroll platform, an email delivery service. The GDPR does not forbid this, but it puts conditions on it, and most of those conditions sit in Article 28. Legal teams usually own the contract, yet the substance of Article 28 is security: the controller must choose processors that offer "sufficient guarantees", the contract must oblige the processor to take all measures required by Article 32, and the controller must be able to verify it all through audits. This guide explains the roles, walks through each mandatory clause from a security engineer's point of view, and gives you a vendor due diligence questionnaire you can adapt.

Controller or processor: getting the roles right

Article 4(7) defines the controller as the entity that determines the purposes and means of processing. Article 4(8) defines the processor as the entity that processes personal data on behalf of the controller. The EDPB Guidelines 07/2020 on the concepts of controller and processor (version 2.0, July 2021) refine this: the controller determines the purposes and the "essential means" (which data, for how long, who has access), while a processor may decide "non-essential means" such as the choice of hardware or software.

This matters for security teams because the role determines who owes what. A managed detection provider that analyses your logs only to protect your environment is usually your processor. If the same provider reuses your telemetry to train a product for all its customers, it is deciding purposes of its own, and Article 28(10) is explicit: a processor that determines the purposes and means of processing is considered a controller for that processing.

Role assessment is a factual exercise. The label in the contract does not decide it; what the vendor actually does with the data does. Record the outcome in your records of processing activities, because Article 30(1)(d) requires you to list categories of recipients.

Article 28(1): only processors with sufficient guarantees

Article 28(1) says the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures so that the processing meets GDPR requirements and protects data subjects' rights. This is the legal hook for vendor security due diligence. "We signed their DPA" is not a guarantee; evidence of how they secure the data is.

What counts as a sufficient guarantee depends on the risk. Article 32(3) notes that adherence to an approved code of conduct or an approved certification mechanism (Articles 40 and 42) may be used as an element to demonstrate compliance with security requirements. Industry certifications and independent audit reports can also inform your assessment, but you should read their scope: a certificate that covers the vendor's corporate IT but not the production platform tells you little.

Article 28(2) and 28(4): sub-processors

Under Article 28(2), a processor must not engage another processor without prior specific or general written authorisation of the controller. With a general authorisation, the processor must inform the controller of any intended changes concerning the addition or replacement of sub-processors, giving the controller the opportunity to object.

Article 28(4) adds the flow-down rule: when a processor engages a sub-processor, the same data protection obligations set out in the controller-processor contract must be imposed on the sub-processor by contract, in particular sufficient guarantees on security. If the sub-processor fails, the initial processor remains fully liable to the controller.

For security teams, this translates into three practical controls:

1. Keep the vendor's current sub-processor list in your vendor inventory, with locations. A sub-processor in a third country may trigger a transfer analysis (see our guide to international data transfers).
2. Subscribe to the vendor's sub-processor change notifications and route them to a named owner, not a shared mailbox nobody reads.
3. Agree an objection window and a process: who evaluates the new sub-processor, and what happens if you object.

Article 28(3): the mandatory contract content

Article 28(3) requires a contract or other legal act that is binding on the processor and sets out the subject-matter and duration of the processing, its nature and purpose, the type of personal data, the categories of data subjects, and the obligations and rights of the controller. Article 28(9) requires this to be in writing, which includes electronic form. The contract must then stipulate the eight obligations in points (a) to (h).

Article 28(3) also requires the processor to immediately inform the controller if, in its opinion, an instruction infringes the GDPR or other Union or Member State data protection provisions.

Breach notification from the processor

Clause 28(3)(f) links directly to Article 33(2): the processor must notify the controller without undue delay after becoming aware of a personal data breach. The regulation does not set a number of hours for the processor. Because your own 72-hour clock under Article 33(1) runs from when you become aware, many controllers negotiate a short contractual deadline and a minimum content for the processor's notice. Our guide on breach notification within 72 hours covers how to integrate processor notices into your incident response.

Deletion at end of contract

Clause 28(3)(g) is where many offboardings fail. Ask the vendor how deletion works in primary storage, replicas, search indexes, logs and backups, and how long each takes. Get this in writing before you sign, not when you are migrating away.

Standard contractual clauses under Article 28(7)

Article 28(7) allows the Commission to lay down standard contractual clauses for controller-processor contracts. The Commission did so with Implementing Decision (EU) 2021/915 of 4 June 2021. These clauses are distinct from the transfer standard contractual clauses in Decision 2021/914, which deal with Chapter V transfers. Using the 2021/915 clauses is optional; many vendors use their own DPA template instead. Either way, the Article 28(3) content must be there.

A vendor security due diligence questionnaire

Article 28(1) due diligence works best when it is standardised and proportionate to risk. The questionnaire below is a starting point; scale the depth to the sensitivity and volume of data the vendor will handle. Keep answers and evidence in your vendor register so you can demonstrate accountability under Article 5(2).

# Vendor security due diligence - GDPR Art. 28(1) evidence
vendor: "Example Helpdesk SaaS"
role_assessment:
  gdpr_role: processor            # processor | controller | joint-controller
  rationale: "Processes support tickets only to provide the service"
  data_categories: ["contact details", "ticket content", "IP addresses"]
  special_categories: false       # Art. 9 data involved?
  data_subjects: ["customers", "employees"]
risk_tier: medium                 # drives depth of review
hosting:
  regions: ["EU (primary)", "EU (backup)"]
  remote_support_access_from: ["EEA", "third country - see transfer register"]
sub_processors:
  list_url_reviewed: true
  change_notification: "email to vendor-risk@ owner, 30-day objection window"
security_controls:
  encryption_in_transit: "TLS for all external endpoints"
  encryption_at_rest: true
  customer_managed_keys: optional
  mfa_for_admin_access: true
  sso_saml_oidc: true
  privileged_access_logging: true
  vulnerability_management: "documented patch SLAs"
  penetration_testing: "annual, summary report provided"
  backup_and_restore_tested: true   # Art. 32(1)(c)
  independent_assurance: "audit report reviewed, scope covers production"
incident_response:
  breach_notice_to_controller: "without undue delay; contractual target agreed"
  notice_content: ["nature", "categories and approx. numbers", "likely consequences", "measures taken"]
  security_contact: "security@vendor.example"
data_subject_rights:
  export_api: true
  deletion_api: true
end_of_contract:
  return_format: "JSON/CSV export"
  deletion_timeline_primary: "defined in DPA"
  deletion_timeline_backups: "defined in DPA"
  deletion_certificate: true
contract:
  dpa_signed: true
  art_28_3_clauses_present: [a, b, c, d, e, f, g, h]
  audit_right: "reports + on-site on reasonable notice"
review:
  reviewed_by: "security engineering"
  dpo_consulted: true
  next_review: "12 months or on material change"

Keeping it proportionate

A vendor that stores marketing newsletter sign-ups does not need the same scrutiny as one that hosts health records or has privileged access to your network. Define two or three risk tiers and map each to a set of required evidence. Where the processing is likely to result in high risk, the vendor assessment feeds into your DPIA.

Ongoing oversight

Article 28 is not a one-time signature. Build these into your vendor lifecycle:

• Periodic re-review of high-risk vendors, and an event-driven review on material changes (new sub-processor, new region, security incident, acquisition).
• Access hygiene: remove vendor accounts and API tokens when contracts end or projects close.
• Instruction discipline: configuration changes you make in a SaaS console are, in effect, instructions. Treat them with change control.
• Evidence retention: keep questionnaires, reports and correspondence so you can demonstrate the "sufficient guarantees" assessment later.

Remember the stakes. Infringements of controller and processor obligations under Articles 25 to 39, which include Article 28, fall under the Article 83(4) tier: up to EUR 10 million or 2% of total worldwide annual turnover, whichever is higher.

Scope of this guide

This article is technical guidance for security and IT teams on implementing GDPR processor requirements. It is not legal advice. Contract terms, role qualification and risk acceptance decisions should be confirmed with your data protection officer and legal counsel.