Can This Self-Hosted Application Support Your Approval Process? A Practical Evaluation Framework

Why an approval feature is not the same as a controlled approval process

Many applications can mark an item as approved, restrict a status change, or notify a colleague for review. That can be useful, but it does not automatically provide a controlled process for a purchase, expense, access request, customer-data change or publication decision.

A controlled approval process needs more than a screen action. It needs a defined decision, eligible decision-makers, rules for when their authority applies, a record of what they decided, and safeguards against people changing or bypassing the process after the fact. The right question is not “Does this application have approvals?” It is “Can we configure and operate this application so that our required decisions are made, enforced and evidenced?”

NIST SP 800-53 treats controls as flexible and customizable within an organization-wide risk-management process. Apply the same principle here: translate your own business, policy and risk requirements into observable tests. A generic feature label is not a substitute for that work.

• Treat a feature as a starting point, not proof of control.
• Separate convenience reviews from decisions that create financial, legal, security or customer-impacting commitments.
• Document which requirements are mandatory, which are desirable and which must be handled outside the application.

Start with the real-world decision

Begin with the business event, not the software configuration. Describe one approval type at a time. “Purchases” is usually too broad: approving a low-value recurring supplier renewal may involve different evidence, authority and risk from approving a new high-value supplier commitment.

For each decision, identify the requester, the record being decided, the required evidence, the possible outcomes and the action that may occur only after approval. Also identify the consequence of an incorrect approval. This determines how much control, visibility and review the workflow needs.

• What is being approved: a request, document, record change, payment, publication, access entitlement or customer-data action?
• Who may request it, and what fields or attachments must be complete before submission?
• Who may approve, reject, return for changes or cancel it?
• What thresholds, risk categories, departments, locations or data classifications alter the route?
• What action becomes permissible after approval, and who performs it?
• How long must the decision record and supporting evidence be retained?

Map the minimum workflow before evaluating software

Write the smallest complete workflow in plain language, then make every step testable in the application. A useful baseline is request, review, decision, notification, execution and record retention. If a proposed tool cannot represent a required step or preserve the needed information, identify the compensating control explicitly rather than assuming users will remember it.

Keep the approval decision distinct from downstream execution. An approver may authorize a purchase, for example, while a different person creates the order. That distinction is important for accountability and separation of duties.

• Request: create a uniquely identifiable item and capture required data and evidence.
• Review: make the item available to the correct reviewer or reviewers.
• Decision: record approval, rejection or return for rework with the responsible identity.
• Notification: tell the requester and next responsible party what happened.
• Execution: permit or trigger the authorized follow-on action only when conditions are met.
• Retention: preserve the decision record, attachments and history for the required period.

Evaluate states and transitions, including changes after approval

A workflow is defined by its states and the permitted transitions between them. At a minimum, test drafts, submitted items, approved items and rejected items. In many processes, you also need returned-for-changes, cancelled, expired, superseded or executed states.

The most revealing test is a material change after approval. If the amount, supplier, scope, attachment, access level or customer-data purpose changes, does the application lock the record, invalidate the approval, create a new revision or simply retain an old approval beside changed content? Your process should state which changes require re-approval, and the application should make that outcome clear.

Also test who can move each state. A requester may be able to edit a draft, but should not necessarily be able to mark it submitted, approved or executed without the required conditions.

• Can users see the current state and full prior state history?
• Are transitions restricted by role, assignment or workflow conditions?
• Are rejected items closed, editable for resubmission, or routed back for correction?
• Does a post-approval change trigger re-approval where your policy requires it?
• Can an approved item be cancelled, and is the cancellation reason and identity retained?
• Can users distinguish an approved record from a pending, revised or superseded record?

Test authority rules, not just approver assignment

A named approver is simple to understand but can be fragile. A robust evaluation tests whether the application can reflect the authority model you actually use: role-based reviewers, thresholds, conditional routes and more than one approval stage. Do not assume that an assigned manager is always the authorized person for every decision.

