Article 28 — Processor

Article 28 GDPR: Processor

Detailed Clause-by-Clause Legal Commentary

1. The fundamental idea behind Article 28

Article 28 is one of the most practically important provisions of the GDPR because modern organisations almost never process all personal data entirely within their own technical and organisational environment.

A company may determine why customer information should be processed, but the actual processing may be performed by a cloud provider, payroll company, CRM provider, call-centre operator, email service, hosting provider, document-management platform, analytics provider, security vendor, recruitment platform, or other specialist service provider.

This creates a fundamental legal problem.

If the controller remains responsible for GDPR compliance, but another organisation physically stores, accesses, analyses, transmits or otherwise processes the personal data, how does the GDPR prevent the controller from escaping its responsibilities simply by outsourcing the processing?

Article 28 is the answer.

Its underlying philosophy can be expressed very simply:

Outsourcing processing does not mean outsourcing responsibility for ensuring that the processing remains GDPR-compliant.

Article 28 therefore creates a controlled legal relationship between a controller and aprocessor.

The controller decides the purposes and essential parameters of the processing. The processor performs processing on behalf of the controller. But the processor is not simply an ordinary commercial contractor. Once it processes personal data on behalf of the controller, GDPR-specific statutory obligations attach to the relationship.

The provision therefore performs several interconnected functions:

1. it regulates processor selection;

2. it requires the controller to exercise due diligence;

3. it prevents processors from freely appointing further processors;

4. it imposes a mandatory contractual framework;

5. it controls the processor's instructions;

6. it imposes confidentiality and security obligations;

7. it requires assistance with data-subject rights;

8. it requires assistance with breach, DPIA and prior-consultation obligations;

9. it regulates deletion and return of personal data;

10. it creates audit and transparency mechanisms;

11. it creates a chain of responsibility for sub-processors;

12. it permits approved codes and certifications to support processor due diligence;

13. it provides for standard contractual clauses;

14. it requires the arrangement to be in writing;

15. and, critically, it prevents a processor from using its contractual label to escape controller status when it actually determines purposes and means.

Article 28 therefore has both a contractual dimension and asubstantive regulatory dimension.

The contract is important, but the contract does not determine the legal reality.

That distinction is essential.

A company cannot simply write:

"Company B is a processor."

and thereby make Company B legally a processor.

The actual allocation of decision-making power matters.

The EDPB repeatedly emphasises that controller and processor are functional concepts. The contractual arrangement should reflect the factual circumstances rather than artificially create them. (European Data Protection Board)

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

Article 28 cannot properly be understood in isolation.

The starting point is Article 4(7), which defines the controller as the entity determining the purposes and means of processing.

Article 4(8) defines the processor as the entity processing personal data on behalf of the controller.

This gives us the fundamental relationship:

Controller

↓ determines purposes and means

Processor

↓ performs processing on behalf of controller

Sub-processor

↓ performs delegated processing on behalf of processor/controller arrangement

The relationship is therefore not simply:

Company A owns the data; Company B receives the data.

Ownership is not the relevant concept.

The GDPR is concerned with decision-making authority over processing.

Consider:

Example

An online retailer appoints a cloud provider to host its customer database. The retailer decides:

• why customer information is collected;
• which customers are included;
• what information is retained;
• why the information is used;

• who may access it;

• how long it should be retained.

The cloud provider decides technical matters such as:

• server architecture;

• database configuration;

• redundancy mechanisms;

• hardware allocation;

• routine technical operations.

The cloud provider may therefore exercise considerable technical discretion without becoming a controller.

This is because a processor can possess substantial autonomy concerning non-essential technical means while still remaining subject to the controller's overall determination of purposes and essential means.

The difficult question is therefore not:

"Does the processor make any decisions?"

It is:

"What kind of decisions does the processor make, and do those decisions amount to determining the purposes and essential means of processing?"

That distinction becomes extremely important under Article 28(10).

3. Article 28(1): The controller cannot simply choose any processor

The first major obligation is placed upon the controller.

The controller must use only processors capable of providing sufficient guarantees that appropriate technical and organisational measures will be implemented so that the processing complies with the GDPR and protects data-subject rights.

This creates a processor-selection obligation.

It is not enough for the controller to say:

"The processor signed our DPA."

The controller must first determine whether the processor is actually suitable.

This is an expression of the GDPR's broader accountability principle under Article 5(2).

The controller must not merely comply.

It must be able to demonstrate compliance.

Consequently, processor selection should ordinarily be treated as an evidentiary exercise.

3.1. "The controller shall use only"

These words are stronger than a recommendation.

The controller is prohibited from appointing a processor that does not provide the required guarantees.

Imagine that a company knows that a prospective processor:

• has weak access controls;

• has repeatedly suffered preventable breaches;

• cannot explain where data are stored;

• has no meaningful incident-response process;

• refuses to provide information about sub-processors;

• cannot demonstrate appropriate security;

• or intends to use customer data for its own purposes.

The controller cannot simply say:

"The vendor is cheap and commercially convenient."

Article 28(1) makes convenience legally subordinate to processor suitability.

The outsourcing decision must therefore be capable of surviving regulatory scrutiny.

4. What are "sufficient guarantees"?

This is one of the most important expressions in Article 28.

The GDPR does not prescribe a universal checklist saying:

Every processor must have ISO certification, SOC 2 certification, a particular encryption standard, a particular number of employees, and a particular insurance policy.

Instead, sufficiency is contextual and risk-based.

Recital 81 specifically identifies factors such as:

• expert knowledge;

• reliability;

• resources;

• technical and organisational measures;

• security capabilities.

The controller therefore has to assess the processor against the processing actually being entrusted to it.

This produces an important principle:

"Sufficient" is not an abstract characteristic of the processor. It is related to the processing activity and the risks involved.

4.1. The same processor may be sufficient for one processing activity but insufficient for another

Suppose Processor X provides cloud storage.

For a company storing:

• publicly available business information;

• ordinary internal administrative documents;

its safeguards might be sufficient.

But suppose another controller wants to use the same provider to store:

• medical records;

• biometric information;

• children's data;

• financial information;

• highly confidential employee information.

The risk profile is dramatically different.

The processor's safeguards may therefore need to be considerably stronger.

This is why processor due diligence should not be conducted as a purely generic vendor exercise.

The correct question is:

"Is this processor sufficiently reliable and capable for this particular processing activity?"

5. What should processor due diligence examine?

A serious Article 28 assessment may examine:

Security

• encryption;

• access controls;

• authentication;

• privileged-access management;

• logging;

• monitoring;

• vulnerability management;

• patching;

• incident response;

• backup and recovery;

• business continuity;

• disaster recovery;

• segregation of customer environments.

Organisational governance

• privacy policies;

• security policies;

• employee training;

• confidentiality arrangements;

• incident-management procedures;

• internal governance;

• data-protection expertise.

Technical capability

• architecture;

• security engineering;

• ability to implement deletion;

• ability to respond to rights requests;

• ability to identify affected data following a breach;

• ability to support DPIAs;

• ability to provide audit information.

Reliability

Past incidents may matter.

Example

if a processor has repeatedly experienced serious breaches and cannot demonstrate meaningful remediation, the controller may have difficulty establishing that sufficient guarantees exist.

Resources

