Article 29: Processing under the authority of the controller or processor

GDPR Article 29 requires you to make “instructions-only” processing real: anyone under your authority (employees, contractors, and processor staff) who can access personal data may process it only on documented controller instructions, unless EU or Member State law requires otherwise (Regulation (EU) 2016/679, Article 29). To operationalize it, you need clear role/scoping decisions, binding internal procedures, access controls aligned to instructions, and evidence that exceptions are governed and justified.

Key takeaways:

• Treat Article 29 as an operational control: instructions must be documented, communicated, and enforced in systems and workflows (Regulation (EU) 2016/679, Article 29).
• Scope is where programs fail: map who acts “under the authority” and which systems enable personal data access, including third parties and contractors.
• Keep an evidence packet: role/scoping register, instruction artifacts, access approvals, training/attestations, exception handling, and audit logs.

Article 29 is short, but it bites in audits because it sits between “paper GDPR” and the way work actually happens. Regulators and customers do not just ask whether you have a policy; they test whether people and third parties with access to personal data are constrained to approved purposes, approved datasets, and approved processing steps. Article 29 frames that constraint as a bright-line rule: no processing except on the controller’s instructions, unless a legal requirement compels otherwise (Regulation (EU) 2016/679, Article 29).

For a Compliance Officer, CCO, or GRC lead, the fastest path is to translate “instructions” into operational objects your organization already uses: ticketed requests, written SOPs, DPAs and SOWs, runbooks, access entitlements, and change approvals. Then you prove it with repeatable evidence: who is authorized, what they are allowed to do, where that permission is implemented, and how you detect and fix drift. This page gives requirement-level guidance you can hand to engineering, IT, security, HR, procurement, and vendor management to implement and defend Article 29.

Regulatory text

Text (verbatim): “The processor and any person acting under the authority of the controller or of the processor, who has access to personal data, shall not process those data except on instructions from the controller, unless required to do so by Union or Member State law.” (Regulation (EU) 2016/679, Article 29)

What the operator must do:
You must ensure that any processing of personal data by people working for you, or working for your processors, is constrained to the controller’s instructions. In practice, that means (a) instructions exist in a usable form, (b) they reach the people and systems doing the work, (c) access and workflows enforce them, and (d) any “required by law” deviation is controlled, documented, and escalated.

Plain-English interpretation (requirement-level)

Article 29 is an “authorized processing only” rule.

• If you are the controller, you must issue clear instructions that define what processing is allowed (purpose, data, systems, actions), and you must make sure people under your authority follow them.
• If you are a processor, you must ensure your staff and subprocessors only process personal data according to the controller’s instructions (typically expressed in the DPA, SOW, and operational runbooks), unless EU or Member State law requires different processing (Regulation (EU) 2016/679, Article 29).

A useful way to phrase the operational test:

“Show me where the instruction lives, who received it, what system controls enforce it, and the logs or approvals that prove it was followed.”

Who it applies to (entities and operational context)

Applies to:

• Any organization acting as a GDPR controller or GDPR processor for in-scope personal data (Regulation (EU) 2016/679, Article 29).
• Any person acting under the authority of the controller or processor who has access to personal data. That includes employees, temps, interns, contractors, and outsourced operations. It also includes processor personnel and often subcontracted support functions where they can access personal data (Regulation (EU) 2016/679, Article 29).

Common operational contexts where Article 29 must be enforced:

• Customer support tools (ticketing, chat, call recordings) where agents can view or export user data.
• Engineering and SRE access to production databases and logs.
• Marketing operations with access to contact lists and analytics exports.
• Finance and billing operations (invoices, payment-related identifiers).
• Third-party managed services (IT support, CRM admins, outsourced customer support, data labeling, fraud operations).

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

Step 1: Make a role-and-scope register specific to Article 29

Create a register that answers, for each processing area:

• Are we acting as controller, processor, or both depending on the dataset/service?
• Which data categories are in scope (customer data, employee data, end-user data)?
• Which systems store or expose that data?
• Which teams and third parties have access paths?

This directly addresses the common failure mode: processing occurs without a clear role decision and scope determination.

Minimum output: a maintained “role-and-scope register” covering systems, teams, and third parties that can access personal data.

