Data controller vs processor in a software project: who decides what

TL;DR — In most agency-built software projects, you, the customer, are the data controller (the party that decides why and how personal data is used), and the agency is usually a processor (the party that handles personal data on your instructions). The most useful practical test is: who decides the purpose of the data use? If that is you, you are the controller; then list every vendor that touches the data and decide whether each is your processor, a separate controller, or both in different contexts. Reading time: ~7 min

What it is and where it sits

“Data controller” and “data processor” are privacy-law roles. They matter because they decide who must do what: privacy notices, legal basis, retention rules, deletion handling, security instructions, and contracts such as a DPA (Data Processing Agreement).

The simple meaning

• Controller: the party that decides why personal data is collected and what for.
• Processor: the party that handles personal data for the controller, following instructions.
• Subprocessor: a processor hired by another processor to help deliver the service.

In a typical software project:

• Your company decides why users sign up, why orders are stored, why support emails are kept, and how long customer records should exist. That usually makes your company the controller.
• The software agency builds and operates the app for you, stores data in systems it manages for you, and accesses data to support the service. That usually makes the agency the processor.
• Cloud hosting, email delivery, backups, monitoring, and support tools are often subprocessors used by the agency or processors used directly by you, depending on whose contract they sit under.

Where it sits in the architecture

This is not a software component like a database or API. It is a way of assigning responsibility across the systems in your stack.

A typical request/data flow looks like this:

[End User] ---- 1. submit form ----> [Web App]
                                   |
                                   | 2. store customer record
                                   v
                              [Database]
                                   |
                                   | 3. agency operates app
                                   v
                              [Software Agency]
                                   |
                                   | 4. uses hosting/email vendors
                                   v
                     [Cloud Host] ----> [Email Service]

[Your Company] ---- 5. decides purpose, fields, retention ----> [Web App]

The key point is that the role is determined less by “where the server lives” and more by “who decides the purpose and essential means” (the important choices about the use of the data).

What it replaces

Many teams start with a vague idea like “the agency has the database, so they must own the data.” That is usually wrong. Hosting or technical control does not automatically make someone the controller. The controller is usually the business deciding why the data exists in the first place.

How it actually works

Let’s walk one realistic example end to end.

Example: a customer portal for appointment booking

Your company runs a clinic. An agency builds and maintains a web app where patients book appointments. The app stores names, email addresses, phone numbers, appointment times, and notes. It sends confirmation emails and gives your staff an admin dashboard.

Step by step:

1. You define the service

   • You tell the agency: “We need online booking, reminders, and a staff dashboard.”
   • You choose what data to collect: name, contact details, appointment reason.
   • You decide why it is collected: to book and manage appointments.
   • You decide retention: for example, keep booking records for a defined period.
   • Result: you are acting as controller.

2. The agency implements your instructions

   • The agency creates the forms, database tables, admin screens, and email templates.
   • The agency can access production data to fix bugs or support the system.
   • But the agency is not deciding to use patient data for its own business purpose.
   • Result: the agency is acting as processor.

3. The app stores data in infrastructure

   • The agency deploys the app to a cloud host and stores records in a managed database.
   • The cloud provider processes the data because it stores and transmits it.
   • If the agency chose and manages that hosting under its own service delivery, the cloud provider is usually the agency’s subprocessor.

4. The app sends confirmation emails

   • The app passes email address, appointment time, and template data to an email delivery service.
   • If that service is used only to send your messages on your behalf, it is usually a processor/subprocessor in that activity.

5. A patient asks for deletion

   • The patient contacts your clinic, not the agency, asking for deletion or access.
   • You decide whether the request should be fulfilled, partially restricted, or retained for legal reasons.
   • You instruct the agency to delete or export the data from the app and backups where feasible under your policy.
   • Result: this is controller-led decision making, processor-led execution.

6. The agency uses logs for security

   • The agency may keep access logs, error logs, or audit logs to secure and operate the service.
   • Usually this is still processor activity if done to deliver the service under your instructions and contract.
   • But if the agency uses data for its own independent purpose, such as building a marketing list from your users, it may become a separate controller for that activity and likely create a serious compliance problem.

The practical test through the whole example is consistent: who chose the purpose? Booking care appointments is your purpose, so you are the controller.

When to use it (and when not to)

You should classify controller/processor roles whenever personal data appears anywhere in the project: forms, CRM syncs, support tickets, analytics, logs, email, backups, or admin tools.

