Health NZ Security Checklist: What Baseline Takes on All 40 Controls

The email comes from your PHO. It carries a PDF, a version number and a request to tick one rating on every row.

Behind it are the Shared Digital Health Record and the National Primary Care Dataset. A practice that wants to share information through either has to show it meets a minimum standard of cyber security first, and the Health NZ security checklist is how it shows that.

For many of the 40 controls, the protection may already be in place. What is missing is the record: who owns each control, where it is written down and what the practice could produce if somebody asked.

This guide walks through what Baseline asks for on each of the ten standards, the evidence worth keeping, and which parts your IT provider should be carrying for you.

What is the Health NZ security checklist?

The Health NZ security checklist is the self-assessment Health New Zealand uses when deciding whether a health service provider can connect to its digital services. Version 1.1, titled Security checklist for health service providers, was published in June 2026, developed with General Practice New Zealand, and is available as a PDF from Health NZ.

It is built on the National Cyber Security Centre’s Minimum Cyber Security Standards. Ten standards each break into four process requirements, which gives 40 controls in total. Each control has four rating rows: Insufficient, Baseline, Better and Best, and the person completing it ticks the row that describes the practice today.

The checklist states that Health NZ relies on the answers when deciding whether an organisation is certified to connect to a Health NZ digital asset. Treat the Health NZ security checklist as a declaration, and answer it on what is true this week.

This guide explains version 1.1 in practical terms. The checklist itself sets the ratings; the tables below are Exodesk summaries and examples, not the full official wording, and this guide is not a Health NZ approval or certification. Health NZ publishes updates through its information sharing and security awareness page, so check there for later versions.

It also supports Health NZ’s own assurance and due diligence obligations under the Government Digital Delivery Agency’s Information Sharing Standard. A single checklist gives every PHO and practice the same questions and the same scale, so a three-doctor rural clinic and a large urban medical centre are measured against one yardstick.

The Health NZ security checklist involves no network scan and names no products. Its Baseline questions cover whether basic protections exist, whether responsibility is clear and whether simple processes are written down.

What does Baseline mean on the Health NZ security checklist?

Baseline means the practice meets CS-CMM Level 2 on that control: the protection is in place, a person is responsible for it and the process is written down. Health NZ expects at least Baseline across the whole checklist before information sharing goes ahead.

The four ratings map one to one onto the four levels of the NCSC’s Cyber Security Capability Maturity Model.

The NCSC calls Level 2 Planned and tracked and sets it as the minimum for the government agencies its standards were first written for. Health NZ has adopted the same floor for providers sharing information with it.

Two points catch practices out. Baseline is a floor on every row, so 39 Better ratings and one Insufficient still leaves the practice short.

The second is that Baseline is not the ceiling for everyone. The Health NZ security checklist says some providers, such as those managing large information systems, are expected to reach Better or Best under the Shared Digital Health Record and National Primary Care Dataset agreements.

Ticking Better where the practice is at Baseline helps nobody. An inflated row is the one an incident, an insurer or a reviewer will find first.

What does Baseline require for governance and staff awareness?

Standards 1 and 2 of the Health NZ security checklist ask for a named owner, a yearly conversation about cyber risk, two simple registers and staff who know how to spot and report a problem. None of it needs new software, and all of it needs writing down.

Control 1.1 is satisfied by one named person, written down. A director, practice manager, clinician or management group can hold the role, and the checklist rates cyber security being assumed to be IT’s job as Insufficient.

Control 1.2 includes supply chain risk. Your PMS vendor, your hosting provider and your IT provider belong on the risk register alongside ransomware, privacy breaches and outages, discussed with the clinical and financial risks.

The critical systems register in control 1.3 should name the PMS, the patient portal, email, e-prescribing, the phone system and lab and imaging access. The test is whether the list can be found quickly during an outage.