Step 2: Define “controller instructions” in your operating model

You need a concrete definition of what counts as an instruction inside your company. Pick a small set of accepted forms and standardize them.

Typical instruction artifacts (choose what fits your environment):

• Data Processing Agreement (DPA) + annexes (services, processing details).
• Statement of Work (SOW) / Order Form (service boundaries).
• Internal SOP/runbook for a processing activity (support workflow, fraud review workflow).
• Ticket templates for ad hoc processing (data pulls, backfills, manual corrections).
• Change management approvals tied to data pipeline changes.

Control objective: staff can’t plausibly claim “we didn’t know what the controller wanted.”

Step 3: Convert instructions into enforceable access and workflow controls

Map each instruction set to “enforcement points”:

• Identity and access management: role-based access, least privilege, privileged access management for production.
• Workflow gating: approvals for exports, approvals for production access, peer review for code changes that touch personal data.
• System guardrails: logging, DLP rules for exports, masking in non-production, scoped API tokens.

You are proving that your organization doesn’t rely on goodwill. The system constrains behavior to instructions.

Practical example: If the instruction is “support may view account profile to resolve tickets but may not export full user lists,” then:

• Grant support read-only access to the support console.
• Block bulk export permissions by default.
• Require a ticket + approval for exceptional exports.
• Log and review export events.

Step 4: Put a requirement-specific operating procedure in place

Write a short Article 29 SOP that answers:

• Who owns the control (usually Privacy + Security + system owners)?
• What are the triggers (new system, new third party, new processing purpose, new support workflow, incident indicating misuse)?
• What approvals are required (privacy review, security review, business owner sign-off)?
• What is the escalation path when instructions are unclear or conflicting?

Keep it executable. Aim for a procedure a manager can follow without interpreting the GDPR.

Step 5: Train and bind “persons acting under authority”

Article 29 covers “any person acting under the authority” with access (Regulation (EU) 2016/679, Article 29). Operationalize that with:

• Confidentiality and data handling obligations in employment/contractor terms.
• Targeted training for high-access roles (support, SRE, data analysts).
• Periodic attestations for privileged access holders that they understand processing limits.

Training alone is weak evidence; pair it with enforced access controls and audit logs.

Step 6: Govern “required by Union or Member State law” exceptions

Article 29 allows processing without controller instructions when the law requires it (Regulation (EU) 2016/679, Article 29). Treat this as an exception workflow:

• Require written legal basis confirmation (from Legal) before processing.
• Record what data was processed, for what legal requirement, and who approved it.
• Notify the controller if your contract requires it (and if permitted by law). Don’t assume; align to your contractual terms.

Step 7: Build an evidence packet on a recurring cadence

For audits and customer diligence, assemble a packet that you can refresh:

• Scope/role register snapshot.
• The SOP and its last review date.
• Examples of controller instructions (redacted DPAs/SOWs, ticket templates).
• Access control exports for relevant systems (roles, group membership, privileged access list).
• Logs showing enforcement (export logs, production access logs).
• Exception records and remediation evidence when issues occurred.

Daydream can help by structuring this as an “Article 29 evidence packet” with named owners, required artifacts, and recurring refresh tasks so the control stays audit-ready without heroics.

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

Retain artifacts that show intent, implementation, and operation:

1. Role-and-scope register (controller/processor role, data categories, systems, teams, third parties).
2. Instruction sources (DPA excerpts, SOW clauses, runbooks, approved tickets).
3. Operating procedure for Article 29 controls (owners, triggers, approvals).
4. Access governance evidence (access requests/approvals, entitlement reviews, privileged access assignments).
5. Monitoring evidence (audit logs, alerts, periodic log review sign-offs).
6. Training and attestations for personnel with access to personal data.
7. Exception workflow records for “required by law” processing (legal sign-off, scope, timing, disclosures).

Common exam/audit questions and hangups

Auditors and customers tend to probe these points:

• “Show me the controller’s instructions.” Do you have a clean mapping from contracts/runbooks to actual processing steps?
• “Who counts as acting under your authority?” Contractors, outsourced support, and IT admins are the usual gaps.
• “How do you prevent ‘off-book’ processing?” Bulk exports, shadow analytics, and ad hoc scripts are typical failure paths.
• “How do you handle privileged access?” Expect scrutiny of production database access, log access, and break-glass accounts.
• “How do you handle legal demands?” They will ask for a documented workflow for legally compelled processing (Regulation (EU) 2016/679, Article 29).

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating “instructions” as a policy statement.
   Fix: Require instructions to exist as contract clauses, runbooks, and ticketable requests tied to real systems and approvals.

2. Mistake: Ignoring internal teams because “we’re the controller.”
   Fix: Article 29 covers people under the controller’s authority too (Regulation (EU) 2016/679, Article 29). Apply the same “authorized processing only” discipline internally.

3. Mistake: Over-broad access and informal exceptions.
   Fix: Default-deny bulk exports and production access. Route exceptions through documented approvals and log review.

4. Mistake: No clean story for third parties.
   Fix: Maintain a third-party access map: which third parties can access personal data, for what purpose, through what systems, and under what instruction set.

5. Mistake: “Required by law” is handled ad hoc.
   Fix: Require Legal sign-off and record the legal requirement, scope, and outputs before processing (Regulation (EU) 2016/679, Article 29).

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog, so this page does not list specific cases.

Operational risk is still concrete:

• Article 29 failures often present as unauthorized internal access, improper data exports, processor staff acting beyond contract, or unclear controller/processor boundaries.
• Those failures create downstream exposure: incident response workload, customer trust erosion, contract breaches, and regulator scrutiny if the processing deviates from documented instructions (Regulation (EU) 2016/679, Article 29).

Practical 30/60/90-day execution plan

Use phases so you can move fast without inventing timing claims.

First 30 days (stabilize and scope)

• Build the Article 29 role-and-scope register for top systems that store or expose personal data.
• Identify top access pathways: support tooling, analytics exports, production database access, third-party managed services.
• Define what counts as an “instruction” in your environment and publish the standard artifacts (templates for runbooks and data access tickets).
• Draft the Article 29 SOP with owners, triggers, and required approvals.

Days 31–60 (enforce and collect evidence)

• Align IAM roles/groups to instruction boundaries; remove broad access where it conflicts with defined instructions.
• Implement workflow approvals for exports and privileged access; ensure logs exist and are retained.
• Roll out targeted training/attestations for high-access roles and third-party operational contacts.
• Stand up the “required by law” exception workflow with Legal.

Days 61–90 (operate and prove)

• Run the first access/entitlement review against the role-and-scope register.
• Sample test: pick a few processing activities and trace instruction → access controls → logs → outputs.
• Create your recurring “evidence packet” refresh process (owner, checklist, repository).
• Track exceptions and remediation actions; ensure closure evidence is retained.

Daydream fits well here as the system of record for the register, SOP, recurring evidence packets, and exception tracking across third parties and internal operators.

Frequently Asked Questions

Does Article 29 apply to employees, or only to processors?

It applies to both. It covers “any person acting under the authority of the controller or of the processor” who has access to personal data (Regulation (EU) 2016/679, Article 29).

What qualifies as “instructions from the controller” in practice?

Use written, traceable artifacts: DPAs/SOWs, documented runbooks, and ticketed requests approved by the controller-side owner. Avoid relying on verbal direction or tribal knowledge because it is hard to defend in audits.

If we are a processor, do we need separate instructions for every task?

You need instructions that are specific enough to constrain processing to agreed purposes and methods (Regulation (EU) 2016/679, Article 29). Many teams handle this by combining contract terms with operational runbooks and change control for new processing.

How do we handle “required by Union or Member State law” processing?

Treat it as a controlled exception: get Legal confirmation of the requirement, limit scope to what is required, and document the decision and outputs (Regulation (EU) 2016/679, Article 29).

Do third-party contractors count as “persons acting under our authority”?

Yes if they act under your direction and can access personal data. Manage them with contract terms, training/attestations where appropriate, and the same access controls you apply to employees.

What evidence will a customer auditor ask for first?

Expect requests for: (1) the DPA/SOW language that defines instructions, (2) access control lists for systems with personal data, (3) samples of approvals for exports or privileged access, and (4) logs that show the controls operate.