A processor processing millions of records should have adequate:

• personnel;

• infrastructure;

• financial resources;

• technical expertise;

• security capabilities.

Sub-processors

The controller should understand:

• who the sub-processors are;

• where they are located;

• what they do;

• what safeguards apply;

• whether international transfers occur.

The EDPB's 2024 Opinion 22/2024 is particularly important here. It stresses that controllers should have information about the identity of processors and sub-processors readily available and that verification of sufficient guarantees remains an obligation even though the intensity of verification may vary according to risk. (European Data Protection Board)

6. Certification is evidence, not immunity

A common mistake is:

"The processor has ISO certification, therefore Article 28 is satisfied."

That conclusion is too simplistic.

Article 28(5) expressly describes approved codes of conduct and certification mechanisms as an element demonstrating sufficient guarantees.

That means certification is evidence.

It is not a universal safe harbour.

Suppose a processor has an approved certification.

The controller should still ask:

• Does the certification cover the relevant service?

• Is it current?

• What processing activities fall within its scope?

• Does it cover the relevant systems?

• Does it address the particular risks?

• Have circumstances changed since certification?

• Has the processor suffered material security incidents?

• Are the relevant sub-processors covered?

Certification therefore reduces uncertainty but does not eliminate the controller's accountability.

7. Processor assessment is continuous

Another major conceptual point is that Article 28(1) is not merely a pre-contract obligation.

Suppose:

Company A selects Processor B in January.

At that point B has excellent security controls.

In June, B changes its infrastructure.

In September, B introduces a new sub-processor.

In November, B suffers a serious security incident.

The controller cannot simply rely upon its January due-diligence file forever.

The relevant question becomes:

Does the processor continue to provide sufficient guarantees?

Article 28 therefore supports ongoing processor oversight.

The controller's compliance programme should accordingly include periodic reassessment proportionate to risk.

For a low-risk service, annual or periodic documentary review may be sufficient.

For high-risk processing, more intensive monitoring may be necessary.

8. The risk-based nature of processor oversight

A particularly important nuance emerges from the EDPB's 2024 Opinion.

The obligation to verify whether processors and sub-processors provide sufficient guarantees does not disappear merely because a processing operation is considered low-risk. What changes is the extent and intensity of verification. (European Data Protection Board)

This is an important distinction.

Incorrect approach:

Low risk = no due diligence.

Correct approach:

Low risk = potentially less extensive due diligence.

For example:

Low-risk processor

A processor handles ordinary business contact information for a limited administrative function.

The controller might conduct:

• questionnaire;

• contract review;

• basic security documentation;

• sub-processor review.

High-risk processor

A processor handles:

• health information;

• biometric information;

• children's information;

• large-scale behavioural profiles.

The controller may reasonably require:

• detailed security assessment;

• independent audit reports;

• penetration-testing information;

• detailed sub-processor mapping;

• transfer assessment;

• incident history;

• technical architecture;

• stronger contractual controls;

• more frequent audits.

9. What happens if the processor stops providing sufficient guarantees?

This creates an important practical question.

Suppose the controller discovers that the processor's safeguards have materially deteriorated.

The controller cannot simply continue indefinitely because terminating the processor would be commercially inconvenient.

The controller must take corrective action.

Depending on circumstances, that may involve:

1. requiring remediation;

2. suspending particular processing;

3. restricting access;

4. replacing the processor;

5. terminating the processing relationship;

6. notifying regulators or data subjects where another GDPR provision requires notification.

The critical point is that Article 28 is designed to ensure that outsourcing never becomes a mechanism for lowering the GDPR's protection level.

10. Article 28(2): The processor cannot freely appoint sub-processors

Modern processing chains are rarely linear.

A controller may appoint Processor A.

Processor A may use:

• cloud provider B;

• email provider C;

• security provider D;

• analytics provider E.

This creates:

Controller → Processor → Sub-processor

Article 28(2) prevents Processor A from simply deciding:

"I have the data, so I can subcontract whatever I want."

It cannot.

The processor requires the controller's prior written authorisation.

This creates an important principle:

The controller must retain meaningful control over the processing chain.

11. Why sub-processor control matters

Imagine an employer appoints a payroll processor.

The employer believes:

"Our payroll data are being handled by Processor A in Germany."

But Processor A secretly sends the payroll database to another company in a third country.

That creates several problems:

• new security risks;

• potentially new recipients;

• potentially new international transfers;

• potentially different legal exposure;

• potentially different retention practices;

• potentially different sub-processing arrangements.

The controller therefore has a legitimate interest, and a GDPR obligation, to know who is actually handling its data.

12. Specific versus general authorisation

Article 28(2) permits two basic structures.

Specific authorisation

The controller authorises a particular sub-processor.

For example:

"Processor may engage Cloud Provider X for hosting the database."

If Processor later wants to replace X with Cloud Provider Y, a new authorisation may be necessary.

This model gives the controller maximum control.

General authorisation

The controller gives broader advance authorisation for sub-processing.

But this does not mean:

"Processor can appoint anyone it wants."

The processor must inform the controller of intended additions or replacements and give the controller an opportunity to object.

Thus, general authorisation is better understood as:

advance conditional permission subject to a continuing objection mechanism.

13. The "opportunity to object" must be meaningful

This is one of the most interesting practical issues under Article 28.

Suppose a processor sends this notice:

"Tomorrow we will appoint Company X as a sub-processor. You may object."

The controller has 24 hours.

The processor knows that the controller cannot realistically replace the entire service.

Is this genuinely meaningful?

That is questionable.

The EDPB has emphasised the importance of a meaningful opportunity to object. The 2024 EDPB Opinion also reinforces the controller's continuing responsibility concerning sub-processors. (European Data Protection Board)

A controller should therefore have enough information and reasonable time to evaluate:

• identity;

• location;

• processing activity;

• security safeguards;

• transfer implications;

• contractual protections.

14. Silence and authorisation

Another subtle issue is the difference between specific and general authorisation.

In a general-authorisation model, the contractual mechanism may allow the controller's failure to object within a specified reasonable period to operate as acceptance.

But this should not be casually transplanted into specific-authorisation arrangements.

Where the controller must specifically authorise a particular sub-processor, silence should not ordinarily be treated as positive authorisation.

This distinction is highly significant in drafting DPAs.

The contract should clearly establish:

• notice period;

• required information;

• objection mechanism;

• form of objection;

• consequences of objection;

• whether suspension is required;

• whether termination rights arise.

15. The controller's role in choosing sub-processors

A particularly important development is the EDPB's clarification that the processor may conduct the initial assessment and propose suitable sub-processors, but the ultimate decision concerning engagement remains with the controller within the Article 28 framework. (European Data Protection Board)

This prevents a common contractual fiction.

A processor should not effectively say:

"We have chosen all of our sub-processors. You have no practical ability to object. Therefore they are your problem."

The controller must retain meaningful oversight.

16. The processing chain can become very complicated

Consider:

Controller A

Processor B

Sub-processor C

Sub-sub-processor D

Cloud infrastructure E

Each layer may create:

• security dependencies;

• transfer issues;

• confidentiality issues;

• access issues;

• deletion issues;

• audit difficulties.

Article 28's architecture is therefore based on flow-down obligations.

The obligations imposed at the controller-processor level must substantially continue down the processing chain.

