Questions are ordered from why an incident response policy is needed, through authority, triage, containment and reporting, to evidence, external providers, post-incident improvement and the gaps most likely to delay or weaken an SME response.
What is an incident response policy, and does my New Zealand business need one?
An incident response policy establishes who has authority to act, the principles and reporting rules the organisation will follow, and the minimum records and reviews required when a cyber incident occurs. It should be supported by a short operational plan or playbook containing the actual contacts, decision steps and technical actions. Own Your Online describes an incident response plan as a step-by-step guide documenting who will do what, and says having one in place helps a business take control, navigate the event and reduce its impact. New Zealand does not impose one universal statutory incident-response-plan format on every private SME. However, Privacy Act 2020 IPP 5 requires reasonable safeguards for personal information, and an effective, tested response capability may be part of what is reasonable for a business holding sensitive or important information. Sector licences, customer contracts, cyber-insurance conditions and government procurement can create more specific requirements. The plan should be available in hard copy, easy to access, short, clear and familiar to staff before an incident occurs.
- all SMEs — Maintain a concise policy, an operational response plan and an accessible contact list.
- personal-information holders — Connect the plan to IPP 5 safeguards and the serious-harm privacy-breach assessment.
- regulated, insured or contracted organisations — Add all licence, regulator, insurer, customer and supplier notification requirements.
- policy and plan — The policy sets authority and rules; the plan and playbooks provide contacts and actions.
We maintain an incident response policy, an operational response plan and scenario-specific playbooks proportionate to our risks. The plan identifies decision authority, roles, contacts, severity criteria, containment and recovery steps, evidence requirements, communication controls and external reporting obligations. A current hard copy is kept in an accessible location, and relevant personnel are trained to use it.
Roles, decision authority and contacts — who does what during an incident?
Assign roles before the incident and name alternates for absences or conflicts. Own Your Online identifies five core responsibilities: coordinating the response and making decisions; technically investigating and containing the incident; communicating with staff; communicating with customers, shareholders or media; and maintaining business-as-usual operations. The response coordinator should generally be separate from the hands-on technical investigator during a significant incident so that one person is not expected to investigate, make commercial decisions, approve expenditure and communicate at the same time. The policy should state who may isolate systems, engage specialists, approve emergency spending, notify regulators, contact affected people, instruct the insurer, speak publicly and decide whether a service can return to production. The contact list should include the MSP or IT provider, cloud and software vendors, website host, bank, lawyer, insurer or broker, communications adviser, NCSC, Privacy Commissioner, Police and relevant sector regulators. Confirm external providers' coverage, after-hours contact method, authority and response time before an incident.
- incident lead — Coordinates the response, owns decisions and maintains the overall operating picture.
- technical lead — Investigates, contains, eradicates, recovers and confirms whether compromise has spread.
- privacy, legal and communications leads — Assess reporting, privilege, customer harm, stakeholder messages and legal commitments.
- business-continuity lead — Maintains priority services and manual alternatives while systems are unavailable.
The incident lead has authority to activate the response plan, assign severity, convene the response team, approve emergency expenditure within delegated limits and escalate decisions to the Chief Executive. The technical lead controls investigation, containment, eradication and recovery. The privacy and legal lead controls legal assessments and notifications. The communications lead controls approved internal and external messaging. The business-continuity lead maintains priority operations. Each role has a named alternate and current after-hours contact details.
How should we handle detection, triage and severity levels?
Staff need one simple route for reporting anything suspicious, including unusual logins, unexpected MFA prompts, changed payment details, lost devices, malware warnings, data sent to the wrong person, service outages and customer reports. Technical monitoring should generate useful alerts rather than merely retain logs. Own Your Online says logs help detect incidents and establish their scope and recommends outlining how staff and customers report suspicious activity. Triage should establish what happened, when it began, which identities, systems, data and suppliers may be affected, whether the incident is continuing, the operational and safety impact, and whether personal information or money is at risk. A practical four-level scale is Low, Medium, High and Critical. This is an editorial model rather than a prescribed New Zealand legal classification. Severity should be raised as new facts emerge, and uncertainty should not delay containment or time-sensitive notification assessments.
- Low — Contained event with no confirmed compromise, material outage, personal-information exposure or financial loss.
- Medium — Confirmed compromise limited to one account, device or service, with manageable impact and no current serious-harm indicator.
- High — Sensitive information, privileged access, multiple systems, material service disruption, fraud or significant customer impact may be involved.
- Critical — Widespread compromise, safety risk, major operational failure, likely serious privacy harm, substantial financial loss or significant public impact.
All personnel must immediately report suspected cyber or privacy incidents through the designated channel. The incident lead assigns an initial Low, Medium, High or Critical severity using confirmed and reasonably suspected impact on people, information, money, privileged access, critical services, suppliers and legal obligations. Severity is reviewed whenever material facts change. Uncertainty must not delay protective action, evidence preservation or notification assessment.
What should containment, eradication and recovery cover, including clean backups?
Containment limits further harm without unnecessarily destroying evidence. Own Your Online advises disconnecting a compromised system from the internet or network where necessary and warns against simply turning it off because useful evidence may be lost. Actions should be directed by the technical lead and may include isolating devices, accounts, network segments, integrations or supplier connections; disabling compromised credentials; blocking malicious infrastructure; and protecting backups from attacker access. Eradication means identifying and removing the cause and persistence mechanism, patching exploited weaknesses, resetting affected credentials and confirming the compromise has not spread. Recovery should use backups known to pre-date the compromise, restored into a clean and monitored environment. Validate backup integrity, rebuild high-risk systems where necessary, restore services in business-priority order and monitor closely for recurrence. Do not reconnect a system merely because it appears to work. Record who authorised each restoration and the evidence supporting the decision.
- containment — Isolate affected assets and identities while preserving evidence and protecting clean backups.
- eradication — Remove malicious access and persistence, patch the entry path and reset exposed credentials.
- recovery — Restore from validated clean sources in business-priority order and monitor for recurrence.
- return-to-service approval — Require technical validation, business acceptance and a recorded decision before reconnection.
Containment actions are directed by the technical lead and must balance rapid harm reduction with evidence preservation. Compromised assets may be isolated from networks and services, but must not be powered off, wiped, rebuilt or reconnected without technical approval. Recovery uses backups and configurations validated as clean and predating the compromise. Services return in approved business-priority order only after the cause, persistence risk, credential exposure and monitoring requirements have been addressed and recorded.
How do we make the reporting decision for NCSC, the Privacy Commissioner, Police, the bank, regulators and the insurer?
Run a parallel notification assessment rather than assuming one report covers everything. Report cyber incidents to the NCSC through https://www.ncsc.govt.nz/report/; assistance with the reporting tool is available on 0800 114 115. The public-facing integration of CERT NZ into the NCSC was completed on 23 July 2025, so the NCSC pathway is now the national cyber-reporting route. If personal information is involved, assess whether the breach has caused or is likely to cause serious harm. A notifiable privacy breach must be reported to the Office of the Privacy Commissioner through NotifyUs, and affected people must generally be told, as soon as practicable. OPC says it should ideally be notified within 72 hours after awareness of a notifiable breach, even while investigation continues. Contact the bank immediately if credentials, accounts or payments may be compromised. Use Police 111 where an emergency response is required or someone is in danger, and Police 105 or its Fraud/Scam/Cyber form for non-emergency crime reporting. RBNZ and FMA duties apply to specified regulated entities and material incidents. Notify the insurer, customers and contractual parties according to their terms. New Zealand has no identified universal equivalent of Australia's mandatory 72-hour ransomware-payment reporting duty for every business.
- NCSC — Use the national cyber-reporting pathway for assistance, disruption, referral and threat sharing.
- Privacy Act — Apply the serious-harm test and notify OPC and affected people as soon as practicable when the breach is notifiable.
- crime or financial compromise — Contact the bank immediately and use Police 111 or 105 according to urgency.
- regulated, insured or contracted — Apply all regulator, insurer, customer and supplier triggers and deadlines separately.
For every incident, the privacy and legal lead will document separate decisions for notification to the NCSC, Privacy Commissioner and affected people, Police, the bank, sector regulators, insurer, customers and contractual parties. Cyber incidents may be reported at https://www.ncsc.govt.nz/report/ or with assistance on 0800 114 115. Police emergencies use 111; non-emergency Fraud/Scam/Cyber matters use 105. One report is not treated as satisfying another obligation unless the relevant authority confirms that it does.
How should we preserve evidence and manage internal and external communications?
Start an incident record immediately and record times, observations, decisions, approvals, actions, people involved and evidence locations. Own Your Online says this record supports lessons learned, insurance claims and external investigations. Preserve relevant logs, emails, text messages, authentication records, security alerts, affected devices, screenshots, ransom notes, bank records and supplier communications. New Zealand Police specifically advises keeping electronic evidence and consulting an administrator or security specialist about preservation. Avoid wiping, rebuilding or powering off affected devices until the technical lead has considered evidence needs. Communications should be accurate, coordinated and useful to the recipient. Separate confirmed facts from assumptions, explain protective actions people should take and avoid details that could assist an attacker. Own Your Online advises against saying anything that may later need to be retracted and warns that stakeholder communications may become public. Use one approved source for staff updates and one authorised spokesperson for external statements, while preserving the ability to meet urgent legal notification duties.
- incident record — Record chronology, observations, decisions, approvals, communications and actions as they occur.
- technical evidence — Preserve logs, affected assets and relevant communications without unnecessarily altering them.
- internal communications — Give staff one trusted update source, clear instructions and rules for public comment.
- external communications — Use confirmed facts, practical protective advice and an approved spokesperson.
The response team will maintain a contemporaneous incident record containing times, facts, assumptions, decisions, approvals, actions, communications and evidence references. Potential evidence must not be deleted, altered, wiped or powered off without technical approval. External messages require approval from the incident, privacy or legal, and communications leads, must distinguish confirmed facts from investigation, and must give affected people clear protective actions without disclosing information that increases security risk.
How should we work with an MSP and cyber insurer during an incident?
Do not wait for an incident to discover what the MSP or policy covers. Record which party monitors alerts, preserves logs, isolates systems, contacts cloud vendors, supplies forensic images, restores backups and provides after-hours response. Own Your Online recommends discussing external support capabilities and response timeframes while preparing the plan. The MSP's technical authority should be explicit: it may need permission to disable accounts, isolate devices or incur emergency costs, but business, legal, privacy and communication decisions remain with the organisation unless formally delegated. Review the cyber-insurance policy and run realistic scenarios against it. Identify the notification deadline, approved hotline, panel lawyers and forensic providers, consent requirements, exclusions, sublimits, excess, business-interruption terms and evidence required. Own Your Online's communications framework notes that cyber-insurance policies can impose reporting responsibilities and may provide communications and reporting support. Contact the insurer before appointing non-panel specialists or making irreversible decisions where the policy requires prior consent, unless immediate action is needed to protect people or prevent further harm.
- managed service provider — Define monitoring, investigation, containment, evidence, vendor escalation, restoration and after-hours responsibilities.
- business owner — Retain authority over risk acceptance, expenditure, legal reporting, customer communication and return to service.
- cyber insurer — Know notification, consent, panel-provider, evidence, exclusion and coverage requirements before an incident.
- shared exercises — Test the response plan with the MSP, insurer and critical vendors rather than reviewing it internally only.
Our MSP, cloud providers and cyber insurer are incorporated into the incident response plan with named contacts, after-hours pathways, contracted response times and defined authority. The MSP controls only the technical actions delegated to it; legal, privacy, financial, communication and business-risk decisions remain with authorised organisational leaders. The insurer is notified within the policy timeframe, and panel-provider or prior-consent requirements are checked before external appointments or material expenditure.
What should happen in the post-incident review and continual-improvement process?
Hold a structured debrief once immediate risk is controlled, while allowing technical and regulatory work to continue. Own Your Online recommends discussing what happened, what worked and what could be improved, then updating the plan, systems and processes. Reconstruct the timeline and root causes without reducing the review to the last person who clicked a link. Consider governance, identity, patching, access, architecture, supplier controls, monitoring, backups, communications, decision-making and business continuity. Track each improvement with an owner, priority, due date and closure evidence. Update the risk register, asset and supplier records, contact list, playbooks, training, insurance assumptions and customer commitments. Share useful threat information with NCSC where appropriate. Exercise the revised plan: Own Your Online suggests practising a scenario every six months to identify outdated contacts, roles or policies. Report completion and unresolved risk to senior management or the board.
- debrief — Review facts, decisions, technical response, business impact, communication and human experience.
- root-cause analysis — Examine system, process, supplier and governance causes rather than blaming one user action.
- corrective action — Assign owners, due dates, priorities and evidence for every agreed improvement.
- retest — Exercise the updated plan and verify that technical and operational fixes work.
After every material incident, the incident lead will convene a documented debrief covering chronology, cause, control performance, decisions, communications, reporting, recovery and business impact. Agreed improvements are entered into the corrective-action register with an owner, priority, due date and closure evidence. The policy, response plan, contacts, risk register and technical controls are updated, and the revised response is exercised within six months.
What are the common gaps and mistakes in New Zealand SME incident response?
Common gaps include a plan stored only on systems that may become unavailable; stale contacts; no named decision-maker or alternate; an MSP expected to make business and legal decisions it was never authorised to make; staff unsure where to report suspicious activity; logs retained without useful alerts; severity based only on outage length rather than personal information, fraud, privilege or safety; switching off, wiping or rebuilding systems before preserving evidence; restoring backups without confirming they are clean and usable; reconnecting too early; notifying NCSC but forgetting OPC, Police, the bank, regulators, insurer or customers; delaying a privacy decision until the investigation is complete; inconsistent or speculative public messages; and no debrief or corrective-action tracking. Another mistake is copying Australian ransomware-payment or critical-infrastructure reporting clocks into a New Zealand policy as though they were New Zealand law. A short tested plan with accurate contacts and clear authority is more useful than a lengthy document nobody can access or follow under pressure.
- unavailable or untested plan — The plan exists but is inaccessible during an outage, unfamiliar to staff or never exercised.
- unclear authority — Nobody knows who may isolate systems, spend money, notify authorities or speak publicly.
- technical shortcuts — Evidence is destroyed, backups are untested, the cause remains active or systems return too early.
- reporting and communication gaps — The organisation treats one report as sufficient or waits for complete certainty before assessing deadlines.
The incident response plan must remain usable when normal systems, email, identity services or premises are unavailable. Contacts, delegated authority, insurer conditions, regulator duties and recovery priorities are reviewed at least every six months. We do not destroy evidence, restore unverified backups, reconnect systems without approval, delay notification assessment until every fact is known, or import overseas reporting duties into this policy as New Zealand law.
What's my next step?
Common misconceptions
- An incident response policy and an incident response plan are necessarily the same document. A policy commonly sets authority and rules, while the operational plan and playbooks contain contacts and actions. INFERRED
- A small business can wait until an incident occurs before deciding who is in charge. Own Your Online recommends assigning coordination, technical, communication and business-continuity responsibilities beforehand. VERIFIED
- The response plan can be stored only on the company network. Own Your Online recommends an accessible hard copy because affected systems may be unavailable. VERIFIED
- Turning off a compromised computer is always the safest first action. Own Your Online warns that doing so can lose evidence and instead recommends technically directed isolation. VERIFIED
- A completed backup job proves the organisation can recover. Recovery depends on the backup being complete, accessible, clean and successfully restorable. INFERRED
- Reporting an incident to NCSC automatically creates a Police report. Police states that NCSC may share information in some circumstances with consent, but this is not itself a Police report. VERIFIED
- Every cyber incident is automatically a notifiable privacy breach. Privacy Act notification depends on a privacy breach having caused or being likely to cause serious harm. VERIFIED
- The Privacy Act contains an absolute statutory 72-hour deadline stated in those exact terms. The Act requires notification as soon as practicable; OPC says notification should ideally occur within 72 hours. VERIFIED
- The organisation should wait for a completed forensic report before notifying OPC. OPC allows notification while investigation is continuing and accepts subsequent updates. VERIFIED
- An MSP automatically owns all incident decisions. Technical responsibilities may be outsourced, but legal, privacy, commercial and communication authority must be expressly allocated. INFERRED
- New Zealand requires every business to report a ransomware payment within 72 hours. No universal New Zealand equivalent of Australia's payment-reporting duty was identified. INFERRED
- Once systems are restored, the incident is finished. Own Your Online recommends a debrief, plan updates, system improvements and regular practice. VERIFIED
Obligations at a glance
The obligations most relevant to this guide, with the regulator, the trigger and the timeframe. Follow the source links in the appendix for the authoritative wording.
| OBLIGATION | REGULATOR | TRIGGER | TIMEFRAME | PENALTY |
|---|---|---|---|---|
| Privacy Act 2020 IPP 5 reasonable safeguards | Office of the Privacy Commissioner | The organisation holds personal information. | Ongoing while personal information is held and when systems, suppliers, risks or handling arrangements change. | |
| Notifiable privacy breach | Office of the Privacy Commissioner | A privacy breach has caused or is likely to cause serious harm to an affected individual. | Notify OPC and affected people as soon as practicable; OPC says it should ideally be notified within 72 hours after awareness of a notifiable breach. | Failure without reasonable excuse to notify the Privacy Commissioner is an offence punishable by a fine up to NZD 10,000. |
| General cyber incident report to NCSC | National Cyber Security Centre | A cyber security issue or incident where assistance, referral, disruption or threat sharing may help; no universal statutory trigger was identified for every private SME. | Report as early as practical through https://www.ncsc.govt.nz/report/; assistance is available on 0800 114 115. | |
| Police cybercrime or ransomware report | New Zealand Police | The incident involves suspected criminal activity such as ransomware, fraud, unauthorised access, extortion or theft. | Use 111 immediately for an emergency or danger; use 105 or the Fraud/Scam/Cyber reporting form for non-emergency incidents. | |
| RBNZ material cyber incident report | Reserve Bank of New Zealand | A material cyber incident affects a registered bank, non-bank deposit taker or insurer covered by the RBNZ reporting requirement. | As soon as practicable and within 72 hours. | |
| FMA material operational or critical-technology incident report | Financial Markets Authority | A covered licence holder determines that an event materially affects service supply or the operational resilience of critical technology systems. | As soon as possible and no later than 72 hours after determining that the event is material. | |
| Bank notification following payment or credential compromise | The organisation's bank or payment provider | Money has been transferred, payment details changed, banking credentials exposed or an unauthorised transaction is suspected. | Immediately, so the bank can attempt to stop or reverse payment and secure affected accounts. | |
| Cyber-insurance incident notification | Insurer under the applicable policy | An incident falls or may fall within the policy's notification, cooperation, consent or claim conditions. | Within the period and through the channel stated in the insurance policy. | Delayed notice or unauthorised expenditure may affect coverage, depending on the policy terms. |
| Contractual customer, supplier or service-provider notification | The party entitled to enforce the applicable contract | The incident meets a security, privacy, service availability, data loss or suspected-breach notification clause. | Within the deadline specified by the agreement, which may be shorter than a statutory reporting period. | Contractual remedies may apply, depending on the agreement. |
Sources
- Create an incident response plan primary
- Get help now primary
- If you have had an online security incident primary
- Protect your business against ransomware primary
- Set up logs and monitoring for your website primary
- Communications framework for cyber security incidents primary
- Communicating in an online security incident primary
- Data breach readiness: what every business should know primary
- Report a cyber security issue primary
- NCSC contact and incident-reporting information primary
- NCSC incident response primary
- NCSC and CERT NZ integration now complete primary
- More than half of New Zealand businesses experiencing cyber threats primary
- Privacy Act 2020 Principle 5 — Storage and security of information primary
- Sorting out privacy breaches primary
- NotifyUs of a serious privacy breach primary
- Office of the Privacy Commissioner Prosecution Policy primary
- Privacy Act 2020 primary
- 105 Police Non-Emergency Online Reporting primary
- Police Fraud, Scam and Cyber reporting primary
- New Zealand Police cybercrime guidance primary
- How to report a crime or incident primary
- Government guidance on cyber ransom payments primary
- RBNZ cyber resilience for regulated entities primary
- FMA business continuity, technology resilience and incident reporting primary
- r/newzealand discussion of the Waikato DHB cyber attack forum
- r/newzealand discussion of the Farmers Group technology outage forum
This guide and its templates are a professionally drafted starting point, not legal advice. Your obligations depend on your industry, your contracts and your data. Have a qualified adviser review anything high stakes before you rely on it.