Security incidents are inevitable. How your organisation responds when one occurs — and whether that response meets NZISM requirements — determines both the outcome and the regulatory exposure.
NZISM's incident management chapter covers the requirements for detecting, responding to, reporting, and learning from security incidents. The National Cyber Security Centre (NCSC) adds reporting obligations for significant cyber incidents. Understanding both is essential.
What NZISM Requires
NZISM requires agencies to:
1. Define what constitutes a security incident — agencies must have documented criteria for what events constitute an incident requiring formal response. An incident is any event that has the potential to affect the confidentiality, integrity, or availability of information or systems.
2. Establish an incident response capability — this includes: a documented incident response plan, trained personnel responsible for executing it, and tested procedures for common incident types.
3. Detect and log incidents — logging controls required by NZISM provide the detection capability. Agencies must ensure their logging is sufficient to detect incidents in a timely manner and provide forensic evidence when needed.
4. Respond according to the plan — when an incident is detected, the response must follow the documented plan. This includes: initial triage, containment, eradication, recovery, and post-incident review.
5. Report incidents — to agency leadership, to the NCSC for significant incidents, and to affected parties where appropriate.
6. Learn from incidents — post-incident reviews must be conducted for significant incidents, and findings must feed back into the security programme.
NCSC Reporting Requirements
The NCSC asks New Zealand organisations to report significant cyber incidents. While reporting is voluntary for many organisations, for government agencies operating under NZISM there is a clear expectation of reporting.
Report to the NCSC:
- Cyber incidents affecting critical systems or classified information
- Incidents with potential national security implications
- Incidents that may affect other organisations
The NCSC incident reporting form is the mechanism. The NCSC also operates a 24/7 incident response service for serious incidents affecting government agencies.
For privacy-related incidents, the Office of the Privacy Commissioner has separate mandatory notification requirements under the Privacy Act 2020. If a security incident results in a privacy breach causing serious harm, both NCSC and Privacy Commissioner reporting may be required simultaneously.
Building an Incident Response Plan
A compliant incident response plan includes:
Scope and objectives — what incidents does this plan cover? What are the objectives of the response (contain the incident, preserve evidence, restore service, notify affected parties)?
Roles and responsibilities — who is the Incident Response Manager? Who are the technical responders? Who authorises communications? Who notifies external parties? For each role, name a primary and a backup.
Incident classification — a tiered classification system (P1 through P4 or similar) with defined criteria and expected response times for each tier. A P1 incident affecting classified systems will have different response requirements than a P4 anomalous login.
Response procedures — step-by-step procedures for common incident types: ransomware, data exfiltration, credential compromise, insider threat, system outage. Generic plans aren't enough — scenarios specific to your environment matter.
Communication plan — who gets notified, when, and through what channel? This includes internal notifications (leadership, legal, HR) and external notifications (NCSC, Privacy Commissioner, affected parties, media if required).
Evidence preservation — procedures for preserving forensic evidence before containment actions destroy it. This is often skipped in the rush to fix things — and later becomes critical if legal or disciplinary action follows.
Post-incident review template — a structured template for conducting a review after every significant incident. What happened? What was the impact? What was the root cause? What would have made the response better? What changes are being made?
Testing Your Response Capability
NZISM expects incident response plans to be tested — not just documented.
Testing approaches:
- Tabletop exercises — walk through a scenario with the response team. No systems touched, just decision-making tested. Best for validating the plan and identifying gaps in roles and communication.
- Functional exercises — actually execute parts of the response plan in a controlled environment. Test the communication chain, the notification process, the escalation path.
- Simulation exercises — inject a simulated incident into the environment (with appropriate safeguards) and observe the real response. Most realistic, most resource-intensive.
For most government agencies, annual tabletop exercises with periodic functional exercises is a reasonable minimum. The NCSC offers exercise support to government agencies.
AccreditAZ provides structured incident management workflows linked to your NZISM controls — log incidents, track response activities, document post-incident reviews, and maintain an evidence trail for accreditation. Start a free trial.