Article 28: Processor

GDPR Article 28 requires you, as a controller, to appoint only processors that can demonstrate “sufficient guarantees” of appropriate technical and organizational measures, and to make that assurance operable through your third-party due diligence and contracting workflow. Operationalize it by defining processor acceptance criteria, running documented assessments before onboarding, and retaining evidence that your selection decision was risk-based. (Regulation (EU) 2016/679, Article 28)

Key takeaways:

• You must be able to show why each processor was trusted with personal data, based on documented “sufficient guarantees.” (Regulation (EU) 2016/679, Article 28)
• Policy language is not enough; Article 28 is executed through intake, due diligence, contracting gates, and ongoing oversight evidence.
• The fastest path is a processor “role-and-scope register” plus a standard operating procedure that forces approvals and recordkeeping.

Article 28 is where GDPR turns third-party risk management into a legal requirement. The text is short, but the operational expectation is not: you need a repeatable method to select processors who can protect data subjects’ rights through appropriate technical and organizational measures, and you must be able to prove you did it. (Regulation (EU) 2016/679, Article 28)

For a CCO or GRC lead, the practical question is: “What is the minimum defensible operating system for processor selection, and what evidence will auditors, regulators, and enterprise customers ask for?” The answer is a set of pre-onboarding controls (role classification, scope definition, and due diligence) and post-onboarding controls (monitoring, change triggers, and exception management), backed by artifacts that survive staff turnover and tool changes.

This page focuses on Article 28(1) as provided: selecting “only processors providing sufficient guarantees.” It does not assume extra clauses from Article 28 beyond the excerpt you provided, and it avoids enforcement claims not supported by your source pack. For the operator, the goal is simple: every processor relationship should produce an auditable evidence packet that ties scope, risk, controls, and approval to a specific decision.

Regulatory text

GDPR Article 28(1) excerpt (selection of processors): “Where processing is to be carried out on behalf of a controller, the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject.” (Regulation (EU) 2016/679, Article 28)

Operator meaning (what you must do):

1. Identify when a third party is acting as a “processor” (processing personal data on your behalf, under your instructions) and treat that as a gated relationship type. (Regulation (EU) 2016/679, Article 28)
2. Select only processors who can show “sufficient guarantees”—in practice, documented security and privacy controls proportionate to the processing risk and scope. (Regulation (EU) 2016/679, Article 28)
3. Be able to demonstrate your decision after the fact. Article 28(1) is a “show your work” requirement. (Regulation (EU) 2016/679, Article 28)

Primary sources: GDPR Article 28 on EUR-Lex and official text. (Regulation (EU) 2016/679, Article 28); (GDPR Official Journal Text); (Regulation (EU) 2016/679)

Plain-English interpretation (requirement-level)

If a third party will handle EU personal data for you, you cannot treat them as a generic supplier. You must have a documented basis to believe they can protect that data and support GDPR-compliant processing. “Sufficient guarantees” is not a slogan; it is the output of due diligence that is scoped to what the processor will do, the data involved, and the systems affected. (Regulation (EU) 2016/679, Article 28)

A practical way to translate “guarantees”:

• Controls: security and organizational controls that reduce likely harms (access control, incident response capability, secure development, segregation of duties, etc.).
• Governance: ownership, policies, training, and accountability for personal data handling.
• Evidence: documents, attestations, and records that support your conclusion.

Who it applies to (entity and operational context)

Applies to you when you act as a controller and you engage any third party to process personal data on your behalf. (Regulation (EU) 2016/679, Article 28)

Common operational contexts:

• SaaS platforms hosting customer data (CRM, ticketing, marketing automation)
• Cloud infrastructure and managed service providers
• Payroll, benefits, background-check providers (employee data)
• Analytics, telemetry, customer support outsourcing
• Consultants/contractors with production access

Also relevant if you are a processor selecting sub-processors, because the same selection logic is commonly flowed down contractually and operationally. Keep the scope clear: Article 28(1) in your excerpt speaks to the controller’s selection of processors. (Regulation (EU) 2016/679, Article 28)

What you actually need to do (step-by-step)

Step 1: Create a role-and-scope register (your anchor record)

Build and maintain a simple register that answers, per third party:

• GDPR role: controller / processor / joint controller / unclear (needs legal review)
• Processing purpose(s) and business owner
• Data categories (customer, employee, end user, etc.)
• Systems touched (apps, environments, storage locations)
• Access model (API, direct login, batch file exchange)
• Geography (where processing/support occurs, where data is stored)

