Article 28: Processor

To meet the article 28: processor requirement, you must select only third-party processors that can demonstrate “sufficient guarantees” of appropriate technical and organisational measures, and you must be able to prove you assessed those guarantees before and during the relationship. Operationalize this by embedding GDPR role/scoping, due diligence, contracting gates, and recurring evidence capture into procurement and vendor management workflows. (Regulation (EU) 2016/679, Article 28)

Key takeaways:

• Decide and document controller vs. processor roles per processing activity before you onboard a third party.
• Run risk-based processor due diligence that tests “sufficient guarantees,” then keep the evidence packet audit-ready.
• Make procurement a hard gate: no access to personal data without approved processor assurances and documented decisioning.

Article 28 is where GDPR turns third-party risk management into a legal obligation: if your organization (as a controller) has a third party process personal data on your behalf, you must choose a processor that can credibly demonstrate it will protect personal data and data subject rights. The requirement is concise, but the operational blast radius is large because it touches intake, procurement, security review, contracting, change management, and ongoing monitoring. (Regulation (EU) 2016/679, Article 28)

For a Compliance Officer, CCO, or GRC lead, the practical goal is defensibility: show that your organization consistently identifies processor relationships, assesses whether the processor provides “sufficient guarantees” (technical and organisational measures), and can produce evidence that the assessment happened before processing began and continues as the relationship changes. (Regulation (EU) 2016/679, Article 28)

This page translates Article 28(1) into a requirement-level operating playbook you can implement quickly. It focuses on the controls and artifacts examiners, customers, and supervisory authorities typically ask for: role clarity, documented assessment criteria, approval gates, and evidence retention that ties the processor to the specific processing scope. (Regulation (EU) 2016/679, Article 28)

Regulatory text

Text (excerpt): “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. Confirm you are the controller for the activity (or acting for a controller) and the third party is processing on your behalf. Article 28(1) triggers on this relationship and purpose. (Regulation (EU) 2016/679, Article 28)
2. Select only processors with “sufficient guarantees.” You need a documented basis that the processor’s technical and organisational measures are appropriate for your data and use case. (Regulation (EU) 2016/679, Article 28)
3. Ensure those measures support GDPR compliance and data subject rights. Your assessment should explicitly connect processor controls to confidentiality, integrity, availability, and the processor’s ability to support GDPR obligations that affect individuals. (Regulation (EU) 2016/679, Article 28)

Plain-English interpretation

If a third party will handle personal data for you, you cannot treat selection as a purely commercial decision. You must check that the processor’s security and governance practices are strong enough for the specific processing you are outsourcing, and you must be able to show your work later. (Regulation (EU) 2016/679, Article 28)

“Sufficient guarantees” is not a slogan. In practice, it means you define what “good enough” looks like for different risk tiers, collect evidence from the processor (not just promises), document any gaps and compensating controls, and approve (or reject) the processor based on that record. (Regulation (EU) 2016/679, Article 28)

Who it applies to

Entities

• Controllers that engage third-party processors to process personal data on the controller’s behalf. (Regulation (EU) 2016/679, Article 28)
• Teams acting for the controller: procurement, third-party risk management, security, privacy, and business owners who sponsor the relationship.

Operational contexts that commonly trigger Article 28(1)

• SaaS platforms processing customer or employee personal data (CRM, HRIS, ticketing, marketing automation).
• Cloud hosting and managed service providers with access to production environments containing personal data.
• Outsourced support, call centers, payroll, benefits administration, background checks, and analytics providers.
• Contractors/consultants who access systems or datasets with personal data as part of delivering services.

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

Step 1: Build and maintain a role-and-scope register (controller vs. processor)

Create a register that answers, for each processing activity that involves a third party:

• Your role (controller or processor) for that activity.
• Third party name and service description.
• Data categories (customer, employee, prospective customer).
• Special handling flags (children’s data, special categories, large-scale processing) as applicable to your environment.
• Systems and locations where processing occurs.
• Whether the third party is a processor (processing on your behalf) or a separate controller/joint controller (requires a different approach). (Regulation (EU) 2016/679, Article 28)

