Reactive is no longer sufficient. So the testing became continuous.

Direct answer

An APRA-regulated Australian bank runs regulatory intelligence and control assurance as one governed reconciliation loop on MorpheusOS. Two instances: one computes what must be true — sweeping APRA, ASIC, AUSTRAC, OAIC and Treasury daily and distilling CPS 230, CPS 234, CPS 220, FAR and SOCI into an obligation register with a human approval on every entry. The other computes what is true — a control library where every control carries an owner, a frequency, a timing and an evidence spec, and where each control’s test runs at its own frequency across eight risk categories. An org-private seam carries approved obligations between them; raw provenance never crosses. ServiceNow GRC remains the system of record. Nothing regulator-bound leaves without a named person releasing it.

Live client workflow — anonymisedTwo instances, one seamRegulator-bound output gated
At a glance

What the loop covers.

These are scope facts — what the workflow carries, at what cadence, across how much of the estate. The bank stays confidential; the standards are public regulation and are named.

BeforeNow
Regulatory intelligenceAd hoc, expensive, aggregated by handDaily sweep · weekly briefing · monthly horizon
Standards distilled to obligationsPer project, by hand6 — CPS 230, CPS 234, CPS 220, FAR, SOCI, Privacy
Standards on watchWhatever was noticed7 more, swept and briefed
Obligation recordA documentSource clause, owner, effective date, mapped controls, review-by
Controls under continuous testTested at review time14, each at its own frequency
Control anatomyDescribed in documentsOwner · type · mode · frequency · timing · evidence spec
Unowned controlsFound at auditTop of the weekly report
Risk categories scored8, on a published formula
Line 2 challengePeriodic, assembled by handMonthly pack, opinion recorded per sample
Line 3 audit trailBindersQueryable run history and evidence provenance
System of recordServiceNow GRCServiceNow GRC — unchanged
The whole case in three sentences

Regulatory signals define what must be true. Control signals report what is true. Compliance is the continuous reconciliation of the two — and until this loop existed, that reconciliation happened periodically, by hand.

The reframe

All a control does is generate a signal.

That sentence came from the bank, not from us, and it is the reason this build works the way it does. A control is not a document describing an intention. It is an instrument reporting whether the right thing is being done.

The signal is the evidence

If a control says everything is encrypted in transit and is checked weekly, then the weekly check is the effectiveness evidence. There is no separate act of proving it later.

So testing belongs at the control’s frequency

Not at review time, not at audit time. Every control already carries a legally required frequency; the test schedule is that frequency, and each control’s test is one automation running on it.

And silence is a signal too

A control that did not run is not neutral. Missed cadence and overdue evidence are recorded as their own signal class and carry weight in the score.

The pipeline starts and ends with signals. Regulation says what must be true; controls report what is true. Everything in between is reconciliation.

The constraint

Three lines of defence, all of them looking backwards.

The machinery was not broken. Line 1 owners run the controls, Line 2 independently challenges them, Line 3 audits periodically — and every one of those acts happens after the period it examines. APRA’s letter to industry says that is no longer sufficient for a bank of this significance.

Line 1 — owners and advisers

Design and run the controls. Effectiveness is asserted in documents and demonstrated at review.

Line 2 — independent challenge

“Show me the DR exercise logs from last month. Show me the pipeline scanning failure rates.” A request that has to be assembled each time it is asked.

Line 3 — internal audit

Deep dives, periodically. The trail exists, but it has to be reconstructed rather than queried.

The delegation problem underneath it

The bank’s own agenda was to regenerate internal standards as principle-based and push implementation down to the teams doing the work. The blocker was never willingness — it was that you cannot delegate implementation unless the signals come back to you continuously. Devolution and telemetry are the same decision.

The architecture

Two instances, one reconciliation seam.

They compute different things from different data, so they are different instances — which also mirrors the real organisational boundary between an intelligence function and the three-lines machinery.

INSTANCE ONE

What must be true

Regulatory watch and obligation distillation, on public material only: regulator publications, standards, letters to industry, consultations, enforcement actions.

  • Watchlist across APRA, ASIC, AUSTRAC, OAIC and Treasury
  • Daily sweep, diffed against what has already been seen
  • Full-document read on anything flagged — what changed, who it binds, effective dates
  • An Obligation Delta, approved by a person before it goes anywhere
