Securing the Chain

The chain holds personal data about everyone employed and terminates in money leaving the organisation. Both properties attract attention.

What the chain exposes

A complete picture of a workforce: who, where, when, paid what.

Bank details at the payroll end.

Home addresses and contact details.

And a path to redirect a payment, which is the fraud this estate is uniquely exposed to.

The payment path

The commonest attack is not technical: a request to change someone's bank details, arriving by email, approved by someone helpful.

Which is why the control is a process — verification through a separate channel — rather than a firewall.

Combine it with the segregation question: if one person can change a bank detail and release a payment, the technical controls are irrelevant.

Test it once: send a plausible change request from outside and see what happens.

Interface credentials

Named service accounts, not a person's login.

Scoped to what the interface does — an export needs read, not write.

Rotatable without downtime, which requires the product to accept two valid credentials during a changeover.

Listed in the access review with their last use.

An integration account with administrator rights is the commonest finding in any review of this kind.

Multi-factor and shared logins

Multi-factor on every account with access to any module.

No shared logins, which are common at site level and make every access log meaningless.

Session timeouts, because an unattended screen in a back office is the most frequent real exposure.

Prompt removal on departure across all four systems, which is the joiner-mover-leaver path again.

The vendors

Four vendors, four sets of support staff with access.

Ask each: who can see customer data, is that access logged, and what is the breach notification commitment in hours?

Get the answers in the contract, because this data is theirs to lose as much as yours.

The check

Is multi-factor enforced everywhere?

Are there shared accounts?

Can one person change a bank detail and release a payment?

When was access last reviewed across all four systems together rather than each separately?

Test the bank detail change

The attack this estate is uniquely exposed to.

Send a plausible change request from outside and see what happens.

The control is a process — verification through a separate channel — rather than a technical measure.

And it interacts with segregation: if one person can change a detail and release a payment, nothing else matters.

Test it once, and again after any process change.

Reproduce the workflow

For another way to make this requirement testable, consult stealth workforce monitoring. Reproduce the case with real roles, codes, failures and recovery steps.

Independent reference

For a thematic point of reference, see NCSC guidance. Its current material provides useful context beyond product documentation.