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

To meet the article 29: processing under the authority of the controller or processor requirement, you must ensure that every employee, contractor, and third party user who can access personal data only processes it on documented instructions from the controller, unless a Union or Member State law requires otherwise (Regulation (EU) 2016/679, Article 29). Operationalize this by hardening access control, embedding “instruction-only” rules into procedures and tooling, and retaining evidence that instructions exist, are understood, and are enforced.

Key takeaways:

• Article 29 is an “instructions + authority” control: access to personal data must map to documented, permitted purposes (Regulation (EU) 2016/679, Article 29).
• You need both governance (role decisions, procedures) and guardrails (RBAC, logging, approvals) so people can’t process outside instructions.
• Evidence matters: keep instruction records, training/acknowledgements, access approvals, and exception handling artifacts.

Article 29 is short, but it drives day-to-day operational discipline. If your people can access personal data, regulators and customers will expect you to show that access is constrained to explicit instructions, and that your workforce and subprocessors don’t “freestyle” new uses like ad hoc analytics, data sharing, or repurposing data for unrelated objectives (Regulation (EU) 2016/679, Article 29). This requirement applies whether you are a controller directing others, or a processor acting on a controller’s behalf.

For a Compliance Officer, CCO, or GRC lead, the fastest path to execution is to treat Article 29 as a control objective that must be true across identity, systems, procedures, and third party management: (1) clear role and scope decisions, (2) written processing instructions that are specific enough to operate, (3) technical and procedural controls that enforce those instructions, and (4) auditable proof you can produce on demand.

This page gives requirement-level implementation guidance you can hand to Legal, Security, IT, Procurement, and business owners without translation. It also highlights common audit questions and failure modes, plus a practical phased plan you can execute without inventing a new compliance program.

Regulatory text

Text (verbatim excerpt): “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

Operationally, Article 29 requires you to:

1. Define and communicate processing instructions from the controller that are concrete enough to constrain real work (Regulation (EU) 2016/679, Article 29).
2. Ensure everyone acting under your authority follows those instructions when they have access to personal data, including employees, temps, contractors, and third party operational users (Regulation (EU) 2016/679, Article 29).
3. Detect and stop processing outside instructions, or treat it as an exception requiring escalation and documented resolution.
4. Handle “required by law” processing as a controlled carve-out, documented and reviewed, rather than an informal justification (Regulation (EU) 2016/679, Article 29).

Plain-English interpretation (what Article 29 means in practice)

If someone can see personal data, they must have a documented reason to touch it, and that reason must trace back to the controller’s instructions. Article 29 is the bridge between contracts/policies and actual behavior. It’s also where “we’re a processor” claims get tested: processors don’t decide new purposes; they execute the controller’s instructions (Regulation (EU) 2016/679, Article 29).

Common real-world examples of “processing outside instructions”:

• Support staff exporting customer data to personal tools for troubleshooting without an approved procedure.
• Engineers pulling production datasets into a dev environment for debugging outside the approved workflow.
• A processor using customer data to improve its own product models without a controller instruction that permits it.

Who it applies to

Entities

• Controllers: You must issue instructions (contractual and operational) and ensure people acting under your authority follow them (Regulation (EU) 2016/679, Article 29).
• Processors: You must ensure your staff and operational chain only process on the controller’s instructions, and you must resist “scope creep” from internal teams who want to reuse the data (Regulation (EU) 2016/679, Article 29).

Operational contexts where Article 29 is tested

• Customer support, incident response, and fraud teams with broad data access.
• Data/analytics and ML experimentation workflows.
• Third party access (BPOs, IT admins, managed services) and subcontractor chains.
• Cross-border operations where staff in multiple jurisdictions access the same datasets.

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

Use this as a build sheet for a control that auditors can test.

Step 1: Build a “role + scope” register for Article 29

Create a simple register that answers, per processing activity/system:

• Are we controller or processor for this dataset/workflow?
• What categories of personal data are involved?
• Which systems store/process the data?
• Which teams and third parties have access pathways?

This prevents the most common failure: trying to enforce “instructions” without knowing which instructions apply to which workflow.

