Skip to content
AuditFront
Art.29 GDPR

GDPR Art.29: Processing Under the Authority of the Controller or Processor

What This Control Requires

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.

In Plain Language

Everyone who touches personal data - your employees, your processor's staff, sub-processor personnel - must only use it for what the controller has authorised. No freelancing, no side projects with the data, no using it for purposes nobody sanctioned. Unless a law specifically compels them, the controller's instructions are the boundary.

This creates a chain of accountability from the controller through to every individual who accesses the data. If a processor steps outside those instructions and starts making their own decisions about how to use the data, they become a controller in their own right for that unauthorised processing - with all the liability that comes with it.

In practice, making this work requires clear documentation of what processing is authorised, access controls that limit who can see what, training so people understand the boundaries, and monitoring to catch violations. You can't just tell people to follow instructions and hope for the best.

How to Implement

Write clear, specific processing instructions for every processor relationship. The instructions should spell out exactly what processing is authorised, which data is in scope, where the boundaries lie, and what counts as unauthorised. Incorporate these into (or reference them from) the data processing agreement and update them whenever processing activities change.

Lock down access with role-based controls. Grant access based on job function and enforce least privilege so that each person only sees the data they need for their specific tasks. Review access permissions regularly and revoke anything that's no longer needed. Stale permissions are one of the most common sources of unauthorised access.

Train every member of staff who has access to personal data. Cover the scope of their authorised processing, what happens if they go beyond it, their confidentiality obligations, and how to report potential violations. Make the training role-specific and refresh it regularly, especially when processing activities or instructions change.

Put monitoring in place to catch unauthorised processing. Log and audit access to personal data. Watch for unusual patterns - bulk downloads, access outside normal hours, queries against data sets that aren't relevant to someone's role. Run periodic compliance checks and have clear escalation procedures when something looks wrong.

Make sure confidentiality obligations are contractually in place for everyone with data access. For employees, this is usually covered by employment contracts. For contractors and temporary staff, get confidentiality agreements signed before granting access. Processors should be able to confirm to you that all their personnel handling your data are bound by appropriate obligations.

Evidence Your Auditor Will Request

  • Documented processing instructions from controllers to processors
  • Access control matrices showing role-based access to personal data
  • Staff training records covering authorised processing scope and confidentiality
  • Monitoring and audit logs for personal data access
  • Confidentiality agreements for all personnel with access to personal data

Common Mistakes

  • Processor staff accessing personal data for purposes beyond the controller's instructions
  • No documented processing instructions, leaving ambiguity about what processing is authorised
  • Excessive access permissions allowing staff to access data beyond their job requirements
  • No monitoring or auditing of personal data access to detect unauthorised processing
  • Staff unaware of the boundaries of their authorised processing activities

Related Controls Across Frameworks

Framework Control ID Relationship
ISO 27001 A.5.15 Related
ISO 27001 A.6.1 Related

Frequently Asked Questions

What happens if a processor processes data outside the controller's instructions?
Under Article 28(10), they become a controller for that unauthorised processing. That means they take on full controller responsibilities and liabilities - including exposure to fines and claims from data subjects. It's a serious consequence, and it's designed to be. Processors who go rogue don't get to hide behind their processor status.
Can a processor refuse a controller's instructions?
They should, if the instructions would break the law. Article 28(3) requires processors to immediately flag any instruction that, in their view, would infringe the GDPR or other data protection legislation. A responsible processor won't just blindly execute an unlawful instruction - they'll push back and document their concerns.
Does this article apply to automated systems as well as people?
Yes. The principle covers all processing, whether it's a person running a query or an automated system crunching data. If your systems are configured to do analytics, profiling, or anything else beyond what the controller authorised, that's a violation regardless of whether a human triggered it.

Track GDPR compliance in one place

AuditFront helps you manage every GDPR control, collect evidence, and stay audit-ready.

Start Free Assessment