Control 1.4 asks for both a security check and an approval before a new system or significant IT change goes in. The record should show what was checked for its effect on patient information or security, and who approved the change. A record that says only that a change was approved does not show the check behind the decision, and the Health NZ security checklist rates a practice Insufficient when a vendor makes changes the practice did not approve.

For control 2.4, the Health NZ security checklist accepts a secure portal, encrypted email, a text prompt or a phone call as alternatives. Where email is the only practical route, staff should understand the risk and check the recipient list before sending.

What does Baseline require for devices, software and patching?

Standards 3, 4 and 5 of the Health NZ security checklist ask whether every computer touching patient information is supported, configured away from its defaults and patched on a written schedule. The Technical delivery owner many of these controls, so the support agreement needs to say who does what.

The Health NZ security checklist names Windows 10 as an example of an end-of-life operating system in control 3.1. Confirm the edition and update arrangements for each device. Extended Security Updates can provide continuing security patches for eligible enrolled machines, but they do not restore full support or establish on their own that the device meets the checklist. Discuss any temporary exception with your PHO or Health NZ, and keep a replacement plan.

Control 3.2 asks the practice to know which systems hold patient data, whether each one is on a server in the building or hosted online, and who is responsible for managing it. A hosted PMS still needs a line on that record.

Control 3.4 needs an approved software list, with installation limited to the IT provider or a nominated person. A practice where staff can install software freely is Insufficient on that row.

Control 5.1 gives 30 days as an example timeframe for applying critical patches, and it expects that timeframe to be agreed in writing with whoever does the patching. Control 5.3 extends the same discipline to the PMS, browsers and remote access tools.

One oddity is worth knowing about. In version 1.1, the Insufficient row for control 3.3 describes defaults that have already been changed, which looks inconsistent. The Baseline row is clear: defaults changed on key systems, basic hardening applied and both recorded in the setup notes. Use that wording when reviewing the configuration, and ask your PHO or Health NZ to clarify if a rating is uncertain.

What does Baseline require for logins and access?

Standards 6 and 8 of the Health NZ security checklist cover multi-factor authentication and least privilege. Every person needs their own login, access matched to their role, accounts closed within a working day of someone leaving, and MFA on remote access, cloud services and the PMS where the system supports it.

Shared logins are hard to remove in a busy clinic. A Reception account used by three people on a front-desk PC is Insufficient on control 8.1 until each person has their own sign-in, or the shared account is documented as an approved exception.

Control 8.3 puts disabling a leaver’s access on the offboarding checklist, within 24 hours of departure. Arrange scheduled departures with the IT provider before the person finishes, including locums and contractors. The checklist also gives a working-day example; ask your PHO to clarify any uncertainty rather than leaving access active over a weekend. Our employee IT onboarding checklist covers the wider leaver process.

Control 8.4 rules out anyone reading email or browsing from an administrator account. A separate admin login, used only for IT tasks, clears it.

Control 6.3 is easy to overlook. Staff should be shown how MFA works when it is set up and know who to call if they lose their phone. Our guide to MFA requirements in New Zealand covers the methods and where each one is expected.

What does Baseline require for detection, recovery and response?

Standards 7, 9 and 10 of the Health NZ security checklist ask whether the practice would notice an attack, could restore its systems and knows who to call. Baseline accepts reactive log review and basic alerting, but it requires backups kept apart from the live network, at least one restore test per critical system and a short incident guide.

Control 9.3 covers cloud-hosted and SaaS services as well as anything in the building. For a hosted PMS, the practice needs its IT provider or vendor to confirm that data has been restored from backup at least once. A green backup report does not meet the row.

Control 9.2 is about where the backups live. A backup drive permanently attached to the server, or a copy on the same network, is Insufficient because ransomware can encrypt it along with everything else.

The business continuity plan in control 9.4 can be a single page. It should explain how the practice sees urgent patients, reaches key information and contacts IT support while systems are down.

Control 10.3 asks for a tabletop exercise in the last three years, attended by the practice manager, the IT contact and key clinical staff. A walk-through of a ransomware scenario, with the attendees, decisions and follow-up actions recorded, meets Baseline.

