How should a business system separate request, approval, execution, review and export permissions?
Conclusion: “administrator” and “standard user” are not an adequate control model. Break each process into request, approval, execution, review, accounting or settlement, viewing and export. Identify actions that one person should not complete end to end, then constrain authority by value, organisation, record ownership, status and time. A small team can use management review and exception reporting as compensating controls, but a universal account should not become the permanent answer for high-risk work.
Who this is for
This article applies to procurement, sales, inventory, expense, contract, project, membership, service and payment systems. Warning signs include a manager submitting and approving the same expense, warehouse staff changing a quantity already accepted by finance, a support agent receiving unrestricted customer exports merely to handle refunds, or employees retaining access after changing roles.
China's Basic Standard for Enterprise Internal Control identifies segregation of incompatible duties and approval controls as core measures. The Small Enterprise Internal Control Standard describes responsibilities across application, internal review and approval, execution, information recording and supervision. Software should consistently enforce responsibilities the business has agreed and preserve evidence; it cannot decide organisational accountability on management's behalf.
Five layers of access
| Layer | Question | Example |
|---|---|---|
| Action | What can this role do? | Create a purchase request, approve a refund, confirm receipt, export a report |
| Data scope | Which records are in scope? | Own customers, department, named stores, named projects, company-wide read-only |
| Condition | Under what circumstances? | Below a value limit, draft only, a defined region or time window |
| Field | Which sensitive values are visible or editable? | Warehouse sees consignee data but not margin; support cannot edit settlement accounts |
| Duration | When does authority begin and end? | Seven-day delegation, automatic expiry after a project, immediate leaver suspension |
Hiding a menu is a usability choice, not a security boundary. Server operations, imports, exports, mobile clients, scheduled jobs and integrations must enforce the same decision. Approval also does not imply unlimited editing after the record moves to the next state.
Where duties should be separated
Request and approval
A requester should not approve their own restricted transaction. Route by value, type, department, budget and exception, and retain the rule version used at the time. Additional sign-off, transfer, rejection and delegation must not bypass a required level.
Approval and execution
Approving a purchase is not receiving it; approving a refund is not releasing money. Separate the decision from confirmation by the person who can observe quantity, quality, receipt of funds or the operational result.
Execution and review
Shipping, receiving, inventory correction, migration and bulk price changes need proportionate review. Review should compare the approved intent with quantities, objects, evidence and exceptions—not add another ceremonial “approve” click.
Processing and accounting or settlement
An operator should not overwrite data that has been invoiced, posted or settled. Corrections should use reversals, adjustments or fresh approval so the original value, reason and impact remain visible.
Viewing and export
Permission to view a record does not automatically permit bulk removal. Customer, employee, price, contract and finance exports need separate authority, restricted fields and scope, plus purpose, generation, download and expiry evidence. Watermarking or secondary approval may be appropriate.
Build a usable permission matrix
Start with risky business actions rather than the current menu. Put each object and action on a row, roles in columns, then record data scope, value or state condition, evidence and backup owner. For refunds, support might request with customer evidence, a supervisor approve within a threshold, finance execute back to the original payment method, finance or the system confirm the result, and audit receive read-only end-to-end access. Only selected roles should export customer contact details.
One person may hold several responsibilities, but the system should record which capacity was used. Where a small company cannot fully separate people, add transaction limits, independent review above a threshold, daily exception reports and scheduled sampling. Name the reviewer and cadence. “We can inspect the logs later” is not a control design.
Privileged access and exceptions
System administrators should manage identities, roles and configuration, not automatically transact in the business. Emergency access should require a reason, defined actions and records, independent approval, automatic expiry and a post-use review. Test, contractor, integration and dormant accounts need an owner, minimum scope, credential lifecycle and end date.
Delegation must preserve the original approver, delegate, period and authority. If the delegate is also the requester, reroute the approval. An organisational move requires review of accumulated roles and data scopes; changing a job title alone does not remove access inherited from earlier assignments.
Implementation sequence and scope
Select five to ten risky processes such as refunds, purchasing, inventory adjustments, contract changes and bulk export. Interview the people who actually execute them. List actions, scope, conditions, evidence and incompatible duties. Assign ownership for employee, position, organisation, store, project and delegation master data. Build reusable roles, then express differences through scope and conditions instead of cloning one role per person. Test allowed and denied scenarios and remove stale accounts before launch.
Scope should cover identity source, organisation and position synchronisation, role templates, row and field scope, export, approval and delegation, temporary access, logs, access requests and periodic certification. If several systems share identity, define the authority source, propagation, failure alerts and revocation timing.
Acceptance checklist
- Every risky action has a named role, data scope, condition and record-state limit.
- Requesters cannot approve their own restricted items, including through delegation or transfer.
- Approval, execution, review and accounting follow the agreed segregation rules.
- Pages, APIs, mobile, imports, exports and background jobs enforce the same policy.
- Changing URLs, record identifiers, organisation values or request parameters cannot cross data scope.
- Settled and archived records cannot be silently overwritten; corrections preserve before-and-after evidence.
- Export is separately authorised and records field scope, requester, downloader and expiry.
- Temporary and delegated rights expire; role change, departure and contractor end trigger review.
- Privileged business actions are visible, constrained and subject to special review.
- The exported permission matrix matches effective system access and can be certified by process owners.
Common mistakes
More roles mean finer control. Personal role copies become unmaintainable. Use roles for stable responsibilities and conditions for organisation, value, state and time.
Executives need every permission. Leaders often need broad reporting and approval, not the ability to edit inventory, release refunds or see every sensitive field.
Logging makes restriction unnecessary. Audit evidence supports detection and accountability; it does not prevent an obvious unauthorised action.
Access is a one-off launch task. People, organisations and thresholds change. Authority must be requestable, expiring, reviewable and revocable.
Ongoing ownership
Review departures, role changes, dormant accounts and temporary rights monthly. Have process owners certify risky roles, data scopes and export access quarterly. Re-run denied-path tests at least annually. A new organisation, store, payment method or bulk operation should update the matrix and acceptance scenarios. Exception reporting belongs in normal operations, not only in incident investigation.
Where one application also serves separate companies or organisations, design tenant isolation and within-tenant data access in addition to the duty controls described here.
Sources
- Ministry of Finance and other authorities: Basic Standard for Enterprise Internal Control (published 4 July 2008; accessed 11 September 2026)
- Ministry of Finance: Small Enterprise Internal Control Standard (Trial) (published 29 June 2017; accessed 11 September 2026)
- Ministry of Finance: Enterprise Internal Control Supporting Guidelines (published May 2010; accessed 11 September 2026)
This article provides a software access-control and accountability framework. Corporate, finance, legal and information-security owners should confirm statutory authority, accounting approval, audit and personal-information requirements.