Daydream fit: Daydream can serve as the system of record for your role-and-scope register and tie it to evidence packets, so you can answer diligence questions consistently across business units.

Step 2: Define “instructions” in an auditable form

“Instructions” cannot live only as tribal knowledge. Put them into at least one of these artifacts:

• Controller-to-processor agreement language plus an attached schedule of processing details.
• Internal operating procedures that translate contract terms into execution steps.
• Ticket-based approvals for non-standard processing requests.

Minimum content for operational instructions:

• Purpose(s) of processing.
• Permitted operations (view, export, transform, share).
• Authorized roles (job functions), not named individuals.
• Limits on onward disclosure and tool use.
• Retention/return/deletion triggers aligned to the controller’s direction.

Step 3: Convert instructions into access control and workflow guardrails

Map each instruction set to enforceable controls:

• Role-based access control (RBAC): Access granted only to roles that need it; remove standing access where possible.
• Just-in-time access for sensitive systems: Use approvals and time-bound access for administrative or investigative work.
• Data export restrictions: Limit bulk export, require managed destinations, and log exports.
• Environment separation: Prevent routine copying of production personal data into non-production unless a defined, approved path exists.

Your test: pick a user with access and prove (a) why they have access, (b) which instruction authorizes it, and (c) what stops them from going beyond it.

Step 4: Train and bind “people acting under authority”

Article 29 explicitly includes “any person acting under the authority” who has access (Regulation (EU) 2016/679, Article 29). That includes contractors and certain third party staff with logical access.

Operational requirements:

• Training that explains “instructions-only” processing and how to escalate unclear requests.
• Written confidentiality and acceptable use commitments.
• Joiner/mover/leaver controls so access changes match role changes.

Step 5: Create an exception path for “required by law”

The law carve-out exists, but it’s easy to abuse. Treat it like a controlled exception:

• Require Legal review and documentation of the legal requirement.
• Record what data was processed/disclosed, why, and under which authority.
• Notify the controller when appropriate and permitted.

Step 6: Monitoring, detection, and response

Define “outside instruction” signals and how you respond:

• Unapproved exports, unusual query patterns, access outside normal hours.
• New tool integrations pulling personal data without review.
• Third party access not tied to a work order.

Response should include containment, investigation, and corrective actions, plus an instruction update if the business need is legitimate.

Required evidence and artifacts to retain

Keep an “Article 29 evidence packet” that you can produce quickly:

Governance

• Role-and-scope register (controller vs processor per activity/system).
• Documented operating procedure for instruction-only processing.
• Data access policy sections covering instruction compliance.

Instruction artifacts

• Controller instructions: contract schedules, DPAs, SOWs, documented written directions (Regulation (EU) 2016/679, Article 29).
• Internal mappings from instructions to systems/roles.

Access and enforcement

• Access request/approval records for privileged or sensitive systems.
• RBAC role definitions and group membership exports.
• Logs demonstrating exports/access are monitored (samples are fine if volume is large).
• Third party access lists and access reviews.

People controls

• Training completion and acknowledgement records.
• Contractor onboarding packs and confidentiality agreements.

Exceptions

• Legal-required processing records and approvals.
• Incident tickets for detected out-of-scope processing and remediation notes.

Common exam/audit questions and hangups

Expect to answer these crisply:

1. “Show me the controller’s instructions for this processing activity.” Provide contract schedule + internal SOP mapping (Regulation (EU) 2016/679, Article 29).
2. “How do you ensure employees/contractors follow instructions?” Show training + access controls + monitoring + disciplinary path.
3. “What prevents your engineers/support from exporting data?” Demonstrate technical restrictions and logged approvals.
4. “How do you handle requests that aren’t covered by current instructions?” Show an escalation and approval workflow that results in updated instructions or denial.
5. “Do third parties have access, and under what authority?” Provide access lists, contracts/SOWs, and oversight evidence.

Hangups that slow audits:

