Security and breach reporting under the GDPR and NISD

A government survey published in May 2016, revealed that two thirds of large UK businesses were hit by cyber breach or attack in the previous twelve months. Nearly 70% of attacks on businesses involved viruses, spyware or malware, most of which could have been prevented by following the steps recommended in the Government's Cyber Essentials scheme. Of course, not all security breaches are the result of hacks. Many are due to human error, for example, sending information to the wrong recipient, losing documentation or failing to redact personal data. Whatever the cause of a data breach, it can cost a business millions. Businesses need to focus on data security, not simply because of the costs and the reputational damage breaches cause, but also because of incoming legislation which steps up security and breach reporting requirements and provides hefty sanctions for non-compliance. Following our top tips is a good place to start.

How relevant is incoming EU legislation in the UK?

The General Data Protection Regulation 2016 (GDPR) and the Network and Information Security Directive 2016 (NISD or Cybersecurity Directive) are both EU pieces of legislation. The GDPR will apply automatically in EU Member States from 25 May 2018, whereas NISD requires Member States to introduce implementing legislation by 9 May 2018. This, of course, begs the question as to how far the UK need take notice following the results of the EU Referendum. The UK will almost certainly still be an EU Member State at the end of May 2018. The ICO has already said that UK organisations should work on the assumption that the UK will either implement the GDPR or very similar legislation in order to ensure the UK maintains 'adequacy' for EU purposes and can continue to receive EU personal data. Less has been said about NISD (which affects only certain businesses) and it remains to be seen whether and to what extent it takes effect in the UK. A new UK National Cyber Security Centre is set to open in the autumn and given the cross-border nature of many cyber attacks, it is likely that the UK will seek to cooperate with the EU in this field.

GDPR requirements

Security and breach reporting requirements are covered in Articles 32-34 of the GDPR.

Security (Article 32)

Controllers and processors are required to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk. The assessment of what might be appropriate involves considering the context and purposes of the processing as well as the risk of varying likelihood and severity for the rights and freedoms of individuals. Appropriate measures are set out as possibly including:

  • pseudonymisation and encryption;
  • ensuring confidentiality, integrity, availability and resilience of processing systems and services;
  • ability to restore availability and access to personal data in a timely manner in the event of an incident; and
  • the regular testing and evaluating of technical and organisational measures designed to ensure security of data processing.

Controllers and processors are also required to ensure anyone acting under their authority accessing the personal data, does so only in accordance with their instructions. Compliance may (but does not have to) be demonstrated by adherence to an approved code of conduct or certification mechanism.

Breach reporting to the Supervisory Authority (Article 33)

Data controllers are required to report a personal data breach to the competent Supervisory Authority (SA) without undue delay and, where feasible, not later than 72 hours after becoming aware of it unless the personal data breach is unlikely to result in a risk to the rights and freedoms of data subjects. If a notification is made after the 72 hour period has expired, the data controller must explain the reasons for the delay. The notification must include at least:

  • a description of the nature of the breach, including, where possible, the categories and approximate number of data subjects and personal data records concerned;
  • the name and contact details of the relevant Data Protection Officer or contact point;
  • the likely consequences of the data breach; and
  • measures taken or proposed by the controller to address the breach and/or mitigate its effects.

Communication of a personal data breach to the data subject (Article 34)

Where a personal data breach is likely to result in a high risk to the rights and freedoms of a data subject, the controller must communicate the breach to the data subject without undue delay. The communication must describe in clear and plain language, the nature of the breach and at least:

  • the name and contact details of the relevant Data Protection Officer or contact point;
  • the likely consequences of the data breach; and
  • measures taken or proposed by the controller to address the breach and/or mitigate its effects.

There is, however, no requirement to make a notification to the data subject where any of the following conditions have been met:

  • technical and organisational measures have been applied to the personal data which will render it unintelligible to unauthorised persons (such as encryption);
  • the controller has taken steps to ensure the originally high risk is no longer likely to materialise; or
  • to notify each data subject would involve disproportionate effort, in which case a public communication or other method of information is used which would inform the affected data subjects in similarly effective manner.

