Morpheus OS
Map a workflow

Live client workflow — anonymised · Regulatory intelligence + control testing · Human approval on release

Continuous control assurance for a regulated bank.

An Australian bank connects what regulators require with evidence of how its controls are working. Two Morpheus instances bring regulatory intelligence and control testing into one review process. ServiceNow remains the system of record, and a named person releases every regulator-bound output.

14 controls
tested across eight risk categories
Two instances
regulatory intelligence and bank evidence
Human release
for regulator-bound output

Chapter 01 / 06

Coverage

Regulatory obligations and control signals are reconciled as one governed loop.

Workflow context and documented result

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.

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.

Regulatory intelligence

Before
Ad hoc, expensive, aggregated by hand
Now
Daily sweep · weekly briefing · monthly horizon

Standards distilled to obligations

Before
Per project, by hand
Now
6 — CPS 230, CPS 234, CPS 220, FAR, SOCI, Privacy

Standards on watch

Before
Whatever was noticed
Now
7 more, swept and briefed

Obligation record

Before
A document
Now
Source clause, owner, effective date, mapped controls, review-by

Controls under continuous test

Before
Tested at review time
Now
14, each at its own frequency

Control anatomy

Before
Described in documents
Now
Owner · type · mode · frequency · timing · evidence spec

Unowned controls

Before
Found at audit
Now
Top of the weekly report

Risk categories scored

Before
—
Now
8, on a published formula

Line 2 challenge

Before
Periodic, assembled by hand
Now
Monthly pack, opinion recorded per sample

Line 3 audit trail

Before
Binders
Now
Queryable run history and evidence provenance

System of record

Before
ServiceNow GRC
Now
ServiceNow GRC — unchanged

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.

End of chapter 1 · Coverage

Related guide in LearningChoosing the first workflow ↗

Chapter 02 / 06

Evidence

The three lines receive a current, queryable evidence surface with ownership and timing intact.

Three lines, with evidence ready for review.

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.

End of chapter 2 · Evidence

Related guide in LearningHow work becomes operating memory ↗

Chapter 03 / 06

Connected instances

Public regulatory intelligence and sensitive bank evidence remain separate while approved records cross the private seam.

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

End of chapter 3 · Connected instances

Related guide in LearningGoverned workflows ↗

Chapter 04 / 06

The control loop

A signal can become an owned, evidenced remediation through the control’s defined cadence.

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.

Three testing patterns and their approval boundaries.

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.

End of chapter 4 · The control loop

Related guide in LearningHow reviewed learning improves the next run ↗

Chapter 05 / 06

Accountability

The view supports accountable people with timestamps, explainable scoring and a named release decision.

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.

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.

A named person approves regulator-bound output.

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.

End of chapter 5 · Accountability

Related guide in LearningHuman authority and approval ↗

Chapter 06 / 06

Questions

The FAQ preserves the system boundary, audit roles, data separation and regulator-release controls.

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

End of chapter 6 · Questions

Related guide in LearningOperating memory, explained ↗

Apply it to your business

Start with one piece of work.

Bring the process, the evidence and the person who owns the decision.

Map a workflow ↗