Both parties carry accountability, but in different ways. The regulated entity remains responsible to APRA for resilience, oversight, and evidence. The provider must meet the contract requirements flowing from that relationship and demonstrate assurance. Good governance makes those obligations explicit, maps them to controls, and avoids the common failure where each side assumes the other is covering the risk.
Why This Matters for Security Teams
CPS 230 does not let a regulated entity outsource accountability just because a provider performs the work. The practical issue is not only who caused the disruption, but who must prove resilience, oversight, and contractual control when a material service provider affects a critical operation. That distinction matters because third-party dependency often creates gaps in evidence, reporting, and remediation even when the service itself is functioning. APRA expects governance to be explicit, not assumed.
This is the same pattern seen in NHI and service-account risk: exposure often sits with a provider, but the enterprise still owns the blast radius. NHIMG has shown that 92% of organisations expose NHIs to third parties, raising supply-chain risk, and only 5.7% have full visibility into their service accounts in the Ultimate Guide to NHIs. In practice, many security teams encounter accountability failure only after a provider incident has already disrupted a critical service, rather than through intentional governance design.
How It Works in Practice
Under CPS 230, accountability should be treated as layered. The regulated entity remains accountable to APRA for the outcome: operational resilience, risk oversight, escalation, and evidence. The provider is accountable for meeting the obligations written into the contract, such as uptime commitments, incident notification, testing participation, access restrictions, and assurance artefacts. This is why strong contracts matter, but contracts alone are not enough.
Practitioners usually translate this into a shared control model:
- Define critical operations, material service providers, and control owners before an incident occurs.
- Map each obligation to evidence, such as logs, test results, attestation, and incident timelines.
- Set notification windows, remediation SLAs, and escalation paths in the service agreement.
- Review provider assurance against the entity’s own risk appetite, not against generic vendor claims.
- Retain the ability to validate access, continuity, and recovery assumptions independently.
This lines up with NIST guidance on access control and risk governance in the NIST Cybersecurity Framework 2.0 and the control discipline in NIST SP 800-53 Rev 5 Security and Privacy Controls. It also fits NHIMG’s emphasis on lifecycle governance and auditability in the Ultimate Guide to NHIs. The key operational point is that provider assurance must be machine-readable enough for the regulated entity to evidence oversight quickly, especially where secrets, service accounts, or API keys are in scope. These controls tend to break down when the provider uses opaque subcontractors and the regulated entity lacks direct evidence of access, change, and recovery testing.
Common Variations and Edge Cases
Tighter contractual control often increases procurement and assurance overhead, requiring organisations to balance resilience gains against vendor speed and cost. The hardest cases are not simple outages, but material service providers that rely on nested subcontractors, shared platforms, or cross-border support teams. In those environments, responsibility can become diffused unless the contract explicitly assigns notification, evidence, and remediation duties at each tier.
There is no universal standard for this yet, but current guidance suggests the regulated entity should never rely on “the provider owns it” as a defence. Even where a provider has operational custody, the entity still needs oversight of privileged access, offboarding, testing, and issue escalation. That is especially important when provider-administered secrets or service accounts are involved, because secret sprawl and delayed revocation can turn a contained failure into a wider operational event. For deeper NHI context, the Top 10 NHI Issues and NHIMG’s lifecycle processes for managing NHIs are useful references for turning accountability into control ownership and evidence.
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, NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC, ID.SC, PR.AA | Covers governance, supply-chain oversight, and access control for third-party critical services. |
| NIST SP 800-53 Rev 5 | SR-3, CA-3, AC-6 | Supports supplier requirements, assessment, and least-privilege controls across provider relationships. |
| NIST Zero Trust (SP 800-207) | 5.2, 5.6 | Relevant because provider access should be continuously verified rather than trusted by default. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Provider-owned service accounts and secrets create shared accountability and lifecycle risk. |
| NIST AI RMF | GOVERN | Accountability for outsourced critical operations depends on clear governance and oversight. |
Assign clear third-party risk owners, map critical suppliers, and verify access and recovery controls continuously.
Related resources from NHI Mgmt Group
- Who is accountable when a third-party service provider mishandles personal data under the Colorado Privacy Act?
- Who is accountable when a third-party service or dependency disrupts regulated financial operations under DORA?
- Who is accountable for verifying digital credential claims in regulated customer journeys?
- Who should be accountable when a new high or critical finding is introduced in a deployment?
