The 72-Hour Clock: What NZ’s Privacy Act and Breach Notification Rules Actually Require of SMBs

A customer database is exposed. An attacker gains access to your web application. An employee discovers that personal information may have been downloaded without authorisation.

At that point, you are no longer dealing only with a cybersecurity incident. You may also have a notifiable privacy breach under New Zealand’s Privacy Act 2020.

The Office of the Privacy Commissioner expects you to notify it within 72 hours of becoming aware that a breach is notifiable. You may need to act while your technical investigation is still underway, before you know exactly what happened, how many people were affected, or whether the attacker accessed, copied, or retained personal information.

That creates a difficult operating environment, particularly for an SMB with limited legal, privacy, and security resources.

You therefore need to understand two things before an incident occurs:

1. What the Privacy Act actually requires you to do.
2. How proactive security testing can reduce the likelihood that you will need to make those decisions under pressure.

‍

Is 72 Hours a Legal Deadline in New Zealand?

The Privacy Act requires an organisation to notify the Privacy Commissioner as soon as practicable after becoming aware that a notifiable privacy breach has occurred. The Office of the Privacy Commissioner, or OPC, expects notification within 72 hours.

The 72-hour period is OPC guidance, not a fixed deadline written into the Act. However, it should not be treated as permission to wait. “As soon as practicable” may require notification sooner when the seriousness of the breach is already clear.

‍

‍

Failing to notify OPC without a reasonable excuse is an offence, with a current maximum fine of NZ$10,000. A petition before Parliament proposes increasing the maximum fine to NZ$100,000, although the proposed change has not become law. A breach may also cause customer harm, contractual problems, reputational damage, and service disruption.

Official guidance is available through OPC’s privacy breach resources, its explanation of how the 72-hour expectation works, and section 114 of the Privacy Act 2020.

Read More: Blacklock Security Achieves CREST Accreditation

‍

Which Privacy Breaches Must Be Reported?

A privacy breach can involve personal information that has been lost, accessed, disclosed, altered, or otherwise handled without authorisation. It may result from a cyberattack, lost device, misdirected email, or inappropriate employee access.

However, not every security incident is a notifiable privacy breach. Notification is required when the breach has caused, or is likely to cause, serious harm to an affected person.

Factors used to assess serious harm

Relevant considerations include:

• The sensitivity and volume of the information
• Whether identity, financial, health, authentication, employment, or other confidential data is involved
• Who obtained the information or may obtain it
• Whether the information was encrypted, recoverable, or still under the organisation’s control
• The potential for fraud, identity theft, financial loss, discrimination, humiliation, or physical or psychological harm
• The effectiveness of containment measures
• Any cultural considerations affecting the severity of harm

OPC’s NotifyUs assessment process helps organisations evaluate these factors

‍

When Does the 72-Hour Clock Start?

The 72-hour expectation does not necessarily begin when an attacker first enters an environment. It begins when the organisation becomes aware that the incident is a notifiable privacy breach.

Some cases are immediately clear, such as evidence that an attacker downloaded an unencrypted customer database. Others require initial enquiries to determine whether personal information was affected and serious harm is likely.

Organisations can investigate before deciding whether notification is required. They should not wait for a complete forensic report when the available evidence already indicates likely serious harm.

Organisational awareness may begin outside the privacy team

Knowledge about the breach held by employees or agents may be treated as knowledge held by the organisation. The clock does not necessarily wait for the matter to reach the chief executive, privacy officer, or legal adviser. An effective escalation process should therefore ensure that:

• Employees know how to report suspected privacy incidents.
• Security alerts reach someone authorised to investigate.
• The privacy officer is involved promptly.
• Service providers have clear incident notification obligations.
• Findings are time-stamped.
• Responsibility for the notification decision is assigned.

Every New Zealand business or organisation must have a privacy officer. OPC provides further guidance on organisational privacy responsibilities.

Information can be supplied incrementally

An organisation may not know the full scope within 72 hours. OPC allows an initial notification containing the verified information reasonably available, followed by updates as further systems, records, and individuals are identified.

‍

What Should Happen After a Potential Breach Is Discovered?

A practical initial response should cover seven steps:

1. Contain the incident. Disable compromised accounts, isolate affected systems, revoke exposed credentials, preserve evidence, and prevent further disclosure.
2. Activate the response team. Involve security, privacy, management, legal, communications, and the affected system owners.
3. Establish what information was affected. Determine what personal information was present, whether it was accessed or removed, and who may be affected.
4. Assess serious harm. Consider the sensitivity of the information, available protections, possible consequences, and containment measures.
5. Notify OPC when required. Use NotifyUs as soon as practicable rather than waiting for the entire investigation to finish.
6. Notify affected individuals when required. Explain what happened, what information was involved, what the organisation is doing, and what affected people should do.
7. Continue investigating and documenting. Maintain a timeline, provide updates, remediate the weakness, and record key decisions.

‍