This is crucial because otherwise Article 28 could be defeated by subcontracting.

17. Article 28(3): The mandatory processing agreement

Article 28(3) is the contractual heart of the provision.

Where processing is carried out by a processor, it must be governed by:

• a contract; or

• another legal act under Union or Member State law.

The arrangement must be binding.

This is not simply a commercial preference.

It is a statutory requirement.

18. The contract does not create the processor relationship

This is an extremely important legal nuance.

Suppose Company A and Company B sign a document stating:

"Company B shall act as a processor."

But in reality B independently decides:

• why the data are collected;

• which categories are processed;

• how the data are monetised;

• which purposes are pursued.

The label does not control.

Company B may actually be a controller.

Conversely, the absence of a DPA does not magically mean that B cannot be a processor.

The relationship arises from the actual processing arrangement.

Failure to have the required Article 28 arrangement is then itself a compliance violation.

This produces two separate questions:

Question 1

What is B legally?

Answer: determined by factual circumstances.

Question 2

Has the legally required Article 28 arrangement been documented?

Answer: a separate compliance question.

19. The contract must be sufficiently specific

A common drafting error is to produce a DPA that merely reproduces Article 28.

For example:

"Processor shall comply with Article 32."

That may be insufficiently operational.

The contract should translate the statutory requirement into concrete arrangements.

For example:

• what security measures apply;

• who controls access;

• how incidents are reported;

• how quickly breaches must be notified;

• how deletion works;

• how rights requests are handled;

• how audits occur;

• what sub-processors may be used;

• where data are stored;

• what transfer mechanisms apply.

The Article 28 contract should therefore operate as an implementation instrument, not merely as a recital of statutory language.

20. Subject matter

The agreement should explain what processing is actually being performed.

For example:

"Hosting and maintenance of the controller's customer relationship management database."

That is much more useful than:

"Processing of personal data."

The subject matter should allow someone examining the contract to understand the actual service.

21. Duration

The contract must identify the duration of processing.

This does not necessarily require a simplistic date.

The contract can establish duration by reference to:

• service period;

• project completion;

• termination;

• specified retention period;

• continuing statutory requirements.

The important thing is that the processing period should be intelligible.

22. Nature of processing

"Nature" concerns what the processor actually does.

Examples

include:

• collecting;
• storing;
• retrieving;
• organising;
• transmitting;
• hosting;
• analysing;
• deleting;
• pseudonymising;
• supporting;
• maintaining. Consider a processor that provides customer-support services. Its nature of processing might involve:
• accessing customer records;
• retrieving account information;
• recording support interactions;
• updating account information;
• transmitting responses. That gives much greater clarity than simply saying: "Customer data processing."

23. Purpose of processing

Purpose is particularly important because purpose is central to determining controller status.

A DPA should identify the purpose with enough specificity to prevent the processor from gradually repurposing the data.

For example:

"To provide customer-support services on behalf of the controller."

is fundamentally different from:

"To improve business intelligence and commercial services."

The latter may introduce independent purposes.

And independent purposes can trigger a controller analysis.

24. Type of personal data

The agreement should identify categories of personal data.

It is insufficiently informative simply to write:

"Personal data."

The contract might specify:

• names;

• contact information;

• account information;

• transaction records;

• device identifiers;

• location information;

• employee information;

• health information.

Where special-category data are involved, the contract should make that clear.

This matters because security and risk assessment depend heavily upon what information is processed.

25. Categories of data subjects

The contract must also identify whose data are involved.

Examples

include:

• customers;
• employees;
• job applicants;
• suppliers;
• patients;
• students;
• website visitors;
• children;
• business contacts. This requirement prevents the processor relationship from becoming so vague that its actual scope becomes impossible to determine.

26. Controller's rights and obligations

The agreement should identify what the controller must do and what authority it retains.

This is important because the controller remains responsible for:

• determining purposes;

• determining essential means;

• establishing lawful processing;

• providing transparency;

• responding to data-subject requests;

• determining retention;

• deciding deletion;

• providing instructions.

The processor cannot replace the controller's legal judgment.

27. Article 28(3)(a): Documented instructions

This is perhaps the most fundamental processor obligation.

A processor acts on behalf of the controller.

Therefore, the processor must process personal data only on documented instructions.

Instructions may be found in:

• the DPA;

• service specifications;

• written policies;

• technical documentation;

• emails;

• ticketing systems;

• documented directions;

• approved procedures.

The key requirement is that they must be documented.

28. Why documentation matters

Suppose the controller verbally tells a processor:

"Use this information for targeted advertising."

Later the processor is investigated.

The processor says:

"We believed we were authorised."

The controller says:

"We never instructed that."

The absence of documentation creates an evidentiary problem.

Article 28 therefore supports a written instruction architecture.

29. Instructions can be granular

A mature processing agreement may specify:

• permitted purposes;

• prohibited uses;

• data categories;

• access restrictions;

• retention periods;

• security objectives;

• approved locations;

• permitted transfers;

• approved sub-processors;

• deletion requirements.

The more sensitive or complex the processing, the more important specificity becomes.

30. Processor autonomy is not completely prohibited

A processor does not have to ask the controller before making every technical decision.

Example

a cloud provider may determine:

• server allocation;

• load balancing;

• routine technical architecture;

• internal system maintenance.

That does not necessarily make it a controller.

The crucial distinction is between:

Essential decisions

such as:

Why are customer profiles being created?

and

Non-essential technical implementation decisions

such as:

Which server cluster should handle the workload?

A processor may generally retain technical expertise concerning the latter.

31. The processor must not use the data for its own purposes

Suppose an email service provider receives customer email addresses to send transactional emails.

It decides:

"We will also analyse these email addresses to build our own marketing database."

That is not merely technical implementation.

It introduces a new purpose.

The provider is no longer simply acting on behalf of the controller for that processing.

Article 28(10) may consequently become relevant.

32. International transfers are expressly covered

Article 28(3)(a) specifically refers to instructions concerning transfers to:

• third countries;

• international organisations.

This is critical.

A controller may instruct:

"Personal data must remain within the EEA."

The processor cannot simply send the information to a third-country sub-processor because doing so is technically convenient.

The processor must respect the controller's documented transfer instructions and the requirements of Chapter V.

Article 28 therefore interacts directly with Articles 44 onward.

33. The legal-compulsion exception

The processor may process data without the controller's ordinary instruction where Union or Member State law requires it.

Example

a processor may receive a legally binding obligation to disclose information to a competent authority.

But the processor generally must inform the controller before processing where legally permitted to do so.

The exception is where applicable law prohibits informing the controller on important grounds of public interest.

This creates an important distinction:

A processor does not become free to disclose data merely because a governmental authority asks for it.

The legal requirement must itself be examined.

This becomes especially important where a third-country authority seeks access to data.

Article 48 and Chapter V may also become relevant.

34. Article 28(3)(b): Confidentiality

The processor must ensure that persons authorised to process personal data are bound by confidentiality obligations or appropriate statutory duties.

This applies to:

• permanent employees;

• temporary employees;

• contractors;

• personnel with privileged access;

• other authorised persons.

The principle is essentially:

Access to personal data must carry a legal duty of confidentiality.

35. Confidentiality is not merely an NDA

