Mapping AWS to the NZISM and PSR: building tiaki, a New Zealand cloud readiness scanner

New Zealand runs a large part of its public sector, and a good deal of its regulated private sector, against two documents: the New Zealand Information Security Manual (NZISM) and the Protective Security Requirements (PSR). If you operate cloud infrastructure for a government agency, a Crown entity, or any organisation that handles New Zealand government information, sooner or later someone will ask how your AWS accounts measure up against them.

tiaki is my open-source attempt to answer part of that question automatically. It is a small tool, written in Go, that reads an AWS account and checks its configuration against a selected set of NZISM and PSR controls. The name is te reo Māori: tiaki, to guard, to protect, to care for. That is roughly the job description.

This post is about what building it taught me: what these frameworks actually are, why mapping them to cloud configuration is harder than it first looks, and the design decisions that keep a tool like this honest.

What the NZISM and the PSR actually are

The two documents do different jobs, and people entering the New Zealand market often conflate them.

The PSR is the higher-level protective-security policy framework for New Zealand government. It is organisational and outcome-focused, spanning governance, information security, personnel security and physical security. It tells you what good protective security looks like and holds leadership accountable for it, but it does not tell you which flag to set on an S3 bucket.

The NZISM is the technical manual that sits underneath the information-security part of that picture. Maintained by the Government Communications Security Bureau’s National Cyber Security Centre, it is where the concrete controls live: cryptography, system hardening, access control, logging and auditing, and the rest. It is detailed, it is revised regularly, and it is written to apply across every kind of system, not cloud specifically.

That last point is the whole challenge. The NZISM predates most people’s cloud estates and is deliberately technology-neutral. Turning a control written for “systems” in general into a check against a specific AWS API response is an act of interpretation, and interpretation is exactly where automated compliance tools tend to overreach.

The mapping problem

Take a control whose intent is that data at rest is encrypted with an approved algorithm. On AWS that touches EBS volumes, S3 buckets, RDS instances, DynamoDB tables, EFS, snapshots and more, each with its own API, its own notion of “encrypted”, and its own way of expressing which key did the encrypting. A single line of framework intent fans out into a dozen distinct technical checks, and none of them, on their own, proves the control is met, only that a particular resource is or is not configured a particular way.

Then there are the controls a scanner simply cannot see. A requirement about key management responsibilities, or about who is authorised to approve a firewall change, is a question about people and process. No amount of API polling answers it. An honest tool has to be loud about that boundary rather than quietly scoring the controls it happens to be able to reach and calling the result “compliance”.

So I split every control I mapped into three buckets:

Technically checkable — a defined AWS configuration signal reliably indicates the control’s technical intent. These are what tiaki reports on.
Partially checkable — the tool can surface evidence, but a human still has to make the call. These are reported as evidence, not as pass or fail.
Out of scope for automation — governance, personnel and process controls. These are named and explicitly handed back to the reader.

Design decisions that keep it honest

A readiness scanner is easy to build badly. Here are the choices that mattered.

Read-only, always. tiaki makes no mutating API calls. It never changes a resource, never writes a tag, never “remediates” anything. It ships as a single static Go binary with no install footprint, so a security team can read the source, drop the binary onto a jump host, and know exactly what it can and cannot do to their account. In a regulated environment, a tool that only ever reads is far easier to get approved than one that promises to fix things for you.

Every finding carries its evidence. A finding is useless if you cannot trace it. Each one states the specific resource and the configuration value observed, the control it maps to, the remediation, and, crucially, what the check could not verify. That last field is the honest part: it names the assumptions the automated check is making so a reviewer can decide whether they hold.

Versioned control mappings. The NZISM changes. If a tool bakes a snapshot of it into compiled code with no version stamp, its output rots silently and nobody notices until an auditor does. tiaki’s mappings are versioned, so a report says which interpretation of which control set produced it. That turns “the scanner said we were fine” into a dated, reviewable claim.

Reports where people actually work. Output is terminal, JSON or HTML. Terminal for the engineer running it locally, JSON for a pipeline that wants to gate on it, HTML for the readable artifact you hand to someone who is not going to read a JSON blob.

# Read-only readiness scan against the NZISM control set,
# rendered as a shareable HTML report.
tiaki scan --framework nzism --profile prod --output html > readiness.html

What a scanner cannot do

This is the part I want New Zealand teams to hear clearly, because it is where compliance tooling most often misleads.

A readiness scanner measures technical readiness. It does not certify compliance. Compliance is a judgement a person accountable under the PSR makes, using evidence. A tool produces some of that evidence. It is not the judge.

Treating a green scan as a certificate is how organisations end up confidently non-compliant. The value of automation here is not the verdict; it is removing the toil of gathering hundreds of pieces of technical evidence by hand, and doing it the same way every time so the result is comparable month to month. The human judgement sits on top of that, not underneath it.

Why this matters if you run cloud in New Zealand

If your work touches New Zealand government information, the NZISM and the PSR are not optional reading, and “we use AWS security best practices” is not an answer to them. The frameworks have their own language, their own control numbering, and their own expectations about evidence and accountability. Being able to speak that language, and to show technical readiness against it with something reproducible, is a genuine differentiator for a cloud or platform engineer working in this market.

Building tiaki was how I learned that language properly rather than skimming it. It also left me with a tool I would actually reach for on day one of a New Zealand engagement, which was the point.

It is open source, read-only, and deliberately modest about what it claims. If you run AWS in Aotearoa and any of this is your world, take a look and tell me where the mappings are wrong. That feedback is the most useful thing it can get.

tiaki is on GitHub. I’m a DevOps and platform engineer relocating to New Zealand — more on the home page.