This register is your “scope determination” evidence and prevents role drift. Your source pack flags role ambiguity as a top risk factor. (Regulation (EU) 2016/679, Article 28)

Step 2: Define “sufficient guarantees” as an acceptance standard

Write a requirement-specific standard that procurement and engineering can execute. Keep it short and testable:

• Minimum security baseline (identity, encryption expectations, vulnerability management, logging)
• Privacy baseline (data minimization expectations, retention/deletion capability, confidentiality controls)
• Operational resilience baseline (incident response readiness, escalation paths)
• Evidence requirements (what you accept as proof)

Map the standard to a common control framework your teams already use (for example, ISO 27001 Annex A or SOC 2 Trust Services Criteria). Article 28 does not name a framework, but auditors and customers will expect an organized control model rather than ad hoc questionnaires. (Regulation (EU) 2016/679, Article 28)

Step 3: Insert a hard onboarding gate in the intake workflow

Your intake must force a yes/no decision before any personal data is shared. Common gates:

• “Processor?” decision recorded in the intake ticket
• Data scope confirmed (what data, why, which systems)
• Due diligence completed and reviewed
• Exception path defined (who can approve residual risk)

If you allow “start now, paperwork later,” Article 28(1) becomes impossible to defend because the selection requirement is pre-processing. (Regulation (EU) 2016/679, Article 28)

Step 4: Perform risk-based due diligence and document the selection decision

Run diligence proportional to scope and risk. A practical pattern:

1. Collect artifacts: security documentation, privacy documentation, and independent reports if available.
2. Evaluate against your acceptance standard: record pass/fail and compensating controls.
3. Identify gaps and remediation: define actions, owners, and timelines.
4. Approve: security + privacy + business owner sign-off for higher-risk processors.
5. Record a decision memo: one page that ties scope → risks → controls/evidence → decision.

Your source pack explicitly recommends retaining decision records and evidence packets. (Regulation (EU) 2016/679, Article 28)

Step 5: Contracting alignment (make the guarantee enforceable)

Even though only Article 28(1) excerpt is provided here, operationalizing “guarantees” requires contract terms that preserve the controls you relied on during selection. At minimum, ensure the agreement:

• Identifies the processing scope in plain language (what services, what data)
• Commits the processor to maintain appropriate technical and organizational measures
• Defines audit/assurance and notification expectations aligned to your risk model

Keep this requirement-level: you are making sure the “guarantees” are not informal promises. (Regulation (EU) 2016/679, Article 28)

Step 6: Ongoing oversight and change triggers

Selection is not “set and forget.” Define trigger events that reopen diligence:

• Material product changes affecting data handling
• New data categories or expansion to production access
• Security incidents involving the processor
• Subcontracting changes that alter how processing occurs
• Renewal/expansion events

Your source pack warns about policy-only implementations that do not translate into operational controls across intake, processing, sharing, and retention. Trigger-based oversight fixes that gap. (Regulation (EU) 2016/679, Article 28)

Step 7: Centralize evidence for audits and customer diligence

Create a “processor evidence packet” per third party, updated on a recurring cadence:

• Role-and-scope record
• Due diligence outputs and reviewed artifacts
• Decision memo and approvals
• Exceptions and remediation tracking
• Contract and relevant addenda
• Ongoing monitoring notes and trigger reviews

Daydream fits naturally here: use it to standardize intake, store processor evidence packets, track exceptions, and produce audit-ready exports without chasing emails and spreadsheets.

Required evidence and artifacts to retain (audit-ready list)

Maintain these artifacts per processor relationship:

• Role-and-scope register entry (controller/processor determination, processing description, systems, data categories)
• Due diligence package (questionnaire responses, supporting documents, independent assurance reports if obtained)
• Risk assessment record (identified risks, ratings/priority, required mitigations)
• Selection decision memo (why you concluded “sufficient guarantees,” who approved, date)
• Exception approvals (documented residual risk acceptance)
• Remediation plan and closure evidence (tickets, change records, re-test notes)
• Ongoing monitoring log (trigger events, reassessments, periodic check results)

These are the items that let you prove a controlled selection process consistent with Article 28(1). (Regulation (EU) 2016/679, Article 28)

Common exam/audit questions and hangups

Expect these:

• “Show me how you determine when a third party is a processor vs. something else.” (Regulation (EU) 2016/679, Article 28)
• “List all processors with access to personal data and show the evidence that each provides sufficient guarantees.” (Regulation (EU) 2016/679, Article 28)
• “What is your minimum bar for processor security and privacy controls? Who approved it?”
• “Demonstrate the onboarding gate. Where is the control that blocks data sharing until approval?”
• “How do you handle exceptions, and how many are currently open?”
• “What events cause you to reassess a processor?”

