Data Processor Contract Explained for UK GDPR Compliance
You've just started using a receipt app, forwarded payroll records to an accountant, or connected a bookkeeping platform to your business. Everyone involved seems trustworthy, so it's tempting to treat the arrangement as an informal handover. Under UK GDPR, trust alone isn't enough when another organisation processes personal data for you.
A data processor contract records what the supplier may do, whose instructions it follows, how information must be protected, and what happens when the relationship ends. Without that written framework, your business may be using a processor before the legal and operational boundaries are clear.
Introduction Why Your Business Cannot Process Data Without a Contract
A small business owner might photograph receipts and send them to an automated service. An accountant might upload client records to a cloud bookkeeping platform. A growing employer might give payroll information to an external provider. These ordinary decisions can move names, addresses, employee details, transaction information, or other personal data outside the organisation.
The UK Information Commissioner's Office says that whenever a controller uses a processor to process personal data, a written contract must bind the controller and processor. Both parties must be part of that agreement, and it must cover the processing scope, purpose, personal-data types, data-subject categories, and the controller's rights and obligations. See the ICO guidance on contracts between controllers and processors for the core requirement.
The practical rule: if a supplier will handle personal data on your instructions, put the contract in place before processing begins.
Why an informal arrangement creates risk
Suppose a receipt-processing supplier stores an image, extracts financial fields, and sends the results to your accounting system. If the contract doesn't describe those activities, nobody has clearly documented whether storage, OCR, synchronisation, support access, or deletion is permitted.
The controller still has responsibility for choosing a processor that offers sufficient guarantees and for issuing documented instructions. The processor also has duties under the contract and under data protection law. A friendly email saying “please process these receipts” cannot replace the detailed legal control required for the relationship.
For a practical overview of UK obligations affecting small businesses, see Snyp's guide to UK data protection. The important point is simple: a data processor contract isn't a ceremonial signature. It is the operating agreement for every system that receives, transforms, stores, or returns personal data on your behalf.
Understanding Controller and Processor Roles in Plain English
Start with the question, who decides why the data is being used? That party is usually the controller. The controller decides the business purpose, the information needed, and the instructions given to the service provider.
The processor performs the work for the controller. It might host records, extract information from documents, send emails, manage payroll, or synchronise accounting data. The processor doesn't get a free-standing licence to reuse the information for its own unrelated purposes merely because it has technical access.
A useful analogy is a shop owner and a courier. The shop owner decides what must be delivered, where it goes, and why the delivery is necessary. The courier carries out the task using the agreed instructions. The courier may choose practical delivery methods within the service, but it shouldn't change the purpose or use the parcels for an unrelated business activity.
Finding your role in a real workflow
You're likely the controller when your business decides to collect customer details, employee records, or expense documents for its own operations. A supplier becomes the processor when it handles those records only to provide the service you selected.
Ask these questions before signing:
- Purpose: Who decided why the information should be collected or analysed?
- Instructions: Can your business tell the supplier what processing is allowed?
- Independent use: Does the supplier decide its own purposes for using the data?
- Access: Will the supplier or its technology view, store, extract, transmit, or delete the information?
If the supplier independently decides the purpose and means of its own processing, the relationship may not be a straightforward controller-processor arrangement. Don't label every data-sharing relationship a processor relationship without examining what each party decides.
Sub-processors extend the chain
A processor may rely on another provider for cloud hosting, OCR, storage, customer support, or other functions. That downstream provider is a sub-processor if it processes personal data on the processor's behalf.
Under UK GDPR Article 28, the main arrangement must be governed by a written contract or binding legal act. Where a processor uses a sub-processor, a separate written contract must impose equivalent data-protection obligations. The ICO explanation of when a contract is needed sets out this chain-based approach.
For financial workflows, the same discipline applies to receipts and account information. Snyp's overview of financial data protection provides useful context for evaluating the systems that touch business records.
Required Clauses Every Data Processor Contract Must Include
A compliant data processor contract must describe the processing precisely enough for people to operate it, review it, and demonstrate what happened. The ICO identifies the required subject matter, duration, nature, purpose, data types, data-subject categories, and controller rights and obligations, alongside practical processor duties. See the ICO requirements for Article 28 contracts.
Define the processing boundaries
The contract should identify:
- Subject matter: what service the processor provides.
- Duration: how long processing lasts and what happens during transition or termination.
- Nature and purpose: the operations permitted, such as collection, extraction, storage, review, or synchronisation, and the reason for them.
- Personal-data types: for a receipt workflow, this might include receipt images and extracted financial fields.
- Data-subject categories: for example, customers, employees, suppliers, contractors, or business contacts.
- Controller obligations and rights: the instructions, oversight, approvals, and decisions retained by the controller.
These descriptions prevent a broad service label from hiding several different processing activities. “Bookkeeping support” may involve email access, document storage, manual review, exports, backups, and accounting synchronisation. Each relevant activity should fit within the agreed scope.
Turn legal duties into operating instructions
The processor must process personal data only on the controller's documented instructions. Those instructions should cover permitted purposes, access, transfers, retention, deletion, and any changes to the workflow.
People authorised to process the information must be bound by confidentiality commitments. The contract must also require appropriate technical and organisational security measures. Avoid relying on vague language if the service needs clear controls around access, encryption, account permissions, incident reporting, or support activity.
A contract should also require the processor to assist with data-subject rights and the controller's wider compliance duties. If an individual asks for access, correction, restriction, or deletion, the controller needs a workable route for finding and handling the relevant records.
Close the loop at the end
The processor must support return or deletion of personal data when the service ends, subject to any lawful reason for retention. The agreement should state how the controller requests this, what evidence is supplied, how backups are handled, and how the processor confirms completion.
Audit and inspection rights matter for the same reason. A controller needs a reasonable way to obtain information and assess whether the processor is meeting its obligations. The right should work in practice, using documentation, assurances, reports, or inspections appropriate to the risk and service.
Use your retention rules alongside the contract. A clear document retention policy can tell the supplier what should happen to records once their business purpose has ended.
Data Processor Contract Checklist and Sample Language You Can Use
A useful review starts with the actual workflow, not the document title. Open the supplier's DPA and check whether each clause answers what the system does, who can access the information, which providers sit behind it, and how the data leaves the service.
| Required Clause | What Good Looks Like | Red Flag If Missing |
|---|---|---|
| Subject matter and duration | Names the service, processing activities, start point, and end point | The agreement refers only to “services” without describing processing |
| Nature and purpose | Explains collection, extraction, storage, review, or synchronisation and why each occurs | The supplier can use data for broad or undefined purposes |
| Data types | Identifies images, extracted fields, contact details, account information, or other relevant data | The contract says “all customer data” with no useful detail |
| Data-subject categories | Identifies whose information may appear in the records | Nobody can tell whether employee, customer, or supplier data is included |
| Documented instructions | Sets out how instructions are issued, changed, recorded, and challenged | The processor can make material changes without approval |
| Confidentiality | Binds authorised personnel to confidentiality duties | Support or engineering access is not addressed |
| Security measures | Describes appropriate technical and organisational safeguards | “Industry standard security” appears without meaningful detail |
| Rights assistance | Explains how the processor helps locate, export, correct, restrict, or delete records | The controller must handle requests without supplier support |
| Sub-processors | Provides authorisation, change notification, equivalent obligations, and responsibility allocation | The processor can appoint unknown suppliers without a defined process |
| Return or deletion | States what happens at termination and how completion is evidenced | Data remains indefinitely after the relationship ends |
| Audit and inspection | Provides information and review rights suited to the processing | The controller has no route to verify compliance |
The sample language below is illustrative, not a substitute for legal review:
Processing instruction: “The processor shall process personal data only to provide the services described in the schedule and only in accordance with documented instructions from the controller.”
Sub-processor control: “The processor shall not appoint or replace a sub-processor without the authorisation process set out in this agreement and shall impose equivalent data-protection obligations by written contract.”
End of service: “At the controller's choice, the processor shall return or delete personal data at the end of the services and provide reasonable evidence of completion.”
If a supplier's template leaves a gap, ask for a schedule rather than accepting an informal promise. Record the processing inventory, approved sub-processors, instructions, retention position, and review owner with the signed agreement.
How Snyp Meets Data Processor Obligations in Real Workflows
A receipt workflow shows why a DPA must describe real data movement. A document doesn't “go into an app”. It may arrive through a message, pass through a secure transfer, undergo OCR and categorisation, appear in a review screen, and then synchronise with an accounting platform.
Follow the receipt through the system
Snyp accepts receipts and related documents through WhatsApp, email forwarding, or direct file upload, including JPEG, PNG, and PDF. The contract and processing schedule should identify those intake channels, the document types, and the instructions that permit the service to handle them.
The service then extracts information such as merchant, amount, date, tax, currency, and category before syncing results with accounting platforms such as Xero or QuickBooks. That means the agreed processing scope should cover both the original image and the resulting structured financial fields, not just “document management”.
Ask who touches the data
The controller should map each handoff:
- Receipt input: the customer or accountant sends the document.
- Secure transfer: the supplier receives it through the service.
- OCR and extraction: the system processes the image and creates financial fields.
- Controller review: an authorised person checks and approves the result.
- Accounting sync: approved information moves to the chosen accounting platform.
At each stage, ask whether a supplier, employee, cloud service, or sub-processor can access the information. The DPA should connect those participants to confidentiality, security, documented instructions, rights assistance, and deletion or return requirements.
A practical test: draw the data flow on one page. If the contract doesn't account for a box or arrow, ask why.
Snyp is one example of a receipt-capture workflow that combines document intake, extraction, categorisation, review, and accounting synchronisation. The same evaluation method applies to any SaaS provider. Request its DPA, inspect the sub-processor information, confirm the permitted purposes, and check whether the end-of-contract process matches your retention policy.
Keeping Your Contract Current When UK Law Changes
A signed contract can become outdated even when nobody has changed the supplier. UK processor agreements have developed alongside changing transfer requirements, regulator guidance, technologies, and processing arrangements.
The UK GDPR baseline became operationally significant on 25 May 2018, when the GDPR came into force and UK organisations were told to update both new contracts and existing contracts continuing beyond that date with data-processing terms. That date matters because it established the expectation that outsourcing arrangements require documented controls, not merely commercial terms.
International transfers added a further maintenance task. GOV.UK's PPN 020 guidance on data protection legislation states that contracts concluded after 22 September 2022 must use one of the two forms of International Data Transfer Agreement. Existing contracts concluded on or before 21 September 2022 could continue relying on EU Standard Contractual Clauses only until 21 March 2024.
Set review triggers
Don't wait for a calendar reminder alone. Review the data processor contract when:
- The workflow changes: a new intake channel, integration, document type, or processing feature is introduced.
- The supplier changes providers: a new cloud, OCR, storage, support, or analytics sub-processor is added.
- The processing purpose changes: the service begins using information for a purpose outside the original instructions.
- The transfer position changes: information will be accessed or stored in a different country.
- The law or guidance changes: regulatory updates may affect clauses, schedules, or transfer mechanisms.
The ICO's contracts guidance has been updated across 2024 to 2026 and is under review because of changes made by the Data (Use and Access) Act. That makes old templates worth revisiting, especially where they contain fixed sub-processor lists, outdated transfer language, or vague deletion rights.
Allocate responsibility clearly
The controller must still ensure that the processor contract meets Article 28 requirements and issue documented instructions. Processors also have direct responsibilities and may be subject to the ICO's investigative and corrective powers, including administrative fines, when they fail to meet their own obligations.
A good contract doesn't erase accountability. It makes ownership visible, gives each party a response path, and creates evidence that the parties review their arrangement when the law or workflow moves.
Putting Your Data Processor Contract Into Practice
Treat the contract as part of supplier management, not as a document that disappears into a folder after signature. Identify every processor, map the information each one receives, confirm the controller and processor roles, and match the schedule to the live workflow.
Then check the essentials: documented instructions, confidentiality, security measures, rights assistance, sub-processor controls, international-transfer safeguards, deletion or return, and audit evidence. Give someone responsibility for reviewing changes and keeping the signed version, schedules, approvals, and supplier notices together.
The ICO's current guidance is under review following changes made by the Data (Use and Access) Act, so an older template may not reflect the current UK framework. If you're comparing software suppliers, a practical resource on the evaluation criteria for GDPR tools can help you turn broad privacy claims into specific procurement questions.
For a freelancer, small business, or accountant, the next action is manageable: list the tools that receive personal data, request each DPA and sub-processor list, compare the clauses with your actual data flows, and resolve gaps before sending more records.
Snyp helps businesses capture receipts from WhatsApp, email forwarding, or uploads, extract structured financial details, and send approved results to accounting platforms such as Xero and QuickBooks. Review the processing terms and workflow controls, then visit Snyp to see whether it fits your receipt-handling process.