INSTANCE TWO

What is true

The control library, the signal engine, assurance and reporting — bank-internal data under the full Australian sensitive-data posture.

  • Control records carrying the legislated anatomy, one to one
  • A test automation minted at each control’s own frequency
  • Evidence captured, validated against the control’s evidence spec
  • Assurance sampling, board reporting and the accountability view
The seam

Approved obligation records and deltas cross between the two instances org-privately. Raw provenance never crosses. The public-data instance never receives anything bank-internal, and the bank instance receives conclusions with their citations rather than the collection trail behind them — which is what makes the split a security posture and not just a diagram.

The loop

From an APRA publication to a closed remediation.

Eight steps, and the reader should notice how few of them are new software. This composes primitives that already existed — playbooks, multi-cadence automations, approvals, delegation, an org-private mesh. It is a setup, not a build.

01 · Sweep

The watchlist is fetched daily and diffed against the seen-log. Urgent items alert the bound channel immediately rather than waiting for the briefing.

02 · Distil

Anything flagged gets a full-document read: what changed, who it binds, effective dates, obligations implied — drafted as an Obligation Delta.

03 · Approve

A person approves the delta before it enters the register. The register is the bank’s own legal artifact; nothing lands in it unread.

04 · Cross the seam

The approved delta publishes org-privately to the bank instance, where the privacy engine captures it on ingest.

05 · Map the impact

Affected controls are identified, gaps analysed, and remediation delegated with named owners and due dates — tracked to closure.

06 · Mint the test

New or changed controls pass a design-effectiveness questionnaire and a reviewer approval, then get their test automation minted at their frequency.

07 · Accumulate

Signals and evidence build continuously at control cadence. The weekly health report leads with failed tests, overdue evidence and unowned controls.

08 · Challenge and report

Monthly assurance sampling generates the Line 2 challenge pack; quarterly board reporting rolls posture, coverage and open remediations up.

And back to the start

The weekly briefing tells everyone what is coming down the pipe — the single artifact that replaced the expensive ad hoc aggregation.

How a control is tested

Three patterns, and one of them is deliberately not in scope.

The control library runs at fourteen controls across eight categories — ten manual, three automated, one being automated — on weekly, monthly and quarterly cadences, with seven named owners and no unowned controls.

Pattern A — the system yields the signal

A connector pulls the result directly from the controlled system. The demonstrator is static source-code analysis on every production pipeline: weekly scan coverage and failure rate become the test result and the evidence bundle, with run links attached.

Pattern B — manual control, automated chase

The control is performed by a person, so the workflow asks at the control’s frequency, captures the reply, files it into the evidence vault, validates it against the evidence spec, records pass, fail or overdue, and escalates on a miss.

Pattern C — probes into live bank systems

Explicitly out of scope. Verifying TLS posture or key management directly against production requires bank access decisions that have not been made. It is named here rather than implied, because a capability boundary you have to discover is a claim.

Classification runs as a control on the platform’s own primitives

The information-asset register is maintained by sweeping registered sources and files through the same classification engine that enforces the bank instance’s privacy posture, with a weekly drift report. The control is not described by the platform — it is executed by it.

Personal accountability

What protects an accountable person is evidence, with timestamps.

Under the Financial Accountability Regime, an accountable person’s defence is demonstrable reasonable steps. Not an assertion that controls exist — a trail showing what was done, when, and on what basis.

The obligations they hold

Drawn from the register, with the source clause and the effective date attached.

The controls mapped to them

Each with its owner, its frequency and its evidence spec — the anatomy the regulation requires.

The current signal state

Not the last review. What the most recent test at each control’s own cadence actually reported.

The page that did not exist before

“What am I personally on the hook for, right now?” used to be a question that started a project. It is now a view: obligations, controls, signal state and the evidence trail behind each one, assembled per accountable person and current to the last run.

The score

A risk score the second line can argue with.

A leadership view scores each of eight categories 0–100 with RAG bands. The reason it is worth trusting is that it shows its own formula — and the weights are register data, not code.

Failed control tests — weight 40

The heaviest class, decayed on a 28-day half-life so a failure eight weeks ago does not read like one from Tuesday.