Why SMBs Struggle During the Notification Window

The legal assessment depends on reliable technical information. It becomes harder when the organisation cannot quickly answer:

• Which internet-facing systems were affected?
• What personal information did the application store or process?
• Was the attacker able to move beyond the initial entry point?
• Did the weakness affect an application, API, server, cloud service, or third-party component?
• Are similar vulnerabilities present elsewhere?
• Has the vulnerability been remediated and retested?

When asset records are incomplete, scanning is irregular, penetration test results are outdated, or remediation evidence is unavailable, much of the notification window may be spent reconstructing information that should already be accessible.

An incident response plan can help an organisation contain the damage, coordinate decisions, preserve evidence, and meet its notification obligations efficiently. However, it is still a reactive control. 

It does not identify the weaknesses that allowed the incident to occur in the first place. That is why breach readiness should be paired with proactive security testing designed to find and remediate exploitable weaknesses before attackers can take advantage of them.

‍

Prevention and Breach Readiness Are Connected

Information Privacy Principle 5 of the Privacy Act requires organisations to use security safeguards that are reasonable in the circumstances to protect personal information against loss, unauthorised access, disclosure, modification, and other misuse.

What is reasonable depends on the information held, the threats faced, and the systems involved. OPC provides more detail in its guidance on Information Privacy Principle 5.

Proactive testing helps determine whether those safeguards work as intended.

‍

‍

While testing cannot prevent every breach, its role is crucial. It reduces avoidable exposure, improves visibility, and gives teams better information when an incident occurs.

‍

How Blacklock Supports Proactive Security Testing

Blacklock combines automated vulnerability scanning with expert-led manual penetration testing, allowing organisations to assess systems continuously and obtain deeper validation where needed.

Blacklock is also an approved supplier in the New Zealand Government Pae Hokohoko Marketplace under the Source Code, Application Review, and Technical Testing category. Its services include penetration testing, vulnerability scanning for web applications, APIs, and infrastructure, static application security testing, and software component analysis.

More information is available in Blacklock’s announcement about joining the NZ Government Marketplace.

‍

Continuous vulnerability scanning

Blacklock Continuous Security Assurance and Monitoring supports scheduled, on-demand, and CI/CD-triggered scans across applications, APIs, infrastructure, and other internet-facing systems.

This capability is particularly useful for organisations that deploy frequently, because a point-in-time penetration test cannot assess vulnerabilities introduced by subsequent releases. Blacklock’s ongoing scanning helps maintain visibility between manual assessments while centralising findings, remediation progress, scan history, and retest evidence.

‍

Web application penetration testing

Web applications often process customer, employee, financial, and authentication data, making them a common route into sensitive systems. Vulnerabilities in authentication, access controls, session management, input handling, or business logic can therefore create a direct path to a privacy breach.

Blacklock’s web application penetration testing service combines automated scanning with CREST-certified manual testing to assess web applications and their associated APIs.

Automated tools identify common web application vulnerabilities, insecure configurations, and exposed components. Manual testers use black- and grey-box techniques to examine authentication, access controls, business logic, HTTP requests, parameters, hidden fields, and API endpoints from an attacker’s perspective, following recognised methodologies such as OWASP and OSSTMM. Findings are prioritised by risk and accompanied by remediation guidance.

‍

Infrastructure penetration testing and on-demand engagements

Blacklock’s infrastructure penetration testing assesses public-facing and private infrastructure for exposed services, insecure configurations, vulnerable software, open ports, and potential attack paths.

Through on-demand manual penetration testing, organisations can also request a CREST-certified engagement aligned with a release, customer assurance requirement, or compliance schedule.

‍

A Practical Readiness Checklist

Before an incident occurs, an organisation should be able to answer yes to the following questions:

• Has a privacy officer been appointed?
• Do employees know how to report a suspected breach?
• Is there an inventory of systems that store or process personal information?
• Are internet-facing applications, APIs, and infrastructure tested regularly and after material changes?
• Is manual penetration testing used where automated scanning is insufficient?
• Is remediation ownership clear, with fixes subsequently retested?
• Can scan history, evidence, and reports be retrieved quickly?
• Can OPC and affected individuals be notified before the full investigation is complete?

‍

Do Not Wait for the Clock to Start

The worst time to discover breach notification obligations is after an attacker has already accessed personal information.

Once a potentially notifiable breach is identified, the organisation may have only a short period to contain the incident, assess serious harm, notify OPC, communicate with affected individuals, and continue the investigation.

Those responsibilities cannot be eliminated. But the likelihood of facing them unprepared can be reduced.

By combining an established privacy breach process with continuous security testing, vulnerability remediation, and regular penetration testing, organisations can identify more weaknesses before they become breach entry points.

You can start a 14-day Blacklock trial or contact Blacklock to discuss the applications, APIs, and infrastructure that need to be assessed.

This article provides general information and is not legal advice. Organisations should obtain appropriate professional advice for their specific circumstances.