Businesses and other institutions collect and generate vast amounts of data about the individuals with whom they come into contact. Many organisations hold records relating to millions of individuals. Some of this data is highly confidential; and the theft or unauthorised disclosure of even non-confidential this data can cause real damage. Security incidents involving personal data are reported in the media every day.
One response of European law to these issues is to be found in Articles 34 and 35 of the General Data Protection Regulation (GDPR), which are concerned with the question of when a personal data breach must be reported. They set out in considerable detail the circumstances in which reports should be made to:
- supervisory authorities, such as the Information Commissioner’s Office in the UK;
- affected data controllers; and
- affected data subjects.
The handling of data breaches and compliance with reporting obligations can be greatly assisted by a data breach notification policy. Although the use of such policy is not a specific and express requirement of the GDPR, the guidance from the regulatory authorities indicates that the existence of such a policy may help an organisation in the event of a breach and regulatory investigation. Of course, a sound policy properly applied should reduce the practical risks associated with a data breach.
In this post, I explore some of the issues you will face when writing or reviewing a data breach notification policy.
GDPR jargon
Before turning to the GDPR rules, a quick note on terminology. If you’re familiar with the key definitions in the GDPR, please feel free to skip this section.
The key definitions in the GDPR in the context of data breaches are as follows:
- personal data: “any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person”;
- controller: “the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data; where the purposes and means of such processing are determined by Union or Member State law, the controller or the specific criteria for its nomination may be provided for by Union or Member State law”;
- processor: “a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller”;
- personal data breach: “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed”.
If your business processes personal data, whether as a controller or processor or both, you should consider creating a data breach policy.
Scope of policy
The first question to decide is the scope of the policy.
Is it intended to cover ancillary matter such as the prevention of data breaches and process for ongoing improvements to systems to reduce the risk. Alternatively, is the focus purely upon notifications.
If the policy will only cover notifications, consider whether prevention and improvements should be covered elsewhere in your organisation’s policy documents.
What data?
The GDPR relates only to personal data. Personal data may or may not be confidential, and confidential information may or may not be personal.
Accordingly, a policy which focuses exclusively on compliance may neglect the risks arising out of the unauthorised disclosure of non-personal confidential information.
Given that the issues are so closely related, it is common to cover both personal and non-personal data breaches in a single policy document.
Reconciling goals
A data breach notification policy needs to reconcile various goals, including goals relating to compliance, risk management, practicality and flexibility.
- Compliance: Ensure or increase the likelihood of legal compliance.
- Risk management: Focus on areas of real risk for the specific organisation. What types of data are likely to be subject to a data breach? What kinds of data breach are most likely to occur? In what circumstances will real damage be suffered?
- Practicality: Create procedures that are no more complex than they need to be. Reflect the realities of imperfect human institutions. Limited resources.
- Flexibility: allow sufficient flexibility to deal with the unforeseen.
In some cases the goals may conflict. For example, there are cases where guaranteed legal compliance under the GDPR conflicts with practicality.
Statutory reporting obligations
Conformity with the statutory reporting obligations in the GDPR and in other applicable legislation is often the starting point for drafting a policy. As noted above, there are specific reporting obligations for controllers to supervisory authorities, processors to controllers, and controllers to data subjects set out the GDPR. The specific obligations include specifications of information to be reported and time periods for reporting.
The use of standard reporting forms as part of your policy can help ensure that all the requisite information is supplied.
Discretionary reports to data subjects
There are situations where, although there is no legal obligation to notify data subjects of a breach, it may nonetheless be a good idea. Consider including a process for determining whether to make such discretionary notifications in your policy.
Contractual reporting obligations: to controllers
While the GDPR itself does not specify a period within which personal data breaches discovered by a data processor must be reported to the relevant controller, guidance from the regulatory authorities suggests that the clock for the 72 hour period within which a controller must report to its supervisory authority can start ticking when a processor is fixed with notice of the breach.
If this is right, then it is sensible for controller-processor contracts to specify a processor-to-controller notification period of less than 72 hours. 24 hours is typical in the data processing agreements I have seen.
There are two ways in which this affects the drafting of a data breach notification policy. First, the policy should specify a period which reflects the contracts that the processor signs up to. Second, the processor should take care to ensure that the contracts it signs up to reflect the requirements of the policy. Standard contracts will help here.
Contractual reporting obligations: under NDAs
Some non-disclosure agreements and confidentiality clauses will provide that the recipient of confidential information must notify the disclosor in the event of an unauthorised disclosure of the confidential information.
Again: insofar as your data breach notification policy is designed to cover confidential information, you should ensure that the policy reflects the contracts that the business has signed up to, and that future contracts reflect the terms of the policy. Standard contracts will help with this latter point.
Using templates
Using a good template should take much of the pain out of the drafting process. A wide range of different template policies are available to purchase on the web. See for example the personal data breach notification policy on our Docular website.
Add a new comment