Maker-Checker Approval Workflow: Definition, Examples, and 12 Essential Controls
A maker-checker approval workflow separates initiation from authorization. Use this guide to define roles, route risk, prevent self-approval, retain audit evidence, and apply 12 practical controls.
What is a maker-checker approval workflow?
A maker-checker approval workflow, also called dual approval, dual control, or the four-eyes principle, is an authorization process that requires at least two people. The maker submits a transaction or change. A different checker independently approves or rejects it. As described in Wikipedia’s maker-checker definition, separating creation from confirmation or authorization prevents one person from completing a covered transaction alone.
Maker-checker is a specific form of an approval workflow built around segregation of duties. OneSpan’s maker-checker authorization guidance applies this separation to sensitive administrative commands. Without dual control, an administrator with the necessary privileges can execute a command immediately. When maker-checker authorization is enabled, the command remains pending until a different, appropriately privileged administrator authorizes it.
“For each transaction, there must be at least two individuals necessary for its completion.”
How does the maker-checker process work step by step?
The maker-checker process moves a sensitive action through five broad states: creation, pending review, independent validation, decision, and execution or return. OneSpan’s administrative authorization guidance documents the core pending-operation, review, approval, and rejection stages. The implementation model should retain who acted, what they reviewed, and when.
- The maker creates and submits the operation with the information and supporting evidence required by the organization’s policy.
- The system records a pending operation and prevents the covered action from completing immediately.
- An eligible checker receives the request. Eligibility should depend on assigned role, administrative scope, authority level, and separation from the maker.
- The checker independently validates accuracy, authorization, scope, supporting evidence, and risk, then approves or rejects the request under defined decision rules.
- The system resolves the operation. Approval either executes the action or authorizes completion of the approved operation. Rejection returns or removes it while retaining the required audit record.
Some implementations execute the operation automatically after approval, while others require the original maker to complete the approved operation. When the final action is separate from approval, the audit design should show whether the executed change matched what the checker approved. A material edit should be treated as a new version requiring review.
Build a risk-routed maker-checker purchase flow
A miniature of Cogniver's visual workflow builder with demo data: steps drop onto the canvas, connectors wire the branches, and a request routes itself to approval under rules your team sets. Hover or tap any AI step to see the rules it follows; a human can always override. Real builders add escalation windows, document requirements, and AI routing.
How are maker and checker responsibilities different?
The maker prepares and submits the transaction or change. The checker holds separate authority and tests the request against the applicable criteria before deciding. OneSpan’s documented model requires the initiator and approver to be different administrators and limits authorization to administrators with the required approve-or-reject privilege.
| Participant | Primary responsibility | Must not do | Evidence produced |
|---|---|---|---|
| Maker | Create an accurate, complete request with supporting material | Approve the maker’s own request | Submitted values, reason, evidence, and timestamp |
| Checker | Validate authority, accuracy, scope, evidence, and risk | Approve outside assigned authority or without review | Decision, comments, identity, and decision time |
| Workflow system | Hold the action pending, enforce configured eligibility, and retain history | Execute the covered action before authorization | State changes, notifications, edits, and execution outcome |
A checker needs enough context to challenge the request, not merely confirm that each field contains a value. Put the proposed change, prior value where relevant, governing policy, attachments, affected resources, and risk indicators in one review view. The checker should not have to reconstruct the case across inboxes and systems.
Which transactions and system changes should require dual approval?
Use dual control when one mistaken or malicious action could cause material financial, security, operational, or compliance harm. Financial transactions, identity administration, authenticator assignments, device security settings, application permissions, network policies, enrollment or trust rules, access exceptions, and automated actions are practical candidates for risk-based review. Putting every routine update behind two people can create avoidable approval queues.
Sample maker-checker controls by business function
| Operation | Maker | Checker | What the checker validates |
|---|---|---|---|
| Payroll change | Payroll or HR specialist | Payroll manager or controller | Employee, rate, effective date, authorization, and source evidence |
| Payment batch | Treasury or accounts payable analyst | Authorized finance approver | Payees, amounts, invoices, payment date, and approval authority |
| Vendor bank update | Vendor-data administrator | Finance or procurement reviewer | Approved change request, account details, requester identity, and scope |
| Privileged access | IT administrator | Security or system owner | Business need, requested role, affected system, duration, and conflicts |
| Device or network policy | Endpoint or network administrator | Security administrator | Policy effect, deployment scope, exception terms, and rollback readiness |
OneSpan applies maker-checker authorization to creating and deleting user accounts and assigning or unassigning authenticators. NinjaOne describes the same model in mobile device management, where makers propose device policies, configuration profiles, and security settings and checkers validate them before deployment. Teams can extend that risk-based design to other high-impact permissions, security settings, trust rules, access exceptions, network policies, and automated actions.
Finance teams should connect the control to the underlying purchase approval workflow instead of adding an isolated signature after the real decision. For IT, an access request approval workflow should retain the requested permissions, duration, owner, and reviewer scope from submission through provisioning.
What controls should a maker-checker workflow include?
A sound maker-checker design combines identity separation, scoped permissions, explicit workflow states, evidence requirements, decision records, exception rules, and operating deadlines. Drawing the flow is the easy part. The real test is whether an ineligible person can approve, a pending change can escape review, or an emergency route can quietly become the default.
Workflow states need operating rules
Pending cannot mean forgotten. Name the queue owner, set the first reminder, define when authority passes to a backup checker, and expire stale requests. If a request reserves a unique account name, device assignment, budget, or another scarce resource, specify whether that reservation remains active during review and how rejection releases it.
Use a reusable approval workflow template to document states and controls consistently. Do not force every operation through the same chain. Checker authority, required evidence, escalation, and expiration should match the action’s risk and reversibility.
When does maker-checker add unnecessary friction?
Maker-checker adds unnecessary friction when an action is low impact, easy to reverse, tightly bounded, and already controlled by automated validation or later monitoring. Keep dual approval where risk is concentrated. Remove it from routine work when review effort and queue delay outweigh the reduction in error, fraud, or unauthorized change.
| Design point | Single-administrator processing | Maker-checker processing |
|---|---|---|
| Execution | Authorized user acts immediately | Action waits in a pending state |
| Review | No independent pre-execution decision | Eligible checker approves or rejects |
| Best fit | Low-impact, reversible routine work | High-impact or difficult-to-reverse actions |
| Main risk | One error or compromised account acts directly | Delay, collusion, or rubber-stamping weakens control |
| Evidence | Action record identifies the operator | Record identifies proposal, review, decision, and execution |
Dual approval does not guarantee a correct decision. Two people can share the same bad assumption, collude, or approve by reflex. Excessive checker access creates another problem: a reviewer with authority across every system becomes a concentrated control point. Clear criteria and narrow authority matter as much as adding the second person.
- Rubber-stamping: review whether checkers opened the required evidence and supplied required comments.
- Bottlenecks: assign backup checkers and escalation routes without granting unrestricted approval rights.
- Vague criteria: specify what the checker must inspect and what requires rejection or return.
- Control sprawl: review covered actions periodically and remove dual approval when the risk no longer justifies it.
How should maker-checker controls be tested and audited?
Test the control from request creation through final execution, not only the approval click. Audit evidence should identify the maker, eligible checker, submitted values, supporting material, timestamps, comments, decision, later edits, exceptions, and execution outcome. Operations teams should also test rejected, expired, reassigned, and emergency requests through the complete process.
Review queue age, approval time, rejection, reassignment, expiration, and rework as operating signals. Examine these approval workflow metrics alongside request samples to identify where submission requirements, checker coverage, or escalation rules need attention.
How Cogniver helps build maker-checker approval workflows
Cogniver turns branched, multi-step approval designs into executable flows. The visual builder supports branching, merging, and multi-step chains, making the maker, checker, escalation route, and final outcome explicit. Purchase and document requests route themselves, while required uploads stop an approval from proceeding until the evidence is attached.
At a branch point, an AI Router sends each request down exactly one path using exact amount rules or an AI-applied policy written in plain words. Every router requires a default branch. If the request does not clearly match another branch, it follows the defined default instead of stalling or forcing the AI to guess. Approvers can enter verified values at their step, and later routing can use those values.
Each workflow gets an isolated AI agent trained by organization administrators on that workflow’s rules and configuration. It answers questions, routes requests, and follows up with approvers. Groups and grades from the shared organization chart drive approver resolution and module access, connecting approval assignments to the organization’s defined structure.
Frequently asked questions
Can the maker and checker be the same person?
No. Under the standard maker-checker model documented by OneSpan, the administrator who initiates the command and the administrator who approves it cannot be the same person. If one person can submit and approve the same operation, the workflow does not enforce segregation of duties, even when the interface displays two separate steps.
Why is maker-checker called the four-eyes principle?
Wikipedia identifies maker-checker as the four-eyes principle because at least two people participate in completing a covered transaction: one creates it and another confirms or authorizes it.
What happens when a checker rejects a request?
OneSpan’s administrative authorization guidance allows a checker to approve or reject a pending operation. A sound control should stop execution and then return, cancel, or remove the request under a defined rule while retaining the required decision record.
What is the difference between maker-checker and an ordinary approval workflow?
Maker-checker specifically requires separate initiator and approver identities and holds the covered action for authorization. Its design therefore emphasizes checker eligibility, pending states, execution evidence, and segregation of duties.
