What do security teams get wrong about CPS 234 evidence?

They often rely on policies, periodic reviews, and static inventories that do not prove control effectiveness in live operations. CPS 234 expects evidence that controls still work when APIs change, third parties connect, or incidents occur, so runtime validation matters as much as documentation.

Why CPS 234 Evidence Fails When It Stays on Paper

CPS 234 evidence is not meant to prove that a control existed at some point in time. It has to show that controls remain effective against current systems, current integrations, and current dependencies. That is where many teams get caught out: they can produce policies, attestations, and review records, but those artefacts do not demonstrate operational resilience when interfaces change or third parties alter behaviour. For teams with API-heavy services or machine-to-machine access, this gap becomes especially visible because static documentation rarely proves live control performance.

APRA’s CPS 234 places responsibility on regulated entities to maintain information security capability, which means evidence has to track actual control operation rather than paper compliance. The most useful evidence usually comes from runtime checks, monitored exceptions, and repeatable validation performed close to the control itself, not from after-the-fact summaries. NHI Management Group sees this distinction matter most when identity, secrets, and service access are embedded in automation and ownership is diffuse. In practice, many security teams discover the weakness only after a dependency changes and the control still looks compliant on paper.

How Teams Should Read CPS 234 Evidence in Live Operations

CPS 234 evidence should answer a simple question: if the environment changed today, would the control still behave as intended? That shifts the focus from documentation volume to control assurance. Evidence is stronger when it shows monitoring, alerting, enforcement, and exception handling under real operating conditions. For example, a reviewed policy may show intent, but it does not prove that privileged access is actually constrained, that logs are retained, or that key integrations are still governed after a platform update.

In practice, the most defensible evidence set is usually a blend of artefacts that reflect different layers of control operation:

configuration or policy state that defines expected behaviour
runtime logs or monitoring output that show the control executed
test or validation records that confirm the control still works after change
exception records that show failed checks were detected and handled
third-party assurance where the control depends on an external service

That mix matters because CPS 234 is concerned with maintained security capability, not a one-time assurance snapshot. If an API change, cloud deployment, or outsourced service can silently bypass the control, then the evidence set is too weak even if the documentation is tidy. This is where teams should be especially careful with access paths tied to service accounts, tokens, certificates, and other non-human identities, because those controls often fail first when they are only reviewed periodically rather than validated continuously.

The standard also becomes harder to satisfy when ownership is fragmented. Security, engineering, and vendor management may each hold part of the evidence, but none of them can individually demonstrate end-to-end control effectiveness. APRA’s guidance around CPS 234 is therefore best treated as an operating discipline, not a filing exercise, and the control should be evidenced in the same place where it is actually enforced. If the only proof available is a PDF or spreadsheet, the evidence is probably too weak for change-heavy environments.

Where Static Inventories and Compliance Reviews Break Down

Tighter evidence expectations often increase operational effort, so organisations have to balance audit convenience against proof that controls still function under change.

The main edge case is when a control is genuinely preventive but only observable indirectly. In those situations, teams should not assume that a review record alone is enough; they should supplement it with monitoring output, test results, or transactional logs that show the control is alive. Another common variation is third-party dependence. If a security outcome depends on a provider, the evidence must reach beyond the internal policy and show how the dependency is monitored, challenged, or revalidated when conditions change. That is a governance issue as much as a technical one.

Another place where teams overstate their position is inventory management. An inventory can be accurate and still fail to prove coverage if it is not reconciled against actual use, active connections, or privileged pathways. The same problem appears with periodic access reviews: they can confirm a review occurred, but they rarely prove that access was constrained at the moment risk mattered. Guidance on this point is consistent across good practice, even if organisations differ on the exact evidence package they expect. The practical test is whether the evidence would still be persuasive after a real incident, not merely during a scheduled review. The OWASP Non-Human Identity Top 10 is useful here because it highlights the operational risk created when machine access is poorly inventoried, weakly governed, or left unvalidated after change.

Where this guidance breaks down is in highly stable, tightly bounded systems with little external dependency, because the evidentiary bar is easier to meet when change is rare and control paths are simple.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.RM-01 — Risk Management Strategy	CPS 234 evidence must show controls remain effective within a managed risk posture.
Recommendation — Map evidence to live risk acceptance decisions and validate controls after change.
CIS Controls v8	6 — Access Control Management	The question centers on proving access controls still work in operation.
	8 — Audit Log Management	CPS 234 evidence should include logs that demonstrate control execution and detection.
Recommendation — Audit access enforcement with runtime evidence, not only periodic review records. Retain logs that prove controls executed and exceptions were detected.
OWASP Non-Human Identity Top 10	NHI-01 — NHI Inventory and Ownership	Static inventories fail when machine identities and service access change unnoticed.
	NHI-02 — Secrets and Credential Management	Evidence gaps often appear where tokens, keys, and certificates are only reviewed periodically.
Recommendation — Keep machine identity inventories reconciled to active access and ownership. Prove credential controls with rotation, revocation, and live validation evidence.

Practitioner Guidance

What to verify: Security teams should verify that evidence covers actual control operation, not just approval history. The key check is whether a change, integration event, or incident would reveal a control failure in the evidence trail, rather than leaving the control looking healthy by default.

Common mistake: Treating periodic review packs as proof of ongoing effectiveness. That approach often overstates assurance because it confuses governance activity with runtime control performance, especially where access, monitoring, or third-party dependencies change frequently.

Practitioner takeaway: The strongest CPS 234 evidence is the kind that would still convince a sceptical reviewer after a live change event, because it demonstrates the control worked when it mattered, not just that someone documented it.