Asserted vs observed compliance.

For twenty years, compliance in Australian financial services has been a documentation discipline. Policies, registers, attestations: paper describing controls. Call it asserted compliance: the institution asserts the control exists, and evidence is assembled retrospectively when someone asks.

CPS 230 quietly breaks that model. When a standard requires you to maintain tolerance levels for disruption to critical operations, the natural supervisory question is no longer "show me the policy" but "show me the signal." What was your data loss position last Tuesday? Which pipeline behind your payments operation breached freshness this quarter, and what happened next?

That is observed compliance: controls whose operation produces a continuous, timestamped signal from the systems themselves. The gap between the two is where operational risk actually lives.

Why documentation-era compliance persists.

Nobody designed asserted compliance on purpose. It is what you get when the incentives reward artefacts over outcomes. A policy can be finished, filed and pointed to; a signal has to be engineered. Risk teams are staffed and tooled for the former: GRC systems built to store documents and route attestations, not to ingest telemetry from a data platform.

There is also a quieter reason: asserted compliance degrades silently. A register drifts out of date the day after it is approved, but nothing alerts on a stale register. The institution keeps passing its own checks while the controls those documents describe quietly stop matching reality. Every post-incident review that finds "the control existed on paper" is this failure mode surfacing.

What an observable control actually looks like.

Concretely, three examples we implement most often:

• A freshness SLO on a critical-operation pipeline. CPS 230 asks you to set a tolerance for data loss. Translate it into a measurable threshold: this pipeline, feeding this payments operation, must be no more than 30 minutes stale. Breaches alert, are logged, and the log is the evidence.
• Schema change detection. An upstream system changes a column and your capital reporting breaks silently. Detection turns "we review changes" from an assertion in a change policy into an event stream a supervisor can inspect.
• Access anomaly signals. Instead of a quarterly access review that samples ten accounts, continuous monitoring flags unusual access to sensitive datasets as it happens, with the trail retained.

None of this replaces the policy. It gives the policy a pulse: the control is described once and then observed continuously.

The board angle.

Directors sign attestations. Under an asserted-only framework, a director is attesting to the existence of documents, and relying on the organisation's ability to reconstruct evidence after the fact. That is a personal risk position more boards are becoming uncomfortable with, particularly as APRA's supervisory posture shifts from reviewing frameworks to testing whether controls demonstrably operate. A live compliance scorecard changes what the attestation rests on: not "we have a policy" but "here is the signal history for the quarter."

A pragmatic first step.

Do not try to make the whole control library observable at once. Pick one critical operation, map it end to end (systems, pipelines, datasets, owners), translate its disruption tolerances into data SLOs, and instrument those. One operation, fully observed, teaches you more about your real risk position than another quarter of attestation gathering, and it gives the board a concrete artefact of what the target state looks like.

From there, coverage grows control by control. That is the model behind our Observed Compliance offering, and the practical detail (who CPS 230 applies to, how it interacts with CPS 234 and CPG 235, the five-step path) is in our CPS 230 compliance guide for data teams.

General information only, not legal or regulatory advice. Current as at August 2026.