The problem
Reviews look backwards. Cases don't stand still.
Most assurance is retrospective. A sample is pulled, checked against the rules as they stood that month, and filed. The file keeps changing — new documents, updated circumstances, revised interpretations, obligations falling due — and nobody looks again until the next sample, a complaint or a regulator's request. That is not a failing of the team. It is what a snapshot is.
Evidence went stale
The case that passed in March.
It was compliant when it was checked. Then a review date passed with no evidence on file, and the next sample was months away.
The rule moved
The rule that changed after you checked.
The interpretation was tightened last quarter. The back book was reviewed under the old one, and nobody re-tested it.
The lookback
The question asked years later.
When a regulator asks whether a control held across a period, a lookback becomes a manual project. In February 2025 the FCA asked 22 of the largest advice firms for seven years of ongoing-advice data.
Two populations, one standard.
Open cases
New cases, as they develop.
Reviewed at intake and again as each document or decision lands, so a gap is raised while the case is still open and cheap to fix, not after it closes.
Back book
Existing cases, over time.
Re-reviewed whenever something that matters changes, on a schedule you set and on demand, for as long as the case sits on your books.
How it works
Five things put a case back under review.
Each trigger re-runs the case against every requirement it is in scope for. Every run is recorded in the evidence ledger; only exceptions reach a person.
01
New evidence lands
A document, record or transcript is added or changed. The case is re-evaluated as it develops, not when it closes.
02
A requirement changes
You revise an interpretation, threshold or evidence standard. Every case in scope is re-run against the new version, and each case it moves is listed.
03
Regulation changes
When a rule changes, the requirements it touches are updated with an effective date, and the affected population is re-reviewed.
04
A date falls due
Review anniversaries, expiry dates, notification deadlines. Tests that depend on time are re-run as time passes, so a case that was in date doesn't quietly fall out of it.
05
A sweep, scheduled or on demand
Every in-scope case is re-run on a cadence you set, or on demand — before a board meeting or an audit, say — whether or not anything flagged. It shows the control operated across the whole period, not only on the days something changed.
Why it works
Every change in a finding has a cause.
Re-run a conventional model and the answer can change for no reason at all. Continuous review built on that would bury reviewers in noise. HaloRT makes every run deterministic: same inputs, same requirement version, same finding. So when a finding on an existing case changes, something real changed — a document, a rule or a date — and the exception carries the extract, requirement version and reasoning that show which.
Every re-review is recorded in the evidence ledger with its inputs, requirement version and signed run manifest. A case's history can be replayed, not reconstructed.
How HaloRT works →Same case · four runs
IllustrativeThe conventional finding drifts while the case stands still, then misses the change that matters. HaloRT's finding moves once, when the case does.
No migration
Nothing to migrate.
IntelCS connects to the systems your teams already use — CRM, case management, document stores, ticketing — over read-only, least-privilege connectors. When a record changes or a document lands there, the case is re-reviewed. Findings and exceptions go back into the GRC platform, case manager or ticketing system your reviewers already work in. No data migration, and nobody changes where they work.
01 · YOUR SYSTEMS
Your systems
CRM, case management, document stores. Read-only connectors.
02 · INTELCS
IntelCS
Continuous review against your requirements, recorded in the evidence ledger.
03 · YOUR WORKFLOW
Your workflow
Findings and exceptions pushed to your GRC, case or ticketing system.
Coverage that holds between reviews.
Exceptions, not re-reads
Reviewers see the cases that need a judgement, with the cause attached. Files that are still fine stay out of the queue.
Coverage across the period
Per requirement, per entity, per period: what was in scope, reviewed, failing and outstanding — across the whole period, not the sample month.
Lookbacks become queries
When someone asks whether a control held over the last three years, the answer is already in the ledger.
Interpretation changes you can test
Change a requirement, re-run the back book, and see every case it moves before you sign it off.
Across sectors
Same mechanic, different rulebook.
The triggers are the same everywhere. The requirements are yours.
Finance
The case
An ongoing-advice client file
What changes
The annual review date passes with no review on file
Continuous review
Raises an exception when the date passes, not at the next sample
Healthcare & life sciences
The case
A deviation with an open CAPA
What changes
The CAPA record is updated; its SOP deadline approaches
Continuous review
Re-reviews each update and raises an exception if the deadline passes with the CAPA still open
Critical infrastructure & defence
The case
An asset's inspection record
What changes
The mandated interval lapses, then a new inspection is logged
Continuous review
Flags the lapse when it happens and clears it when the evidence lands
Regulated consumer services
The case
A gambling customer's account
What changes
New transactions change the staking pattern
Continuous review
Re-checks affordability evidence against your intervention policy
Sources
Seven-year ongoing-advice data request to 22 advice firms — FCA, Ongoing financial advice services, February 2025