Maker-checker separation is a control where one person creates or proposes a change and a different person reviews and approves it. It is used in systems such as payments, configuration management and privileged access workflows to reduce errors and fraud by separating initiation from authorisation.
What Maker-Checker Separation Does
Maker-checker separation splits a sensitive workflow into two roles, one that initiates or proposes a change and another that independently reviews and approves it. The control is meant to reduce both accidental error and deliberate abuse by preventing a single actor from completing the full action alone.
It is most useful when the change has financial, operational or privilege consequences, such as payment instructions, configuration changes, account changes or access grants. The control is not about slowing work for its own sake, it is about creating a second point of judgment before the organisation commits to an irreversible or high-impact action.
Where Maker-Checker Separation Matters
Maker-checker is strongest where a workflow has clear initiation and approval stages, a meaningful audit trail, and a real risk if the same person can both create and authorise the change. In practice, the control is often paired with thresholds, exception handling and escalation paths so routine low-risk actions do not get treated the same way as high-impact ones.
Its value depends on role independence. If the approver routinely rubber-stamps requests, or if business pressure makes rejection unlikely, the control exists on paper but does not provide much protection. That is why organisations usually align maker-checker design with segregation of duties, approval evidence and periodic review of who can approve what.
For systems that gate privileged or destructive actions, independent approval is a familiar pattern, and NHIMG’s Dual control and four-eyes approval for privileged and agent actions shows how the same principle is applied when the action itself carries elevated impact.
How It Is Applied in Payments, Configuration and Access Workflows
In payments, maker-checker helps stop single-person fraud, beneficiary manipulation and simple data-entry mistakes from becoming completed transfers. In configuration management, it can prevent one administrator from pushing a risky change without review, especially where the change affects security, availability or downstream controls. In privileged access workflows, it can force a second person to validate that the request is legitimate before rights are granted or extended.
The control is most effective when the approving person has enough context to challenge the request, but not so much operational overlap that they are effectively approving their own work. That is why organisations often separate request creation, business approval and technical execution rather than letting one control act as both business sign-off and system admin action.
For teams working with autonomous or semi-autonomous tooling, the same concept is increasingly used to gate high-impact actions before they are executed. NHIMG’s AI Agents in Financial Services Security Guide discusses supervisory expectations, audit evidence and payment authorisation limits where agent-driven workflows are involved.
Why the Control Fails When It Is Only Formal
Maker-checker separation can fail when the approver is not truly independent, when approvals are fast-tracked without review, or when the system allows the maker to influence the checker through pre-filled approvals, weak attestations or poor workflow design. It also weakens when approvals happen outside the system and are later copied back in, because the audit trail then reflects a clerical step rather than a real control decision.
Another common weakness is scope drift. An organisation may apply maker-checker to obvious transactions but leave adjacent actions, such as profile changes, payee edits or privilege escalations, outside the control boundary. Attackers and fraudsters often look for those gaps because they offer a less visible path to the same outcome.
Authoritative control catalogues and control frameworks treat this kind of separation as part of broader access, change and audit governance. For a general control baseline, NIST SP 800-53 Rev 5 Security and Privacy Controls provides the surrounding control structure for review, audit and authorization discipline.
Where the workflow is implemented through APIs or service layers, broken authorization can undermine the intent of the control even when the front end looks correct. In those cases, the backend must enforce who may submit, approve and execute each step, not just display separate buttons.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | Maker-checker is a classic separation-of-duties control for initiating and approving sensitive actions. |
| AU-2 — Event Logging | Maker-checker requires auditable evidence of who proposed and who approved each action. | |
| CM-3 — Configuration Change Control | The control is commonly used to govern high-impact configuration changes through independent review. | |
| Recommendation — Define distinct maker and checker duties so no single user can both initiate and approve the same sensitive change. Log maker and checker actions separately so approvals can be reviewed and investigated later. Require independent approval for significant configuration changes before they are implemented. | ||
| ISO/IEC 27001:2022 | A.5.3 — Segregation of duties | This Annex A control directly matches the maker-checker separation principle. |
| A.5.15 — Access control | Maker-checker often depends on access rules that restrict who may submit, review and approve actions. | |
| Recommendation — Separate initiation and approval responsibilities for sensitive business and administrative actions. Restrict approval rights so only authorised reviewers can complete high-impact requests. | ||
Practitioner Guidance
Governance implication: Treat maker-checker as a segregation-of-duties control, not just a workflow feature. The real design question is whether the approver can independently reject the action and whether the system preserves evidence that they actually did so.
What to watch for: Pay particular attention to self-approval paths, emergency override paths, bulk approvals and workflows where the same individual can repeatedly act as both maker and checker. Those are the points where the control is most likely to collapse into a formality.
Practitioner takeaway: The strongest maker-checker designs are narrow, explicit and auditable, with clear approval boundaries and no hidden path that lets initiation and authorisation recombine in practice.