A sophisticated confidentiality framework should also include:

• access controls;

• need-to-know principles;

• role-based access;

• employee training;

• disciplinary mechanisms;

• offboarding;

• privileged-access monitoring.

An employee who technically signs a confidentiality agreement but has unrestricted access to millions of records may still present a significant security problem.

Thus confidentiality and security overlap, but they are not identical.

36. Article 28(3)(c): Article 32 security measures

The processor must implement the measures required by Article 32.

This is not simply a promise to "maintain reasonable security."

The contractual framework should make the security requirements sufficiently concrete.

Possible measures include:

• encryption;

• pseudonymisation;

• resilience;

• availability;

• restoration capability;

• testing;

• vulnerability management;

• access control;

• authentication;

• monitoring.

The exact measures depend on the risk.

37. Security is dynamic

A major mistake is to treat the security annex as a frozen document.

Security risks evolve.

A measure that was adequate three years ago may no longer be adequate today.

Consequently, the controller and processor should periodically review:

• threats;

• vulnerabilities;

• architecture;

• authentication;

• encryption;

• incident experience;

• technological developments.

The legal obligation is one of appropriate security, not permanent adherence to an obsolete checklist.

38. Article 28(3)(d): Sub-processors

The processor must respect the requirements governing further processors.

This links paragraph 3(d) with paragraphs 2 and 4.

The processor therefore cannot treat subcontracting as merely a commercial issue.

It is a GDPR governance issue.

39. Article 28(3)(e): Assistance with data-subject rights

The controller remains responsible for responding to rights requests.

But the processor often physically possesses the relevant data.

Therefore, Article 28 requires the processor to assist.

Consider:

A customer sends an erasure request to an online retailer.

The retailer must determine whether the legal conditions for erasure are satisfied.

But the retailer may need its cloud provider to:

• identify the relevant records;

• delete them;

• remove them from active systems;

• assist with backups where required;

• confirm completion.

The processor therefore provides operational assistance, while the controller generally retains the legal decision-making responsibility.

40. The processor cannot extend the controller's statutory deadline

Suppose the controller has a statutory deadline to respond to a data-subject request.

The processor says:

"We need another three months to locate the data."

That does not automatically extend the controller's legal deadline.

The controller must organise its processor relationship so that the processor can provide timely assistance.

This is why good DPAs specify:

• response times;

• escalation procedures;

• technical mechanisms;

• responsible contacts;

• formats for data extraction;

• deletion confirmation procedures.

41. The "insofar as possible" qualification

Article 28(3)(e) is qualified by:

• the nature of processing;

• what is possible.

This prevents absurd interpretations.

Suppose a processor is hired solely to physically destroy storage media.

It may be able to destroy a particular medium but may not possess all the technical information necessary to make the controller's legal determination about an Article 17 request.

Its obligation must therefore be interpreted according to the processing it actually performs.

The processor is not required to perform impossible tasks.

But "impossible" should not become a contractual escape clause for ordinary assistance that is technically feasible.

42. Article 28(3)(f): Assistance concerning Articles 32 - 36

This provision expands assistance beyond individual rights.

The processor must assist with:

• security;

• breach notification;

• communication of breaches;

• DPIAs;

• prior consultation.

This reflects an important reality:

The controller cannot conduct a meaningful risk assessment if it does not understand what its processor is actually doing.

43. Breach assistance

Suppose a processor suffers a cyberattack.

The controller may need information concerning:

• when the breach occurred;

• when it was discovered;

• systems affected;

• categories of data affected;

• number of individuals;

• likely consequences;

• containment measures;

• remediation.

The processor is therefore expected to provide meaningful information.

A vague contractual clause saying:

"Processor shall cooperate with breach notification"

is less useful than specifying:

• notification deadline;

• emergency contact;

• minimum information;

• update frequency;

• cooperation obligations.

44. "Without undue delay" versus contractual notification periods

Article 33 establishes the controller's breach-notification obligations.

The processor should therefore notify the controller without undue delay.

In practice, contracts frequently impose much tighter operational deadlines, such as:

"within 24 hours of becoming aware."

That contractual deadline does not replace the statutory standard. It operationalises it.

For high-risk processing, even shorter periods may be appropriate.

45. DPIA assistance

Article 35 places the DPIA obligation on the controller.

The processor does not become the legal owner of the DPIA merely because it supplies technical information.

But the processor may have essential information concerning:

• system architecture;

• data flows;

• security;

• retention;

• sub-processing;

• access;

• technical risks.

Therefore, processor cooperation can be indispensable to the controller's DPIA.

46. Prior consultation

If the DPIA reveals a high residual risk that cannot adequately be mitigated, Article 36 may require prior consultation with the supervisory authority.

Again, the controller bears the legal responsibility.

But the processor may need to provide the technical and operational information necessary to make the consultation meaningful.

47. Article 28(3)(g): Return or deletion

At the end of the processing relationship, the processor cannot simply keep the data indefinitely.

The controller chooses between:

• return; or

• deletion.

The processor must follow that choice unless applicable Union or Member State law requires continued storage.

This provision is extremely important because termination is a major privacy risk.

A processor might otherwise retain:

• databases;

• backups;

• logs;

• documents;

• archives;

• credentials;

• cached information.

48. Existing copies

The provision expressly addresses existing copies.

This is important because saying:

"We deleted the production database"

does not necessarily mean the personal data are gone.

Copies may exist in:

• backups;

• disaster-recovery environments;

• replicated databases;

• archives;

• testing environments;

• temporary storage.

The contractual framework should therefore address how deletion operates across the relevant environments.

49. Legal retention exception

If law requires retention, deletion may not immediately be possible.

Example

tax or accounting legislation may require records to be preserved.

But the processor should not interpret this exception as permission to retain data for general business convenience.

The retention must be legally required.

Where retained data are no longer processed on behalf of the controller but must be retained independently for a legal purpose, the legal character of that processing must also be carefully considered.

50. Article 28(3)(h): Information and audits

Article 28 creates an important accountability mechanism.

The processor must provide information necessary to demonstrate compliance and must permit and contribute to audits.

This is much more than a right to ask:

"Are you GDPR compliant?"

The controller should be able to obtain evidence.

Examples

include:

• audit reports;
• security certifications;
• penetration-testing summaries;
• relevant policies;
• sub-processor information;
• processing locations;
• transfer information;
• incident information;
• security documentation.

51. Audits are not merely theoretical

A contract might say:

"Controller may audit processor."

But if the processor has 100,000 customers and says:

"No customer may ever audit us physically, and we will provide nothing beyond a marketing certificate"

the controller may not have meaningful oversight.

The audit mechanism should therefore be proportionate but genuine.

Possible mechanisms include:

Documentary audit

Reviewing:

• certifications;

• audit reports;

• policies;

• security assessments.

Remote audit

Video or remote inspection of systems and controls.

On-site audit

Physical inspection where justified.

Independent third-party audit

An auditor conducts the review on behalf of the controller.

The appropriate mechanism depends upon risk.

52. Audit rights must be balanced against security and confidentiality

An audit does not mean the controller can necessarily demand unrestricted access to every server.

The processor may have:

• other customers;

• trade secrets;

• security-sensitive information;

• restricted facilities.

Therefore, audit rights should be structured intelligently.

For example:

"The controller may conduct an on-site audit where documentary evidence and independent reports are insufficient to establish compliance."

This can balance accountability and operational security.

53. Article 28(3) final sentence: Processor must challenge unlawful instructions

This is one of the most legally interesting provisions.

The processor must immediately inform the controller if, in its opinion, an instruction infringes the GDPR or other applicable Union or Member State data-protection law.

This creates a limited legal-checking function for the processor.

The processor is not merely a passive machine.

It cannot knowingly execute an apparently unlawful instruction without raising the issue.

54. Example: unlawful instruction

Suppose a controller instructs its processor:

"Keep all customer data forever."

The processor identifies that the instruction appears inconsistent with applicable storage-limitation obligations.

It should alert the controller.

The controller must then reassess the instruction.

55. What happens after the processor raises the objection?

The contract should ideally specify:

• who reviews the issue;

• how quickly it must be reviewed;

• whether processing is suspended;

• who makes the final decision;

• what happens if the controller insists;

• whether termination is possible.

The EDPB has suggested mechanisms such as suspension of the affected instruction while the issue is investigated. (European Data Protection Board)

This is particularly important because processors may otherwise find themselves trapped between:

• contractual obligations to the controller; and

• statutory obligations under the GDPR.

56. Article 28(4): Sub-processors must receive equivalent obligations

Suppose:

Controller A

contracts with

Processor B

and B uses

Sub-processor C.

B cannot simply give C an ordinary commercial outsourcing contract.

C must be bound by data-protection obligations corresponding in substance to those imposed upon B.

This is the flow-down principle.

57. "Same obligations" does not mean identical wording

This is an important drafting nuance.

Suppose B provides customer-support services but C only provides encrypted storage.

It would make little sense to copy every provision of B's DPA word-for-word into C's agreement.

Instead, the obligations should be functionally equivalent and appropriate to the processing C performs.

The EDPB has expressly explained that the requirement should be understood functionally rather than formally. (European Data Protection Board)

Thus:

same substantive protection

does not necessarily mean:

identical document.

58. Liability for the sub-processor

Article 28(4) creates a powerful contractual responsibility rule.

If the sub-processor fails to fulfil its data-protection obligations, the original processor remains fully liable to the controller for performance of those obligations.

This prevents:

"It wasn't our fault; our subcontractor did it."

from becoming an easy defence against the controller.

The processor has chosen the sub-processor and therefore bears responsibility within the controller-processor relationship.

59. But this does not erase every possible legal relationship

The rule must not be misunderstood as saying:

"The sub-processor is legally invisible."

A sub-processor may itself have GDPR obligations.

Moreover, the allocation of liability between the various actors can involve Articles 82, 83 and other provisions.

Article 28(4) specifically protects the controller's position against the original processor.

60. A four-level example

Consider:

1. Retailer A Controller
2. Cloud Company B Processor
3. Hosting Company C Sub-processor
4. Infrastructure Company D Further sub-processor

A customer suffers harm because D's security failure exposes personal data.

The contractual chain should not allow B to say:

"D caused it, so B has no responsibility."

Article 28 is specifically structured to prevent responsibility from disappearing as the processing chain becomes longer.

61. Article 28(5): Codes of conduct

Approved codes of conduct under Article 40 can help demonstrate sufficient guarantees.

This is useful particularly where:

• an industry has established recognised privacy standards;

• the processor operates in a specialised sector;

• controllers need scalable methods for vendor assessment.

But adherence is evidence rather than automatic compliance.

62. Article 28(6): Standard contractual clauses

Article 28 permits controller-processor arrangements to be based wholly or partly on standard contractual clauses.

This facilitates standardisation.

It is particularly useful for:

• cloud services;

• hosting;

• SaaS;

• infrastructure providers;

• standardised enterprise services.

The important point is that using standard clauses does not eliminate the need to complete them properly.

A standard clause is a framework.

The parties still need to specify the actual:

• processing;

• data;

• data subjects;

• purposes;

• duration;

• security;

• sub-processors;

• transfer arrangements.

63. A critical distinction: Article 28 SCCs versus international-transfer SCCs

This is a frequent exam and practical mistake.

There are different forms of Commission standard contractual clauses serving different purposes.

Article 28 SCCs

These regulate:

controller ↔ processor

or the relevant processor relationship within the GDPR framework.

Article 46 SCCs

These concern:

transfers of personal data to third countries.

They serve different legal functions.

The existence of an Article 28 processing agreement does not automatically legalise an international transfer.

If personal data are transferred to a third country, Chapter V must separately be considered.

64. Article 28(7): Commission standard clauses

Article 28(7) gives the Commission authority to establish standard contractual clauses for Article 28 matters.

The Commission exercised this authority in 2021 through Implementing Decision 2021/915. (EUR-Lex)

These clauses provide a recognised framework for controller-processor arrangements.

But they are not a substitute for analysing the actual processing operation.

65. Article 28(8): Supervisory-authority clauses

Supervisory authorities may also adopt standard contractual clauses through the GDPR's consistency framework.

The purpose is harmonisation.

Without mechanisms of this kind, Member States might develop significantly divergent contractual standards.

66. Article 28(9): Written form

The contract or legal act must be in writing, including electronic form.

This means a purely oral arrangement does not satisfy the formal requirement.

Electronic documentation is expressly permitted.

A conventional electronic DPA can therefore satisfy the requirement.

67. Article 28(10): The most important boundary

Article 28(10) is the provision that prevents the processor concept from becoming a shield against responsibility.

The basic principle is:

A processor cannot determine the purposes and means of processing for itself while continuing to claim the legal status of processor.

Suppose:

Company A hires Company B to analyse customer data for customer support.

B then decides:

"We will use this data to train our own commercial AI model."

B has introduced its own purpose.

It is no longer simply processing on A's behalf for that activity.

B may therefore become a controller in respect of that processing.

68. Processor-to-controller conversion can be purpose-specific

An entity does not necessarily become a controller for every activity merely because it acts as a controller for one activity.

Consider:

Company B processes customer data:

1. to provide hosting services to A; and

2. to train B's own commercial analytics product.

B may remain a processor for activity 1 while being a controller for activity 2.

This is a crucial analytical point.

The legal role can be processing-specific.

69. Example: cloud provider

A cloud provider may legitimately:

• allocate computing resources;

• manage infrastructure;

• perform technical maintenance;

• optimise system performance.

But suppose it begins analysing customer content for its own advertising purposes.

The issue is no longer merely technical means.

It has introduced an independent purpose.

That may transform its status concerning that processing.

70. Example: payroll provider

A payroll company processes employee salary data for an employer.

It cannot decide:

"We will sell aggregated employee salary profiles to advertisers."

Even if the company claims:

"We are simply analysing data as part of our technology."

The legal question is whether the new use is a purpose determined independently by the provider.

If so, the provider may be a controller for that processing.

71. What if the processor is given broad discretion?

This is a grey area.

Suppose the controller says:

"Use whatever methods you consider appropriate to analyse our customer data."

Does that make the processor a controller?

Not necessarily.

The answer depends on what has actually been delegated.

A processor can have considerable discretion regarding non-essential means.

The danger arises where the delegation concerns:

• why the processing occurs;

• which objectives are pursued;

• which categories of processing are undertaken;

• independent reuse;

