← All posts

Controller or Processor? How Irish SMEs Work Out Their GDPR Role

If a customer questionnaire, a tender or an insurer has asked whether you are a "data controller or data processor", the short answer is this: you are a controller for personal data where you decide why and how it is used, and a processor where you handle it only on another organisation's instructions. Most SMEs are both, depending on the activity. A payroll provider is a processor for its clients' payroll and a controller for its own staff and marketing lists. The role belongs to the processing activity, not to the company.

Getting it right matters for two of the jobs you are probably trying to do: answering a customer security questionnaire and passing an audit. A wrong answer ends up in a contract, a privacy notice and a record of processing, where it is hard to unpick.

Key Takeaways

  • A controller decides the purposes and means of processing. A processor acts on the controller's behalf and on its documented instructions.
  • Your role is set by what you actually do with the data, not by what the contract calls you.
  • Most SMEs are controllers for their own staff and customer data, and processors when they serve other businesses.
  • Article 28 requires a written contract between controller and processor, and processors need the controller's authorisation for sub-processors.
  • A processor that starts deciding its own purposes is treated as a controller for that processing.

Table of Contents

The two roles in plain English

The Irish Data Protection Commission describes a controller as the person or legal entity that determines the purposes and means of processing personal data, and says most GDPR compliance responsibilities rest with it. A processor carries out processing on behalf of the controller and in accordance with its instructions. An employee of the controller is not a processor.

Two words do the work: purposes and means. The purpose is why the data is processed. The means is how. The EDPB's SME guide puts it as the "why and how" of a processing operation.

A simple example. You run a 60-person engineering firm and use an external payroll bureau. You decide that staff must be paid, what data is needed and for how long it is kept. The bureau runs the payroll the way you tell it to. You are the controller, the bureau is the processor.

Now reverse it. Your firm builds booking software for dental clinics. The clinics decide who gets reminders and what the patient records are used for. You host and process that data on their behalf. For that activity you are the processor, and the clinics are the controllers.

The two roles in plain English

The test: five questions to ask about each activity

The EDPB Guidelines 07/2020 say that controllership can come from law or from the factual circumstances of the case. A contract helps to identify the controller but is not always decisive. So start with facts, activity by activity:

  1. Who decided this processing should happen at all? The organisation that made that decision is usually the controller.
  2. Who benefits from the result? If the data serves your own business purpose, you are probably a controller.
  3. Who chose which categories of data are collected and from whom? These are essential choices, and they sit with the controller.
  4. Who decides how long the data is kept and who gets it? Again, a controller decision.
  5. Could the supplier use the data for its own reasons? If so, it is acting as a controller for that use.

The guidelines make one useful distinction. A controller must decide the essential means, which are closely tied to purpose. Practical matters such as which hardware or software is used, or how security is implemented, can be left to the processor. The same guidelines note that a controller does not need to have access to the data to be a controller. A clinic that never looks inside your hosting platform is still the controller of its patient data.

The four situations SMEs get wrong

1. Calling yourself a processor because the software does the work

Using a tool does not make you a processor. If you choose to send newsletters to your customers using an email platform, you are the controller and the platform is your processor. Your obligations do not move to the supplier.

2. A processor that goes beyond its instructions

The EDPB guidelines are clear that a processor infringes the GDPR if it goes beyond the controller's instructions and starts determining its own purposes and means. For that processing it is then considered a controller, and it may face sanctions for exceeding its instructions. For a software or managed service firm, this is the practical risk: using customer data to train your own models, build benchmarks or sell insights is your own purpose, not your customer's.

3. Groups of companies

Two companies in the same group are separate legal entities. As INPLP commentary on the EDPB guidelines explains, one group company can be a processor for another acting as controller. Two departments of the same legal entity cannot be controller and processor to each other, and a controller using its own staff is not in a processor situation.

4. Joint controllers and successive controllers

Where two or more controllers jointly determine purposes and means, Article 26 GDPR makes them joint controllers. They must set out their respective responsibilities in a transparent arrangement, in particular for data subject rights and for the information given under Articles 13 and 14. The essence of the arrangement must be available to the individuals concerned.

Not every shared dataset is joint control. The same INPLP commentary points out that where several actors process the same data in a chain, each with its own purpose and means, and without joint participation in the same processing, they are successive independent controllers. A retailer that passes order data to a courier, which then uses it to deliver and for its own records, is an example to consider carefully for each part of the flow.

Joint and successive controller roles compared

Where roles are unclear, the answer can depend on legal interpretation. Take legal advice before you settle the wording in a contract that carries real risk.

What a controller owes

The EDPB SME guide lists a controller's responsibilities. In summary, the controller must:

  • comply with the Article 5 principles and uphold individuals' rights;
  • keep records of processing and secure the processing;
  • choose an appropriate processor and bind it in a contract;
  • notify personal data breaches to the supervisory authority and, where required, to individuals;
  • build in data protection by design and by default;
  • carry out data protection impact assessments when necessary;
  • appoint a data protection officer when necessary;
  • comply with the rules on international transfers.

If you are a controller, our guides on building a record of processing activities, data mapping and whether you need a DPO cover the practical work. The wider GDPR compliance checklist puts it in order.

What a processor owes

A processor has fewer duties than a controller, but they are direct. The University of Galway's guide for health researchers summarises them: process only on the controller's instructions, sign a binding contract, engage no sub-processor without written permission, apply appropriate technical and organisational security, and in a breach notify the controller without undue delay and assist it.

The breach point is in Article 33(2) GDPR. It is the one that catches smaller suppliers out. The controller's own 72-hour clock to the Data Protection Commission is only workable if its processors tell it quickly. If you are a processor, agree in advance who you call and what you send. Our guide to the first 72 hours of a breach shows what the controller needs from you.

