TL;DR
- The core decision: which payroll changes should be seen by a second person before money moves.
- When doing nothing is right: when somebody other than the editor already looks at what changed.
- What has to be true: no single person can make a change and release the payment unseen.
- How the options split: by whether a second pair of eyes exists, and whether it is used.
- Decision rule: you do not need more people, you need the change visible before the run goes.
- Outcome to expect: the same team, with one step nobody can quietly skip.
The Realisation
Somebody works through how payroll actually operates, usually because a question came up, and arrives at an uncomfortable observation: one person can change a bank account, change a rate, add a payment, and approve the run that sends the money.
Not because anything was designed badly. It happened because the team is small, because that person is trusted, because access was granted to let them do their job, and because nobody sat down and asked what the arrangement would look like written out. It's the normal state in a lot of organisations and it's worth looking at plainly.
This isn't primarily about suspicion. The people it usually concerns are entirely trustworthy, and the reason to change the arrangement is not that anybody expects them to do anything. It's that a control which depends on one person being reliable isn't a control, and the person in that position is also the one most exposed by it, because if anything ever goes wrong there's nobody who can say they looked.
Best tools for Payroll Software
Payroll is also distinctive among HR systems in that it moves money. An HR system with loose access is a data problem. A payroll system with loose access is a data problem and a payments problem, and the second one has a different character because it's irreversible in practice.
The usual objection is headcount: separation of duties sounds like it needs people a small team doesn't have. It doesn't. The practical control is not that a different person performs the work, it's that somebody other than the person who made a change sees it before the money moves, and that's achievable through timing and visibility rather than through roles.
What obligations apply to access to personal and financial data differ by jurisdiction and by sector, and they change. Nothing here tells you what applies to you. Establish that with local advice, because it may set requirements beyond what's sensible practice.
When You Genuinely Do Not Need to Act Yet
Somebody other than the editor sees changes before release. Whatever form it takes, if changes are visible to a second person before money moves, the essential control exists.
One person can do everything, and nothing has gone wrong. The common position. Nothing having gone wrong is not evidence that the arrangement is sound; it's the absence of evidence either way, and the exposure sits on the individual as much as the organisation.
Approval exists but is given without looking. Worse than it appears, because it produces a record suggesting a control operated when none did. The fix is usually about what the approver is shown rather than about who they are.
The edge case that forces it. A question from outside, an audit, a funding round, or somebody asking who authorised a payment, and the honest answer is nobody can tell. That's the moment the arrangement becomes visible, and it's better to have looked first.
Five Questions This Reader Asks at 11pm
What does separation of duties mean in payroll? That the person who makes a change is not the only person who sees it before it takes effect. It's frequently described as splitting roles, which makes it sound impossible in a small team. The functional requirement is narrower: a second pair of eyes on changes that move money, before the money moves.
Which changes actually matter? Bank details, because they redirect where money goes. Rates and terms, because they change amounts persistently. One-off payments, because they're the easiest thing to add and the least likely to be questioned. Access itself, because somebody who can grant access can grant their own.
Can you do this with two people? Yes, and the mechanism is timing rather than roles. One person makes changes; the other looks at a list of what changed before approving the run. Neither needs the other's job, and the control works because the review happens before release.
What if one person is the whole payroll function? Then the reviewer comes from outside payroll. Somebody in finance, or a manager, or whoever is senior enough, looking at a short list of changes before release. They don't need payroll expertise to notice a bank account that changed or a payment nobody mentioned.
Should a provider be able to change bank details? Worth establishing explicitly rather than assuming either way. If an external party can alter where your employees' money goes, on instruction, the question is what verification sits behind that instruction. It's a reasonable thing to ask and the answer is frequently vaguer than expected.
The Changes Worth Watching
| The change | Why it matters | The smallest control that addresses it |
|---|---|---|
| Bank details | Redirects money to a different destination | Second pair of eyes, plus confirmation to the person |
| Rate or salary | Changes amounts persistently, quietly | Change visible to somebody other than the editor |
| A one-off payment | Easiest to add, least likely to be queried | A list of additions, read before release |
| A new person added | Creates a payee who may not exist | Cross-check against the employee record |
| A standing element | Repeats forever with no further signal | Periodic review of the standing list |
| Access rights | Whoever grants access can grant their own | Changes visible to somebody else |
| The approval itself | A record without a decision behind it | Give the approver something specific |
| Provider-side changes | Outside your visibility entirely | Establish what they can change, and on whose word |
The first row is the one to address before any other, because it's the only change that sends money somewhere other than intended without altering any amount. A confirmation sent to the employee through a separate channel, telling them their details were changed, costs nothing and means an unauthorised change is noticed by the person best placed to notice it.
The third row is the quiet one. A single additional payment on one run is small, unremarkable, and unlikely to be questioned by anybody, which is exactly what makes a list of additions worth reading every period. It's a short list and reading it takes a minute.
The last row is outside your systems and inside your exposure. Whether an external party can change banking details, and what verification they require before acting on an instruction, is worth establishing in writing rather than discovering afterwards.
Five Diagnostic Questions You Can Self-Assess Against
Can one person change a bank account and release the payment? If yes, that's the finding. Everything else here is secondary to it.
Who sees what changed, before the run goes? Name them. If the answer is the person who made the changes, no second pair of eyes exists regardless of what the approval record shows.
What is the approver actually shown? If it's the whole run or nothing specific, the approval is a formality. People approve what they can't examine.
Who can grant access? Somebody who can change permissions can extend their own, which makes access changes worth being visible to somebody else.
What can your provider change, and on whose instruction? Establish it in writing. This sits outside your systems and it's the part most often assumed.
Work through these five by tracing an actual change rather than by describing the process. Ask somebody to walk you through what happened to a real rate change last period, step by step, and the answer will differ from the documented version in at least one place.
Six Access Arrangements, Reviewed
One person with full access and no second pair of eyes
A single individual makes every change and approves every run. It earns its place on speed and simplicity, and it's the honest reality in a lot of small organisations, where the alternative appears to require people who don't exist.
Where it falls short is that no control exists at all. Not a weak one, none, and the exposure runs both ways: the organisation has nothing standing between an error or worse and the money leaving, and the individual has nobody who can attest that what they did was correct.
Worth changing even when nothing has gone wrong. The change needed is smaller than it appears, and it protects the person in the role as much as anything else.
The conversation is easier than people expect, too. Framed as protecting the individual rather than checking up on them, it is usually welcomed by the person concerned, who has frequently been uneasy about the arrangement without raising it.
The practical starting point is a list rather than a restructure. Somebody sensible reading what changed, before the run goes, delivers most of the benefit on the first cycle and requires nothing to be reorganised.
Two people splitting entry and approval
One makes changes, the other approves the run. It earns its place as the most practical arrangement available to a small team, since it requires no additional headcount and delivers the actual requirement, which is that somebody other than the editor sees changes before release.
Where it falls short is when the approver is shown the wrong thing. Approval of a complete run is not review; approval of a short list of what changed is. The arrangement also weakens if the two people are the same person during absences.
The right default. Give the approver the list of changes, and name a substitute for each role.
The substitute question is the one that determines whether this holds up. An arrangement where the two people cover for each other has no separation during any absence, which is when cycles are most rushed and errors most likely. Each role needs somebody outside the pair who can step in.
Agree what the approver should do when something looks wrong, as well. Without a stated path, the practical options are approve or stop the run, and nobody stops the run.
Approval by somebody outside payroll entirely
The reviewer sits in finance, or is a manager, or somebody else senior. It earns its place where payroll is genuinely one person, because it creates a second pair of eyes without needing a second payroll person.
Where it falls short is context. Somebody outside payroll can tell that a bank account changed or a payment was added; they can't always judge whether a rate is right. That's an acceptable limit, because the changes with most exposure are the ones that need least expertise to notice.
Good where payroll is one person. Focus what they're asked to look at on things that need no payroll knowledge.
The items that work well for this are new payees, changed bank accounts, added one-off payments and anybody who has disappeared from the run. All four are noticeable without understanding how payroll calculates anything, and all four are short lists.
Be clear with them about what they are and are not confirming. An outside reviewer is saying that nothing looks unexpected, not that every figure is correct, and stating that distinction protects them as much as it clarifies the control.
A system-enforced rule that the approver cannot be the editor
The system refuses to let the same account approve a change it made. It earns its place by making the control structural rather than behavioural, so it holds under time pressure, during absences, and after the people who designed it have moved on.
Where it falls short is coverage and workarounds. The rule may apply to some change types and not others, and a team under pressure will find a way around it, typically by sharing an account, which removes the control and the audit trail together.
Worth having where available. Check which changes it covers, and make sure absence arrangements don't require anybody to share credentials.
Coverage is the part to test rather than assume. A rule may apply to approving a run and not to changing a standing element, or to salary changes and not to banking details, and the gaps are rarely stated anywhere obvious.
The credential sharing risk deserves anticipating rather than prohibiting. People share logins because the alternative is that payroll does not go out, so the answer is a cover arrangement that actually works rather than a rule telling them not to.
A provider holding the ability to change bank details
An external party can alter payment destinations, usually on instruction from somebody at your organisation. It earns its place on practicality: it's how a lot of arrangements work, and it lets changes be made without your team touching the payment setup.
Where it falls short is verification. The control now rests on how the provider confirms that an instruction is genuine, which is outside your visibility and frequently unspecified. An instruction that appears to come from the right person may be all that's required.
Establish in writing what they can change and what verification they apply. Ask them to confirm banking changes back to you through a separate route.
The question worth asking directly is what an instruction has to look like before they act on it. If the answer is a message from a recognised address, the control is thinner than it sounds, and knowing that lets you decide whether to add something on your side.
Also establish who at your organisation they will take instructions from, and keep that list current. It is the sort of thing agreed once at setup and never revisited, long after the people on it have changed roles.
Approval that exists but is always given without looking
The workflow routes, the approval is recorded, and no examination occurs. It earns its place on paper, which is the problem: there's a complete record of a control that isn't operating.
Where it falls short is that it's arguably worse than having nothing, because the record stops anybody asking whether the process is safe. The behaviour is also rational rather than careless: an approver given a whole run, at a predictable time, with no realistic option but yes, will approve.
Fix the information and the options rather than asking for more care. Show them what changed, and give them a way to query one item without holding the entire run.
It is worth being honest that the approver is not the problem here. Somebody receiving an identical request at the same point every cycle, with no specifics and no workable alternative to yes, is behaving exactly as the process designed them to. Treating it as a discipline issue produces nothing.
One useful test is to ask the approver what they would need in order to say no. The answer usually describes precisely what the process is failing to give them.
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| Second pair of eyes on changes | Any | Any | None | Change nothing |
| One person can change and release | Any | Any | No control at all | Add a reviewer, any reviewer |
| Payroll is genuinely one person | Small | Any | No second payroll person | Reviewer from outside payroll |
| Approver shown the whole run | Any | Two people | Approval as a formality | Show the change list instead |
| Approval given without looking | Any | Workflow | A record, not a control | Fix information and options |
| Provider can change bank details | Any | Outsourced | Verification outside your view | Establish it in writing |
| Same person covers during absence | Any | Two people | Control lapses when needed most | Name substitutes for both roles |
| Credentials shared to get work done | Any | Enforced rules | Control and trail both gone | Fix the absence arrangement |
| Nobody reviews standing elements | Any | Any | Repeats forever, unseen | A scheduled review |
The second row is the one to act on first and the fix is smaller than people expect. It doesn't require a payroll hire, a new system, or a restructure. It requires somebody, anybody sensible, looking at a list of what changed before the run is released.
The fourth and fifth rows are the same failure at different stages, and both are about information rather than intent. An approver shown the entire run cannot examine it, and an approver shown nothing specific has nothing to examine, so in both cases the approval records a decision that was never available to be made.
The seventh row is where good arrangements quietly fail. Separation that exists in normal weeks and collapses during holidays isn't separation, and the collapse tends to coincide with a rushed cycle, which is when errors are most likely anyway.
The ninth row covers the gap that no change-based review can reach. Standing elements are visible in the period they are created and silent forever afterwards, so an item set up wrongly, or one that should have ended, passes every subsequent review by producing no change at all. A scheduled look at the list is the only thing that catches it.
Separation of Duties in a Team of Two
The requirement is visibility, not headcount. The functional control is that somebody other than the person who made a change sees it before money moves. That's achievable by two people, or by one person in payroll plus one outside it.
The reviewer does not need payroll expertise. The changes with most exposure, a bank account, a new payee, an added payment, are all visible to anybody. Judging whether a rate is correct needs knowledge; noticing that a rate changed does not.
Give them a short list, not the run. This is the single thing that determines whether the review is real. A list of what changed since the last run is readable in a couple of minutes; a complete register is not, and handing over the register guarantees a nominal approval.
Name substitutes for both roles. An arrangement that works when both people are present and collapses when one is away has a gap at exactly the wrong moment. Both roles need a named alternate who can actually do it.
Confirm bank changes to the person affected. A message to the employee saying their details were changed, sent through a channel other than the one used to request it, means an unauthorised change is caught by the one person certain to care.
Review standing elements on a schedule. Anything that applies every period produces no signal after the first one, so it's invisible to a change-based review. A periodic look at the standing list is what covers that gap.
Keep a record of who reviewed what. Not an elaborate one. A note of who looked at the change list before each run, kept with the run, is what lets anybody demonstrate later that a second person saw it, and it costs a line.
The whole of this is achievable without hiring anybody, and most of it is achievable in an afternoon. The reason it frequently doesn't exist isn't cost or difficulty, it's that nobody has written down how payroll currently works, and the arrangement only becomes visible when somebody does.
It is also worth doing before anybody asks. The question tends to arrive at an inconvenient moment, during a funding round, an audit or an investigation into something unrelated, and having looked first is a considerably better position than looking because you were asked to.
Where These Arrangements Go Wrong
| The failure | How it shows up | What would have to change |
|---|---|---|
| One person does everything | No control, and no way to demonstrate one | Any second reviewer |
| Approver shown the whole run | Nominal approval every period | A short change list |
| Approval with no way to query one item | Everything approved, always | A path to hold one item |
| Separation lapses during absence | Gap at the busiest moment | Named substitutes |
| Credentials shared under pressure | Control and audit trail both lost | Workable absence cover |
| Provider verification unexamined | Money redirected on a plausible instruction | Establish it, in writing |
The third row is the quiet reason approvals become formalities. If the only options are to approve everything or hold the entire run, and holding the run means nobody gets paid, then approval is effectively compulsory. Giving the approver a way to question one item without stopping the cycle is what makes refusal realistic.
The fifth row is worth anticipating rather than prohibiting. People share credentials because the alternative is that work doesn't happen, so the fix is a cover arrangement that works, not a rule against it.
The sixth row is the one that sits outside your systems and therefore outside most reviews. Where an external party can act on an instruction to change a payment destination, the effective control is their verification process, and very few organisations have asked what it consists of. It is a short conversation and the answer is frequently thinner than expected.
What to Put in Writing
| Artefact | Who owns it | When it is written | What it prevents |
|---|---|---|---|
| Who can change what, today | Whoever runs payroll | Now | An arrangement nobody has examined |
| The change list the approver reads | Whoever runs payroll | Before it is relied on | Approval as a formality |
| Substitutes for both roles | Whoever runs payroll | Now | A gap during absence |
| Bank change confirmation route | Whoever runs payroll | Now | A redirected payment unnoticed |
| What the provider can change | You, with the provider | Before it matters | Verification you never examined |
| Obligations on data access | You, with local advice | Now | Requirements discovered late |
The first row is the exercise that starts everything. Writing out who can currently do what, without judgement, takes under an hour and is how most organisations discover that one person holds the whole thing. The arrangement is usually invisible until it's on paper.
The third row is the one that keeps the rest working. Every control here holds only while the people it depends on are present, and payroll cycles do not move around anybody's absence, so naming substitutes converts a good arrangement into a durable one.
Questions to Ask Before You Commit
On access. Who can change a bank account? A bad answer is the payroll team.
On review. Who sees changes before release? A bad answer is that it is approved.
On information. What does the approver see? A bad answer is the full run.
On absence. Who covers each role? A bad answer is that they cover each other.
On the provider. What can they change, and on whose word? A bad answer is that it is secure.
On records. Can you show who authorised a payment? A bad answer is probably.
What Getting This Wrong Costs
The first cost is that you cannot demonstrate anything. When somebody asks who authorised a particular payment, an organisation where one person does everything has no answer beyond naming them, and that's unsatisfying to whoever asked and unfair to the person named. The absence of a control is a problem even in the overwhelmingly likely case that nothing improper ever happened.
The second cost falls on the individual in that position. Sole access to a system that moves money means any question about any payment points at one person, with nobody able to corroborate that they did it correctly. Most people in that role haven't thought about it in those terms, and they're usually glad when somebody else starts looking.
It also makes their absence harder than it should be. Somebody who is the only person able to operate payroll cannot easily be away during a cycle, which is a quiet cost they absorb personally and one that a second trained pair of hands removes.
The third cost is the error nobody catches. A change made in good faith and entered wrongly, a payment added to the wrong person, a bank account typed incorrectly: all are caught by a second pair of eyes and none are caught by anything else. The most common thing a review prevents is a mistake, not misconduct, and that alone justifies it.
That is also the argument worth making internally, because it is both true and easier to raise. Nobody enjoys proposing a control that implies distrust, and framing it as catching the typing errors that everybody makes is accurate and gets agreement faster.
So do three things this week. Write out who can currently change what. Put somebody, anybody sensible, in front of a short list of changes before each run is released. And set up a confirmation to the employee whenever their bank details change. None of those needs budget, headcount or a system.
When You Are Ready to Go Further
Start by writing down the current arrangement, because it's usually invisible until it's on paper and the exercise takes under an hour. Who can change a bank account, a rate, an element, who approves, who grants access. Most organisations find at least one thing they didn't expect.
Then create the change list. What changed since the last run, in a form somebody can read in a couple of minutes, given to a person other than whoever made the changes, before the payment is released. This is the whole control, and it works with two people or with one person plus somebody outside payroll.
Keep it genuinely short. The temptation is to include everything so that nothing is missed, and a list long enough to be comprehensive is a list nobody reads, which puts you back where you started with a record suggesting otherwise.
Finally, close the two gaps that survive good arrangements: absence, by naming substitutes for both roles so the separation doesn't lapse in the week it's most needed, and standing elements, by reviewing the list on a schedule since they produce no signal after the period they were created. Both are small, and both cover cases a change-based review can't reach on its own.
HROpsLab publishes independent comparison work across HR tooling, payroll and workforce systems. We sell nothing, we take no vendor money, and we publish no paid placements. If the next step is understanding what controls your current tooling supports, our comparison work is one place to start.
Frequently Asked Questions
What does payroll security mean in practice?
Mostly it means access: who can change what, and whether anybody other than that person sees the change before money moves. Payroll is distinctive among HR systems because it both holds sensitive personal information and moves funds, so an access arrangement that would be merely untidy elsewhere has a payments dimension here. The practical question is narrower than the term suggests, and it comes down to whether a single individual can alter a payment destination, add an amount, and release the run without anybody else looking.
Who should have access to payroll?
As few people as need it, and the more useful question is what each of them can do rather than whether they have access at all. Viewing information, entering changes, approving a run and granting access to others are different capabilities with different exposure, and they frequently arrive bundled. Worth reviewing periodically, because access is granted when somebody needs it and almost never removed when they stop needing it. What obligations apply to who may access personal and financial data differs by jurisdiction and sector, so establish that with local advice.
What does separation of duties mean in payroll?
That the person who makes a change is not the only person who sees it before it takes effect. It is often described as splitting roles between people, which makes it sound like it requires headcount a small team does not have. The functional requirement is narrower: a second pair of eyes on the changes that move money, before the money moves. That is achievable through timing and visibility rather than through job design, which is why it works in a team of two and even in a team of one plus somebody outside payroll.
How should payroll be approved safely?
By showing the approver what changed rather than the whole run, and by giving them a way to question one item without holding the entire cycle. Both matter. A complete register cannot be examined in the time available, so approval becomes nominal; and where the only alternative to approving is stopping everybody's pay, approval is effectively compulsory regardless of what the approver sees. Fixing the information and the options changes the behaviour, whereas asking people to be more careful reliably does not.
Which payroll changes should require a second person?
Bank details first, because they redirect money without altering any amount and are therefore invisible to any check based on totals. Then rates and terms, which change amounts persistently, and one-off payments, which are the easiest thing to add and the least likely to be queried. Access changes matter too, because whoever can grant permissions can extend their own. Standing elements need a different treatment, since they produce no signal after the period they were set up, which is why a scheduled review of the standing list covers what a change-based review cannot.
How should bank detail changes be handled?
With a second pair of eyes before the change takes effect, and a confirmation to the employee through a channel other than the one used to request it. The confirmation is the cheaper and more effective of the two, because it puts the notification in front of the one person certain to care whether their money is going somewhere unexpected. It is also worth telling people at the point of change when the new details will actually take effect, since a change made after the payment file was produced will not apply to that run.
Should a payroll provider be able to change bank details?
It is common, and the question worth asking is not whether they can but what verification sits behind an instruction to do so. Where an external party alters payment destinations on instruction, the control has moved outside your visibility, and how they confirm that a request is genuine is frequently unspecified until somebody asks. Establish it in writing, and ask them to confirm any banking change back to you through a separate route, so a change you did not request is visible to you rather than only to them.
How do small teams manage payroll controls?
By using timing and visibility instead of headcount. One person makes changes and a second looks at a short list of what changed before the run is released, and that second person does not need payroll expertise, because noticing that a bank account changed or a payment was added requires none. Where payroll is genuinely one person, the reviewer comes from outside it entirely. The two gaps that catch out otherwise sound arrangements are absence, which needs named substitutes for both roles, and standing elements, which need a periodic review.
A control that depends on one person being reliable is not a control.
