|
|
| Regulator |
GCSB / NCSC |
| Jurisdiction |
NZ |
| Status |
live |
| Applicability |
Platform |
The New Zealand Information Security Manual (NZISM) is published by the Government
Communications Security Bureau (GCSB) through the National Cyber Security Centre (NCSC).
It is the New Zealand government's standard for information security, specifying protective
security controls across network segmentation, privileged access management, patch
management, security logging, and vulnerability disclosure.
The NZISM is not legally binding for registered banks. However, RBNZ technology risk
guidance explicitly references NZISM-equivalent controls in its expectations, and the
standard is treated as best-practice baseline for RBNZ supervisory assessments of
technology risk and cyber resilience. Non-compliance with NZISM controls is likely to be
raised as a finding in RBNZ-supervised technology risk reviews.
Key NZISM requirements relevant to banking: network segmentation, no standing privileged
access (privileged access management), patch management with a 30-day SLA for critical
vulnerabilities, comprehensive security logging, and a vulnerability disclosure programme.
Compliance register
This register maps every material NZISM control expectation to the platform control or
institutional process that satisfies it. It is the static traceability layer for the Totara
compliance report — dynamic data (module build status, test evidence, control test dates)
is overlaid at runtime.
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 — ISMS programme, physical security, HR. 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 |
Access control and privileged access
| Ref |
Obligation |
Scope |
Policy |
Platform controls |
Build |
| ISM-1 |
No standing privileged access — all production access must be just-in-time, time-limited, and individually approved |
🤖 Automated |
DT-001 |
MOD-046 (GATE) — no standing production access; every session is approved, time-limited, and logged; no engineer can access production data without an auditable PAM session |
🔨 |
| ISM-2 |
All privileged access sessions logged with who accessed what and when |
📊 Evidenced |
DT-001 |
MOD-046 (LOG) — all production access sessions available to audit; session records are immutable and available to internal_audit role for examination |
🔨 |
| ISM-3 |
Least-privilege access enforced at API layer — roles cannot access data outside their permitted scope |
🤖 Automated |
DT-001 |
MOD-044 (GATE) — JWT RBAC validates role and scopes on every API request; minimum necessary data access enforced; MOD-052 (GATE) — minimum necessary data access enforced at API for compliance-sensitive data |
🔨 |
Network segmentation
| Ref |
Obligation |
Scope |
Policy |
Platform controls |
Build |
| ISM-4 |
Network segmentation — system domains isolated at the network layer |
🤖 Automated |
DT-001 |
MOD-103 (GATE) — each system domain is provisioned with its own Postgres database and role; cross-domain direct DB connections are structurally prevented |
🔨 |
| ISM-5 |
All service-to-service traffic authenticated and encrypted in transit |
🤖 Automated |
DT-001, DT-002 |
MOD-075 (GATE) — all service-to-service traffic passes through TLS-terminated endpoints with mutual authentication; no plaintext internal API calls are permitted |
🔨 |
Secrets and key management
| Ref |
Obligation |
Scope |
Policy |
Platform controls |
Build |
| ISM-6 |
Secrets (API keys, credentials, certificates) stored in a vault — not in code or config files |
🤖 Automated |
DT-001 |
MOD-045 (AUTO) — secrets cannot be extracted by developers; all credentials are vaulted and access-controlled; no plaintext secrets in any repository |
🔨 |
| ISM-7 |
Cryptographic key rotation automated — no reliance on manual rotation schedule |
🤖 Automated |
DT-002 |
MOD-045 (AUTO) — key rotation automated; certificate expiry monitoring triggers automatic renewal; no manual rotation required |
🔨 |
Patch management
| Ref |
Obligation |
Scope |
Policy |
Platform controls |
Build |
| ISM-8 |
Critical vulnerabilities patched within 30 days of disclosure |
🤖 Automated |
DT-002 |
MOD-150 (AUTO) — unpatched CVEs from SAST are auto-classified as technology risk events and written to the risk register with a 30-day SLA; overdue patch items auto-escalate |
🔨 |
| ISM-9 |
Vulnerability scanning integrated into CI/CD pipeline |
🤖 Automated |
DT-002 |
MOD-150 (AUTO) — SAST integration feeds CVE findings into the technology risk register automatically on every build; findings are tracked until remediated |
🔨 |
Security logging (SIEM)
| Ref |
Obligation |
Scope |
Policy |
Platform controls |
Build |
| ISM-10 |
Comprehensive security event logging — all authentication events, access failures, and privileged actions logged |
🤖 Automated |
DT-001 |
MOD-044 (AUTO) — all authenticated API calls logged with user ID, role, endpoint, and timestamp; MOD-044 (LOG) — all production access events written as immutable records |
🔨 |
| ISM-11 |
SIEM — centralised security logging with detection rules and alerting |
🤖 Automated |
DT-001, DT-002 |
MOD-076 (ALERT) — availability monitoring collects metrics from all services, evaluates alerting rules, and routes notifications; MOD-150 (AUTO) — security anomalies (CloudTrail access failures, Cognito brute-force patterns, Secrets Manager anomalies) are auto-classified as potential breaches |
🔨 |
| ISM-12 |
Security log retention for a minimum period |
📊 Evidenced |
DT-001 |
MOD-076 (LOG) — 90-day hot retention window in the observability platform; longer-term retention in S3 cold storage provisioned by MOD-104; retention period is configuration, aligned to NZISM minimum |
🔨 |
API security
| Ref |
Obligation |
Scope |
Policy |
Platform controls |
Build |
| ISM-13 |
API security — rate limiting, request authentication, and protection against abuse |
🤖 Automated |
DT-001, DT-002 |
MOD-075 (GATE) — rate limiting and request signing enforce that only registered, authenticated services can call platform APIs; unauthenticated requests rejected at the gateway |
🔨 |
| Obligation |
Owner |
Platform evidence input |
| Information Security Management System (ISMS) programme design and maintenance |
Chief Information Security Officer |
MOD-044, MOD-045, MOD-046, MOD-075, MOD-076 implement the technical controls; ISMS governance is institutional |
| Physical security programme |
Chief Operating Officer / Head of Facilities |
Not platform scope — physical access control and CCTV are institutional |
| Personnel screening (background checks) |
Chief People Officer |
Not platform scope — HR pre-employment screening process |
| Vulnerability disclosure programme (responsible disclosure policy) |
Chief Information Security Officer |
MOD-150 CVE tracking provides the internal tracking layer; external disclosure policy authorship and VDP management are institutional |
| Annual penetration testing and security assessment |
Chief Information Security Officer |
MOD-076 observability and MOD-150 CVE register provide the baseline; test scheduling and third-party execution are institutional |
| NCSC / CERT NZ incident reporting |
Chief Information Security Officer |
MOD-150 incident detection provides the trigger; external reporting is institutional |
Coverage summary
| Area |
Total obligations |
Platform automated 🤖 |
Platform evidenced 📊 |
Institutional 🏛 |
N/A |
| Access control and PAM |
3 |
2 |
1 |
0 |
0 |
| Network segmentation |
2 |
2 |
0 |
0 |
0 |
| Secrets and key management |
2 |
2 |
0 |
0 |
0 |
| Patch management |
2 |
2 |
0 |
0 |
0 |
| Security logging |
3 |
2 |
1 |
0 |
0 |
| API security |
1 |
1 |
0 |
0 |
0 |
| Total |
13 |
11 (85%) |
2 (15%) |
0 (0%) |
0 (0%) |
The NZISM is voluntary for banks but all platform controls are being built to satisfy these
requirements as best-practice baseline for RBNZ supervisory assessment. All attributed modules
are currently build_status: Not started — the compliance position will update as modules
are built and deployed.
| Policy |
Title |
| DT-001 |
Information Security Policy |
| DT-002 |
Cybersecurity Policy |
Official documentation
Policies referencing this standard
- DT-001 — Information Security Policy
- DT-002 — Cybersecurity Policy
Compiled 2026-05-22 from source/entities/regulations/nz-ism.yaml