When a rule changes but the configuration does not, and other payroll risks to rehearse

Payroll risk is easier to manage when a team rehearses a concrete failure instead of maintaining a vague risk register. The following scenarios are prompts for employers in England. They do not predict that an event will occur, and each organisation should adapt the controls to its workforce, timetable and systems.

A rule changes but configuration does not

A payroll is processed using old statutory logic after an effective date. The control set should include an official change register, named owner, supplier-release review and synthetic acceptance cases. Keep the source and expected result beside every decisive test.

This matters for live changes such as statutory sick pay. HMRC's February 2026 Employer Bulletin explains the removal of the waiting period and lower earnings limit from 6 April 2026. A green supplier status should not replace an employer's own check of affected cases.

An integration silently drops changes

HR records show a starter, leaver or pay adjustment, but the payroll import omits it without a visible rejection. Control totals should compare record counts, gross values and exception lists before calculation. A named person must investigate differences rather than correcting the final net figure without finding the cause.

Test blank fields, duplicate identifiers, retrospective dates and interrupted transfers. Retain the source file and import report so the investigation has evidence.

An AI assistant invents an answer

An operator asks a built-in assistant about an unusual deduction and receives a plausible but unsupported instruction. HMRC's generative AI guidance for tax software explicitly identifies inaccurate or made-up outputs as a limitation users should understand.

Restrict the assistant to approved purposes, display its sources and require human review for changes. Complex cases should be referred to reliable guidance or a qualified adviser. Logs must show the prompt, response, correction and final decision without retaining unnecessary personal data.

The service is unavailable near payday

An outage blocks calculations, reports or payment files. Establish recovery priorities and deadlines before buying the service. Ask for documented backup, restoration and incident-communication arrangements, then test the employer's own continuity steps.

The NCSC's Software Security Code of Practice provides a voluntary baseline for customer conversations about resilient software and supplier responsibilities. The contract should also state escalation channels, dependencies and access to essential records.

The fallback might be a delayed change, an authorised prior-period method or a separately controlled payment process. It should never be invented during a crisis. Legal, financial and employee consequences need review in advance.

The employer cannot leave the supplier cleanly

At contract end, data arrives late, lacks history or uses an unusable format. The buyer should specify exports, attachments, audit logs, field definitions, timing, assistance, retention and deletion before signing. Run a sample export while the relationship is healthy.

The ICO's worker information guidance is relevant because changing processor does not remove the employer's data protection duties. Access and deletion need confirmation on both sides of the migration.

Turn scenarios into rehearsals

Assign an owner, warning signal, preventive control, response and recovery evidence to each scenario. Test one or two cases every quarter with synthetic data, and record what the exercise changes. Update the set after a new rule, integration, supplier incident or workforce shift.

The purpose is not to produce a risk score that looks precise. It is to make sure the payroll team knows what to notice, who can decide and how employees will be paid accurately when an ordinary process fails.