Before treating “Approved” as permission to proceed, require the record to answer three questions: what was reviewed, who had authority to decide, and whether anything material has changed since. Build the compliance review workflow around those answers before configuring screens or reminders.
The recommended model below makes decisions, ownership and delay reconstructable. It is an illustrative business-change review, not a universal regulatory process or a guarantee of compliance or auditor acceptance.
Start with the change and its decision boundary
Consider a hypothetical change: the customer-support team wants to move written support tickets into a new external platform. The review covers the proposed ticket fields, staff access and retention arrangements before migration. Its evidence package contains a data-field inventory, an access matrix and the supplier’s retention and deletion documentation. The support operations manager owns the case; a designated compliance approver decides within the organisation’s policy.
Agree which changes enter the process, what approval permits and who remains accountable while review is open. Separate permission to implement from confirmation that implementation occurred. If implementation needs verification, track that work separately rather than making “Approved” mean both.
Model states around decisions and evidence
The Open Worldwide Application Security Project (OWASP) recommends explicitly controlling permitted transaction state transitions. Apply that principle here as a bounded software-design analogy: define each allowed move and its conditions. The guidance does not prescribe a compliance-review lifecycle.
Enter with a case ID, proposed scope and owner. Submit a versioned package or record a withdrawal reason.
Enter with a submission snapshot and timestamp. Record completeness and assignments, an evidence request or a withdrawal.
Enter with a reviewer and reviewable package. Exit with an evidence request, authorised decision or permitted withdrawal.
Enter with specific requests and a response owner. Return with responses and a new package version, or withdraw.
Enter with a version-bound authorised decision. Reopen with a revision reason and new package; preserve the earlier decision.
Enter with an authorised rejection and reasons. A later proposal starts a linked case.
Enter with a permitted actor, reason and timestamp. A later proposal starts a linked case.
Every transition needs permission and a recorded basis.
Recommended states, entry records and permitted exits. Disallow paths not listed.Use “Awaiting evidence” for both missing material and requested changes in this model. Record the outstanding request and re-triage the response. Require all mandatory evidence and review findings to be resolved before approval; specify who may withdraw a case and under what conditions.
Keep escalation as an event or flag attached to the current state. An escalated case may still be awaiting evidence. Moving it into a separate “Escalated” state would obscure that distinction unless the underlying review state remained visible.
Bind approval to the reviewed version
For the support-platform change, a missing deletion procedure sends the case to Awaiting evidence with a named response owner. Once the missing document is supplied and the findings resolved, the approver can decide on that exact submission version. Bind the decision to the case scope, field inventory, access matrix, evidence versions and policy or checklist version. Preserve the reviewed snapshot or references that resolve to those exact versions, rather than an overwriteable document link.
Define materiality and who may assess it before launch. Treat changes to scope, decision-relevant evidence or the basis of approval as requiring renewed review. Retain the historical approval, but do not apply it to the revised proposal. Reopen through triage, or create a linked case requiring fresh approval. Record permitted administrative corrections without rewriting the approved snapshot. In this example, adding call recordings to the migration changes the approved data scope. The written-ticket approval remains historical evidence; it does not authorise the expanded migration.
At decision time, have the server verify that the version and state still match what the approver reviewed. Make the check and decision a single indivisible operation. If an edit or another decision intervened, reject the stale action and require the approver to review the current record. The last arriving request must not overwrite an earlier decision outside a permitted transition.
Separate responsibility from permission
Assign distinct responsibilities even when one person holds several roles. Decide which combinations are acceptable for the risk in scope. The accountable case owner keeps the work moving; that assignment does not itself confer approval authority.
Supplies the proposal and evidence. Identify any substitute contributor.
Maintains assignments and follows up blockers. Record handover to a backup.
Records findings and requests. Give a qualified backup access to prior findings.
Acts within defined authority. Delegation needs scope, duration and conflict checks.
Acknowledges and records action. Use a named fallback if acknowledgement is missing.
Manages rules and access. Administrative privileges alone grant no approval authority.
A backup needs authority, not just access.
Recommended responsibilities and the conditions for substitution or delegation.Apply separation of duties proportionately, with no self-approval where a defined conflict applies. Record who authorised each delegation, its permitted actions, scope, effective period and delegate. If no eligible approver is available, escalate the blockage rather than relax the approval rule. Control changes to these permissions as well as their use.
OWASP recommends access-control checks on every request for the specific object or functionality accessed. For this workflow, enforce checks server-side against the case and requested action, alongside state, version, conflict and delegation conditions. Hiding an approval button does not enforce these rules.
Measure service time without erasing age
A service-level agreement (SLA) should specify the service commitment and how it is measured. In this model, use it to govern internal review targets, tracked separately from statutory or contractual deadlines. Do not assume that pausing an internal clock changes an external obligation.
The National Institute of Standards and Technology (NIST) describes security and privacy control assessment procedures as tailorable to organisational risk-management processes and stated risk tolerance. That supports a tailoring principle, not a particular review target, calendar or escalation threshold. Choose those rules explicitly for this process.
Start at Submitted/Triage, including queue time within the service calendar. Retain the first-submission timestamp.
Record the request and pause reason. Keep total elapsed age and external deadlines visible.
Resume a paused clock, or continue an unpaused one. Record the cycle without erasing accumulated time.
Only when its trigger applies, record the recipient, acknowledgement and fallback. Escalation is not a required stage.
Stop the internal review clock. Do not mark separate obligations complete merely because review ended.
Clock rules are conditional; escalation can occur in any active state. Keep case age and external deadlines visible.
Recommended timing rules and a separate conditional escalation event, not a mandatory sequence.Specify working hours, holidays, the business calendar and governing timezone. Define treatment of daylight-saving changes and submissions outside working hours. Store event timestamps consistently and display the governing timezone beside due times.
Show current queue age, accumulated service time and total elapsed time since first submission separately. Define queue age from entry into the current work queue; retain earlier queue intervals in the history. Preserve every evidence-wait interval and resubmission cycle. Reopening an approved case starts a new review cycle without deleting the previous one or resetting the case’s original age.
Version the timing policy and calendar, and record which version governed each cycle. For due-time changes, retain the old and new values, actor, reason and authorising basis. Decide whether policy updates affect open cases rather than silently recalculating history. Waiting for evidence must not silently stop a legal deadline; any adjustment requires a separately established and documented basis.
Make escalation a recorded intervention
Specify each escalation rule’s trigger, recipient, acknowledgement requirement, fallback owner and required action record. Consider threatened due times, unresolved evidence requests and unavailable eligible approvers as distinct triggers. Set thresholds according to the review’s risk and operational needs, not a universal interval.
Keep the accountable case owner assigned until an explicit reassignment is recorded. A notification does not transfer responsibility, and acknowledgement does not resolve the issue. Require the escalation owner to record the intervention: arranging an authorised backup, assigning an evidence response or documenting a continuing block and next action.
Define when missing acknowledgement invokes the fallback, including failed delivery and unavailable recipients. Specify a final accountable recipient if the fallback is also absent. Make retries recognise an existing escalation rather than create competing assignments. Overdue must never mean automatically approved; an exceptional decision still needs an authorised actor, reviewed version and recorded basis. For this hypothetical case, route a missed acknowledgement by the compliance escalation lead to the named operations director. The director records the next action and arranges an eligible backup where permitted; the support operations manager remains case owner until a handover is recorded.
Keep the decision record and test difficult paths
Keep a chronological event history, not just the latest status. Use the following record to reconstruct both decisions and the actions leading to them.
- Identity and scope: case ID, scope, submission version and versioned evidence references.
- Governing rules: policy or checklist version, timing-policy version and applicable delegation reference.
- Action: author, action, timestamp, reason, previous state and next state. Retain identical states for events without a transition.
- Accountability and outcome: assigned owner, due time and decision where applicable. Preserve prior values when assignments or due times change.
- Missing required evidence: block approval, record the request and preserve elapsed age.
- Conflicting approver: deny the decision server-side, including requests that bypass the interface.
- Absence or backup: permit only valid delegated authority and record the handover.
- Weekend or timezone boundary: calculate due time under the governing calendar, including daylight-saving changes.
- Revised submission: preserve the prior package, re-triage and retain accumulated time. A material post-approval edit must require renewed review.
- Stale or concurrent approval: reject outdated or incompatible decisions without overwriting history.
- Duplicate escalation: retain one identifiable intervention and an unambiguous owner. Test missing acknowledgement and fallback routing too.
- Timeout: establish whether the original action committed before retrying; do not duplicate decisions, lose events or imply approval.
NIST cautions against assuming control equivalency solely from relationship tables: mappings and crosswalks are not always one-to-one, and relationship analysis can be subjective. Treat a mapped control label as a reference, not a substitute for examining the workflow’s permissions, decisions and records.
Before release, rehearse the support-platform case through missing deletion evidence, approval of written-ticket migration, a proposed expansion to call recordings and an unanswered escalation. Require the team to reconstruct which version may proceed, who must act next and which deadlines remain live from the record alone. Resolve any ambiguity before adding more states or notifications.
