A maker-checker control separates execution from approval. One person completes an action, and another reviews or authorises it before it is final. This reduces fraud, accidental errors, and unchecked changes in financial and sensitive operational workflows, especially where data, money, or access are involved.
What Maker-Checker Control Means in Practice
Maker-checker is an approval pattern, not just a documentation habit. It works best when the first person can prepare or submit an action, but cannot finalise it without independent review by a second person.
The control is most valuable where a mistake or abuse would have immediate financial, operational, or access consequences. That includes payments, journal entries, master-data changes, privilege updates, and other workflows where a single unchecked step can create durable damage.
Its strength comes from separation of duties. By splitting creation from authorisation, the control reduces the chance that one person can both initiate and conceal a harmful change, while also introducing a deliberate pause for review.
Where Maker-Checker Control Fits
Maker-checker is commonly used in finance, operations, compliance, and identity-adjacent workflows. It is a process control that sits between request and final execution, making it especially relevant in systems where change approval is as important as the change itself.
The pattern is sometimes implemented in software, sometimes in manual procedures, and sometimes across both. A bank may use it for payments and trading instructions, while an enterprise may use it for user provisioning, limit changes, vendor master edits, or configuration updates.
It is closely related to separation of duties and dual control, but it is narrower than a broad governance model. The key idea is that the person who prepares the action is not the person who completes it.
In practice, maker-checker is often used to reduce concentrated trust. NIST Cybersecurity Framework 2.0 aligns with that goal through governance, protection, and recovery disciplines that depend on controlled changes and accountable decision-making.
Failure Modes and Control Weaknesses
Maker-checker only works when the reviewer is genuinely independent and has enough context to challenge the action. If reviewers rubber-stamp requests, share credentials, or inherit the maker’s assumptions, the control becomes procedural rather than effective.
Common weaknesses include poor role design, weak auditability, backlog pressure, and exception handling that bypasses the second approval step. Another failure mode is over-broad checker authority, where reviewers approve too many actions without meaningful scrutiny.
The control also weakens when the underlying workflow is fragmented. If one system captures the request, another executes it, and audit logs are incomplete, organisations can lose the evidence needed to prove that the approval actually happened before finalisation.
Those gaps map to broader access and control expectations in NIST SP 800-53 Rev 5 Security and Privacy Controls, especially the controls that govern access, auditability, and configuration discipline.
Why It Matters for Security and Trust
Maker-checker is important because many damaging events are not technically sophisticated. Fraud, accidental deletion, unauthorised entitlement changes, and incorrect payment releases often succeed because a single person can both initiate and complete the action.
The control adds friction by design, but that friction is what creates time to detect a bad request, a mistaken amount, or an impersonation attempt. In that sense, it is both a preventive and a detective control, because it creates a review point before final effect.
Where workflows involve API-driven approvals or automated execution, the control still needs human accountability around the final authorisation decision. The broader access risk is captured well by OWASP API Security Top 10, especially where authorisation failures can let a request move from draft to action without the intended checks.
In regulated or high-trust environments, maker-checker also supports evidentiary needs. A strong approval trail helps explain who reviewed the action, when the decision was made, and whether the final step matched policy.
Risk and Threat Considerations
Maker-checker controls are attractive to attackers precisely because they introduce a trust boundary, and trust boundaries are often where compromise or abuse becomes visible. If the reviewer is weak, rushed, or bypassed, an attacker can use a legitimate workflow to authorise harmful action that appears normal on the surface.
Failure mechanism: The control fails when the maker and checker are not truly independent, when approvals are auto-routed or rubber-stamped, or when high-volume operations encourage blind acceptance of requests.
Impact: Harmful changes can be finalised with legitimate-looking approval, leading to fraud, unauthorised payments, privilege escalation, or configuration changes that are difficult to unwind.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.PO-01 — Policy | Maker-checker is a policy-backed control pattern for governed approvals and accountability. |
| PR.AA-05 — Identity Management, Authentication, and Access Control for Assets and Services | Maker-checker often depends on distinct approver access and controlled authorisation paths. | |
| Recommendation — Define approval policy that separates request and final authorisation for sensitive workflows. Enforce distinct approver access and prevent self-approval in sensitive workflows. | ||
| NIST SP 800-53 Rev 5 | AC-5 — Separation of Duties | Maker-checker is a classic separation-of-duties control that splits initiation from approval. |
| AU-2 — Event Logging | Maker-checker depends on auditable records of who requested, reviewed, and finalised an action. | |
| CM-5 — Access Restrictions for Change | Maker-checker reduces uncontrolled changes by requiring approval before finalising sensitive modifications. | |
| Recommendation — Separate request, review, and execution roles for high-impact actions. Log maker, checker, timestamp, and outcome for every controlled approval. Require approved change workflows before executing sensitive configuration updates. | ||
Practitioner Guidance
Governance implication: Treat maker-checker as a control design decision, not just a workflow convenience. The approval path should be narrow enough that the reviewer can genuinely verify the business intent, while still being practical enough that teams do not route around it under pressure.
What to watch for: Repeated same-day approvals, identical approver and requester patterns, exception-heavy queues, and approvals made without enough supporting context are all signs that the control may exist in form only. The real test is whether the second person can still reject the action with confidence.
Practitioner takeaway: Maker-checker is strongest when independence, traceability, and timely review all hold at the same time, because removing any one of them turns the control into ceremony.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
