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 requirements and breach reporting requirements and introduces hefty sanctions for non-compliance.

Incoming EU legislation

The General Data Protection Regulation 2016 (GDPR) will apply from 25 May 2018. The Network Information Systems Directive 2016 (NISD or Cybersecurity Directive) must be implemented into UK law by 9 May 2018. While the GDPR has a broad reach, NISD only impacts on certain businesses. In terms of cybersecurity, the GDPR focuses on protecting personal data, whereas NISD is more concerned with network and systems security and interruption to service. Businesses caught by NISD will also have to comply with the GDPR in respect of any personal data.

GDPR and NISD at a glance


Sanctions for non-compliance of breach reporting provisions under the GDPR can be up to the higher of 4% of annual global turnover or €20m, but a data breach may trigger more than one provision of the GDPR and fines can be cumulative (although will be limited to the higher applicable bracket in relation to a single incident). A data breach may, for example, incur the highest level of fines in relation to related failure to take appropriate technical and organisational measures, and also, the lower level (up to the higher of 2% of annual global turnover or €10m) for failure to make the appropriate breach notification.

In addition, sanctions under NISD can total £17m in the UK (Member States have discretion to set maximum penalties).

While regulators are anxious to reassure businesses that these levels of fines will only be imposed for the most egregious breaches, the new enforcement regime is not to be taken lightly.

GDPR requirements

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


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.

What is a breach?

The Article 29 Working Party (WP29) guidance identifies three types of breach. Some breaches may engage all three elements:

  • confidentiality breach – unauthorised or accidental disclosure of or access to personal data;
  • integrity breach – unauthorised or accidental alteration;
  • availability breach – accidental or unauthorised loss of access to or destruction of data (e.g. by a power cut or systems failure).

All breaches must be recorded alongside the decision making process engaged to decide whether or not to report the breach. Only breaches which are likely to result in a risk to the rights and freedoms of data subjects have to be reported to the Supervisory Authority (SA). The WP29 gives examples of breaches which are not reportable, for example, where encrypted data which remains secure is taken. However, it also suggests it is better to over report than to under report; there are no sanctions for reporting something which turns out to be low risk.

Timing of breach reporting to the SA

Data controllers are required to report a personal data breach to the competent 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 WP29 guidance also suggests that the point at which the data controller becomes aware of a breach is when the controller has a reasonable degree of certainty that a security incident leading to a personal data breach has taken place. This means there may be a short period of investigation during which the controller is not regarded as being aware and before the clock starts ticking. Where, however, a data processor becomes aware of a breach, the data controller is deemed to have knowledge so controllers should ensure processors are contractually obliged to inform them of any breach immediately.

What should be in the notification?

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.

Precise figures may not be available and the guidance suggests that a tiered notification may be appropriate where it can be justified. In addition, batch notifications can be made where.

Which SA to notify

The WP29 guidance advises organisations to identify their Lead SA as soon as possible. If a reportable breach occurs, the organisation should notify the Lead SA where there is one. If there is no Lead SA, notification should be made to the SA where the breach has taken place. The WP29 recommends that SAs in affected Member States are also informed but if an organisation chooses not to do this, it should, at least, provide its Lead SA with a list of Member States where data subjects are affected by the breach.

Communication of a personal data breach to the data subject

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 – which means as soon as possible. This is a higher threshold to meet than the reporting requirement to SAs so it is possible that a breach may need to be reported to the SA but not to data subjects. Where a breach is reported to an SA and not to the data subjects, the SA may subsequently require the data controller to notify affected data subjects.

There is 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 can be used which would inform the affected data subjects in similarly effective manner.

How to notify data subjects

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.

The WP29 guidance underlines that transparency is key and that includes using appropriate language so more than one type of notification may be needed depending on the intended audience. While in theory, every affected data subject should be notified individually, where this involves disproportionate effort, a group notification can be used but the WP29 is clear that this should not take the form of a press release or corporate blog – the notification has to be active and may have to be made through multiple avenues.

Breach reporting obligations on processors

Data processors are required to notify controllers of a personal data breach without undue delay, which effectively means immediately.

What does this mean for controllers and processors?

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. This should sit alongside a breach response plan so that it is entirely clear what procedure should be followed in the event of a breach.

As with so much of the GDPR, being able to demonstrate that the proper precautions and steps were taken, will be key.

NISD requirements

NISD has a different objective to the GDPR. Rather than focusing on the security of personal data, it deals with the security of network and information systems.

NISD is a minimum harmonisation Directive which means, not only that Member States have to produce implementing legislation, but also that they have discretion to go above and beyond what the Directive says. We are, therefore, looking (to a certain extent) at fragmented implementation across the EU although multi-jurisdictional companies can take comfort from the fact that they will be regulated in the place of their “main establishment”.

The UK has not yet published its implementing legislation but the government held a consultation in autumn 2017 and published its response to the consultation (Response) in February 2018 so we have a reasonable idea of its intentions.

Who has to comply with NISD?

NISD is relevant to you if you are an Operator of an Essential Service (OES) 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. 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).

How will organisations be regulated?

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.