Why this matters: Article 28(1) is easy to miss when teams classify relationships as “just a vendor.” Your register becomes the source of truth for which third parties must meet processor selection requirements. (Regulation (EU) 2016/679, Article 28)

Step 2: Define “sufficient guarantees” as testable acceptance criteria

Turn legal language into review criteria your team can apply consistently. Start with:

• Technical measures: access control, authentication, encryption approach, logging/monitoring, vulnerability management, incident response, secure SDLC if the processor builds software.
• Organisational measures: security governance, staff training, background checks where relevant, policies, risk management, internal audit, vendor management (their subprocessors), and documented procedures. (Regulation (EU) 2016/679, Article 28)

Map those criteria to a risk-tier model:

• Lower-risk processing (limited data types, low impact) can accept lighter evidence.
• Higher-risk processing (production access, sensitive data, high volume) requires deeper evidence and explicit sign-off by Security/Privacy. (Regulation (EU) 2016/679, Article 28)

Practical approach: Use a standard due diligence questionnaire plus required attachments (SOC reports if available, pen test summaries if available, security policies, incident process overview). Do not accept “we are compliant” statements without underlying evidence.

Step 3: Embed a procurement gate (no PO, no access, no data) until review is complete

Operationalize Article 28(1) as a workflow gate:

1. Business owner submits third-party intake with the processing scope.
2. Privacy/GRC confirms role classification and whether the third party is a processor for this scope. (Regulation (EU) 2016/679, Article 28)
3. Security/GRC performs due diligence against your acceptance criteria.
4. Approvals recorded (approve, approve with conditions, reject).
5. Only after approval: onboarding, system access, and data sharing.

Hangup to plan for: “Shadow processors” appear when teams sign up for SaaS with a corporate card. Your gate must cover expense workflows and SSO/app catalogs, not just formal procurement.

Step 4: Document the decision in an auditable way

For each processor onboarding, produce a decision record that includes:

• Scope statement (what data, what purpose, what systems).
• Evidence reviewed (documents, attestations, reports).
• Risks found and remediation plan (including compensating controls).
• Final determination that the processor provides sufficient guarantees for this scope, or the rationale for rejection. (Regulation (EU) 2016/679, Article 28)

If you use Daydream, configure an evidence packet per processor and per processing scope so approvals, exceptions, and remediation stay linked to the requirement and can be exported for audits without manual chasing.

Step 5: Monitor and re-assess when risk changes

Article 28(1) is a selection requirement, but regulators and auditors often evaluate whether your “sufficient guarantees” conclusion stays true after change. Re-assess on triggers such as:

• Processor introduces a major subprocessors change (if relevant to your services).
• Material incident affecting confidentiality/availability.
• Significant scope change (new data categories, new regions, new system integrations).
• Contract renewal or material pricing/service changes that alter operational commitments.

Define trigger events and owners in an operating procedure so reviews happen by design, not by luck. (Regulation (EU) 2016/679, Article 28)

Required evidence and artifacts to retain

Keep a defensible “Article 28(1) evidence packet” per processor relationship:

• Role-and-scope register entry (controller/processor determination and scope).
• Completed due diligence questionnaire and supporting attachments.
• Security review notes and risk rating.
• Approval record (who approved, conditions, date).
• Exception memo(s) and compensating controls where you accepted gaps.
• Ongoing monitoring records tied to trigger events (scope changes, incidents, renewals).
• A current inventory of processors used for in-scope personal data processing.

Retention should follow your broader compliance recordkeeping rules, but the key is consistency and retrievability.

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me your processor inventory for personal data processing and how you determined each party is a processor.” (Regulation (EU) 2016/679, Article 28)
• “What does ‘sufficient guarantees’ mean in your program, and where are the acceptance criteria documented?” (Regulation (EU) 2016/679, Article 28)
• “Pick a high-risk processor. Prove the review was completed before data processing began.”
• “How do you handle exceptions, and who can approve them?”
• “What are your re-assessment triggers, and show evidence they occurred for at least one change event?”

