Risk & compliance
The control exists.Did it execute?
A control is designed once and executed thousands of times. Assurance depends on the difference between those two facts — and much of that difference is already recorded across your systems.
What the control framework states
- The control, its owner and its frequency
- Approval thresholds and authority limits
- Segregation of duties between roles
What execution shows
- Whether it ran, when, and in what order
- Approvals granted outside limit, or after the fact
- Request and approval touched by one identity
Design tells you what should happen. Execution tells you what did.
The assurance gap
Sampling tests a handful of cases.Execution evidence reaches far more.
Testing a control against twenty-five cases a quarter produces evidence about twenty-five cases. It is a reasonable answer to a resourcing problem, not to an assurance one. Far more of that activity is already recorded — approvals, overrides and exceptions, captured in sequence by the systems that processed the work. Reading it does not require a new control, a new form or a new attestation.
What the evidence looks like
The control as designed, against the control as executed
One payment case, reconstructed across the request, approval, execution and posting systems that handled it. The controls did not disappear — they moved.
Three of these four exceptions close cleanly on paper. The control has an owner, a procedure and a completed record. Only the order in which the records were written shows what happened.
How it works
From population, to deviation, to evidence
Three steps, in order. Each one narrows the question, and each one keeps the answer traceable back to the underlying record.
Widen the lens beyond the sample
How much of the activity can we see?Reconstruct the cases the control was meant to govern from the systems that recorded them. Coverage stops being a sampling decision and becomes a data question.
Find where execution left the design
Which cases did not follow it?Compare the intended control sequence against what the records show: missing steps, wrong order, wrong identity, wrong time, wrong threshold.
Open any finding to the record
Can we stand behind it?Each deviation drills through to the transaction, timestamps and identities behind it — what an auditor, regulator or control owner needs to accept or dismiss it.
What deviation looks like
Four ways a working control still fails
None of these produce a missing record. Each one produces a complete record in the wrong shape — which is why they survive a documentation review and a sample test.
Out-of-order execution
Steps completed before the check that was meant to gate them. The control ran; it simply ran too late to prevent anything.
Override and exception
Approvals granted outside a threshold, a limit or a role, and the exception paths that carry more volume than anyone assumed.
Same-hand execution
Request and approval touched by one identity, or by two identities that resolve to the same person through a delegation or a shared account.
Retro-approval
The control recorded after the outcome it was meant to control. Complete in the register, ineffective in practice.
How RE-ViVE helps
Start with the execution evidence you already have
RE-ViVE reads how controlled processes actually executed from records already held in your systems. It adds no control, no attestation and no burden on the first line.
No new control to operate
Observation sits beside the process rather than inside it, so nothing new lands on the teams doing the work.
No new instrumentation
Use the operational data your applications already write. No agents, no logging changes, no production impact.
Evidence an auditor can open
Every finding drills through to timestamps, identities and transaction detail rather than a summary count.
Continuous rather than periodic
Watch the control between test cycles, so a deviation surfaces when it starts instead of at the next review.
Where it applies
Wherever a control depends on the order things happened
Controls that live inside a cross-system workflow are the hardest to evidence, because no single system holds the sequence. Those are the ones execution data answers best.
SOX and the close
Journal approvals, three-way match exceptions, manual postings and the segregation of duties that spans two or three applications.
KYC, AML and screening
Verification steps taken out of sequence, screening cleared by the requesting party, and alerts closed without the review they required.
Procurement and vendor risk
Purchase orders raised after the invoice, vendors created and paid inside the same window, approvals routed around a threshold.
Regulatory timelines
Cases with a statutory clock — complaints, breach notification, reporting deadlines — where the wait is the risk, not the outcome.
Next steps
You probably do not need another control.You need to watch the one you have execute.
Choose one controlled process. We will reconstruct how it actually ran across the full population, from read-only extracts, and show you where execution left the design.