The work, on most of our engagements, is reading them against each other so that neither gets quietly skipped. This is a phase-by-phase mapping and a working pattern.
What CAF is, structurally
CAF organises a cloud programme into seven dispositions: Strategy, Plan, Ready, Adopt (split into Migrate and Innovate), Govern, Manage, and Secure. The framework is documented and prescriptive in some areas (landing zones, the Cloud Adoption Plan template), opinionated in others (FinOps as a Manage discipline), and deliberately light where customer context dominates — data sovereignty, sectoral regulation, and personnel security among them.
The model reads sequential at first glance and is concurrent in practice. Govern, Manage, and Secure are never “done”: they are continuous tracks that begin in Ready and persist through every Adopt cycle.
What NZISM is, structurally
NZISM is organised by domain, not by phase. Chapters cover Information Security Governance (Ch 3–5), Documentation (Ch 4), Personnel Security (Ch 9), Physical Security (Ch 10), Communications Security (Ch 11–12), Cryptography (Ch 17), Network Security (Ch 18), Access Control & IDAM (Ch 16), and Cloud Computing (Ch 22, with related material spread through Ch 18 and Ch 20), among others.
Each chapter sets controls at compliance levels — typically “Should” and “Must” — and the choice of applicable controls depends on the classification of the information the system handles: UNCLASSIFIED, IN-CONFIDENCE, SENSITIVE, RESTRICTED, and above. The Manual is updated regularly. The version in force at the time of accreditation matters, and shouldn’t be assumed stable across a multi-year programme.
The crucial point: NZISM is risk-based. It doesn’t tell you which technologies to use. It tells you what controls must be in place, and what evidence is acceptable, for a given risk posture.
Mapping the two, phase by phase
Strategy → NZISM governance and the Cloud First expectation
CAF Strategy asks for motivations and business outcomes. The New Zealand overlay: every Strategy must reckon with the NZ Government Cloud First policy (public cloud is the default; on-premises requires justification) and the classification of the data in scope. Strategy decisions that don’t survive an early classification review tend to fall apart in Ready.
Plan → NZISM Chapter 4 (Documentation) and the Cloud Risk Discovery Tool
The Cloud Adoption Plan should be paired with a Risk Discovery exercise (the GCDO’s successor to the older Cloud Risk Assessment Tool), and an early sketch of the System Security Plan. Both have to name the information classification driving control selection. A Plan that doesn’t carry these is a Plan that will have to be redone.
Ready → NZISM Chapter 18 (Network) and Chapter 16 (IDAM)
This is where the largest divergence between vanilla CAF and NZ practice shows up. CAF’s Azure Landing Zone reference is excellent, but its defaults assume a private sector posture: a single hub-spoke, broad workload identities, sane-enough defaults for most enterprises. NZISM’s network segmentation and IDAM requirements often demand:
- Hub-and-spoke at minimum, with classification-based segmentation between spokes.
- Just-in-time and just-enough access (PIM-style) configured against NZISM Chapter 16.
- Conditional Access policies aligned to NZISM personnel controls in Chapter 9 — clearance status feeds access policy, not the other way around.
- Cryptography choices made against NZISM Chapter 17, not against vendor default ciphers. Most defaults clear; a few do not, and the audit cost of finding out late is significant.
If the landing zone is built against CAF defaults and then “audited” later, retrofitting these is expensive. They need to be in the landing-zone blueprint.
Adopt — Migrate → NZISM Chapter 22 (Cloud Computing)
Migration patterns (rehost, refactor, rearchitect, rebuild) need a control-mapping step. Rehosted workloads inherit the controls of the host platform; NZISM Chapter 22 requires the agency to satisfy itself that the platform’s controls are equivalent. Microsoft Azure, AWS, and Google Cloud each publish NZISM mapping documents. None of these replace the agency’s own assessment — they are inputs, not approvals.
Adopt — Innovate → NZISM Chapter 7 (Monitoring) and Chapter 8 (Incident Management)
Net-new cloud-native workloads typically benefit from CAF’s plan more than they need NZISM-specific deviations — until they touch data subject to classification. At that point monitoring and incident-response controls have to be designed in, not added in a year-two hardening sprint.
Govern → NZISM Chapter 5 (Risk Management) and Chapter 4 (Documentation)
CAF’s Govern disciplines (Cost, Identity, Resource Consistency, Security Baseline, Deployment Acceleration) map well onto NZISM at the documentation layer. The Security Baseline discipline must produce the artefacts that NZISM expects: Information Security Policy, System Security Plan, Risk Management Plan, and the deviation register that records every place implementation departs from baseline.
Manage → NZISM Chapter 7 (Monitoring) and Chapter 12 (Patching)
Operational controls. CAF’s Manage methodology is essentially compatible; the NZISM overlay is documentary (audit-grade evidence) and contractual (operational responsibilities under managed-service agreements with hyperscaler partners or local MSPs).
Secure → NZISM Chapters 11, 12, 17, 18
Cross-cutting. Communications, patching, cryptography, network — this is the disposition where most NZ-specific control work crystalises in a CAF programme. It also tends to be the disposition that’s least visible to a programme board until accreditation forces it into view.
Where CAF underestimates the NZ context
Three areas, repeatedly:
- Data sovereignty for RESTRICTED+ data. CAF treats data location as a discipline decision. NZISM treats it as a control input. For some classifications, off-shore processing is not a posture choice — it’s a control failure.
- Personnel security. CAF assumes the customer manages workforce vetting outside the framework. NZISM Chapter 9 has substantive personnel security requirements, including clearance levels that must be matched to data access. This shows up in IDAM design and in Conditional Access policy.
- Cryptography defaults. CAF reference architectures specify cryptographic settings using cloud-vendor defaults. NZISM Chapter 17 has approved algorithm and key-length minimums. Most defaults clear NZISM, but vendor-managed key configurations and some legacy TLS profiles need explicit review.
A working pattern
What works on the ground is the opposite of “do CAF, then assess against NZISM at the end”. The pattern we use:
- Treat NZISM as a Ready input. Information classification, control selection, and a draft System Security Plan are completed during CAF Plan, before landing-zone design begins.
- Map controls to landing-zone primitives. Every NZISM “Must” attaches to a specific Azure (or AWS / GCP) primitive in the landing zone blueprint — not a paragraph in a Word document. If a control can’t be tied to a deployable resource, the design isn’t finished.
- Make the deviation register a living artefact. CAF tooling doesn’t produce it; you produce it. Every place the implementation deviates from a NZISM control, document why, by whom, and on what risk basis. The deviation register is what an accreditor will ask for first.
- Re-baseline at Manage handover. NZISM updates between programme inception and operations. A controls baseline that’s two years old at handover is the same as no baseline.
The synthesis is straightforward: CAF is the delivery framework, NZISM is the controls truth, and the value comes from designing controls into the landing zone rather than discovering them at accreditation. Done that way, a cloud programme can be CAF-fast and NZISM-defensible at the same time. Done sequentially, it’s neither.