Hangup to plan for: teams often can produce a contract but cannot produce a documented selection rationale tied to the scope at the time of onboarding.

Frequent implementation mistakes (and how to avoid them)

1. No explicit role decision. Fix: require “controller/processor/joint/unclear” selection in the intake form, with a mandatory justification field. (Regulation (EU) 2016/679, Article 28)
2. One-size due diligence. Fix: tier diligence by data sensitivity and access model; document why the chosen depth was appropriate. (Regulation (EU) 2016/679, Article 28)
3. Evidence scattered across email. Fix: store a single evidence packet per processor in a system of record (Daydream or equivalent) with version control.
4. Approval without a standard. Fix: publish an acceptance standard for “sufficient guarantees” so reviewers evaluate against criteria rather than intuition. (Regulation (EU) 2016/679, Article 28)
5. “Paper compliance” policy. Fix: implement workflow controls (gates, triggers, exception queues) and test them periodically. Your risk factors call this out directly. (Regulation (EU) 2016/679, Article 28)

Enforcement context and risk implications

No public enforcement cases were provided in your source catalog, so this page does not cite specific cases. Operationally, Article 28(1) failures tend to create downstream exposure: if a processor incident occurs, regulators and customers will ask whether you had a defensible basis for trusting that processor with personal data and whether your selection process was real, repeatable, and documented. (Regulation (EU) 2016/679, Article 28)

Practical 30/60/90-day execution plan

Use phases instead of day counts if your procurement cycles vary, but keep the sequence.

First 30 days (Immediate stabilization)

• Stand up the role-and-scope register for all existing third parties that touch personal data.
• Publish the “sufficient guarantees” acceptance standard (one page) with owners in Security and Privacy.
• Add an intake gate: no personal data shared until the role is classified and diligence is approved.
• Define the evidence packet template and a single repository location.

Days 31–60 (Operationalization)

• Tier third parties by risk and run diligence on the highest-risk processors first.
• Implement an exception process (approval authority, expiry condition, remediation tracking).
• Update procurement and legal checklists so processor onboarding cannot complete without the evidence packet.

Days 61–90 (Ongoing oversight)

• Add change triggers and integrate them with renewal, incident, and architecture change workflows.
• Run a tabletop “audit drill”: pick several processors and produce the evidence packets end-to-end.
• Automate reporting: open exceptions, processors lacking evidence, and upcoming trigger events (Daydream is a strong fit for this operational reporting).

Frequently Asked Questions

How do I decide whether a third party is a processor under Article 28?

Treat it as a documented role decision: if the third party processes personal data on your behalf and under your instructions for a defined service, classify them as a processor in your role-and-scope register. If the role is unclear, route to privacy/legal review before data sharing. (Regulation (EU) 2016/679, Article 28)

What counts as “sufficient guarantees” in practice?

“Sufficient guarantees” means you have a documented basis to believe the processor’s technical and organizational measures are appropriate for the processing scope and risks. Make it testable by defining an acceptance standard and recording what evidence met it for that processor. (Regulation (EU) 2016/679, Article 28)

Can I rely on a SOC 2 report alone to satisfy Article 28(1)?

A report can be a strong input, but Article 28(1) is about your selection decision for your specific processing scope. You still need a decision record that ties the report coverage and any gaps to your acceptance standard for that relationship. (Regulation (EU) 2016/679, Article 28)

We already have a procurement questionnaire. What do we need to add for Article 28?

Add three things: an explicit role-and-scope section, a defined “pass/fail with exceptions” acceptance standard, and a stored evidence packet with approvals. Without those, you will struggle to prove you used only processors with sufficient guarantees. (Regulation (EU) 2016/679, Article 28)

How should we handle exceptions when a processor can’t meet a control requirement?

Document the gap, the compensating controls, the residual risk acceptance, and a remediation plan with an owner. Store the exception alongside the processor’s evidence packet so you can show auditors that the decision was controlled and time-bounded. (Regulation (EU) 2016/679, Article 28)

What evidence do customers or auditors ask for first?

They usually ask for your processor inventory (role-and-scope), proof of due diligence for a sample of key processors, and the approvals/decision records that show how you concluded “sufficient guarantees.” Keep those items assembled per processor to avoid a scramble. (Regulation (EU) 2016/679, Article 28)