• retention decisions;

• disclosures;

• commercial exploitation.

Thus:

technical discretion ≠ automatically controller status.

But:

independent determination of purposes = strong indicator of controller status.

72. The "controller by contract" fallacy

A sophisticated legal analysis must resist another common mistake.

Suppose a processor contract says:

"Processor has complete discretion over processing."

The parties then argue:

"Therefore the processor is authorised to determine purposes."

That does not necessarily solve the problem.

The GDPR's role allocation is based on substantive reality.

A contract cannot lawfully convert a controller into a processor merely by using terminology inconsistent with the actual arrangement.

73. Controller responsibility is not eliminated by Article 28

This is the overarching principle.

The controller remains responsible for:

• choosing processors;

• ensuring lawful processing;

• issuing appropriate instructions;

• maintaining transparency;

• assessing risks;

• supervising processors;

• responding to data-subject requests;

• making appropriate breach decisions;

• ensuring deletion/retention;

• ensuring international transfers are lawful.

Article 28 therefore creates shared operational responsibility, but it does not transfer the controller's overall legal role to the processor.

74. Processor responsibility is also real

The opposite mistake is equally dangerous:

"The processor is only following instructions, therefore it has no GDPR responsibility."

Incorrect.

Article 28 itself creates direct obligations for processors.

These include:

• processing only on documented instructions;

• confidentiality;

• security;

• sub-processor controls;

• assistance;

• deletion/return;

• audit cooperation;

• warning about unlawful instructions.

The GDPR therefore deliberately creates a processor that is neither:

an independent controller,

nor:

an entirely passive contractor.

It is a legally regulated intermediary.

75. A useful conceptual model: three layers of processor responsibility

Article 28 can be understood through three layers.

Layer 1: Selection

The controller must select a sufficiently reliable processor.

Layer 2: Governance

The controller and processor must establish an appropriate binding framework.

Layer 3: Monitoring

The controller must continue to exercise oversight.

This produces:

Select → Contract → Supervise

If any of these three stages is missing, Article 28 compliance becomes vulnerable.

76. The processor lifecycle

A practical Article 28 compliance lifecycle can therefore be represented as:

Vendor identification

Role classification

Risk assessment

Due diligence

Processor selection

Article 28 agreement

Instruction framework

Sub-processor approval

Ongoing monitoring

Audits

Incident management

Rights-request assistance

Periodic reassessment

Termination

Return/deletion

This is why Article 28 should not be treated merely as a "DPA provision."

It is really a processor governance framework.

77. The relationship with Article 5(2): Accountability

Article 5(2) requires accountability.

Article 28 operationalises accountability in the outsourcing context.

Suppose a regulator asks:

"Why did you select this processor?"

The controller should ideally be able to produce:

• due-diligence questionnaire;

• security documentation;

• risk assessment;

• certifications;

• audit reports;

• sub-processor review;

• contract;

• instructions;

• monitoring records.

This evidentiary trail demonstrates that processor selection was not arbitrary.

78. The relationship with Article 24

Article 24 imposes responsibility on the controller to implement appropriate measures and demonstrate that processing is performed in accordance with the GDPR.

A controller cannot realistically satisfy Article 24 if it has no idea:

• where its processor stores data;

• who accesses it;

• which sub-processors are involved;

• what security controls exist;

• what happens after termination.

Article 28 therefore functions as one of the mechanisms through which Article 24 accountability is made operational.

79. The relationship with Article 32

Article 32 concerns security of processing.

Article 28 ensures that processor security becomes part of the controller's governance architecture.

A controller therefore needs to ask:

"What security controls does my processor implement?"

rather than:

"Is my own organisation secure?"

Because the controller's security perimeter includes outsourced processing.

80. The relationship with Articles 33 and 34

The controller generally bears the legal obligation to determine whether a breach must be notified.

But the processor may be the first organisation to detect the incident.

Article 28 therefore creates the operational bridge.

For example:

Processor detects breach at 02:00

1. Processor immediately alerts controller
2. Processor provides technical facts
3. Controller assesses risk
4. Controller determines whether Article 33 notification is required
5. Controller determines whether Article 34 communication is required

The processor supplies the information.

The controller performs the legal assessment.

81. The relationship with Articles 35 and 36

The same principle applies to DPIAs.

The controller is responsible for deciding whether a DPIA is required and conducting it.

But the processor may have the technical information necessary to assess:

• architecture;

• data flows;

• access;

• security;

• retention;

• sub-processing;

• risks.

Article 28 ensures that the processor cannot simply say:

"That's your DPIA. We don't help."

82. The relationship with Articles 44 onwards

International transfers are one of the most difficult Article 28 issues.

Suppose a controller appoints a processor in the EU.

The processor uses a sub-processor in the United States.

The question is not simply:

"Do we have an Article 28 DPA?"

The controller must also ask:

"What Chapter V transfer mechanism applies?"

Possible mechanisms may include:

• adequacy;

• appropriate safeguards;

• applicable derogations in limited circumstances.

Article 28 controls the processor relationship.

Chapter V controls the international transfer.

The two regimes operate together.

83. A processor's location is not the whole transfer analysis

Another common misconception is:

"The processor is located in the EU, so there is no transfer issue."

That may be incomplete.

If EU-based Processor A makes personal data available to a third-country entity or allows relevant processing by a third-country sub-processor, the international-transfer rules may become relevant depending on the circumstances.

The actual data flow and access arrangements must therefore be mapped.

84. Article 28 and AI providers

Article 28 has become particularly important for AI services.

Consider:

Company A

uses an AI service from

Provider B

to analyse customer support tickets.

The first question is:

Is B actually acting only on A's behalf?

Suppose B uses the tickets to train its own general-purpose commercial model.

That introduces a new purpose.

The analysis under Article 28(10) becomes critical.

The parties cannot simply label B a "processor" and assume the issue disappears.

The controller must examine:

• training;

• retention;

• model improvement;

• human review;

• data reuse;

• logging;

• telemetry;

• sub-processors;

• international access.

85. Example: SaaS analytics platform

Suppose Company A uploads employee performance information to an analytics platform.

The platform contract says:

"We process the information solely to provide analytics services."

But elsewhere the provider reserves a right to:

"use customer data to improve our products."

This creates a significant legal question.

Is "improve our products" merely technical service delivery?

Or does it constitute an independent purpose?

The answer depends upon the actual operation, the nature of the information, and the extent of the provider's independent decision-making.

This is precisely why controller-processor classification cannot be performed by looking only at labels.

86. A difficult borderline case: independent expertise

Suppose a processor is a sophisticated cybersecurity provider.

The controller instructs:

"Protect our database."

The processor chooses:

• intrusion-detection technology;

• encryption;

• threat intelligence;

• monitoring systems;

• technical architecture.

Does this make the processor a controller?

Normally, no.

The processor is using professional expertise to determine technical means.

The purpose remains:

protecting the controller's database on the controller's behalf.

The distinction between technical implementation autonomy andpurpose autonomy is therefore essential.

87. Another difficult case: professional service providers

Not every organisation that receives personal data is necessarily a processor.

Suppose a company gives employee information to an independent lawyer.

The lawyer may determine professional purposes and means governed by legal obligations and professional duties.

The lawyer may therefore not fit neatly into an Article 28 relationship.