Missed cadence or overdue evidence — 20

The control that did not run. Absence recorded as a signal rather than as a gap in the chart.

Unowned controls and design gaps — 15

Structural rather than operational, and legally significant: an owner is a must-have, not an attribute.

Remediations past due — 15

Delegated work that has not closed, against the due date it was given.

Deltas not yet impact-assessed — 10

Inflow pressure: regulation that has landed and has not yet been mapped to controls.

Bands at 25 and 55

Green below 25, amber to 55, red above. Published, so a category’s colour is never a matter of opinion.

Independent challenge is the point of a second line. A score it cannot inspect is a score it cannot challenge — so the formula renders on the page it scores.

What stays human — and what became reusable

Nothing regulator-bound leaves on its own.

This workflow prepares. Every artifact that crosses a regulatory boundary stops at a named person first, and the judgment the three lines exist to apply stays where it is.

Regulator-bound artifacts

An incident notification draft arrives with its clock attached and its evidence bundle assembled — and a hard approval gate in front of it.

Applicability and mapping

Whether an obligation binds the bank, and which controls answer it, are decided by people in the risk function through approval gates.

Line 2 and Line 3 judgment

Neither is replaced. Line 2 gets a sampling surface and records its own opinion; Line 3 gets a queryable trail instead of binders.

What became reusable

The obligation register itself — source clause, applicability, effective date, accountable person, mapped controls, review date — as a maintained artifact rather than a document that ages. The control anatomy, carried identically by every control so that a test schedule can be minted from it. The distillation method, which is per-standard, so promoting a watch-only standard into the register is a watchlist edit and one run, not a redesign. And the score model, held as data so that recalibrating it is a decision the risk function can make and evidence, rather than a change request.

Common questions

What people ask about this build.

Answered against the architecture and the run record, not the intention.

What does continuous control testing actually mean?

Testing at the control’s own frequency rather than at review time. Every control is legally required to carry an owner, a timing and a frequency; each control’s test schedule is one automation running at that frequency, so a weekly control is tested weekly and the result is the evidence. The reframe underneath it came from the bank: all a control does is generate a signal about whether the right thing is being done.

Does this replace Line 2 challenge or Line 3 internal audit?

No, and it does not claim to. Line 2 gains a sampling surface — a monthly challenge pack generated from completed control tests, with a recorded opinion per sample. Line 3 gains a queryable system of record: run history, playbook definitions and evidence provenance, instead of binders. The judgment stays with the people whose job it is.

Why two instances instead of one?

Because they compute different things from different data. The regulatory instance works only on public material and computes what must be true. The bank instance holds internal control and evidence data under the full Australian sensitive-data posture and computes what is true. An org-private seam carries approved obligations and deltas between them; raw provenance never crosses. It also mirrors the real organisational boundary, and it limits blast radius.

Does anything reach APRA automatically?

No. Incident notification drafts are prepared with the relevant clock attached and the evidence bundle assembled, and they stop at a hard approval gate. Nothing regulator-bound leaves without a named person releasing it.

Does the bank have to replace its GRC system?

No. ServiceNow GRC remains the system of record and is unchanged. The loop sits above it. What it adds is the layer the system of record never held — the reasoning between a regulatory change and a control signal, kept with its provenance.

How does this help an accountable person under FAR?

What protects an accountable person is demonstrable reasonable steps — evidence with provenance and timestamps. The accountability view assembles, per accountable person, the obligations they hold, the controls mapped to them, the current signal state of those controls, and the evidence trail behind it.

Is the risk score a black box?

No — it renders its own formula. Five weighted signal classes: failed tests at 40 and recency-decayed, missed cadence or overdue evidence at 20, unowned controls and design gaps at 15, remediations past due at 15, and unassessed regulatory deltas at 10, on a 28-day half-life with bands at 25 and 55. The weights live in register data rather than in code, precisely so the second and third lines can challenge them.

What is deliberately not in this build?

Live probes into production bank systems — verifying TLS posture or key management directly — which need bank access decisions that have not been made. Also: no replacement of Line 2 or Line 3 judgment, and no new engineering. The loop composes primitives that already existed.

Map a workflow like this   The bank risk & controls lane