The DPC's page on controller and processor relationships adds that the processor must assist the controller with data subject rights requests, security under Article 32, breach notification under Articles 33 and 34, and impact assessments under Articles 35 and 36.

The Article 28 contract: what must be in it

When one organisation processes personal data for another, Article 28 GDPR requires a binding contract. The DPC states that it must, at a minimum, set out:

  • the subject matter, duration, nature and purpose of the processing;
  • the type of personal data and the categories of data subjects;
  • the obligations and rights of the controller.

It must also contain mandatory terms. The processor only processes on the controller's documented instructions. People handling the data are bound by confidentiality. The processor takes the security measures required by Article 32. It obtains prior specific or general written authorisation for any sub-processor.

A quick review of any contract you receive:

Check Where it goes wrong
Subject matter and duration Left generic, or tied to a master agreement that has expired
Types of data and data subjects "All data" with no categories listed
Documented instructions Instructions exist only in an email thread nobody can find
Sub-processor authorisation A list that was true two years ago
Breach notification "Promptly" with no contact or timescale
Return or deletion at the end No process, so data lingers on the supplier's systems

Estimate about an hour per supplier to read the terms and match them to this table, and longer for the large ones.

Sub-processors: the chain of responsibility

The DPC says sub-processors are bound by the same data protection obligations as the processor, and the processor stays directly liable to the controller for the sub-processor's performance. Even where the controller has given general written authorisation, the processor must tell it about new or replaced sub-processors and give it the chance to object, as IAPP commentary on Article 28 explains. The same commentary notes that the burden is on the controller to vet processors for sufficient guarantees.

If you resell or build on third-party infrastructure, map it. An Irish business choosing cloud services for a small business or a SaaS team designing its GDPR approach for a SaaS product both need the same list: each supplier, what data it touches, where it sits and what the contract says.

Which of the four jobs are you doing?

Answering a customer questionnaire. The question "are you a controller or a processor?" is rarely a yes or no. Answer by activity: processor for customer data you host or handle for them, controller for your own staff, prospects and website visitors. Attach the Article 28 terms you offer.

Passing an audit. Auditors look for consistency. Your record of processing, privacy notices and supplier contracts should describe the same roles. A processor-side record under Article 30 differs from a controller's, so check which one you hold.

Reporting to the board. Give directors one page: the activities where you are controller, where you are processor, the top suppliers and the open gaps in contracts. Directors need to see who is accountable for which data.

Handling an incident inside the regulator's clock. The role decides who notifies whom. A controller notifies the supervisory authority, in Ireland the Data Protection Commission. A processor notifies the controller. If the role is unsettled when a breach happens, you lose hours you do not have.

What to do this week

  1. List your processing activities (about 2 hours). Customers, staff, suppliers, website, marketing, plus anything you handle for clients.
  2. Mark the role for each (30 minutes). Use the five questions above. Note any activity you are unsure about and take legal advice on those.
  3. List suppliers that touch personal data (1 hour). Include the tools staff signed up to on their own.
  4. Find the contract for each (1 to 2 hours). Check it against the Article 28 table. Mark missing or out-of-date terms.
  5. Check your own customer contracts (1 hour). If you are the processor, confirm that instructions, sub-processors and breach contacts are written down.
  6. Write one page for the board (45 minutes). Roles, top ten suppliers, gaps and who owns closing them.

About a working day covers a business of 10 to 50 people. Larger firms with many suppliers will need longer.

Where ShieldIQ fits

ShieldIQ is an AI-powered GRC platform built in Ireland for teams without a security team: SMEs and the IT managers, operations directors and compliance leads inside them. It helps you assess, prioritise, document and evidence your GDPR position, with a supplier register, a record of processing and an AI policy drafter in one place. A first baseline assessment takes about 15 minutes, and the Starter plan is free with no card. Certification comes from an accredited body, not from ShieldIQ. Current plans are on the pricing page, and the ShieldIQ home page shows the frameworks covered.

ShieldIQ

Customer data is hosted in the EU (Ireland) on AWS, and AI analysis is processed by Anthropic (Claude), which does not train on customer data. The Trust & Privacy page sets out the detail. If you want a person alongside the software to review roles and contracts, our consulting services include a virtual CISO.

Perspective

Most role confusion we see in SME compliance work comes from treating "controller or processor" as a label for the whole company. It is a decision about each activity, and it should be written down once and reused: in the record of processing, the privacy notice, the supplier register and the questionnaire answers.

We built ShieldIQ for teams that do not have a security team. The aim is that the person who owns compliance can assess where they stand, draft the policies and keep the evidence in one place, instead of rebuilding the same spreadsheet for every customer who asks.

Sit in the CISO chair for a while and you learn that the roles question is really about time. When a customer asks, or a breach happens, the business that already knows who is controller and who is processor answers in minutes. The business that does not spends days finding out.

Matthew Lemon

FAQ

Can a company be both controller and processor?

Yes. The role depends on the processing activity. A software firm is typically a controller for its own employee and marketing data and a processor for the customer data it handles on instructions. Each activity should be assessed and recorded separately.

Do I need a contract with every processor?

Yes, where an organisation processes personal data on your behalf, Article 28 requires a binding contract with the mandatory terms. The Data Protection Commission lists the minimum content, including documented instructions, confidentiality, Article 32 security and sub-processor authorisation.

What happens if a processor uses the data for its own purposes?

It is then treated as a controller for that processing, according to the EDPB guidelines, and may face sanctions for going beyond the controller's instructions. Controllers should keep their instructions clear and documented.

Who notifies the Data Protection Commission of a breach?

The controller does. A processor must tell the controller without undue delay, and help it meet its obligations. Agree the contact, the format and the timing in the contract before an incident happens.

Sources

Recommended