For control 10.4, the procedure should name who assesses whether a privacy breach is notifiable, and who contacts the Privacy Commissioner and the affected people. The Privacy Commissioner’s guidance on notifying a privacy breach says notification is required as soon as practicable, subject to the exceptions in the Act, and treats 72 hours from becoming aware of a notifiable breach as a guide, even while the investigation continues. Record PHO, Health NZ and insurer reporting duties separately, from the agreements that apply to the practice.

Writing the guide itself is covered in our post on building an incident response plan, which suits the short format the checklist asks for.

What should your providers deliver, and what must the practice own?

Technical controls sit with whoever delivers them under the practice’s agreements, while the practice owns governance, training, continuity and privacy decisions and stays accountable for its answers. The Health NZ security checklist allows controls to be delivered by an IT provider, a PHO or another supporting service, but it expects the practice to understand what is in place and who delivers it.

Ask the organisation responsible for each technical control to confirm what is in place and where the record can be found. That may be your IT provider, PMS vendor, hosting provider or PHO. If the answer or record is missing, check the position before selecting a rating.

The support agreement matters more than usual here. Several Baseline rows, including patching, application updates and backups, expect the arrangement to be written into the IT support agreement.

Cyber security for medical practices is mostly this kind of shared work. Our healthcare IT support is built around that split, for medical and allied health practices in Christchurch, Dunedin and across New Zealand.

How should a practice work through the Health NZ security checklist?

Work through the Health NZ security checklist in one sitting with your IT provider, score each row on what is true today, then close the Insufficient rows starting with access controls and backups. Keep the evidence in one folder as you go.

A practice with none of this written down should expect the first pass to take longer than later ones. Each later review starts from the folder.

What evidence should a practice keep for the Health NZ security checklist?

Keep the record each Baseline row describes, in one place the practice can find without the IT provider: the registers, the support agreement, training records, the restore test record, the incident guide and the change approvals. Many rows name the document they expect in their own wording.

• Governance note. One page naming the person responsible for cyber security, which clears control 1.1.
• Risk record. The risk register or the minutes of the annual leadership discussion, covering suppliers as well as ransomware and outages.
• Registers. The critical systems register and the data location record, which can be one spreadsheet with a hosting column.
• Support agreement. The IT support agreement, showing the patch schedule, backup arrangements and application updates.
• Training records. Induction material and the date of the last refresher, with who attended.
• Access records. The offboarding checklist and the current user list from the PMS.
• Restore tests. The record of the last restore test for each critical system, confirmed by the IT provider.
• Response documents. The incident guide, the outage plan, the contact list and notes from the last tabletop exercise.

Date every document. Several rows ask for something at least annually, and an undated policy cannot show that. A practice that keeps this folder current can answer the Health NZ security checklist again from the same records, and can answer an insurer’s questionnaire from them too.

What happens after the Health NZ security checklist is complete?

Health NZ uses the answers in its due diligence, and the practice then signs the Access and Use Agreement before information sharing begins. Any row below Baseline has to be closed before the practice proceeds.

The checklist stays relevant after signing. Several Baseline rows carry their own clock: an annual risk discussion, an annual staff refresher, an annual configuration review by the IT provider and a tabletop exercise at least every three years.

Staff change, systems are replaced and providers move on. The Health NZ security checklist answered in 2026 has to stay true in 2027. The evidence folder and the review date keep it that way between submissions.

Health NZ security checklist support from Exodesk

Exodesk works with medical and allied health practices to work through the 40 controls with the practice manager, close the Insufficient rows on the technical side and keep the records behind each answer in order. Where the practice already has an IT provider, we can work through the technical rows with them.

Exodesk has supported New Zealand businesses since 1989. Today, our Christchurch and Dunedin teams support businesses nationwide. Contact us or call 0800 396 337 to talk about your checklist.