Where the Keys Are
Payroll depends on four or five credentials held by one person. It is the most common thing that strands a substitute and the easiest to fix.
Nobody elseif the person who does this is away
Running payroll depends on four or five credentials, and in a small business one person holds all of them: the payroll package, the bank, the filing registration, and whatever delivers payslips.
The practical lesson in “Where the Keys Are” is that payroll depends on a sequence somebody can explain. When a small team reviews GDPR employee monitoring for GDPR employee monitoring, the useful role is to organise time and project evidence before approval, with proportional settings and a clear correction route for employees.
It is the most common thing that strands a substitute, and it is the easiest part of this whole problem to fix.
For an outside reference relevant to “Where the Keys Are”, consult Zoho People resources. Compare general guidance with the employer’s jurisdiction, contracts and current payroll process.
What the list usually is
The payroll software. The bank account used to pay. The statutory filing registration or credential. The email address or portal that issues payslips. Occasionally a pension or benefits provider.
| System | The question that matters |
|---|---|
| Payroll package | Can a second person have their own login |
| Bank | Does the mandate let them pay, not just look |
| Filing registration | Who holds it, and can anybody else reach it |
| Payslip delivery | Is it tied to one person's account |
Five, give or take, and nobody has ever written them down.
Why it strands people
Because the sequence can be perfect and the deputy still cannot start. Access failures are absolute: there is no partial version of being able to log in.
Separate accounts, not shared passwords
The right answer where the system supports it: each person with their own login and appropriate rights.
It preserves the record of who did what, survives somebody leaving, and does not require anybody to hold a password they should not.
When sharing is unavoidable
Some systems have one credential by design, particularly the registrations tied to the employer.
Where that is true, the credential belongs somewhere controlled rather than in one person's memory or a note in their desk.
Where credentials belong
A password manager with a shared section, or a sealed written record held by a director. Not a spreadsheet called passwords, not a note on a phone, not an email to yourself.
The requirement is that access survives the person and does not leak.
The two-factor problem
The one that catches businesses out. A credential protected by a code sent to one person's phone cannot be used by anybody else, however well the password is documented.
This is now the commonest reason a deputy with full documentation still cannot do anything.
What to do about it
Where the system allows a second enrolled device or a backup method, set it up for the deputy at the same time as everything else.
Where it does not, that is worth knowing in advance — it means that particular step genuinely cannot be covered and has to be planned around.
Testing it
Have the deputy log in to each system once, now, while nothing depends on it. Not read the password — log in.
Half of all documented access turns out not to work on first attempt, and finding that out in a quiet week is the entire point.
Removing access on departure
Access removed promptly, and the shared credentials changed. A shared login means this breaks everybody's access at once, which is one more argument for separate accounts.
The bank
Usually the best-governed of the lot, because banks require proper mandates and businesses take them seriously.
Worth checking that the mandate actually allows the deputy to make the payments payroll needs, rather than just to look.
Keeping the list current
Reviewed when anything changes and once a year regardless. Credentials expire, systems change, people's phones are replaced.
A list that was accurate two years ago is a list that will fail when used.
What to write down beside each one
What it is for, who holds it, how a second person gets in, and whether it has a two-factor method that is tied to one device.
Four columns, five rows, and it is the single most useful page in the business's payroll documentation.
The reason this gets skipped
It feels like a security risk to write down, which it is if done badly. Done properly it is a smaller risk than the alternative, which is a business that cannot pay anybody because one phone is unavailable.
The one page worth having
Five rows and four columns: what the system is, who holds it, how a second person gets in, and whether access depends on a code sent to one device.
That last column is the one that matters now and did not exist a few years ago, and it is where most documented access quietly fails.
Testing rather than documenting
A password written down is a claim. A deputy logging in successfully is a fact.
About half of documented access does not work on first attempt — an expired credential, a changed password, a verification step nobody anticipated — and finding that out in a quiet week is the entire point of testing it.
What a small business can reasonably do
Separate logins where the package supports them, a shared credential held properly where it does not, a second device enrolled where possible, and a note of which steps genuinely cannot be covered.
The last of those is not a failure. Knowing that one step cannot be delegated is itself useful, because it can then be planned around rather than discovered.
The afternoon version
List the credentials, set up separate logins where possible, enrol a second device where supported, test each one, and store the list somewhere controlled.
Two hours, once, and it removes the most absolute failure mode in this collection.