Our website uses cookies so we can analyse our site usage and give you the best experience. Click "Accept" if you’re happy with this, or click "More" for information about cookies on our site, how to opt out, and how to disable cookies altogether.
We respect your Do Not Track preference.
There are key components that an organisation needs to have in place to manage privacy breaches successfully – we call this a breach management system. A tested and integrated incident response plan is crucial because it helps organisations respond appropriately when a serious breach occurs or can prevent a breach from becoming serious because of an unprepared response.
A robust breach management system is also an important source of data to inform your privacy work programme. The implementation of a breach management system requires communication across the business, which will raise the profile of privacy within your organisation.
In this pou we are focusing on three key aspects of breach management:
While this pou is primarily concerned with notifiable breaches, the information will be useful for thinking about responding, reporting, and reflecting on interferences with privacy and other breaches (such as breaches of the privacy principles that don’t cause harm).
Your privacy function and anyone within the organisation who has a responsibility for privacy incident management. In smaller organisations, this may be an individual privacy officer. In larger organisations, there may be some specific privacy roles that focus on responding, reporting and reflecting on privacy breaches.
The unauthorised sharing, exposure, use or loss of access to personal information may cause serious harm to impacted individuals or groups. Some types of information are inherently more sensitive than others, and therefore more likely to cause serious harm. You should also consider what you know about the people who have been impacted by the breach, as some people are particularly vulnerable or at a greater risk of harm. For example, victims of family violence.
Types of serious harm include:
If you suspect a privacy breach may result in imminent harm to an individual, you should notify the NZ Police immediately before reporting the breach to OPC through Notify Us.
Assessing a privacy breach as quickly as possible can help an organisation understand the steps needed to appropriately respond alongside any action taken to contain the breach.
Knowing the scope of the personal information involved and the nature of the individuals impacted will help you determine whether serious harm has occurred or is likely to occur and what your notification obligations are.
For example, a leaked list of clients of a specialist mental health service provider is likely to be more sensitive and therefore more likely to cause serious harm to the individuals affected than a leaked list of subscribers to a newspaper.
The criteria for assessing the likelihood of serious harm are outlined in section 113 of the Privacy Act 2020.
Those criteria are:
Have you taken steps to contain the breach? How quickly were you able to take them? How effective or successful were these steps?
Do you have an incident response plan? Such a plan outlines the procedures that your organisation will take following a breach. See the Reflect section ifor further guidance on what should be included in an incident response plan.
Try to identify the size and scope of the breach, including the number and nature of the likely recipients as well as the number of affected people. Identify the risk of the information being circulated further and respond accordingly.
Certain types of information are more likely to lead to harm than others. For example, financial or identification documents can lead to fraud or identity theft. Other types of sensitive information include information relating to someone’s biometrics, health, genetic or ethnic background, political or religious beliefs, sex life or sexual orientation, or whether someone has committed any crimes.
The personal information of children and young people is also more likely to be considered sensitive.
Context matters. Personal information that might not normally be considered sensitive, such as email addresses, may be considered sensitive in specific circumstances. For example, where a person with a protection order in place has their home address shared.
The opposite can also be true; some information may be inherently sensitive but may not be sensitive in the specific circumstances. For example, if the information has gone to someone who already knows it or it’s already publicly available.
Was the receiver a trusted, known person or organisation that can be expected to return the information? Were they under any kind of obligation of confidentiality or secrecy, similar to that of a doctor or lawyer?
Or was the information taken by, or given to, an unknown receiver, someone who might pose a particular risk, or to a wide range of people with the potential to misuse the information?
For example, if the breach was caused by a malicious actor who used unlawful means to access the information, this increases the likelihood that they intend to misuse any information they obtain.
Knowing, and even not knowing, who has received the information will shape how you respond.
This factor is about security measures that are designed to protect the breached personal information from being accessed and misused either accidentally or maliciously once it has been breached. It is not about the security of the system that the personal information came from.
If breached personal information is password protected or encrypted, there is a lesser chance of it being accessed and misused than if it is unprotected. Likewise, if the breached personal information is on a lost or stolen laptop that can be remotely wiped, this would reduce the chances of access and misuse.
You should consider whether the security measures that protect information involved in a breach are likely to be effective at preventing access to it in the circumstances.
Being open and transparent with people about how personal information is being handled is a fundamental rule of privacy, especially when there has been a breach. Notification can also be a key step in helping people affected by a breach.
If a privacy breach creates a risk of serious harm to people, those affected need to be notified, unless one of the exceptions in the Act applies. Prompt notification can enable people to take steps to protect themselves and regain control of their information.
You must inform the Privacy Commissioner of serious privacy breaches as soon as you practically can after becoming aware of them. Our expectation is that you will do this within 72 hours of becoming aware that it’s a notifiable breach. This timeframe is a guide only and is intended to initiate prompt notification to us.
In some cases, it will be clear from the outset that a breach has occurred and that it is notifiable. In other cases, an organisation may not discover the breach immediately or may need to undertake some enquiries to figure out whether a breach has occurred or is serious (for example, where an audit of an employee’s access raises questions about inappropriate access).
OPC’s Notify Us tool can help you assess how serious your breach is and whether you will need to notify the Privacy Commissioner. This tool is a guide only, so if you're not sure, please notify. If you do need to notify OPC, you can also do this using Notify Us.
Becoming aware of a notifiable breach requires some degree of knowledge or an assessment about the risk of harm from the privacy breach. This will be a straightforward assessment for some breaches, while others may be more complex or have unique facts or circumstances.
The key thing is once your initial assessment indicates that harm is likely based on what you know at that time (e.g. sensitivity of the information, weakness in security measures, and probable harm to individuals) you should be thinking about prompt notification, even if there are still some unknowns (such as who has obtained or could obtain the information).
Information known by your employees or agents (third-party providers) is treated as being known by the organisation. This means that a privacy breach can be notifiable as soon as any employee or agent identifies that it is notifiable, not just your privacy officer. You need to ensure that your processes support prompt disclosure of privacy incidents to your privacy function and that you promptly act upon that information, including undertaking further investigation and assessment where necessary.
We understand that not all information will be available at the same time. An organisation can fulfil its notification requirements to our Office and affected individuals on an incremental basis, under section 117(5) of the Privacy Act, so long as the organisation does this as soon as reasonably practicable after finding out that information. However, you should still let us know as much as you can. You can provide any subsequent updates to us at notifyus@privacy.org.nz using the PBN/xxxx number provided.
If your assessment is that notification is not required, you need to regularly review that as your breach response or investigation progresses and the information that you have changes (for example, you may discover that the lost USB key was not encrypted).
It’s important to keep good records. Your assessment of the breach, decision whether to notify, and the reasons for that decision should be well documented. Recording reasons at the time helps to support good decision-making and promote accountability. It also helps you to explain and justify the decisions if any concerns are raised, or you need to provide additional information to OPC and individuals. You can print a copy of your notification to OPC for your records.
A privacy officer at Very Large Tech Company Ltd hears from a cyber-security staff member at the company that they have identified unusual activity on the company servers but are still working out the details. The privacy officer joins the incident response team to support them to work quickly to identify whether the issue is a privacy breach.
It becomes clear the next day that personal information has been accessed by a hacker for ransom, but it’s not clear exactly what personal information has been accessed, what has happened to it and how many people have been impacted. However, as personal information has been criminally accessed, it’s reasonable to conclude that serious harm is likely.
Hackers are known to post the data on the dark web and use or sell identity data for fraudulent purposes, even when a ransom is paid by the organisation.
This means the privacy officer must notify the Office of the Privacy Commissioner as soon as practicable and within 72 hours, which they do via Notify Us. They continue learning more about the breach, so they update the breach notification to the Commissioner incrementally and notify affected individuals via a public notice and then individually once they have established whose information was compromised and locate their contact details.
A member of the public emails the privacy officer at Very Large Tech Company Ltd to tell them that they have a file of the Company’s hard-copy papers which they found on a train. The email doesn’t say what is in the file, and it takes a couple days for the individual to respond to the Privacy Officer’s calls. During the phone call, the individual says that they got the company’s details from a policy document that was on the file but didn’t look through the other documents.
They also say that they are happy for the Privacy Officer to collect the file, but not for another 5 days as they are away on holiday. At this stage, the Privacy Officer records their view that they don’t think that there is a notifiable privacy breach as the individual has proactively notified the Company, has taken steps to secure the file, and says that they have only seen a policy document.
The Privacy Officer collects the file as soon as the individual returns from holiday. On review, they discover that the file contained a document with highly sensitive personal information about another employee at the Company. As the file was unsecured while on the train and could have been accessed by a member of the public prior to the individual securing it, the Privacy Officer revises their decision and decides that there has been a notifiable privacy breach and notifies OPC as soon as practicable and within 72 hours.
They also work with the Company’s HR department to notify the affected employee.
Where there is a notifiable privacy breach, you will also need to notify the people affected unless an exception applies. These exceptions include situations where notifying them would adversely affect that person’s health or wellbeing. If law enforcement authorities are involved because the breach involves criminal activity, you may want to check with those authorities before you notify so that their investigation isn’t compromised.
If there is no risk of serious harm, you are not required to notify people of a privacy breach, but you may still choose to. You may decide that it’s in the best interests of the affected individuals to be informed. Each incident needs to be considered on a case-by-case basis. Being open and transparent with customers and employees when things go wrong can help build trust in how your organisation manages and protects the personal information it’s responsible for.
When notifying people, it’s important that you have as much information as possible about what happened and what information of theirs was impacted. Incorrectly notifying the wrong people that their information has been breached may cause them unnecessary stress and harm. If you’re notifying people, and you don’t have all the details yet, it’s important to be open about that. You should let them know what’s happening, when, and who they can get support from.
Things to consider:
Organisations should notify affected individuals directly. However, there are circumstances where it may be appropriate to issue a public notice instead. For example, where many affected individuals cannot be directly contacted.
You are not required to notify the people involved, or give public notice, of a notifiable privacy breach, if you believe that the notification or public notice will:
There may be multiple organisations involved in managing a breach.
You will need to work out who will be responsible for notifying the Office of the Privacy Commissioner and affected individuals, and any ongoing communications. This will require you to step through which organisations are legally required to notify. This will depend on whether your organisation is ‘holding’ the information that has been compromised.
For example, if a service provider (A) processes information on behalf of another organisation (B) and does not use the information for its own purposes, the breach notification obligation rests with the organisation (B). (B) will want to ensure it has contractual protections in place so that if (A) suffers a breach that impacts (B)’s data, (A) is required to tell (B) immediately and take steps to manage the breach.
However, if (A) uses the information for its own purposes, both (A) and (B) will have notification obligations. While in practice, (A) and (B) could agree in contract that one of them will notify on behalf of the other, they will need to ensure that the contracted party takes appropriate action to fulfil the notification obligations.
Generally, the organisation that has the closest relationship with the affected individuals should be the one to notify them, but the notification should be clear that it is being made on behalf of multiple organisations.
You don’t need to notify a person about, or give public notice of, a notifiable privacy breach involving their personal information if:
However, in those circumstances, you must:
Then, you must notify the person’s parent, guardian or other representative (rather than notify the person involved or give public notice).
If you are not intending to notify, the Privacy Commissioner is likely to seek further information from you on this decision.
You can also delay notifying the people involved, or giving public notice, if you believe that:
You can only delay the notification or public notice while those risks continue to outweigh the benefits. This decision should be continuously revisited throughout the process of managing the breach.
Regardless, you must not delay or refuse to tell OPC about a notifiable privacy breach.
It is always best to notify affected people directly – by phone, letter, email, or in person. Direct notification is more sincere and personal.
Where it is not reasonably practical to notify individuals directly, you may issue a public notification.
Examples of where it’s not practical for an organisation to notify people individually of a breach could be when the organisation doesn’t know exactly which people were affected by a breach, or when you don’t hold accurate contact details for those affected.
Public notices must be published on the organisation’s website and must be publicly accessible and free of charge. The notice needs to be in at least one other format that will bring the notice to the attention of the greatest number of affected individuals. Consider your audience and traditional channels, such as radio or television, as well as social media. Under regulation 12 of the Privacy Regulations 2020, the public notice must:
Capturing all privacy breaches and near misses in a log will help you manage the breach and identify risks that could make a breach more likely to occur. It also helps you to develop a plan to improve your process and systems.
We do not suggest that you set a target of zero breaches, as it discourages the reporting of breaches and incidents and the important insights that your organisation can gain from them.
Information you can capture in the log:
Consider using dropdown menus instead of free text wherever possible. This will help with data analysis, trend analysis, and anomaly detection. Dropdown menus can also minimise the risk of users entering erroneous data.
It’s important to keep in mind that an incident log can be a sensitive document in and of itself, due to the type of information that may be captured when describing an incident or privacy breach.
You shouldn’t capture any personal information in these logs. Instead, you could use a unique identifier, such as a file number, so that information can be linked back to the actual incident.
For example, if recording incidents of employee browsing, it is crucial to preserve the confidentiality of any investigations or disciplinary processes. You should ensure only the minimum amount of information is captured in the reporting log.
You should have controls in place to manage who has access to the log itself, and then look to facilitate wider access to the information in safe, aggregated ways for reporting purposes.
Fortunately, there are many occasions when somebody realises a privacy breach is about to happen and acts before it’s too late. Similarly, sometimes privacy breaches occur but serious harm is not caused.
Many of the most common privacy breaches are easily preventable, and all these circumstances provide an opportunity for organisations to learn and make system changes to avoid a serious breach next time.
Often organisations or individuals will narrowly avoid serious privacy breaches through sheer luck.
For example, you might be about to send an email containing personal information to the wrong person.
You may have drafted an email containing sensitive information to a list of people and cc’d in each email address rather than bcc’d. In each of these instances, a breach could be avoided if, just before clicking ‘send’, you realise your mistake and take appropriate action to avert a breach.
Other examples of narrowly avoiding serious privacy breaches could be:
Near misses
Prevention is better than cure – near misses provide the perfect opportunity for organisations to examine how they handle customer or client information and improve their privacy game.
You can still notify the Office of the Privacy Commissioner of breaches that aren’t likely to cause serious harm. This provides an opportunity for OPC to give you advice and direction on how to reduce the likelihood of it occurring again, or in a way that does cause serious harm.
Return to top
There are always new lessons learned from every incident. You should plan a debrief meeting with the key people involved after the incident has settled. The meeting will help you to identify any systemic risks, whether any changes are required to systems and processes, and whether there is a need for additional privacy training and awareness for staff.
You should always include a root cause analysis as part of the debrief:
Note that the root cause is the fundamental reason for the incident occurring. For example, the root cause of a cyber-hack could be a low security password or access setting, or an IT security patch not being applied in a timely way. The root cause of human error may be a multi-step operational process that drives staff to create a workaround that increases the likelihood of mistakes.
You should also take the time to consider how the incident was managed overall:
It is crucial for organisations to develop and maintain a plan to respond to privacy breaches that impact personal information they are responsible for. This includes personal information collected by, or shared with, third parties e.g., as part of a vendor or service provider contract. Where information is passed to a third-party service provider, the contract between the organisation should clearly set out the roles and responsibilities of each party when an incident occurs.
A privacy breach response plan will enable your organisation to respond quickly to a breach or incident, which can substantially decrease the impact on affected individuals, reduce the costs associated with dealing with a breach, and reduce the potential reputational damage to your organisation.
The plan should:
Your incident response plan should be in a format that is concise and easy to follow. Make sure your employees know where the plan is stored and can access it easily. Your staff should also be familiar with the plan before they need to use it. This could be achieved by testing the plan in a simulated incident exercise, to give staff practice at putting the plan into action.
You should involve various business groups in the development of the plan, for example:
Understanding who does what in an incident will save time, avoid confusion, and provide employees with a clear picture of what they need to do. It also ensures that all required stakeholders are involved when they should be.
You will need to assign someone to the following roles when you assemble your incident response team:
These are all tasks that must be done, but you don’t need a huge team of people to do them. However, you may wish to bring in experts to support the incident response team, particularly if you are a small organisation with a single person covering many of the response functions.
While it’s important to reflect on the lessons learned from privacy breaches and incidents, it’s equally important to implement changes and improvements to prevent them from occurring.
See our Security and Internal access controls pou for guidance on some of the most common practices that can lead to data and privacy breaches if not appropriately monitored and managed within your organisation, and some of the preventative controls available to you.
We’ve included some use cases based on fictional organisations to demonstrate each of the pou in practice. Read more of the background on our Organisation Examples page.
Fern Leaf holds a large volume of personal information. The Privacy Team works very closely with the Information Security team and together they run tabletop exercises to test potential breach scenarios and how to respond.
Fern Leaf regularly reminds its employees of the importance of spotting privacy breaches quickly. It runs training sessions and uses anonymised real-life scenarios to make the training more relatable. It reports regularly to senior management on trends they are seeing, and action taken to contain breaches.
If a breach is notifiable, the privacy team has a clear process on what information is required and the factors to consider. The Privacy Officer signs off on any notification to OPC and assists with drafting communications to impacted individuals.
Reach High knows that a privacy breach would have a significant impact on client and stakeholder trust, which in turn would impact on its ability to deliver important services to at risk young people. For this reason, the director of support services develops a simple Privacy Breach Management Plan to ensure that all breaches are recognised and managed properly. Reach High has decided that the most important thing to focus on is ensuring that all its employees can recognise a breach and know who to report it to. So, they complement the new plan with some targeted training that focuses on recognising and escalating breaches.
As a small organisation, breaches are managed by the leadership team as a group, with specific advice from the director of support services. Breaches are recorded in the Privacy Risk Register, which the Director of Support Services uses to track resolution.
Although the personal information Swiftstart NZ holds on its own behalf is reasonably minimal, it knows it has the potential to hold significant customer information within its platform on behalf of its clients, particularly as the company expands. It also knows that its clients have strong expectations around the security of the platform and will need to be immediately notified in the event of any breach to ensure the client company can take all appropriate steps (including making any required notifications).
The operations manager develops a privacy incident plan under which they will be the initial escalation point for any potential privacy incidents or near misses. They will undertake an initial investigation and assessment, including taking any appropriate immediate containment measures. Within 12 hours they will provide a report to the Swiftstart NZ founders with their assessment of the incident and recommended next steps, including whether notification to OPC and affected individuals is required or otherwise recommended. The founders endorse the plan and agree to commit to Swiftstart NZ’s customers that any confirmed breaches where information is at risk will be notified within 24 hours of initial identification.
The founders recognise that ensuring speedy identification and escalation of any issues will be vital in order to meet their committed timeframe for client notification and decide to incorporate regular testing of the privacy incident plan by way of simulated incident into their routine digital readiness simulations. They also task one of their developers with creating an internal reporting tool so that any incidents can be easily logged by staff and pushed through to a log managed and maintained by the operations manager.
The administrator for Green Gardens develops a simple Privacy Breach Management Plan, which they run past the owner/manager, since accountability for privacy is shared between them.
As a small business, breaches are managed by the owner/manager and the administrator together, with the administrator leading the response, including initial investigation, any notification requirements, and recording breaches in a privacy incident register.
Jo Jones develops a simple Privacy Breach Management Plan, which she has designed as a checklist for herself to go through whenever she thinks she may have identified a breach or near miss.
Jo also has an Incident Register which is an excel spreadsheet where she records any breaches or near misses and the cause of them. When Jo is working for a community health service provider, Jo familiarises herself with their privacy breach management process, and knows who to escalate any incidents to, and where to record near misses.
The Privacy team uses the relationships it has built with the Ministry’s IT and information management team through its collaboration on data inventory, to work more closely together on breach management. All teams understand that breaches that affect one team are likely to impact or be relevant to others.
The teams work together to develop a breach response plan. They then trial and test the plan in a mock privacy breach scenario with SLT members so they know what to expect should a serious breach happen. The team has also established clear escalation pathways for breaches that customer service becomes aware of, so that issues are promptly identified and acted upon.