Incident response will be separate from incident reporting. In the UK, all NIS incidents will be reported to the relevant CA who will log the incident and decide whether follow up investigation is required. The National Cyber Security Centre (NCSC) will be the UK's Computer Security Incident Response Team (CSIRT). Voluntary reporting can be made to either the CA or the NSCS. Incident response support on cyber related incidents (e.g. DDoS attacks, malware, hacking) will be provided by the NCSC where required. CAs or possibly the relevant Lead Government Department will provide support for non-cyber or resilience incidents (e.g. hardware failure, fire, physical damage).

Operators of essential services

  • Member States are required to identify OESs in categories set out in Annex II of the Response 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. The UK has published its list of OESs and their Competent Authorities (CAs) in the Response.
  • Member States may make their own rules as to how to identify OESs 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 OESs 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.
  • OESs 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 within 72 hours in the UK) 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 CA or the CSIRT.

Who is a Digital Service Provider (DSP)?

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; and
  • There are also exceptions for micro-enterprises and small enterprises (i.e. fewer than 50 employees and an annual turnover or balance sheet below €10 million) from being classed as DSPs.

The UK government has said that it will mirror the Directive's language defining DSPs in its implementing legislation but will provide the following clarifications through guidance:

Online marketplaces

  • An online marketplace should be defined as a platform that acts as an intermediary between buyers and sellers, facilitating the sale of goods or services, i.e. a service that enables consumers and traders to conclude online sales or service contracts with traders, and it represents the final destination for the conclusion of those contracts.
  • Sites that redirect users to other services to make the final contract (e.g. price comparison sites), or that only connect buyers and sellers to trade with each other (e.g. classified advert sites), or that only sell directly to consumers on behalf of themselves (e.g. online retailers), are not in scope.

Online search engines

  • ‘online search engine’ means a digital service that allows users to perform searches of the ‘public parts of the worldwide web’ 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.
  • Where a site offers search engine facilities as outlined above, but those facilities are powered by another search engine, then the underlying search engine is required to meet the requirements of the NIS Directive. Internal organisational search engines, that do not facilitate external searches of the internet are not in scope.

Cloud computing services

The Government considers that this primarily (but not exclusively) includes Digital Service Providers that provide public cloud services of the following nature:

  • ‘cloud computing service’ means any Digital Service Provider that enables access to a scalable and elastic pool of shareable physical or virtual resources.
    • “‘Infrastructure as a Service’ (IaaS) - the delivery of virtualised computing resource as a service across a network connection, specifically hardware – or computing infrastructure - delivered as a service;
    • ‘Platform as a Service’ (PaaS) - services that provide developers with environments on which they can build applications that are delivered over the internet, often through a web browser; and
    • Software as a Service’ (SaaS), provided the resources available to the customer through that software are changeable in an elastic and scalable way. The Government considers that this would likely exclude most online gaming, entertainment or VOIP services, as the resources available to the user are not scalable, but may include services such as email or online storage providers, where the resources are scaleable.”

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 (it is 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 CA 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 OES relies on the service provided by the DSP, the OES 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.


Regulators are given various general powers but Member States are left to legislate on penalties for non-compliance. There has been a lot of concern around the potential for ‘double jeopardy’ in terms of fines under NISD and the GDPR. The UK government confirms that it intends to amend the proposed penalty regime to introduce a maximum financial penalty of £17m for all contraventions under NISD. It cannot, however, remove the possibility of sanctions relating to different aspects of the wrongdoing under other applicable law, including the GDPR.

Note that NISD will not apply directly to suppliers to OES’s or DSPs and enforcement will not take place down the supply chain. OES’s and DSPs will be responsible for ensuring that their suppliers have appropriate measures in place to ensure they are compliant.

Concerns have been raised that different CAs will take different views about enforcement. The government says that while it will encourage cooperation and common procedures, divergence may be appropriate in order to reflect the needs or different sectors.

CAs will be required to take a reasonable and proportionate approach to enforcement. The government recognises that the process of improving network security will take a number of years and is anticipating a collaborative approach by stakeholders.

OESs will be given time to implement the required security measures, and the main priority of CAs in the first year will be information gathering. OESs will be expected to begin analysing their existing systems and security in order to assess what needs to be done.

The recitals to NISD 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. CAs should only take action when provided with evidence of non-compliance.

The role of the NCSC

In newly published guidance, the NCSC makes it clear that it does not play a regulatory role. It does, however, have a role in providing support and guidance. It will also take on the following roles:

  • Single Point of Contact (SPOC) – the NCSC will act as the contact point for engagement with EU partners on NISD, coordinating requests for action or information and submitting annual incident statistics.
  • CSIRT (Computer Security Incident Response Team) - incidents that are believed to be reportable under NISD should be reported to the appropriate CA. Where they are identified or suspected of having a cyber security aspect, the operator should also contact NCSC for advice and support on these aspects.
  • Technical Authority on Cyber Security - the NCSC will support OESs and CAs with cyber security advice and guidance and act as a source of technical expertise. It may work with OESs and CAs to tailor some generic guidance to individual sectors if necessary.

The NCSC is intending to publish a Cyber Assessment Framework – a systematic means of assessing whether an OES is complying with NISD, in April 2018. In the meantime, it has published guidance on complying with NISD. The advice is based on the 14 Principles set out by the government in its consultation and response to the consultation.

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 DSPs will be regulated by the ICO under both sets of legislation.

To help minimise risk and prepare for the new requirements, see our checklists: