GDPR and payroll data, a guide to ICO guidance for UK HR software buyers

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.

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	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.

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.

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.

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.

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.

A due diligence checklist for HR software buyers

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.

Work through it in order. Each step produces evidence you can file and show to an auditor, a board or the ICO if asked.

Map the payroll data you hold, its purposes, lawful bases and retention periods.
Confirm your role and the vendor's role as controller, processor or joint controller.
Obtain the vendor's security documentation, penetration test summary and sub-processor list.
Review the vendor due diligence file, including company identity checks at Companies House and financial standing.
Agree the data processing terms, breach notification timescales and audit rights.
Test subject access request and data export functions in a sandbox before go-live.
Settle commercial contracts terms on liability, exit, data return and deletion.

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.