Where a breach is reported to an SA and not to the data subjects, the SA may require the data controller to notify affected data subjects.

Breach reporting obligations on processors (Article 33)

Data processors are required to notify controllers of a personal data breach without undue delay.

What does this mean for controllers and processors?

Controllers will have been relieved to see that data breach reporting requirements have become more realistic than those proposed under the first draft of the GDPR, as a result of intensive lobbying. The original draft required that all data breaches, no matter how insignificant, to be reported without undue delay and within 24 hours. Notification of data subjects was then also required unless the relevant DPA was satisfied that data subjects had been sufficiently protected by measures such as encryption.

Processors have also seen reporting requirements changed from "immediate" to "without undue delay".

The emphasis placed on the controller's assessment of the situation is to be welcomed but, as with all legislative requirements which include flexibility, there will also be an element of doubt as to when a data breach poses a risk and when such risk is sufficiently serious to require notification of data subjects. Different SAs may also (as they do now) take different approaches.

The best way for organisations to deal with this is, of course, to minimise breaches, but also, to have policies in place to enable staff to assess risk and to be able to demonstrate compliance. As with so much of the GDPR, being able to demonstrate that the proper precautions and steps were taken, will be key (see our top tips for more on this).

Sanctions for non-compliance

Failure to comply with breach reporting requirements under the GDPR will not just result in regulator scrutiny, negative PR and, possibly, in loss of business. There are also very real financial penalties which the regulators have in their armouries for serious failures – up 2% of annual global turnover or 10 million Euros, whichever is higher.

NISD requirements

The Cybersecurity Directive is relevant to you if you are an Essential Service provider or if you are a Digital Service Provider (DSP) i.e. an online marketplace, an online search engine or a cloud services provider. Where sectors are subject to sector-specific Union legal acts relating to information and network security, these will take precedence (e.g. NISD does not apply to telecoms providers as their security is dealt with by the Framework Directive).

NISD is designed to work alongside data protection legislation. It covers ‘natural persons’ which includes companies, whereas data protection law covers only personal data. Regulators must cooperate. As with the GDPR, NISD is intended to have some extra-EU application and will apply to DSPs which are established outside the EU but which offer services within the EU (on more than an incidental and passive basis).

Organisations will be regulated in the Member State of their main establishment which will be where their head office is located. Note that this is a different definition from that used in the GDPR which states that the place of main establishment is presumed to be the data controller’s place of central administration unless the main decision making with regard to the personal data is taken in another Member State.

Where an organisation is subject to NISD but does not have a main establishment in the EU, it must appoint a representative in one of the Member States in which it offers services and it will be subject to regulation in that Member State.

There are exceptions for micro-enterprises and small enterprises as defined by a 2003 EC recommendation.

Operators of essential services

  • Member States are required to identify operators of essential services in categories set out in Annex II with an establishment in their territory by 9 November 2018. These categories include operators of essential services in the energy, transport, financial services (including banks), health and drinking water supply and digital infrastructure (including internet exchange points, domain name system service providers and top level domain name registries). Lists must be reviewed and updated at least every two years.
  • Member States may make their own rules as to how to identify operators of essential services in each sector but this is to be decided against the broad criteria that the entity provides a service essential for the maintenance of critical societal and/or economic activities where the provision of that service depends on network and information systems and an incident to the network and information systems of that service would have significant disruptive effects on its provision. Whether or not a disruption has a significant disruptive effect should take into account the number of users relying on the service, the dependency of other essential service sectors on it, the impact the incident might have, the market share and geographic reach of the entity and its importance in maintaining a sufficient level of service taking into account availability of alternative providers.

Security and notification requirements for operators of essential services

  • Member States must ensure all operators of essential services take appropriate and proportionate technical and organisational measures to manage risks (defined as “any reasonably identifiable circumstances or event having a potential adverse effect on the security of networks and information systems”) posed to the security of networks and information services which they use to deliver their services and to minimise the impact of any network security incidents with a view to ensuring continuity of service.
  • Operators of essential services must notify the competent authority or the CSIRT of incidents having a significant impact on the continuity of the service they supply. Notifications must be made without undue delay and must contain enough information to allow the competent authority or the CSIRT to determine any cross-border impact of the incident. To assess the nature of the incident, the number of affected users, the duration of the incident and the geographical spread of its impact must be taken into account.
  • The public may be informed of an incident by the competent authority or the CSIRT.

