When the same person can create and pay suppliers, the control boundary collapses and the organisation loses an important check against fraud and error. Lookback analysis helps uncover whether that access pattern was actually used, whether unauthorized transactions occurred, and whether sensitive financial data was touched without proper approval. It turns a suspected weakness into evidence.
What actually fails when one person can both create and pay suppliers
segregation of duties is not just a policy label, it is a control design that forces an independent check between supplier setup and payment release. In a healthy workflow, one role can initiate or maintain supplier records while another approves and pays. When those steps collapse into one account, the organisation loses the separation that exposes fake vendors, duplicate records, changed bank details, and rushed approvals.
That matters because supplier creation is where fraudulent payees, altered remittance data, and weak master-data changes can enter the system. Payment execution is where those changes become money movement. If the same user can do both, the workflow no longer challenges itself, and a single compromised or dishonest account can create a vendor, route funds, and conceal the trail unless later review is strong enough to catch the pattern.
Controls around this boundary should also be read as an access-governance problem, not only a finance process problem. The right question is whether the workflow still requires separate authority for creating the vendor, approving sensitive master-data changes, and releasing payment. Where those rights overlap, the organisation should treat the combined path as materially higher risk and verify whether exceptions are temporary, approved, and logged with enough detail to reconstruct what happened.
Why the control boundary is the real asset
The value of segregation in this workflow is that it creates friction at the exact point where fraud and error are easiest to hide. Supplier onboarding and supplier payment are complementary checks: the first asserts who should be paid, the second confirms that the payment is valid. When one operator controls both, you lose the ability to detect mismatched bank-account changes, shell suppliers, and payments that were technically authorised but not independently challenged.
Lookback analysis is useful because it turns that design weakness into a testable question. You are not only asking whether access existed, but whether the access pattern was used in a way that created a financial event or touched sensitive data without the intended approval path. That makes the review evidential, especially when you can correlate supplier master-data changes, payment run logs, and exception approvals across the same user or role.
For practitioners, the meaningful signal is whether the workflow still enforces a second set of eyes at the point of financial commitment. If approvals can be bypassed through role overlap, delegated authority, or permanent broad access, the control is functionally weakened even if the process document still says segregation exists. A process is only segregated when the system and the operating model both enforce the separation.
The scale issue is important too. One bad workflow in a low-volume unit is a local control gap; the same pattern across shared-service finance, procurement, or ERP administration can become a systemic exposure. In those environments, the risk is less about a single mistake and more about repeatable abuse of a trusted path that looks normal in logs.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while PCI DSS v4.0 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 6 — Access Control Management | Segregated supplier setup and payment requires distinct access rights and role boundaries. |
| 8 — Audit Log Management | Lookback analysis depends on logs that show who changed supplier data and who released payment. | |
| Recommendation — Restrict supplier creation and payment permissions to separate, approved roles. Log supplier master-data changes and payment actions with enough detail to reconstruct the workflow. | ||
| NIST CSF 2.0 | PR.AC — Access Control | The issue is a broken control boundary where one user holds conflicting authority. |
| Recommendation — Enforce role separation so no single account can complete both supplier creation and payment release. | ||
| PCI DSS v4.0 | 7 — Restrict Access by Business Need to Know | Payment workflows need least-privilege access to reduce fraudulent or accidental payment authority. |
| Recommendation — Limit payment and vendor-maintenance access to the minimum business roles required. | ||
Practitioner Guidance
What to verify: Confirm whether supplier creation, bank-detail changes, payment approval, and payment release are held by distinct roles in the live system, not only in policy. Then test a sample of real transactions to see whether any user could complete the end-to-end path without an independent review.
Decision rule: If one role can both create a supplier and trigger payment, treat that path as a control exception until the access model is redesigned or a compensating control proves effective. If the business insists on shared access for operational reasons, require tighter monitoring, explicit approval evidence, and rapid review of master-data changes.
What practitioners underestimate: The most damaging failures are often small changes to supplier records, not obviously fraudulent payments. A bank-detail update or new vendor record can be enough to redirect legitimate spend, so review effort should focus on who changed the payee data, who approved it, and whether the payment followed the same operator path.
Practitioner takeaway: In supplier workflows, segregation of duties is only real if no single person can both authorise the payee and release the money; otherwise the control has collapsed into a traceable but much weaker after-the-fact review.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