Similarly, independent accountants, auditors, doctors, lawyers and other professionals require fact-specific analysis.

The question remains:

Is the recipient genuinely processing personal data on behalf of the controller under the controller's instructions?

If not, Article 28 may not be the correct framework.

88. Another difficult case: group companies

Corporate groups often create confusion.

Suppose:

Parent Company A

appoints

Subsidiary B

to provide HR services.

The fact that B is within the same corporate group does not automatically make it a processor.

The same functional analysis applies.

If B independently determines purposes, it may be a controller or joint controller.

If B merely processes on A's behalf, it may be a processor.

Corporate ownership is not determinative.

89. Another difficult case: mandatory service providers

Suppose a controller is legally required to use a particular government-mandated service provider.

Can it meaningfully "choose" the processor?

The wording of Article 28(1) raises difficult questions in such circumstances.

The important point is that processor status itself cannot be created merely by calling the entity a processor.

Where another legal framework determines who controls the processing, the GDPR role analysis must consider that legal framework.

The Article 28 contractual requirement must then be reconciled with the relevant statutory framework.

90. Article 28 and bargaining power

Large technology providers often present standard terms.

A small controller may have little negotiating power.

But commercial inequality does not eliminate the controller's GDPR responsibilities.

The controller cannot defend itself by saying:

"The vendor forced us to accept its DPA."

The controller remains responsible for assessing whether the processor provides sufficient guarantees.

If the contractual arrangement is incompatible with Article 28, commercial inconvenience does not automatically excuse the problem.

91. Common mistake: treating the DPA as the entire compliance programme

A DPA is important.

But:

DPA ≠ Article 28 compliance in its entirety.

A controller can have an excellent DPA and still violate Article 28 by:

• selecting an inadequate processor;

• failing to conduct due diligence;

• ignoring a serious security deterioration;

• failing to monitor sub-processors;

• accepting unlawful processing;

• failing to conduct required audits;

• failing to manage termination.

Similarly, a processor can sign a beautiful DPA and then violate it in practice.

92. Common mistake: assuming certification proves everything

As discussed above:

certification = evidence

not:

certification = automatic compliance.

The controller still needs to assess relevance and scope.

93. Common mistake: assuming the processor is responsible for everything

The processor does not become the controller merely because it:

• stores the data;

• technically accesses the data;

• operates the software;

• selects technical security tools.

The controller remains responsible for determining the purposes and essential means.

94. Common mistake: assuming the controller is responsible for everything

The reverse is also wrong.

The processor has direct statutory duties.

A processor cannot defend itself by saying:

"We only followed the contract."

If it:

• violates instructions;

• fails to maintain security;

• unlawfully appoints a sub-processor;

• refuses required assistance;

• fails to delete data;

• independently determines purposes;

Article 28 may be directly engaged.

95. Common mistake: treating sub-processors as the processor's private business

They are not.

The controller needs meaningful visibility into the processing chain.

This is especially important where the chain contains:

• third-country entities;

• AI providers;

• cloud infrastructure;

• data analytics companies;

• remote support teams.

96. Common mistake: using a generic DPA

A generic DPA may state:

"Processor processes personal data for business purposes."

That tells the parties almost nothing.

A useful Article 28 agreement should answer:

• What data?

• Whose data?

• Why?

• What operations?

• For how long?

• Where?

• Who accesses?

• Which sub-processors?

• What security?

• What transfers?

• What happens on termination?

• How are rights requests handled?

• How are incidents handled?

• How can the controller audit?

97. A model analytical framework for Article 28 problems

When faced with an Article 28 problem, ask the following questions in sequence.

Step 1: Is personal data being processed?

If not, Article 28 does not apply.

Step 2: Is the activity actually processing?

Apply Article 4(2).

Step 3: Who determines the purposes?

That is central to controller status.

Step 4: Who determines the essential means?

This helps distinguish controller from processor.

Step 5: Is the recipient acting on behalf of another entity?

If yes, processor status becomes possible.

Step 6: Has the controller selected an appropriate processor?

Examine sufficient guarantees.

Step 7: Is there an Article 28-compliant arrangement?

Check the mandatory content.

Step 8: Are there sub-processors?

If yes, examine authorisation.

Step 9: Are international transfers involved?

Apply Chapter V separately.

Step 10: Does the processor have adequate security?

Apply Articles 28 and 32.

Step 11: Can the processor assist with rights?

Examine Articles 12, 22.

Step 12: Can it assist with breaches and DPIAs?

Examine Articles 32, 36.

Step 13: What happens at termination?

Examine return/deletion.

Step 14: Can the controller demonstrate compliance?

Examine Article 5(2), Article 24 and Article 28(3)(h).

Step 15: Has the processor independently determined purposes?

If yes, Article 28(10) becomes critical.

98. The most important conceptual distinction: instructions versus independent purposes

Almost every difficult Article 28 question ultimately comes back to this distinction.

Imagine a processor receives customer data.

It may:

sort the data according to the controller's instructions.

It may:

store the data using its own technical architecture.

It may:

encrypt the information using its own technology.

It may:

allocate computing resources according to operational needs.

But it should not independently decide:

"We will use these customer profiles to build our own advertising database."

The first category concerns implementing the controller's processing.

The second introduces an independent purpose.

That is the boundary Article 28 protects.

99. The Article 28 "control paradox"

There is a subtle paradox within processor relationships.

The processor needs enough autonomy to perform sophisticated technical services efficiently.

But it cannot have so much autonomy that it becomes the real decision-maker concerning purposes and essential means.

Thus Article 28 attempts to create:

operational autonomy without purposive autonomy.

A cloud provider may decide how to implement a service.

An analytics provider may choose technical algorithms within the agreed purpose.

A cybersecurity provider may select security tools.

But the processor should not independently redefine why the data are being processed.

This is one of the most useful conceptual tools for understanding difficult controller-processor classifications.

100. The significance of Opinion 22/2024

The EDPB's 2024 Opinion is especially important because processor chains have become substantially more complex since the GDPR was enacted.

The Opinion addresses questions concerning:

• identification of processors and sub-processors;

• sufficient guarantees;

• controller oversight;

• sub-processor selection;

• contractual arrangements;

• onward transfers;

• accountability.

The EDPB emphasised that controllers should have information concerning the identity of all processors and sub-processors readily available, and that the ultimate decision concerning engagement of a specific sub-processor remains with the controller. (European Data Protection Board)

This is highly relevant to modern cloud and SaaS environments.

A controller should therefore resist the idea that:

"Our processor uses hundreds of vendors, so we don't need to know who they are."

The complexity of the processor's ecosystem does not eliminate the controller's Article 28 obligations.

101. Article 28 and accountability in the modern cloud environment

Modern cloud processing illustrates why Article 28 is so important.

A company may believe it has selected:

"one cloud provider."

But technically the provider may rely upon:

• data centres;

• infrastructure providers;

• security providers;

• support providers;

• monitoring services;

• CDN providers;

• identity providers;

• backup providers;

• AI services.

The controller therefore needs sufficient visibility to understand the actual processing chain.

Article 28 is essentially a legal mechanism for preventing the outsourcing black box.

102. Article 28 as a supply-chain governance provision

It is therefore useful to think of Article 28 as a form of privacy supply-chain governance.