Common hangup: teams produce a security questionnaire but cannot tie it to the actual processing scope. Auditors see that as a generic control, not Article 28(1) execution.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: No role decision, just a vendor list.
   Fix: Require a controller/processor determination in intake and store it in the register. (Regulation (EU) 2016/679, Article 28)

2. Mistake: Treating “sufficient guarantees” as a one-time checkbox.
   Fix: Define trigger-based re-assessment and document it in the operating procedure.

3. Mistake: Evidence is scattered across email, ticketing, and shared drives.
   Fix: Centralize the evidence packet per processor with clear naming and exportable records (Daydream works well as the system of record).

4. Mistake: Approving the company, not the processing.
   Fix: Tie the approval to scope, data types, and systems; require re-approval on material scope change.

Enforcement context and risk implications

No public enforcement cases were provided in the approved source catalog for this page, so this guidance does not cite specific actions. The practical risk remains: if you cannot demonstrate “sufficient guarantees” selection for processors, you can fail supervisory inquiries, customer diligence, or internal audit testing because Article 28(1) is an evidence-driven requirement. (Regulation (EU) 2016/679, Article 28)

Practical execution plan (30/60/90)

Use phases rather than fixed timelines if you need flexibility, but this structure works for most programs.

First 30 days (Immediate stabilization)

• Stand up the role-and-scope register and populate it with known high-impact processors (cloud, HR, CRM, support tooling).
• Publish acceptance criteria for “sufficient guarantees” and a minimum evidence list.
• Add an intake step that forces role classification and flags processor relationships. (Regulation (EU) 2016/679, Article 28)

Days 31–60 (Operational gates)

• Implement the procurement/onboarding approval gate in your workflow tooling (procurement system, ticketing, or GRC platform).
• Train business owners and procurement on what counts as a processor and what evidence is required.
• Establish an exception process with documented approvals and compensating controls. (Regulation (EU) 2016/679, Article 28)

Days 61–90 (Monitoring and defensibility)

• Define trigger events and launch recurring/trigger-based reviews for high-risk processors.
• Run a tabletop “audit”: select a processor and assemble the full evidence packet from intake to approval to monitoring.
• If using Daydream, configure templates for processor evidence packets, decision records, and exception workflows so the program runs with less manual follow-up.

Frequently Asked Questions

Do we have to do Article 28 due diligence for every vendor?

Do it for every third party that acts as a processor for personal data in your scope, meaning they process on your behalf. Maintain a role-and-scope register so you can separate processors from other third parties. (Regulation (EU) 2016/679, Article 28)

What counts as “sufficient guarantees” in practice?

Evidence that the processor has appropriate technical and organisational measures for your specific processing scope. Define acceptance criteria (security and governance controls) and document the evidence you reviewed and your approval rationale. (Regulation (EU) 2016/679, Article 28)

Can we rely on a processor’s marketing claims or a generic security whitepaper?

You can collect them, but you should base approval on reviewable evidence tied to your acceptance criteria. Keep a decision record that shows what you assessed and why it met your threshold. (Regulation (EU) 2016/679, Article 28)

What if a business team already onboarded a processor without review?

Treat it as an exception: document the gap, run expedited due diligence, apply compensating controls, and decide whether to continue processing. Then fix the intake/procurement gate so it cannot happen again. (Regulation (EU) 2016/679, Article 28)

How do we operationalize this across many SaaS tools?

Standardize intake questions, tier processors by risk, and require an evidence packet per processor and scope. Centralize artifacts and approvals so you can answer audits without searching across systems.

Does Article 28 apply if the third party is an independent controller?

Article 28(1) addresses processing carried out on behalf of a controller by a processor. If the third party determines purposes/means independently, treat the relationship differently and document your role decision in the register. (Regulation (EU) 2016/679, Article 28)