Decision table

You probably don’t need a long debate about this if...

• The app clearly exists to run your business process, for your customers or staff.
• The agency does not decide the business purpose of the data.
• The agency contract already says the agency processes personal data only on your documented instructions.

You do need to look closer if...

• The agency wants broad rights to “use project data to improve services.”
• There is shared product development across multiple customers.
• Data is fed into third-party analytics, AI, fraud, or advertising systems.
• The same vendor appears in multiple roles depending on the feature.

Trade-offs

This classification is useful, but it has costs.

A common mistake is treating role classification as paperwork only. It affects real architecture choices: where data is stored, who can access production, which vendors are allowed, and who can approve new uses of data.

In practice

Below are two practical artifacts you can adapt today: a data-flow register and a contract clause checklist.

Example 1: a simple role register for your project

Use a spreadsheet or internal document. This CSV format is enough to start.

system_or_vendor,what_data,who_decides_purpose,likely_role,contract_owner,notes
Main web app,"name,email,orders",Your Company,Controller,Your Company,"Business decides fields and retention"
Software agency,"all app data for support and maintenance",Your Company,Processor,Your Company,"Access limited to support and change requests"
Cloud hosting,"database contents,logs,backups",Your Company via Agency,Subprocessor,Agency,"Only if agency contracts with host"
Email delivery,"email address,transactional message data",Your Company,Processor,Your Company,"If you contract directly with email vendor"
Analytics tool,"IP,cookie ID,events",Depends on setup,Needs review,Your Company,"May be processor or separate controller"

What it does: this gives you a one-page map of who is doing what. The gotcha: do not fill the “likely_role” column by vendor type alone; the same analytics or email vendor can be a processor in one setup and a separate controller in another.

Example 2: a processor instruction clause checklist

Put this into your contract review notes or statement of work. It is not legal advice, but it helps you ask the right questions.

{
  "processor_instructions": [
    "Process personal data only to deliver and support the project services described in the SOW.",
    "Do not use customer personal data for the agency's own marketing, product training, or unrelated analytics.",
    "Allow access to production data only for named support, security, and maintenance tasks.",
    "Keep a current list of subprocessors and notify the customer before material changes.",
    "Assist the customer with access, deletion, correction, export, and incident response requests.",
    "Delete or return personal data at contract end, except where law requires retention.",
    "Apply encryption, access control, logging, and backup measures appropriate to the service."
  ]
}

What it does: this turns the controller/processor split into concrete operating rules. The gotcha: “appropriate security” is too vague on its own; pair it with your actual controls list in the SOW, security schedule, or vendor questionnaire.

Example 3: internal handoff note for the agency

If you want the agency to act only on your instructions, say so plainly in project operations.

project: patient-booking-portal
controller: Your Company Ltd
processor: Example Agency Ltd
approved_purposes:
  - appointment booking
  - transactional email reminders
  - support and maintenance
forbidden_uses:
  - agency marketing
  - model training on production user data
  - cross-client benchmarking using identifiable records
support_access:
  production_access: ticket-approved
  emergency_access: incident-only
  retention_days_for_support_exports: 30
subprocessors:
  - cloud hosting
  - managed database
  - email delivery
  - error monitoring

What it does: this is a practical operating note the delivery team can follow. The gotcha: if this says one thing and the contract says another, the contract usually wins, so align both.

⚠️ If you change contracts, retention rules, or deletion procedures in a live system, you can create downtime or permanently remove records. Review the impact with the agency before changing production settings or instructing bulk deletion.

A practical checklist you can do this week

1. Open your project documents and list every system that touches personal data.
2. For each one, answer in one sentence: “Why does this data exist?”
3. Mark who decided that purpose: your company, the agency, or the vendor.
4. In your provider’s dashboard or contract folder, find who holds each vendor contract.
5. Ask the agency for its current subprocessor list.
6. Compare the list against your privacy notice, DPA, and retention policy.

If you only do one thing, do steps 1-3. That usually makes the controller/processor split obvious.

Further reading

• European Data Protection Board Guidelines 07/2020 on the concepts of controller and processor in the GDPR
• UK ICO guidance on Controllers and Processors
• GDPR Article 4 and Article 28
• NIST Privacy Framework
• The "How to choose your service providers" sections of your external privacy counsel or DPO playbook

This article was written by an AI system and published pending human review. Verify anything you intend to act on.