Understanding the rules for data processors and controllers

Article 28 of the General Data Protection Regulation (GDPR) is one of the most practical parts of the law. It explains what needs to happen when a company (the “controller”) hires another company (the “processor”) to handle personal data on its behalf.

If you remember nothing else, remember this: Article 28 is about making sure everyone knows who is responsible for what when data is being handled.

1. Who’s who

• Controller = the organisation that decides why and how personal data is processed.
  Example: a retailer collecting customer information to manage online orders.
   
• Processor = the organisation that processes personal data for the controller, following their instructions.
  Example: a cloud provider that stores the retailer’s customer database.
   

Article 28 exists because controllers often rely on third parties, and GDPR wants to make sure that handing over data doesn’t mean sifting away from responsibility.

2. You must have a written contract

Whenever a controller uses a processor, there must be a written contract (often called a Data Processing Agreement, or DPA).

This contract is not just paperwork. It’s the legal backbone that defines:

• what personal data is being collected,
• why it’s being processed,
• how it should be handled, and
• what safeguards the processor must apply.

Without this contract, both parties are technically in breach of the GDPR.

3. What the contract must say

Article 28(3) lists the specific things that must go in the contract. Think of it as a checklist.

Your DPA must cover:

1.    Processing on instructions only
The processor must only act on written instructions from the controller. They can’t use or share data for their own reasons.

2.    Confidentiality
The processor must ensure staff handling data are bound by confidentiality agreements or duties.

3.    Security
The processor must take appropriate technical and organisational measures to protect the data (encryption, access controls, backups, etc.).

4.    Sub-processors
The processor cannot hire another processor (a “sub-processor”) without the controller’s written approval. If they do, the same GDPR-level terms must be passed down.

5.    Help with individuals’ rights
The processor must help the controller respond to data subject rights requests (access, deletion, correction, etc.).

6.    Help with security and DPIAs
The processor must assist with security breaches, data protection impact assessments (DPIA), and any consultations with regulators.

7.    End of contract
When the work ends, the processor must delete or return all personal data, unless law requires it to be kept.

8.    Audit rights
The processor must allow audits and inspections so the controller can check compliance.
 

4. Processors are not off the hook

Even though controllers hold most of the responsibility, processors have their own duties under GDPR.

They must:

• keep records of their processing activities (Article 30(2)), otherwise known as RoPA,
• notify the controller of data breaches without undue delay,
• only work with other processors who can guarantee GDPR-level protection, and
• possibly face fines directly if they misuse data.

So “we just follow orders” is not an excuse.

5. Why Article 28 matters in real life

Without clear contracts and responsibilities, privacy incidents can quickly become messy. Here’s why this article is important:

• It stops “buck-passing” when something goes wrong.
• It forces suppliers to prove they take privacy seriously.
• It protects data subjects because everyone in the chain is accountable.
• It gives controllers a legal route to act if a processor fails to protect data.

In short, it’s about trust, transparency, and traceability between partners.

6. Monday morning takeaways

If you’re a controller:

1. Check your contracts. Make sure every supplier handling personal data has a compliant DPA in place.
2. Review security standards. Ask processors for proof of their security measures and audits.
3. Keep records. You should know who processes what, where, and for how long.
4. Have a process for approvals. Make sure you formally approve any sub-processors your suppliers use.

If you’re a processor:

1. Follow instructions only. If you’re unsure, ask before acting.
2. Get your own contracts right. If you use sub-processors, ensure you pass the same obligations down.
3. Be ready for audits. Keep evidence of security and privacy practices.
4. Build a breach plan. Know how to report incidents quickly to your controller.

7. Keep it practical

GDPR compliance isn’t about paperwork alone. Make sure your teams working with data:

• know who the controller and processor are in each data flow,
• understand what data is being handled and why,
• have a simple register of all processors and sub-processors, and
• review contracts at least once a year.

Quick summary

In plain terms

Article 28 is GDPR’s version of a “trust but verify” rule. It lets controllers trust others with personal data, but only if they can show that those others are trustworthy, secure, and contractually bound to do the right thing.