Digital Service Providers

DSPs are providers of online marketplaces, online search engines or cloud computing services. These are all defined terms in the Directive:

  • “online marketplace” is a digital service that allows consumers and/or traders to conclude online sales and service contracts with traders either on the online marketplace’s website or on a trader’s website that uses computing services provided by the online marketplace (this includes app stores but excludes price comparison websites);
  • "online search engine” is a digital service that allows users to perform searches of, in principle, all websites or websites in a particular language on the basis of a query on any subject in the form of a keyword, phrase or other input; and returns links in which information related to the requested content can be found;
  • “cloud computing” service is a digital service that enables access to a scalable and elastic pool of shareable computing resources.
  • Hardware manufacturers and software developers are specifically excluded in the recitals.

Security and notification requirements for DSPs

  • DSPs must identify and take appropriate and proportionate technical and organisational measures to manage the risks posed to the security of networks and information systems they use in the context of offering services referred to in Annex III within the Union (slightly unclear what impact of Annex III is as it just repeats list of DSPs). Those measures shall ensure a level of security of those systems appropriate to the risk presented taking into account: security of systems and facilities; incident handling; business continuity management; monitoring, auditing and testing; and compliance with international standards.
  • DSPs must take measures to prevent and minimise the impact of incidents affecting the security of their network and information systems.
  • DSPs must notify incidents having a substantial impact on the provision of a service as referred to in Annex III within the Union to the competent authority or CSIRT. Notifications must contain enough information to allow the notified body to determine the significance of any cross-border impact.
  • In determining the impact of an incident, the number of affected users, particularly those relying on the service to provide their own services, the duration of the incident, its geographical spread, the extent of the disruption to the service and the extent of the impact on economic and societal activities must be taken into account;
  • Where an operator of an essential service relies on the service provided by the DSP, the essential service operator must also be informed. DSPs may also be required to inform the public or the competent authority or CSIRT may do so after consultation with the DSP.
  • The recitals state that the security levels required for DSPs will vary on a case by case basis and they will be subject to a light touch and reactive system of supervision without being subject to general compliance monitoring. Competent authorities should only take action when provided with evidence of non-compliance.

Enforcement

Regulators are given various general powers but Member States are left to legislate on penalties for non-compliance.

What does this mean for those required to notify breaches?

The eagle eyed will have noticed that the GDPR and NISD use different criteria to set out what might be considered to be appropriate technical and organisational measures. However, the intent is broadly the same. An assessment of risk has to be made and appropriate steps need to be taken to prevent that risk from materialising and minimising the damage if it does.

Most organisations caught by the security and breach reporting requirements under NISD, will also be subject to the GDPR. Reporting a breach to the SA under the GDPR will not mean there is no requirement to notify under NISD although it is possible these may be rationalised by SAs in future if they are also appointed as a competent authority under NISD.

  • Identify your role – are you a data controller or processor? Are you an operator of an essential service or a digital service provider?
  • Conduct a risk assessments where appropriate and then act on the results.
  • Ensure it is clear who is responsible for dealing with cyber and data security.
  • Ensure you have up to date security systems such as firewalls, encryption and authentication and test them on a regular basis.
  • Develop a cybersecurity policy – check regularly that it is complied with.
  • Ensure employees receive training on the cybersecurity policy and when to report incidents internally.
  • Restrict access to personal data to those in the company who need to have access to it.
  • Develop a detailed breach response plan including when to notify regulators and individuals as well as how to handle data breaches from a PR perspective.
  • Consider making financial provision to handle any data breaches and taking out insurance to cover data breaches.
  • Keep records of any data breaches, what data was compromised and how the breach was dealt with as well as what steps were taken to ensure that type of breach does not re-occur.
  • Make use of the government's Cyber Essentials scheme and other regulator guidance on cybersecurity and data breaches.