
Rules and ethics
UK GDPR payroll data duties for HR software buyers
A practical overview of UK GDPR payroll duties for HR software buyers, covering lawful bases, vendor roles, security, access requests and breach reporting.
What to take away
- Payroll data is personal data, so any HR software you buy must support UK GDPR duties from day one.
- You need a lawful basis for processing before the first pay run, not after.
- Controller and processor roles must be written into the contract, not assumed from the sales pitch.
- Subject access requests and breach reporting are operational tasks your software should make possible, not theoretical risks.
- A written due diligence checklist, covering security, contracts and exit, is the cheapest protection you will ever buy.
Why payroll data is personal data under UK GDPR
Payroll records identify people. Names, National Insurance numbers, bank details, home addresses and salaries all relate to an identifiable individual. That makes them personal data under UK GDPR, and some of it, such as health-related absence records or trade union subscription deductions, can fall into special category data.
The Information Commissioner's Office (ICO) publishes the guidance that governs this territory, and it is the first place to look when you are scoping an HR software purchase. The UK GDPR guidance and resources set out the principles, the individual rights and the accountability expectations you will be measured against.
Payroll sits inside a wider compliance web. You run Real Time Information submissions to HM Revenue & Customs, auto-enrolment duties overseen by The Pensions Regulator, National Minimum Wage checks and pension deductions. Each of those adds a purpose and a retention period to the data you hold.
Most employers process payroll data every month, sometimes weekly, for years. Volume and routine are exactly why mistakes go unnoticed. A misdirected payslip or an over-shared spreadsheet is a personal data breach whether or not anyone complains.
Before you compare features, write down what data the payroll function actually holds, where it comes from and who sees it. That list becomes the specification you test vendors against. It also exposes gaps, such as leavers whose records sit in three systems with no deletion date.
Lawful basis for processing payroll and HR information
You cannot process payroll data simply because you always have. UK GDPR requires a lawful basis, and you should identify it before processing begins and record it. The ICO's guidance on lawful bases for processing payroll data explains the options and how to choose between them.
Lawful bases by payroll purpose
Contract
- Paying salary
- Bank details
- Tax and NI
- —
- Auto-enrolment
- —
- Sick pay
- —
- Union deductions
- —
- Payslip sending
- Contract
- Salary benchmarking
- —
Legal obligation
- Paying salary
- —
- Tax and NI
- Statute
- Auto-enrolment
- Statute
- Sick pay
- —
- Union deductions
- —
- Payslip sending
- —
- Salary benchmarking
- —
Special category condition
- Paying salary
- —
- Tax and NI
- —
- Auto-enrolment
- —
- Sick pay
- Employment law
- Union deductions
- Own condition
- Payslip sending
- —
- Salary benchmarking
- Legitimate interests
For most payroll processing, the basis is one of two. Contract is the natural fit for paying someone under their employment contract: you cannot pay them without their bank details. Legal obligation covers tax, National Insurance, statutory payments and auto-enrolment, because statute requires you to report and deduct.
Special category data needs more. Health data used for statutory sick pay or occupational sick pay normally relies on employment law obligations or, where relevant, the substantial public interest condition. Trade union membership deductions need their own condition.
The basis differs by purpose, not by person. Sending payslips uses one basis; running a salary benchmarking exercise may use legitimate interests; monitoring absence may need another. Document each purpose and its basis in a short table.
Consent is rarely the right answer in an employment relationship. Employees can feel unable to refuse, and consent can be withdrawn, which is unhelpful when you must run a legally required pay run. Reserve it for genuinely optional extras.
When you assess HR software, ask how the system records your lawful basis and retention periods. Some products let you tag purposes and set deletion rules. Others leave it all to spreadsheets and memory, which is where audits go wrong.
Purpose, basis and retention in practice
The table below is the kind of record the ICO expects you to be able to produce. Adapt it for your own payroll and keep it current.
Purpose, basis and retention
| Purpose | Typical lawful basis | Retention |
|---|---|---|
| Paying salary and wages | Contract | Employment plus six years |
| PAYE and National Insurance reporting | Legal obligation | Six years from tax year end |
| Statutory sick pay and absence | Legal obligation, plus special category condition | Six years, health data minimised |
| Auto-enrolment pension deductions | Legal obligation | Scheme rules plus six years |
| Payroll analytics and budgeting | Legitimate interests | Aggregated or anonymised |
Controller and processor duties when buying HR software
Your organisation is almost always the controller for its own payroll. The vendor is usually a processor. That split matters because duties, liability and the wording of your contract follow from it.
Controller vs processor duties
Controller (you)
- Decides why
- Yes
- Decides how
- Yes
- Acts on instructions
- No
- Own purposes
- Yes
- Sub-processors
- Must be told
- Contract terms
- Sets
Processor (vendor)
- Decides why
- No
- Decides how
- No
- Acts on instructions
- Yes
- Own purposes
- Becomes controller
- Sub-processors
- Appoints
- Contract terms
- Accepts
The ICO's guidance on controllers and processors for payroll bureaus and vendors is the reference point. A controller decides why and how personal data is processed. A processor acts on the controller's documented instructions.
Some vendors try to blur the line. A bureau that calculates pay, files RTI returns and answers HMRC correspondence on your behalf is still normally a processor, because you decide who gets paid and how much.
If the vendor uses the data for its own purposes, such as product analytics or marketing, it becomes a controller for that activity and needs its own basis.
Where a vendor subcontracts hosting, support or disaster recovery to another company, that is a sub-processor. You must be told about sub-processors, and you should be able to object to new ones. A change of hosting provider should not happen quietly.
Working out who is really the controller is the first practical step in any payroll data protection review. Get it wrong and your contract, your privacy notice and your breach analysis will all be wrong too.
Group structures add complexity. A parent company setting pay policy for subsidiaries may be a joint controller with each employing entity. Joint arrangements need a documented allocation of responsibilities, and employees must be able to understand who is accountable.
Security features to demand from an HR software vendor
Security is where procurement questions earn their keep. Ask for evidence, not adjectives. A vendor that cannot describe its encryption, access controls and incident history in plain terms is telling you something.
Security evidence to demand
- Encryption in transit and at rest
- Keys managed separately
- Role-based access permissions
- Multi-factor authentication for admins
- Tamper-evident audit logs
- Penetration test summary
- Data location and transfer mechanism
Start with encryption. Data should be encrypted in transit and at rest, with keys managed separately from the application. Confirm what happens to backups and whether they are encrypted to the same standard.
Access control comes next. You want role-based permissions, so a line manager sees their team's absence data but not salaries, and multi-factor authentication for all administrative accounts. Shared logins are a finding waiting to happen.
Audit logging should record who viewed, exported or changed payroll records, and those logs should be tamper-evident. When a subject access request arrives, logs help you show what data exists and who has touched it.
Ask about penetration testing: how often, by whom, and whether you can see a summary report under confidentiality. Ask how patches are deployed and how quickly critical vulnerabilities are addressed.
Data location matters. Confirm where payroll data is stored and whether any support access happens from outside the UK. If data leaves the UK, you need a transfer mechanism and a clear description of it.
Questions that separate vendors
- Can you show encryption standards for data at rest, in transit and in backup?
- How are admin accounts protected, and is multi-factor authentication mandatory?
- What audit logs exist, how long are they kept, and can we export them?
- When was the last independent penetration test, and can we see a summary?
- Which sub-processors touch payroll data, and where are they located?
- What is your documented incident response and notification timeline?
- How do we export all our data, in a usable format, on exit?
Subject access requests and individual rights in payroll
An employee can ask for a copy of their personal data at any time, and payroll is often where the request bites. The ICO's guidance on subject access requests relevant to payroll data sets out how to respond.
Subject access request clock
- Day 0Request received
- Within 1 monthStandard reply deadline
- Up to 2 monthsExtension for complex requests
- Before replySearch all systems and redact third party data
You normally have one month to reply, extendable by two months for complex requests. You must search all relevant systems, including the payroll platform, the HR system, email, spreadsheets and any bureau-held records. Redact third party data, such as another employee's details in a shared document.
Payroll data is rarely exempt. Salary, deductions, pension contributions, absence records and correspondence about pay are all in scope. Legal privilege and certain negotiations may be exempt, but those exceptions are narrow and should be applied case by case.
Software makes the difference between a two-day job and a two-week one. Check whether your HR software can search and export an individual's records across modules, including historical pay runs and attachments.
Other rights follow the same pattern. Rectification means correcting a wrong bank detail or address. Erasure applies once retention periods end, subject to tax and employment law requirements to keep records. Portability rarely applies to payroll because processing rests on contract or legal obligation, not consent.
Train the people who receive requests. A request sent to a payroll administrator or a line manager is still a valid request, and the clock starts when the organisation receives it, not when it reaches the data protection lead.
Breach reporting duties and the ICO data protection fee
A personal data breach means any security incident that causes personal data to be destroyed, lost, altered, disclosed or accessed accidentally or unlawfully. A payslip emailed to the wrong person counts. So does ransomware that locks a payroll system.
Breach notification duties
- ImmediatelyProcessor notifies controller
- Within 72 hoursReport to ICO if risk is likely
- Without undue delayInform affected people if risk is high
- AlwaysLog the breach internally
You must tell the ICO about a breach within 72 hours of learning of it if it is likely to put people's rights and freedoms at risk. The ICO's breach reporting page explains what to include and how to submit. Where the risk is high, you must also inform those affected without undue delay.
Your processor must notify you without undue delay after becoming aware of a breach. That obligation belongs in the contract with a specific timescale, not a vague promise to inform you promptly. When a vendor holds payroll for thousands of employees, hours matter.
Keep an internal breach log even for incidents you do not report. The ICO expects you to record the facts, the effects and the remedial action. A log also shows patterns, such as repeated misdirected emails, that point to a training or configuration problem.
Separately, most organisations that process personal data must pay the annual data protection fee to the ICO. It is a legal requirement, not a subscription, and it is separate from any breach notification. Check that your registration details, including your trading name and address, are current.
Selected HR software due diligence checks
Due diligence is a process, not a form. Run it before you sign, and repeat the key checks at renewal or when the vendor changes its hosting, ownership or sub-processors.
The numbered examples below are selected checks, not a complete sequence. Keep evidence of your review so you can show it to an auditor, a board or the ICO if asked.
Due diligence in order
- Map payroll data, purposes, bases, retention
- Confirm controller and processor roles
- Obtain security docs, pen test, sub-processors
- Review vendor due diligence file
- Agree processing terms and breach timescales
- Test subject access and export in sandbox
- Settle contract terms on liability and exit
Worked example: a 400-employee manufacturer in the West Midlands
The manufacturer runs weekly pay for 400 staff across two sites and uses a bureau for RTI submissions. A payroll administrator emails a P45 to the wrong address. The recipient confirms deletion and no one else opens it.
The breach is logged but not reported, because the risk to the individual is low and the data was recovered. The internal log records the date, the data involved, the recipient's confirmation and the remedial action: a check that address fields are verified before sending.
At renewal, the manufacturer asks the bureau for its current sub-processor list and a fresh penetration test summary, and confirms the data processing agreement still matches how pay is actually run. The whole review takes an afternoon.
That is the standard to aim for. Routine checks, documented decisions and a contract that matches reality. Buying HR software with these duties in view is far cheaper than retrofitting compliance after a complaint.
Common questions
Do we need consent to process payroll data?
No, in most cases. Contract and legal obligation cover ordinary payroll processing, and consent is usually inappropriate in an employment relationship because of the imbalance of power. Identify and record the basis you actually rely on.
Is our payroll bureau a controller or a processor?
Normally a processor, because you decide who is paid and how much. If the bureau uses payroll data for its own purposes, it becomes a controller for that activity. Put the roles in writing.
How quickly must we report a payroll data breach to the ICO?
Within 72 hours of becoming aware of a breach that is likely to risk people's rights and freedoms. If the risk is high, tell affected employees without undue delay as well.
Can an employee request their full payroll history?
Yes. A subject access request covers personal data held about them, including historical pay runs, deductions and related correspondence. You have one month to respond, extendable for complex requests.
What security features should we insist on in HR software?
Encryption in transit and at rest, role-based access, mandatory multi-factor authentication for administrators, tamper-evident audit logs and a current independent penetration test. Ask for evidence of each.
Do we still need to pay the ICO data protection fee?
Most organisations processing personal data do, unless an exemption applies. It is separate from breach reporting and should be reviewed annually alongside your registration details.