• Instructions exist, but they are too vague to map to systems.
• Access is “broad by default” and justified after the fact.
• Processor teams treat product improvement as implied permission.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails Article 29	Fix
“Instructions” only in a DPA with generic language	Not specific enough to constrain real operations	Add processing schedules and SOP mappings per system/workflow
Assuming employment = authority compliance	People still improvise under time pressure	Train + enforce with tooling, approvals, and monitoring
Treating analytics/ML as “internal use”	New purposes can exceed controller instructions	Require a documented instruction for each new use case (Regulation (EU) 2016/679, Article 29)
Third party support has standing admin access	Hard to prove access is limited to instructions	Use scoped roles, time-bound access, and ticketed work orders
“Required by law” handled informally	Creates uncontrolled disclosures	Legal-reviewed exception workflow with retained records (Regulation (EU) 2016/679, Article 29)

Enforcement context and risk implications

No public enforcement case sources were provided in the materials for this page, so this section stays requirement-focused. Practically, Article 29 failures often surface during investigations of broader issues: data misuse, unauthorized sharing, or weak access controls. When you cannot show instructions, approvals, and guardrails, you lose the ability to argue that a processing event was authorized and controlled (Regulation (EU) 2016/679, Article 29).

Practical execution plan (30/60/90-day)

You asked for speed. Use this phased plan without attaching fixed calendar claims to control maturity.

First 30 days (Immediate stabilization)

• Appoint owners: Privacy (instruction content), Security/IT (access enforcement), Procurement/Vendor (third party access).
• Build the first version of the role-and-scope register for highest-risk systems.
• Identify where instructions live today (DPAs, SOWs, internal SOPs) and centralize references.
• Freeze informal data exports: require tickets for bulk exports and privileged access until controls are in place.

Days 31–60 (Operationalize and prove)

• Publish an “Article 29 instruction-only processing” SOP with clear escalation paths.
• Implement RBAC clean-up for priority systems and remove unnecessary standing access.
• Add structured approvals for non-standard processing requests.
• Start evidence packet cadence: collect access approvals, training completion, and log samples.

Days 61–90 (Scale and harden)

• Extend scope register coverage to remaining systems and third party access pathways.
• Add monitoring rules for common out-of-scope behaviors (bulk export, unusual queries).
• Run a tabletop: simulate an auditor request for “instructions for X processing,” and verify you can produce the packet quickly.
• Formalize exception governance for “required by law” processing with Legal sign-off and retention.

Where Daydream helps: Many teams stall on evidence assembly. Daydream can structure the requirement into repeatable checklists, assign owners, and store the “instructions-to-controls-to-evidence” chain so you are not rebuilding it for every customer or regulator question.

Frequently Asked Questions

Do we need written instructions even if we are the controller?

Yes. Article 29 covers “any person acting under the authority of the controller,” so your workforce needs documented direction that constrains how they process personal data (Regulation (EU) 2016/679, Article 29).

What counts as an “instruction” that satisfies Article 29?

A controller instruction must be written and specific enough to limit purpose and permitted operations in practice, not just broad statements. Many teams implement this via contract schedules plus internal SOPs mapped to systems and roles (Regulation (EU) 2016/679, Article 29).

We’re a processor. Can we use the data to improve our product?

Only if the controller’s instructions allow that specific use. If your contracts or processing schedules do not clearly permit it, treat it as out-of-scope and route it through a formal instruction change process (Regulation (EU) 2016/679, Article 29).

How do we handle emergency support where engineers need rapid access?

Pre-define an emergency access procedure aligned to controller instructions, use time-bound access with ticketing, and retain logs and approvals. The goal is controlled speed, not informal exceptions.

Does Article 29 apply to contractors and third party support staff?

Yes if they act under the authority of the controller or processor and have access to personal data. Control it with contractual terms, onboarding/training, and scoped access tied to approved work (Regulation (EU) 2016/679, Article 29).

What’s the minimum evidence we should be able to produce in an audit?

For a sampled system, be able to show the instruction source (contract/SOP), the users/roles with access and approvals, and proof of monitoring or enforcement (for example export restrictions or log review artifacts) (Regulation (EU) 2016/679, Article 29).