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

Below is a detailed, exam- and practice-oriented commentary on Article 29. I have not reproduced the bare provision. The focus is on the legal meaning, structure, practical operation, grey areas, difficult classification questions, interaction with Article 28, employee/freelancer/sub-processor issues, unlawful instructions, statutory exceptions, liability implications, and practical examples.

1. The fundamental purpose of Article 29

Article 29 is a short provision, but its practical importance is considerably greater than its length suggests.

At its core, Article 29 establishes a principle of instruction-based processing. Where an individual or organisation is processing personal data under the authority of a controller or processor, that person cannot independently decide what to do with the data. The processing must remain within the authority and instructions of the entity that has the relevant decision-making role.

The provision therefore helps preserve one of the GDPR's most important structural distinctions:

Controller → determines purposes and means

Processor → processes on behalf of the controller

Person acting under authority → carries out processing within the authority of the controller or processor

The purpose is to prevent a processor, employee, contractor or other authorised person from quietly becoming an independent decision-maker merely because they have practical access to personal data.

This is particularly important because modern processing rarely occurs through a single person. A company may determine why employee data is processed, use a cloud provider to host it, employ administrators to operate the system, use an IT consultant to troubleshoot the platform, and permit a security team to investigate incidents.

Article 29 creates a legal discipline across this chain.

The central question is:

Who has the authority to decide what happens to the personal data, and is the person actually processing it acting within that authority?

That question becomes particularly important when something goes wrong.

Example

suppose a company instructs its payroll processor to store employee salary data and calculate salaries. An employee of the processor downloads the salary database and uses it for a personal research project.

The problem is not simply that the employee has breached an internal company policy. The processing is outside the authority under which the employee was permitted to access the data. Article 29 is therefore directly relevant.

Article 29 consequently functions as a control mechanism for organisational data access.

2. Article 29 must be read together with Articles 4, 28 and 32

Article 29 should never be analysed in isolation.

Its practical meaning becomes much clearer when it is read alongside the GDPR's rules concerning controllers, processors, processor contracts and security.

Article 4

Article 4 establishes the foundational concepts of:

• controller;

• processor;

• processing;

• personal data.

The distinction between controller and processor is particularly important.

A controller determines the purposes and means of processing. A processor processes personal data on behalf of the controller.

Article 29 operates downstream from this distinction.

Article 28

Article 28 governs the relationship between controller and processor.

It imposes substantial obligations concerning:

• selection of processors;

• contractual arrangements;

• documented instructions;

• confidentiality;

• security;

• sub-processors;

• assistance to the controller;

• deletion or return of data;

• audits and inspections.

Article 29 then operates at the level of the persons actually carrying out processing under that authority.

This creates an important distinction:

Article 28 primarily regulates the controller-processor relationship.

Article 29 directly regulates processing carried out under that authority.

This is why it would be incorrect to treat Article 29 as merely another contractual requirement.

3. Article 29 is directly applicable

One of the most important points about Article 29 is that its obligation is directly imposed by the GDPR.

The parties do not have to insert a special contractual clause before the obligation exists.

Example

assume:

Company A appoints Company B as a processor.

Company B employs Employee X.

The processor agreement between A and B contains no specific sentence saying:

"Employee X shall process personal data only in accordance with instructions."

Article 29 nevertheless applies.

The absence of contractual wording does not eliminate the statutory obligation.

This is important because GDPR compliance cannot be reduced to contract drafting.

A company cannot say:

"We forgot to put the instruction requirement in the employment contract, therefore Article 29 does not apply."

It does apply.

The contract may strengthen, clarify or operationalise the obligation, but it does not create the obligation in the first place.

4. Who is actually covered?

Article 29 identifies two broad categories.

First, it covers the processor.

Second, it covers persons acting under the authority of the controller or processor who have access to personal data.

The second category is where many of the difficult questions arise.

The phrase "any person" is deliberately broad.

It can potentially include:

• employees;

• temporary staff;

• authorised administrators;

• internal IT personnel;

• certain consultants;

• certain freelancers;

• persons working under comparable authority arrangements;

• persons acting under the processor's authority;

• persons working for sub-processors.

The critical issue is not simply the person's job title.

The real question is whether that person is acting under the authority of the controller or processor in relation to the processing.

5. "Access" is broader than actual viewing

One of the most important practical nuances is that "access to personal data" should not be interpreted as requiring actual viewing of the data.

The relevant concept is the possibility of access.

Consider an employee who administers a database.

The employee has technical permissions capable of exposing customer records but never actually opens a customer record.

It would be artificial to say Article 29 does not apply because the employee did not happen to view the information.

The potential ability to access the data is sufficient.

This matters enormously for cybersecurity and access-control systems.

For example:

A cloud administrator has privileged credentials that technically allow access to a database containing millions of customer records.

The administrator does not inspect any customer records.

The administrator is still a person with access to personal data.

Similarly, a software engineer may have production-system privileges that permit access to user information even though their ordinary work involves only troubleshooting.

The legal significance of access therefore cannot be reduced to evidence of actual data consumption.

6. Why the concept of "mere possibility of access" matters

Suppose an organisation adopts the following argument:

"Our IT administrator never actually looked at the employee database, so Article 29 did not apply to him."

That is the wrong approach.

If the administrator had the ability to access the database, the GDPR's concern already exists.

This is also consistent with the broader GDPR principle that security and governance must operate preventively.

An organisation should not wait until someone actually misuses data before recognising that the person was subject to appropriate controls.

The practical consequence is that organisations should identify:

• who can access personal data;

• what categories of data they can access;

• why they have that access;

• what instructions govern their access;

• whether confidentiality obligations exist;

• whether access is technically restricted;

• whether access is logged;

• whether access is periodically reviewed.

Article 29 therefore has an important connection with Article 32 and general access-control practices.

7. Employees are normally not separate processors

A particularly important distinction concerns employees.

An employee working within a controller's organisation will generally not become a separate controller or processor merely because the employee processes personal data.

Example

an HR employee accesses employee records to administer salaries.

The employee does not normally become:

• a separate controller; or

• a processor.

The employee is generally acting under the authority of the controller.

The same principle applies within a processor organisation.

Suppose a payroll company processes employee data on behalf of Company A.

An employee of the payroll company accesses the payroll database to perform payroll calculations.

That employee is generally not independently a processor.

The employee is acting under the processor's authority.

This prevents the GDPR from artificially multiplying the number of controllers and processors within an organisation.

8. The employee's authority is the critical concept

The employee does not have unlimited freedom simply because they are employed by the organisation.

The employee's authority must be connected to the processing.

Imagine:

A hospital employee is authorised to access patient information for administrative purposes.

The employee becomes curious about a celebrity patient and accesses that patient's medical file.

The employee's employment relationship with the hospital does not automatically authorise the processing.

The employee had authority to perform certain functions, not to satisfy personal curiosity.

This distinction is fundamental:

Employment relationship ≠ unlimited authority to process personal data.

The scope of authority matters.

Article 29 therefore operates through the concept of functional authority.

9. What does "acting under the authority" actually mean?

The phrase requires more than the existence of some superficial relationship.

There must generally be a relationship in which the controller or processor has authority over the person's processing of personal data.

Relevant factors may include:

• the contractual relationship;

• organisational integration;

• degree of independence;

• instructions given;

• supervision;

• reporting structure;

• nature of the work;

• ability to determine purposes and means;

• confidentiality arrangements;

• degree of operational autonomy.

This becomes difficult with consultants and freelancers.

10. The difficult freelancer problem

Consider a company that hires a freelance IT specialist.

The freelancer occasionally enters the company's systems to troubleshoot software.

The freelancer may have access to employee personal data.

What is the freelancer?

There are at least two possibilities.

Possibility 1: The freelancer is a person under authority

This may be appropriate where the freelancer is sufficiently integrated into the organisation and operates under the company's instructions.

Possibility 2: The freelancer is a processor

If the freelancer independently provides a processing service on behalf of the company and processes personal data as part of that service, Article 28 may become relevant.

This classification cannot safely be determined merely by asking:

"Is the person called a freelancer?"

The label is not decisive.

The substance of the relationship matters.

11. Independence is a major classification factor

Suppose two consultants both have access to employee data.

Consultant A:

• works under daily instructions;

• uses company systems;

• follows company procedures;

• has no independent decision-making authority;

• performs tasks integrated into the company's operations.

Consultant B:

• operates an independent technology service;

• determines how the service is technically performed;

• provides processing services to multiple clients;

• has significant operational independence;

• determines substantial elements of how the processing is carried out.

It becomes much more plausible that Consultant B is operating as a processor rather than merely as a person under the controller's authority.

This is why independence is an important factor.

12. The danger of misclassifying a processor as a person under authority

This is one of the most important practical traps.

An organisation should not call an external service provider a "person acting under authority" simply to avoid Article 28.

Suppose Company A hires an independent cloud analytics provider.

The provider stores and analyses personal data for Company A.

Company A cannot necessarily avoid entering into an Article 28 arrangement by declaring:

"The cloud provider is simply acting under our authority."

If the relationship substantively constitutes a processor relationship, Article 28 applies.

Article 29 should therefore not become a loophole for avoiding processor obligations.

This is especially important for:

• cloud providers;

• SaaS providers;

• outsourced HR providers;

• payroll providers;

• marketing service providers;

• customer-support providers;

• IT managed-service providers;

• data analytics providers.

13. Sub-processors and Article 29

Article 29 can also apply in the sub-processing chain.

Consider:

Controller → Processor → Sub-processor → Employees of sub-processor

The original processor remains responsible for appropriately managing its relationship with the sub-processor under Article 28.

At the operational level, people working within the sub-processor may themselves be persons acting under the sub-processor's authority.

The existence of Article 29 does not eliminate Article 28 obligations.

Both provisions may operate simultaneously at different levels.

This is an important structural point:

Article 28 regulates the organisational relationship.

Article 29 controls the behaviour of persons processing within that structure.

14. Article 29 and confidentiality

Article 29 should also be read alongside the confidentiality requirements under Article 28.

An organisation should ensure that persons authorised to process personal data are subject to appropriate confidentiality obligations.

This is particularly important because instruction-following and confidentiality address different risks.

Consider an employee who is instructed to process customer data only for customer support.

The employee may comply with the instruction but disclose the information to a friend.

The problem involves confidentiality.

Conversely, an employee may keep the information confidential but use it for an unauthorised personal purpose.

That raises the Article 29 instruction issue.

Therefore:

Instruction compliance and confidentiality are complementary safeguards.

They are not interchangeable.

15. What constitutes an "instruction"?

Article 29 does not prescribe a particular format for instructions.

An instruction can concern:

• what data may be processed;

• why it may be processed;

• who may access it;

• how it may be accessed;

• what systems may be used;

• how long it may be retained;

• whether it may be copied;

• whether it may be transferred;

• whether it may be disclosed;

• technical and organisational measures;

• deletion;

• incident handling;

• responding to data-subject requests.

Instructions can therefore be operational as well as conceptual.

For example:

"Use the customer database only to respond to customer support requests."

is an instruction.

So is:

"Do not download customer records to local devices."

So is:

"Delete temporary troubleshooting files after completing the task."

So is:

"Only authorised members of the security team may access the incident database."

16. Instructions should be sufficiently clear

Although Article 29 does not prescribe a detailed formal structure for every instruction, vague instructions create substantial compliance risk.

Consider:

"Process customer data appropriately."

This provides little operational guidance.

Compare:

"Access customer records only where necessary to resolve a support ticket assigned to you. Do not export, download or retain copies outside the approved customer-support platform."

The second instruction is much more useful because it establishes boundaries.

Good instructions should ideally answer:

• What may be done?

• Why may it be done?

• With which data?

• By whom?

• Through which system?

• For how long?

• What is prohibited?

• What happens when the task ends?

17. Documentation is extremely important

From a governance perspective, instructions should generally be documented.

Why?

Because disputes frequently arise after an incident.

Imagine a processor employee exports a database.

The employee says:

"My manager told me this was permitted."

The manager says:

"I never authorised that."

Without documentation, determining the scope of authority becomes difficult.

Documented instructions therefore create evidence concerning:

• authorised purposes;

• permitted operations;

• access limits;

• deletion requirements;

• security requirements;

• escalation procedures.

This is especially important in high-risk processing environments.

18. Does every employee have to independently assess GDPR lawfulness?

Generally, the GDPR does not expect every employee who performs an authorised processing task to conduct an independent legal analysis of whether the controller's instruction complies with every GDPR requirement.

Example

a customer-service employee receiving an instruction to update a customer's address would not ordinarily be expected to conduct a complete Article 6 lawful-basis analysis before entering the information.

The organisation has governance responsibilities for determining the lawfulness of its processing.

However, this principle has limits.

A person cannot rely indefinitely on an instruction that is obviously unlawful.

This creates an important distinction between:

ordinary instructions that the person reasonably relies upon, and

manifestly unlawful instructions that should trigger escalation or refusal.

19. The difficult issue of unlawful instructions

This is one of Article 29's most interesting grey areas.

Suppose a processor receives an instruction from a controller:

"Send the entire customer database to my personal email address."

The processor's employee might immediately recognise that something is seriously wrong.

Article 29 cannot sensibly be understood as requiring blind obedience to obviously unlawful conduct.

The better approach is escalation.

The person should raise the issue through appropriate channels, particularly where the instruction conflicts with applicable law, contractual restrictions, security requirements or clearly established GDPR obligations.

For processors, Article 28 is especially important because the processor must inform the controller if, in its opinion, an instruction infringes the GDPR or other applicable data protection law.

Therefore, Article 29 should not be interpreted as establishing a doctrine of blind obedience.

It establishes controlled processing under authority.

20. Article 29 is not a "blind obedience" rule

This is an important exam and practical distinction.

The logic is not:

Controller says X → processor must always do X.

The correct logic is closer to:

Controller determines the processing → processor operates within that authority → processor must comply with lawful and applicable instructions → apparent legal conflicts should be escalated → clearly unlawful processing cannot be legitimised merely by calling it an instruction.

This distinction becomes particularly important in regulated industries.

Example

suppose a controller tells a processor to destroy records immediately, but applicable law requires those records to be retained.

The processor cannot simply assume that the controller's instruction overrides the law.

The legal analysis must account for the applicable statutory requirement.

21. The statutory exception: Union or Member State law

Article 29 contains an important exception to instruction-based processing.

A person may process personal data without following the controller's instruction where processing is required by applicable Union or Member State law.

This is an important distinction.

There is a difference between:

law permitting processing

and

law requiring processing.

The Article 29 exception is concerned with the latter.

22. Permission is not the same as obligation

Suppose national law says:

"A company may retain certain records for five years."

That does not necessarily mean the processor is legally required to retain those records for five years.

The provision merely permits retention.

Contrast this with a statute saying:

"Records falling within this category must be retained for five years."

That creates a legal obligation.

This distinction is extremely important.

The Article 29 exception should not be expanded into:

"Any law that permits processing allows the processor to ignore the controller."

That would undermine the controller-processor structure.

23. Example: mandatory disclosure to authorities

Suppose a processor receives a legally binding request requiring it to provide specified personal data to a competent authority.

The controller may have instructed:

"Do not disclose customer data to third parties."

But if applicable Union or Member State law independently requires the disclosure, Article 29 recognises that statutory obligation.

The processor is not simply following the controller's instruction.

It is complying with law.

This illustrates the hierarchy:

Controller instruction governs ordinary processing.

A binding legal requirement may override the instruction.

24. But the legal obligation must actually apply to the processor

This is another subtle point.

It is not sufficient that a legal obligation exists somewhere in the regulatory framework.

The obligation must actually be directed at the relevant actor.

Suppose a law imposes an obligation specifically on the controller.

The processor cannot automatically treat that controller obligation as its own independent legal authority for processing.

Example

if legislation requires a particular type of record to be maintained by the controller, the processor cannot simply say:

"The controller is legally required to retain it, therefore I can independently retain everything forever."

The processor must determine whether the legal requirement actually applies to it.

25. Mandatory retention

Retention is one of the clearest areas where Article 29's statutory exception becomes relevant.

Imagine:

A controller instructs its processor to delete customer records after three years.

A Member State law requires certain financial records to be retained for seven years.

The processor may have a legal obligation to retain the relevant records despite the controller's deletion instruction.

But this does not necessarily mean the processor acquires unlimited rights over the data.

The processor should still consider:

• which records must be retained;

• for how long;

• under what legal authority;

• whether access must be restricted;

• whether the retained data can be isolated;

• whether it may be used for other purposes;

• what happens after the statutory period ends.

A statutory retention obligation does not automatically transform the processor into a controller for every conceivable purpose.

26. Article 29 and purpose limitation

Article 29 is closely connected to the GDPR's purpose limitation principle.

Suppose a processor receives customer data for the purpose of providing email delivery.

The processor cannot decide:

"We have millions of customer email addresses. We should use them to build our own advertising database."

That would involve an independent purpose.

The processor would be moving beyond the authority granted by the controller.

This is exactly the type of behaviour Article 29 seeks to prevent.

27. The boundary between processor and controller

One of the most important consequences of ignoring Article 29 is the possibility that the processor may effectively become a controller.

Suppose:

Controller A tells Processor B:

"Use this customer data to send transactional emails."

Processor B decides independently:

"We will also analyse the customer data to create advertising profiles for our own business."

Processor B has now introduced an independent purpose.

The issue is no longer simply:

"Did B violate the instruction?"

It may become:

"Has B determined its own purposes and therefore acted as a controller for that processing?"

This is why Article 29 has structural importance.

It helps preserve the distinction between the controller and processor.

28. Article 28(10) connection

The connection with Article 28(10) is particularly important.

Where a processor determines the purposes and means of processing in a manner that makes it a controller in respect of that processing, the processor may be treated as a controller for that operation.

Therefore, an unauthorised processing activity can have consequences much more serious than a simple internal breach of instructions.

It can potentially change the legal role of the actor.

This creates a major compliance lesson:

A processor must not assume that everything it does with personal data remains "processor processing".

The moment the processor independently decides why the data should be processed, the legal analysis can change.

29. Example: analytics provider

Suppose an analytics provider is instructed to process website visitor data to generate traffic statistics.

The provider then decides to combine the data from thousands of customers and create its own behavioural dataset for commercial purposes.

That second activity is qualitatively different.

The provider is no longer merely implementing the customer's instructions.

It has introduced its own purpose.

This is a classic example of why contractual labels cannot control the legal analysis.

Calling the company a "processor" does not make every activity it undertakes processor activity.

30. The controller cannot outsource responsibility simply by issuing instructions

The opposite mistake is equally important.

A controller cannot say:

"We instructed the processor, so we are no longer responsible."

The GDPR does not work that way.

The controller retains substantial responsibilities under Article 24 and Article 28.

Article 29 is therefore part of a broader accountability architecture.

The controller must:

• choose appropriate processors;

• provide appropriate instructions;

• establish contractual controls;

• supervise compliance;

• implement appropriate governance;

• address risks;

• respond to incidents.

The processor and persons under its authority also have their own obligations.

Responsibility is therefore distributed, not eliminated through outsourcing.

31. Article 29 and security incidents

Article 29 becomes particularly significant during a data breach.

Suppose an employee of a processor downloads 500,000 customer records without authorisation.

Several questions immediately arise:

1. Was the employee authorised to access the data?

2. Was downloading permitted?

3. Was the employee acting within the controller's instructions?

4. Was the employee acting within the processor's instructions?

5. Were adequate access controls implemented?

6. Were confidentiality obligations imposed?

7. Was the employee's access logged?

8. Did the processor have appropriate security measures?

9. Does the incident constitute a personal data breach?

10. What notification and cooperation obligations follow?

Article 29 is therefore not merely an abstract governance provision.

It can become highly relevant to breach investigations.

32. Article 29 and privileged access

The concept becomes particularly important for privileged users.

Examples

include:

• database administrators;
• system administrators;
• security engineers;
• cloud administrators;
• DevOps personnel;
• IT support teams. These people may have technical access far beyond what they need for ordinary tasks. Article 29 therefore supports the principle that technical capability does not equal substantive authorisation. A database administrator might technically be capable of reading every customer record. That does not mean the administrator is legally authorised to inspect every customer record. This distinction is critical in privacy-by-design and security governance.

33. "I could access it" versus "I was authorised to access it"

A sophisticated compliance analysis distinguishes:

technical access

from

authorised processing.

For example:

An employee has credentials capable of accessing 100,000 records.

Their job requires access to only 500 records.

The employee opens 100,000 records simply because the system permits it.

Technical access existed.

But Article 29 concerns processing under authority.

The organisation therefore needs appropriate technical controls to ensure that authority is reflected in actual access rights.

This illustrates the relationship between legal governance and technical design.

34. Article 29 and least privilege

Although Article 29 does not itself establish a complete technical security framework, it strongly supports a least-privilege approach.

Employees should receive only the level of access reasonably required for their functions.

For example:

A customer-service employee should not ordinarily receive unrestricted access to the entire HR database.

A payroll administrator may need salary information but not necessarily access to unrelated disciplinary records.

A security engineer may need access to system logs but not unrestricted access to the content of every customer communication.

Article 29 therefore has practical implications for role-based access control.

35. Article 29 and AI systems

Article 29 has increasingly important implications for AI and machine-learning environments.

Suppose an organisation instructs an external AI service provider to process customer data solely to provide a customer-support chatbot.

An employee of the AI provider then decides to use customer conversations to create an unrelated dataset for personal experimentation.

That use would be outside the authorised processing.

Similarly, if the AI provider itself decides to use customer data for model training when the controller did not authorise such processing, a serious controller-processor classification issue may arise.

The key questions become:

• Was model training authorised?

• Was it within the agreed purpose?

• Who determined the purpose?

• Was the data reused independently?

• Did the provider determine its own purposes?

• Was the processing covered by the Article 28 arrangement?

• Were the persons with model-development access appropriately authorised?

Article 29 therefore has substantial relevance to modern AI governance.

36. Article 29 and "function creep"

Function creep occurs when data collected for one purpose gradually gets used for another.

Article 29 creates an important barrier against such internal function creep within processor relationships.

Example

A company hires a customer-support processor. The processor initially receives customer names and order information to resolve complaints. Later, the processor decides: "Since we already possess the data, let's analyse it to identify profitable customer segments." Possession does not create permission. The fact that data is already available to the processor does not mean the processor can freely determine new purposes.

This is one of the most important practical lessons:

Access is not ownership, and possession is not authorisation.

37. Instructions can concern technical measures

Instructions are not limited to substantive processing purposes.

They may also concern technical and organisational requirements.

Example

a controller may instruct a processor to:

• encrypt data at rest;

• use specified authentication controls;

• restrict administrator access;

• maintain logs;

• delete temporary copies;

• use approved infrastructure;

• implement segregation of customer environments.

The processor therefore operates within an instruction environment that can include both legal and technical requirements.

However, Article 29 does not mean that every technical detail must be dictated by the controller.

Article 28 and the broader GDPR framework leave room for processors to exercise appropriate technical expertise.

The critical distinction is between technical implementation discretion andindependent determination of the purposes of processing.

38. The processor may have technical discretion without becoming a controller

Suppose a controller instructs a processor:

"Secure the customer database using appropriate encryption."

The processor chooses AES-256 rather than another technically suitable encryption method.

That does not necessarily mean the processor has become a controller.

The processor is exercising implementation expertise while remaining within the controller's purpose and authority.

This is important because the controller cannot realistically specify every technical implementation detail.

The processor can retain operational discretion while remaining a processor.

The danger arises when that discretion crosses into independent determination of purposes or material means in a manner inconsistent with the processor role.

39. Article 29 and internal investigations

Suppose an organisation investigates suspected employee misconduct.

An authorised investigator receives access to employee communications.

The investigator may process those communications only for the authorised investigation.

The investigator cannot then use the same information to investigate unrelated personal matters.

Again, the relevant concept is scope.

An instruction can be broad enough to authorise an investigation but still limited by:

• purpose;

• necessity;

• proportionality;

• authorised personnel;

• relevant categories of data.

Article 29 therefore supports disciplined internal investigations.

40. What happens when instructions conflict?

Conflicts can occur at multiple levels.

For example:

Controller instruction: delete data.

Processor's statutory obligation: retain specific records.

Or:

Controller instruction: provide unrestricted access.

Processor's security policy: prohibit such access without additional approval.

Or:

Manager's instruction: export the database.

Organisation's privacy policy: prohibit local downloads.

In such circumstances, the correct approach is not to blindly follow whichever instruction was received most recently.

The actor should determine:

• which authority issued the instruction;

• whether the instruction is within the person's scope of authority;

• whether a legal obligation applies;

• whether another superior instruction exists;

• whether escalation is required.

Documentation and governance procedures become extremely important.

41. Article 29 creates an accountability trail

An effective Article 29 compliance framework should make it possible to reconstruct:

Controller's purpose

Processor's contractual authority

Processor's documented instructions

Employee/authorised person's role

Actual access

Actual processing

This creates an accountability trail.

If the actual processing differs from the authorised processing, the organisation can identify where the deviation occurred.

That makes Article 29 especially useful during:

• audits;

• regulatory investigations;

• data breach investigations;

• litigation;

• internal compliance reviews.

42. A major practical trap: "the system allowed it"

A person cannot necessarily defend unauthorised processing by saying:

"The software allowed me to do it."

Technical permission and legal authorisation are separate concepts.

Suppose an employee can export an entire customer database because the software has an export button.

That does not automatically mean the employee was authorised to use it.

A well-designed GDPR compliance system therefore requires alignment between:

legal authority + organisational policy + technical permissions.

If these three diverge, risk increases dramatically.

43. Another major trap: broad contractual language

A processor agreement saying:

"Processor may process personal data as necessary to provide the services"

may be too broad to answer every operational question.

A good governance structure should distinguish between:

• core processing purpose;

• categories of data;

• authorised personnel;

• permitted operations;

• retention;

• security;

• secondary uses;

• disclosures;

• deletion.

The more sensitive the processing, the more important precise instructions become.

44. Article 29 and accountability

Article 29 contributes to the GDPR's broader accountability principle.

The organisation should be able to demonstrate not merely that:

"We have a processor agreement."

but also that:

"We control who can access personal data, what they are allowed to do, and whether their actual processing remains within the authorised scope."

This means Article 29 compliance should be reflected in operational documentation.

Examples

include:

• access-control matrices;
• role descriptions;
• data-processing procedures;
• employee instructions;
• processor manuals;
• incident procedures;
• confidentiality agreements;
• privileged-access procedures;
• audit logs;
• deletion procedures.

45. A useful analytical framework for Article 29 problems

When confronted with an Article 29 problem, analyse it in the following sequence.

Step 1: Identify the data

Is the material personal data?

If not, Article 29 is not triggered.

Step 2: Identify the actor

Is the actor:

• the processor;

• an employee;

• a consultant;

• a freelancer;

• a sub-processor;

• an employee of a sub-processor?

Step 3: Determine the relationship

Is the person actually acting under the authority of the controller or processor?

Step 4: Determine access

Did the person have the possibility of accessing personal data?

Actual viewing is not necessarily required.

Step 5: Identify the instruction

What was the person authorised to do?

Step 6: Compare conduct with instruction

Did the actual processing remain within that scope?

Step 7: Check independent purpose

Did the actor decide to use the data for a new purpose?

If yes, controller-status issues may arise.

Step 8: Check legal obligations

Was the actor legally required to undertake the processing independently of the controller's instructions?

Step 9: Examine Article 28

If the actor is actually a processor or sub-processor, Article 28 must also be considered.

Step 10: Examine consequences

Consider:

• breach;

• security failure;

• unlawful processing;

• controller/processor reclassification;

• contractual consequences;

• regulatory consequences.

This framework is useful both for examinations and real-world compliance investigations.

46. A consolidated example

Consider the following scenario.

Company A operates an online marketplace.

It appoints Company B to provide customer-support services.

Company B's employees can access customer names, addresses, order histories and complaint records.

Company A instructs B to use the information solely to resolve customer complaints.

One employee of B accesses the customer database.

First, Article 29 applies because the employee is acting under B's authority and has access to personal data.

Second, the employee is not normally an independent processor.

Third, the employee may access the information only within the authorised scope.

Suppose the employee then downloads customer records and creates a personal spreadsheet.

That processing is outside the authorised purpose.

Suppose the employee then sells the spreadsheet to a marketing company.

The situation becomes even more serious.

The employee is no longer merely performing the assigned customer-support task.

The processing is entirely outside the authority under which access was provided.

Now suppose instead that Company B itself decides to sell the information.

The analysis changes again.

This may raise the question whether B has determined an independent purpose and therefore acted as a controller for that activity.

Finally, suppose a law independently requires B to disclose certain records to a competent authority.

B may have a legal obligation to process or disclose the relevant information notwithstanding the controller's ordinary instructions.

The same basic facts can therefore produce very different legal consequences depending on who decided what, why they decided it, and whether a legal obligation independently required the processing.

47. The deepest conceptual point

The deepest point about Article 29 is that the GDPR does not treat personal data access as equivalent to personal data authority.

An organisation may give someone technical access because they need to perform their job.

That does not give that person unrestricted discretion.

The authority remains bounded by:

• purpose;

• instructions;

• role;

• necessity;

• applicable law;

• security requirements;

• confidentiality.

Article 29 therefore reinforces the architecture of controlled delegation.

The controller can delegate processing.

The processor can operationalise processing.

Employees and authorised persons can perform processing.

But each level remains constrained by the authority under which the processing occurs.

48. Key grey areas to remember

The most difficult Article 29 questions generally arise around the boundaries.

Employee or processor?

Look at substance, independence and the actual relationship, not the label.

Freelancer or person under authority?

Examine integration, independence, contractual structure and decision-making power.

Technical access or authorised access?

Technical capability does not itself create legal authorisation.

Instruction or independent purpose?

If the actor begins determining a new purpose, controller-status issues may arise.

Permission under law or obligation under law?

A legal permission to process is not necessarily enough to invoke the Article 29 exception.

Instruction or unlawful command?

Article 29 does not create a principle of blind obedience. Serious or manifestly unlawful instructions require appropriate escalation.

Article 29 or Article 28?

They operate together. Article 29 should not be used to avoid Article 28 where a genuine processor relationship exists.

49. Practical compliance checklist

An organisation seeking to operationalise Article 29 should ask:

Governance

• Have all persons with access to personal data been identified?

• Are their roles clearly defined?

• Are their processing permissions documented?

Instructions

• Are instructions sufficiently clear?

• Are they documented?

• Are prohibited activities identified?

• Are instructions updated when processing changes?

Access

• Does technical access correspond to actual job requirements?

• Are privileged accounts controlled?

• Are access rights periodically reviewed?

• Are unnecessary permissions removed?

Personnel

• Are employees subject to confidentiality obligations?

• Are contractors appropriately classified?

• Are freelancers assessed for processor status?

• Are sub-processors properly governed?

Processor relationships

• Is Article 28 documentation in place where required?

• Are sub-processors properly authorised?

• Are processor instructions documented?

• Are independent secondary uses prohibited unless legally justified?

Legal obligations

• Are statutory retention requirements identified?

• Are mandatory disclosure obligations identified?

• Can the processor distinguish legal requirements from mere permissions?

Incidents

• Are unauthorised uses detected?

• Are access logs maintained?

• Is there an escalation procedure for questionable instructions?

• Can the organisation reconstruct what happened?

50. Final synthesis

Article 29 may appear to be a simple instruction-following provision, but its real function is much broader.

It protects the structural distinction between the controller and everyone processing data under the controller's authority.

Its central idea is:

Authority to access personal data does not mean authority to determine what may be done with it.

The controller establishes the purposes and relevant framework of processing. The processor performs processing on the controller's behalf. Employees and other persons acting under the authority of either entity must operate within the scope of that authority.

The provision therefore addresses several risks simultaneously:

1. unauthorised internal use;

2. employee misuse;

3. uncontrolled processor activity;

4. function creep;

5. unauthorised secondary purposes;

6. inappropriate access;

7. misuse of privileged permissions;

8. confusion between technical capability and legal authorisation;

9. processor attempts to exercise independent purposes;

10. breakdown of the controller-processor chain.

At the same time, Article 29 is not absolute. The most important qualification is the possibility of processing where Union or Member State law independently requires it. Even here, the distinction between a legal obligation and a mere legalpermission is crucial.

The provision also cannot be understood as a mechanism for transferring all GDPR responsibility to employees or processors. Article 24 and Article 28 continue to impose significant obligations on controllers, while processors remain subject to their own GDPR duties.

The most important practical lesson is therefore not merely:

"Follow instructions."

It is:

Every person who has access to personal data must understand the legal and organisational boundaries within which that access is granted, and processing must remain within those boundaries unless an independent legal obligation requires otherwise.

That is why Article 29 is particularly significant in environments involving large databases, cloud services, outsourced operations, privileged IT access, AI systems, analytics, HR platforms and complex processor chains.

In a mature GDPR compliance programme, Article 29 should ultimately translate into a practical chain of control:

defined purpose → documented authority → authorised personnel → controlled access → clear instructions → monitored processing → escalation of conflicts → deletion/retention controls → accountability evidence.

Where that chain is intact, Article 29 operates as a powerful safeguard against uncontrolled processing.

Where that chain breaks, the consequences can extend far beyond an employee's breach of instructions. The incident may implicate Article 28, Article 32, the principles of Article 5, breach-notification obligations, contractual liability, and potentially even the legal classification of the actor as a controller.

That is the real significance of Article 29: it is not merely a rule about obeying instructions; it is a rule preserving the architecture of authority, purpose and accountability throughout the processing chain.

If you want, I can continue with Article 30 in the same detailed 3,000-word commentary style, including the difficult ROPA issues, joint-controller records, processor records, exemptions, territorial scope, mandatory fields, and practical examples.

Absolutely. Article 30 is one of the most operationally important provisions in the GDPR because it converts the abstract principle of accountability into a concrete documentary system. A good Article 30 analysis should therefore go far beyond saying "maintain a ROPA." The difficult questions are what counts as a processing activity, how granular the record must be, who must maintain it in groups and joint-controller arrangements, how it interacts with Articles 5, 6, 13, 14, 15, 24, 25, 28, 32 and 35, how the 250-employee exception actually works, and why in practice even organisations technically exempt from Article 30 often need a ROPA.