Use representative cases. Test a routine request, a request just below and just above a monetary threshold, a high-risk request, a request that spans two departments, and a request requiring legal, security or finance review. Record whether routing is automatic, whether it can be changed, and what users can see when they are not the current reviewer.

• Named authority: can a particular accountable person approve?
• Role-based authority: can the current holder of an approved business role approve?
• Threshold authority: does the route change at the required amount or risk level?
• Multi-step authority: can required reviewers act in the correct order?
• Parallel authority: when several reviews are required, must all approve or is one sufficient?
• Conditional authority: can required reviewers vary by department, data type, country, project or request category?

Check segregation of duties and privileged access

Separation of duties means more than assigning different labels to people. NIST control AC-5 calls for defined duty separation, documented separation and access authorizations that support it. Turn that principle into direct tests: can a requester approve their own request, alter an approved record, choose an ineligible approver or bypass a required reviewer?

Evaluate ordinary application roles and operational access separately. In a self-hosted deployment, people with broad deployment or host access may be able to alter application operation, data or configuration outside the business workflow. Docker documents that its standard authorization model is all-or-nothing for users allowed to access the Docker daemon: such users can run Docker client commands. Include this access in your threat model and governance design.

Docker authorization plugins can make allow-or-deny decisions based on authentication and command context, but Docker also documents limits to their enforcement scope. If you intend to rely on such controls, test their scope against the administrative actions that matter to your process. Do not infer that application-level workflow restrictions alone constrain infrastructure administrators.

• Use separate test accounts for requester, approver, executor, application administrator and infrastructure administrator.
• Attempt self-approval, approval by an unauthorized role and approval after reassignment.
• Attempt to edit key fields and attachments after approval.
• Identify who can alter workflow rules, roles, audit settings, data stores, containers and backups.
• Define who reviews privileged access and how often.
• Ensure the process acknowledges residual risk where a small technical team necessarily holds broad operational access.

Assess delegation, absence and overdue work without losing accountability

Approval workflows often fail in ordinary circumstances: an approver is on leave, has changed roles or simply does not act. A workable process needs a deliberate route for delegation, reassignment and escalation. The goal is continuity without obscuring who had authority and who made the final decision.

Test whether the application records the original assignee, the person or rule that reassigned the work, the delegate’s decision and the timing of each event. If delegation is handled outside the application, decide how that instruction will be documented and how the new approver’s authority will be verified.

• Can an approver delegate only within a permitted role or authority level?
• Does the system preserve the original assignee and the delegation history?
• Can a process owner reassign an overdue item, and is the reason recorded?
• Are reminders and escalations configurable enough for the required response time?
• What happens if an approver account is disabled or removed while work is pending?
• Is there a documented emergency path, with later review, for decisions that cannot wait?

Assess approval evidence and audit records

The decision record should answer basic questions without relying on someone’s memory: what happened, when and where it happened, what or who caused it, what the outcome was, and which identities were associated with it. These are aligned with the audit-record elements in NIST control AU-3.

For each decision, inspect the actual retained output rather than relying on a dashboard. Determine whether it includes the request version, decision, date and time, approver identity, comments, attached evidence, assignments and all meaningful changes. Then test whether a user can export or retrieve the evidence in a form that remains understandable outside the application.

Evidence is only useful if it remains trustworthy. NIST AU-9 addresses protection of audit information and restricting management of logging functions to an appropriate subset of privileged users. Ask who can modify, delete, disable or replace approval records and logs, and how those actions themselves are detected or reviewed.

• Request identifier and the approved version or revision.
• Event type, time, relevant source or location, outcome and associated identities.
• Decision comments, rejection reasons and linked attachments where required.
• A complete assignment, delegation and state-change history.
• Retention, export and retrieval procedures that have been tested.
• Access controls over approval records and audit logging, including privileged-user governance.