A legal or policy test used to decide whether a data breach requires formal disclosure. The assessment weighs the type of information exposed, how easily it could be misused, and the potential consequences for the people affected. It is a judgement call, but one that should be documented and made quickly.
What the serious harm test means
The serious harm test is a decision threshold, not a mechanical rule. It asks whether a breach is likely to cause meaningful harm if the exposed information is misused, taking into account both what was disclosed and how readily it could be turned against the people affected. Because the judgement must be made quickly and defensibly, organisations need a clear process for consistent assessment.
The test matters because the same breach can look very different depending on the data involved. Names and contact details may be lower impact than financial data, credentials, health information, or other records that enable fraud, embarrassment, exclusion, or identity misuse. The assessment is therefore context sensitive, and the quality of the decision depends on understanding both the data and the people at risk.
How the serious harm test is assessed
Assessment usually combines three questions: what information was exposed, how usable it is to an attacker or other bad actor, and what consequences are plausible for the affected individuals. That means a breach with limited-looking data can still be serious if the information is easy to link to other records or can be used to impersonate, pressure, discriminate against, or defraud someone.
The judgement also depends on the surrounding facts. A single data element may be low risk in isolation but much more dangerous when combined with other records, public sources, or prior compromise. That is why teams should avoid treating the test as a simple checklist and instead document the reasoning behind the conclusion.
Why timing and documentation matter
The test is designed to support rapid notification decisions, so delay can itself create regulatory and operational risk. If organisations spend too long debating the threshold, they can miss notification windows, lose evidence, or fail to contain follow-on misuse while the exposure is still active.
Good documentation turns the test from an ad hoc judgement into a repeatable control. It creates an audit trail showing what was known at the time, what risks were considered, and why the final view was reached, which is especially important when later facts change the apparent severity of the breach.
What this means for organisations
The practical challenge is not only deciding whether harm is serious, but doing so consistently across incidents. That requires a shared understanding of the information types most likely to create harm, a fast route to legal and privacy review, and enough incident context to support a sound call under pressure.
For teams handling privacy incidents, the test should sit alongside broader breach response work: contain the event, preserve evidence, assess the people impact, and decide whether disclosure is required. New Zealand Privacy Act Guide is a useful reference for the notifiable breach and serious harm context under New Zealand privacy law.
Risk and Threat Considerations
The serious harm test exists because breach impact is often driven by misuse, not just exposure. Information that seems benign can enable fraud, account takeover, stalking, coercion, discrimination, or reputational damage once it is combined with other data or used in the wrong hands.
Failure mechanism: Organisations underestimate harm when they focus on the data type alone and ignore linkage, context, or downstream use, which can lead to missed notifications and delayed protective action.
Impact: A weak assessment can leave affected people exposed to ongoing misuse while also increasing legal, regulatory, and trust consequences for the organisation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 and GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | The test is a risk decision that must be documented and governed consistently. |
| Recommendation — Define decision criteria for breach-harm assessments and record the rationale used for disclosure calls. | ||
| ISO/IEC 27001:2022 | A.5.24 — Information security incident management planning and preparation | The test is part of incident handling and disclosure preparation for security events. |
| Recommendation — Prepare incident workflows that route serious-harm determinations through agreed review and escalation. | ||
| GDPR | Art. 33 — Notification of a personal data breach to the supervisory authority | The test parallels breach-notification thresholding where harm likelihood drives reporting duty. |
| Recommendation — Assess breach impact promptly and determine whether notification obligations are triggered. | ||
| NIST SP 800-53 Rev 5 | IR-8 — Incident Response Plan | The assessment belongs in a documented response process for determining breach handling actions. |
| AU-6 — Audit Record Review, Analysis, and Reporting | Documenting the decision requires reviewable records and traceable incident analysis. | |
| Recommendation — Embed breach-severity evaluation and notification decision points in the incident response plan. Capture the facts and reasoning behind the harm assessment in incident records for later review. | ||
Practitioner Guidance
Why practitioners should care: The serious harm test is one of the few privacy judgements that directly affects disclosure timing, so it needs an accountable owner and a documented basis. Treat it as a structured decision under incident pressure, not a legal afterthought.
What to watch for: Pay close attention when exposed data can be linked to other records, when the dataset contains identifiers plus sensitive context, or when the breach involves information that could be used for impersonation, fraud, or coercion. Those are the situations where “low-looking” breaches can become high-impact events.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 31, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org