NZ: RBNZ Cyber Resilience Standard
|
|
| Regulator |
Reserve Bank of NZ |
| Jurisdiction |
NZ |
| Status |
live |
| Applicability |
Platform |
The RBNZ Cyber Resilience Standard sets requirements for registered banks and other regulated
entities to manage cyber risk, maintain resilience against cyber threats, and respond effectively
to cyber incidents. It aligns with international frameworks including NIST CSF and ISO 27001, and
is administered under the Reserve Bank of NZ Act 1989.
Under the Deposit Takers Act 2023, technology and cyber resilience obligations are addressed
within the Deposit Takers (Operational Resilience) Standard. This pre-DTA standard remains live
and applicable to registered banks until the DTA framework takes effect on 1 December 2028.
Compliance register
This register maps every material obligation under the standard to the platform control or
institutional process that satisfies it.
Scope legend
| Symbol |
Meaning |
| 🤖 Automated |
Platform enforces or performs the obligation. Primary control mode is GATE, AUTO, CALC, or ALERT. Human action is not required in the normal case. |
| 📊 Evidenced |
Platform captures the evidence trail automatically. Human compliance decision sits on top. Primary control mode is LOG. |
| 🏛 Institutional |
Obligation is met by a process entirely outside the platform — governance, HR, vendor contracts. Platform may generate evidence inputs but does not own the process. |
| N/A |
Obligation does not apply to this deployment configuration. |
Build legend
| Symbol |
Meaning |
| ✅ |
Module built and deployed |
| 🔨 |
Module planned — not yet built (build_status: Not started) |
| ❌ |
Uncontrolled gap — no module attributed |
Governance and framework
| Ref |
Obligation |
Scope |
Policy |
Platform controls |
Build |
| CR1 |
Maintain a board-approved cyber resilience framework covering governance, risk management, and continuous improvement |
🏛 Institutional |
DT-002 |
Cyber resilience framework design and board approval are institutional; MOD-076 (LOG) provides the observability evidence base that the framework monitors |
— |
| CR2 |
Designate a senior accountable person for cyber resilience |
🏛 Institutional |
DT-002 |
CISO designation is an institutional HR decision; not a platform function |
— |
Threat intelligence and detection
| Ref |
Obligation |
Scope |
Policy |
Platform controls |
Build |
| CR3 |
Maintain threat intelligence capabilities — subscribe to relevant threat feeds and use intelligence to inform control calibration |
🏛 Institutional |
DT-002 |
Threat intelligence subscription is a vendor procurement decision; MOD-044 (GATE) consumes threat intelligence via JWT/RBAC controls; platform controls are calibrated against intelligence inputs |
— |
| CR4 |
Implement continuous monitoring and detection of cyber threats across critical systems |
🤖 Automated |
DT-002 |
MOD-044 (GATE) — JWT RBAC enforces least-privilege at every API call; MOD-075 (GATE) — internal API gateway blocks unauthenticated service-to-service calls; MOD-076 (ALERT) — observability platform detects anomalous system behaviour and escalates to on-call |
🔨 |
| CR5 |
Maintain a SIEM or equivalent capability for centralised log aggregation and threat detection |
🤖 Automated |
DT-002, OPS-003 |
MOD-044 (LOG) — all authenticated API calls logged with user ID, role, endpoint, and timestamp; MOD-046 (LOG) — all production access sessions available for audit; MOD-076 (ALERT) — centralised log aggregation, alerting, and 90-day hot retention |
🔨 |
Access control and secrets management
| Ref |
Obligation |
Scope |
Policy |
Platform controls |
Build |
| CR6 |
Enforce least-privilege access controls across production systems |
🤖 Automated |
DT-002 |
MOD-044 (GATE) — RBAC enforces least-privilege at API gateway level; MOD-046 (GATE) — no standing production access; every privileged session is approved, time-limited, and recorded |
🔨 |
| CR7 |
Manage secrets, certificates, and cryptographic keys using a centralised, automated system — no manual key rotation |
🤖 Automated |
DT-002 |
MOD-045 (AUTO) — secrets cannot be extracted by developers; key rotation automated with no reliance on manual schedule |
🔨 |
| CR8 |
Privileged access management — no standing access to production environments |
🤖 Automated |
DT-002 |
MOD-046 (GATE) — no standing production access; engineer access requires an approved, time-limited session with full session recording |
🔨 |
Vulnerability management
| Ref |
Obligation |
Scope |
Policy |
Platform controls |
Build |
| CR9 |
Maintain a vulnerability management programme — identify, prioritise, and remediate vulnerabilities on a risk basis |
📊 Evidenced |
DT-002, OPS-003 |
MOD-150 (AUTO) — unpatched CVEs from SAST are auto-classified and written to the technology risk register; MOD-076 (ALERT) — infrastructure anomalies generate observability alerts |
🔨 |
| CR10 |
Conduct regular penetration testing on critical systems on a risk-appropriate schedule |
🏛 Institutional |
DT-002 |
Penetration testing programme is an institutional vendor engagement; MOD-076 provides the system inventory and monitoring coverage used to scope engagements |
— |
Incident response
| Ref |
Obligation |
Scope |
Policy |
Platform controls |
Build |
| CR11 |
Maintain and test a cyber incident response plan |
🏛 Institutional |
OPS-003, DT-002 |
Incident response plan design and testing are institutional; MOD-150 (AUTO) — incidents auto-created from observability alerts with P1/P2/P3 classification, SLA timers, and routing |
— |
| CR12 |
Report material cyber incidents to the RBNZ within the prescribed timeframe |
🤖 Automated |
OPS-003 |
MOD-150 (AUTO) — material incidents auto-detected and routed through the notification assembly workflow; regulator notification is automated where an API is available |
🔨 |
| CR13 |
Maintain logs sufficient to support post-incident forensic investigation |
🤖 Automated |
DT-002, OPS-002 |
MOD-044 (LOG) — all API calls logged; MOD-046 (LOG) — all privileged access sessions recorded; MOD-076 (LOG) — 90-day hot log retention across all platform services |
🔨 |
| Obligation |
Owner |
Platform evidence input |
| Cyber resilience board-level oversight and attestation |
Board / CISO |
MOD-076 and MOD-150 provide the evidence base for board cyber reporting |
| Threat intelligence subscription and feed management |
CISO |
Threat feeds configure platform controls; subscription itself is a vendor contract |
| Penetration testing programme — scheduling, scoping, and remediation governance |
CISO |
MOD-076 provides system inventory and monitoring coverage for scoping |
| Staff cyber awareness training programme |
Chief People Officer / CISO |
Training LMS is institutional; not platform scope |
| Business continuity and cyber recovery testing |
CTO / CISO |
MOD-076 and MOD-150 provide observability data used in DR testing |
Coverage summary
| Area |
Total obligations |
Platform automated 🤖 |
Platform evidenced 📊 |
Institutional 🏛 |
N/A |
| Governance and framework |
2 |
0 |
0 |
2 |
0 |
| Threat intelligence and detection |
3 |
2 |
0 |
1 |
0 |
| Access control and secrets |
3 |
3 |
0 |
0 |
0 |
| Vulnerability management |
2 |
0 |
1 |
1 |
0 |
| Incident response |
3 |
2 |
0 |
1 |
0 |
| Total |
13 |
7 (54%) |
1 (8%) |
5 (38%) |
0 |
All attributed modules are currently build_status: Not started — the compliance position will
update as modules are built and deployed.
| Policy |
Title |
| DT-002 |
Cybersecurity Policy |
| OPS-002 |
Disaster Recovery Policy |
| OPS-003 |
Incident Management Policy |
See D05 Data & Technology for the full risk domain.
Official documentation
Policies referencing this standard
- DT-002 — Cybersecurity Policy
- OPS-002 — Disaster Recovery Policy
- OPS-003 — Incident Management Policy
Compiled 2026-05-22 from source/entities/regulations/nz-rbnz-cyber-resilience.yaml