The controller must know:

Who processes?

What do they process?

Why?

Where?

How?

Who else processes it?

What safeguards exist?

What happens if something goes wrong?

What happens when the relationship ends?

That is the deeper function of Article 28.

103. Practical example: HR outsourcing

Consider:

Company A employs 10,000 employees.

It hires Company B to operate payroll.

B receives:

• employee names;

• addresses;

• bank information;

• tax information;

• salary;

• employment information.

B uses cloud provider C.

C uses infrastructure provider D.

Article 28 analysis

A must assess B's sufficient guarantees.

A and B need an Article 28 arrangement.

B must obtain authorisation for C.

C must be contractually bound by appropriate data-protection obligations.

D must be appropriately addressed within the processing chain.

Security requirements must be established.

B must assist A with:

• employee access requests;

• correction;

• deletion where legally applicable;

• breaches;

• DPIAs where relevant;

• audits.

At termination:

• payroll data must be returned or deleted, subject to legally required retention.

If B starts using employee salary information to build its own commercial analytics product:

Article 28(10) becomes potentially decisive.

This single example demonstrates how virtually every paragraph of Article 28 interacts with the others.

104. Practical example: customer-support call centre

Company A operates an e-commerce platform.

It hires Company B for customer support.

B can access:

• customer names;

• orders;

• addresses;

• complaints;

• payment-related information;

• communication records.

B uses C for transcription.

Questions

Is B a processor?

Probably, assuming it acts solely on A's behalf.

Is C a sub-processor?

Potentially, if C processes personal data on B's behalf.

Can B appoint C without A's authorisation?

No.

Can B use customer conversations to train its own unrelated commercial model?

That requires separate analysis and may make B a controller for that independent processing.

Can A simply rely on B's ISO certificate?

No.

Does B need confidentiality arrangements?

Yes.

Does B need security?

Yes.

Does B need to assist with data-subject requests?

Yes.

Does B need to cooperate with audits?

Yes.

This demonstrates why Article 28 should be read as a system rather than as isolated contractual clauses.

105. Practical example: processor receives an unlawful instruction

Company A instructs processor B:

"Retain all customer recordings indefinitely."

B believes this conflicts with GDPR requirements.

B should notify A.

A reassesses.

If A corrects the instruction, processing can continue according to the corrected instruction.

If A insists on unlawful processing, B's contractual and statutory exposure increases.

The contract should ideally specify what happens in such circumstances.

106. Practical example: processor breach

Processor B suffers ransomware.

B discovers:

• customer records were encrypted;

• some data may have been exfiltrated;

• logs are incomplete.

B must provide information to A without undue delay.

A must assess:

• whether a personal-data breach occurred;

• likelihood of risk;

• whether supervisory-authority notification is required;

• whether communication to affected individuals is required.

B should assist with technical facts.

A remains responsible for the legal notification decision.

107. Practical example: processor termination

A terminates B's contract.

B has:

• production database;

• backup copies;

• archived records;

• disaster-recovery replicas.

A chooses deletion.

B must implement appropriate deletion, subject to lawful retention requirements.

A should ideally receive confirmation or evidence of deletion.

This is why Article 28 should be drafted with lifecycle management in mind.

108. The deeper significance of Article 28

Article 28 ultimately reflects a fundamental principle of modern data protection law:

Responsibility follows decision-making, but protection must follow the data throughout the processing chain.

The controller is the principal decision-maker.

The processor is the operational actor.

The sub-processor is a delegated operational actor.

But the rights of the data subject do not become weaker simply because processing has been outsourced.

That is the central policy objective.

109. Article 28 does not make outsourcing impossible

The GDPR does not prohibit outsourcing.

Quite the opposite.

It recognises that modern organisations need specialised providers.

Article 28 therefore creates a framework under which outsourcing can occur without sacrificing data protection.

The provision attempts to balance:

Commercial reality

Organisations need:

• cloud computing;

• SaaS;

• payroll;

• customer support;

• hosting;

• security;

• analytics.

with:

Fundamental rights

Individuals need:

• confidentiality;

• security;

• transparency;

• control;

• rights enforcement;

• protection against secondary use.

Article 28 is the bridge between the two.

110. Final synthesis

Article 28 should not be understood merely as:

"Sign a Data Processing Agreement."

That is far too narrow.

Its real structure is:

1. Choose carefully

The controller must select only processors providing sufficient guarantees.

2. Define the relationship

The processing must be governed by a binding legal arrangement.

3. Specify the processing

The agreement must identify the subject matter, duration, nature, purpose, data and data subjects.

4. Control instructions

The processor must act on documented instructions.

5. Protect confidentiality

Authorised personnel must be bound by confidentiality.

6. Secure the processing

Article 32 measures must be implemented.

7. Control subcontracting

Sub-processors require prior authorisation and appropriate flow-down obligations.

8. Preserve data-subject rights

The processor must assist the controller.

9. Support security governance

The processor must assist with Articles 32, 36.

10. End processing properly

Data must be returned or deleted as instructed, subject to lawful retention.

11. Permit accountability

The controller must receive sufficient information and have meaningful audit mechanisms.

12. Challenge unlawful instructions

The processor must alert the controller to potentially unlawful instructions.

13. Maintain the chain

Sub-processors must receive functionally equivalent data-protection obligations.

14. Use certification intelligently

Codes and certifications can demonstrate guarantees but do not eliminate due diligence.

15. Use standard clauses where appropriate

Standard contractual mechanisms can structure the relationship but do not replace case-specific analysis.

16. Keep it written

The Article 28 arrangement must be in writing, including electronic form.

17. Watch for role transformation

If the processor independently determines purposes and means, it may become a controller for that processing.

111. The ultimate legal test

When analysing an Article 28 problem, the strongest question is not:

"Does the contract call the company a processor?"

Nor is it:

"Does the company physically handle the data?"

The correct sequence is:

Who determines why the processing occurs?

Then:

Who determines the essential means?

Then:

Is the other party genuinely acting on behalf of that decision-maker?

Then:

Has the controller selected a processor providing sufficient guarantees?

Then:

Has the relationship been properly governed under Article 28?

Then:

Does the processor remain within the controller's instructions?

Then:

Are all sub-processors appropriately authorised and governed?

Then:

Can the controller actually demonstrate oversight?

Finally:

Has the processor crossed the line into independently determining purposes or essential means?

That final question is what prevents Article 28 from becoming a contractual fiction.

The deepest principle running through the entire provision is therefore:

A controller cannot escape GDPR responsibility by outsourcing processing, and a processor cannot escape controller-level responsibility by calling itself a processor when it actually determines its own purposes.

Article 28 consequently operates simultaneously as a vendor-selection rule, contractual governance rule, supply-chain control mechanism, accountability mechanism, security mechanism, data-subject-rights mechanism and role-classification safeguard.

That is why it is considerably more important than the familiar phrase "have an Article 28 DPA" suggests.

For primary study, the most authoritative materials to keep alongside this commentary are the EDPB's final Guidelines 07/2020 andOpinion 22/2024, together with the official GDPR text and the Commission's 2021 Article 28 standard contractual clauses. EDPB Guidelines 07/2020 EDPB Opinion 22/2024 Official GDPR text on EUR-Lex Commission Implementing Decision 2021/915