Part 8: Information Security and Breach Management
The GDPR places high importance on the security of Processing. This part of the SWGfL GDPR Guidance focusses on the security requirements of the GDPR, and summarises the measures schools should take to comply with the GDPR and to implement necessary information security provisions.
Important GDPR Definitions
The following definitions are used throughout the GDPR, and throughout the SWGfL GDPR guidance:
- Processing is any operation (including collection, recording, organising, storing, altering, using, and transmitting) performed on Personal Data.
- Personal Data is any information relating to a natural person (called a Data Subject) who can be (directly or indirectly) identified using that information.
- A Data Controller is a person, authority, agency or other body which determines the purposes and the means of Processing.
- A Data Processor is a person, authority, agency or other body which undertakes Processing on behalf of a Data Controller.
What is Information Security?
A simple definition of information security is ‘the process of ensuring that only authorised users have access to accurate and complete information, when access is required’.
There are three elements, often called the ‘CIA Triad’:
Confidentiality:
- Only authorised users can access information and systems.
- Unauthorised users must be prevented from accessing information and systems.
Availability:
- Authorised users have access to information systems when they require it.
- The systems must defend against attempts to prevent access.
Integrity:
- The information is complete and accurate.
- Unauthorised attempts to intercept and change information must be prevented.
Information Security in the GDPR
The GDPR requires both the Data Controller and the Data Processor to implement appropriate technical and organisational measures to ensure an appropriate level of security.
What constitutes appropriate security measures will depend on the risks associated with the Processing, but the GDPR sets out (Article 32) specifically:
- the use of pseudonymisation and encryption;
- the ability to ensure the confidentiality, integrity and availability, as well as resilience, of Processing systems;
- the ability to restore Personal Data in a timely manner if it is lost, damaged or inaccessible; and
- a requirement for regular testing of security measures to ensure their effectiveness.
Pseudonymisation and Encryption
Pseudonymisation is the process through which information that is identifiable becomes de-identifiable: Personal Data within is replaced with artificial data (or pseudonyms). The theory is that, while pseudonymised, the data cannot be used to identify individuals, however when required for lawful Processing, the Data Controller or Data Processor can de-pseudonymise it.
Encryption is the process of applying an ‘encryption algorithm’ (or cipher) to the Personal Data, which converts it from ‘plaintext’ to ‘ciphertext’. The ciphertext is not intelligible, and therefore similarly means that it cannot be used to identify individuals, however when required for lawful Processing, the Data Controller or Data Processor can decrypt it.
The GDPR mentions both pseudonymisation and encryption specifically (where the Data Protection Act 1998 did not), suggesting that it is expected these technologies will be widely used (and indeed that where they are not, and a breach occurs, the sanctions may be more severe).
Ensuring Confidentiality, Integrity and Availability
This is a much wider area than any of the others set out in Article 32 of the GDPR, and is a major link between data protection and information security.
Information security (or InfoSec) requires each of the three elements of the CIA Triad to be addressed:
- Confidentiality could be affected by hackers accessing a school network or system (an unauthorised user has then accessed information and/or systems).
- Integrity could be compromised by an attacker intercepting an email and changing the content on the way to the recipient (the information is then no longer complete and/or accurate).
- Availability could be impacted by a Distributed Denial of Service (DDoS) attack, preventing authorised users accessing the internet (users are then not able to access information systems when they require access).
Schools will need to implement a range of measures (also called ‘controls’) to achieve this, as no single process, person or technology would be sufficient.
Information security controls are typically grouped into three categories:
- Management, or administrative controls (also called procedural controls): including policies, standards, processes, procedures and guidelines.
- Operational, or physical controls: including execution of the management controls, as well as walls, doors, locks, fences, CCTV and other physical security measures.
- Logical, or technical controls: including system-level access controls, authentication and authorisation systems, technological defences and other technical protections.
Ensuring Resilience
The resilience of a Processing system refers to the ability of the Data Controller or Data Processor to:
- continue to operate during a period of disruption; and
- to return the operation to a normal state after the disruption.
Resilience therefore will be achieved through a combination of:
- plans and provisions that harden systems against issues and/or allow for operations to be undertaken on alternative systems if required; and
- preparedness for such issues, and specifically for recovery of systems (including Personal Data) from either backup copies or from the alternative systems employed above.
From an information security perspective, this would be considered partly in the risk analysis and controls required to ensure confidentiality, availability and integrity, and also in a Business Continuity and Disaster Recovery (BCDR) plan.
Business Continuity (BC) refers to the ability of a business to continue important functions and processes during and after a disaster, whereas Disaster Recovery (DR) refers to the technology processes to return the systems and data to a normal operating state.
A BCDR plan should:
- identify important systems;
- identify important processes;
- define continuity options for different issues;
- set objectives for recovery;
- set out backup and restore processes;
- provide step-by-step procedures for different activities and scenarios;
- set out a communications plan; and
- list contact details for relevant parties.
Restoration of Personal Data
As an extension to the resilience requirements and BCDR plan, the GDPR states that it should be possible to restore the availability and access to Personal Data in a timely manner in the event of a physical or technical incident.
To comply with this, schools will need robust and reliable backup and restore processes.
Regular Testing of Security Measures
The GDPR also requires that Data Controllers and Data Processors have a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of Processing.
Given that the measures will be a combination of the controls:
- management, or administrative controls (also called procedural controls);
- operational, or physical controls; and
- logical, or technical controls,
the testing, assessing and evaluating process will need to cover these three areas. It is unlikely that a test for one type of control (e.g. the effectiveness of physical security controls such as doors and locks) would be applicable to another (e.g. the extent to which the antivirus solution protects the school from malware).
Schools will therefore need to plan and perform a series of different tests, assessments and evaluations to comply with this. In some cases, external support may be required.
Schools must ensure the Confidentiality, Integrity and Availability of data and systems, including:
|
Breach Management
The accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to data is a Data Breach. Where that data is Personal Data, it is a Personal Data Breach.
GDPR (Article 33) requires that, where a Personal Data Breach takes place, the Data Controller shall notify the ICO without undue delay and within 72 hours of becoming aware of it.
Where a Personal Data Breach affects a Data Processor (rather than a Data Controller), the Data Processor shall notify the Data Controller without undue delay.
Detecting a Breach
For this to be possible, the first thing that schools need to be capable of doing is detecting a Personal Data Breach. Given that a breach includes unintended loss, alteration, disclosure or access to data, it is possible that it could be:
- caused by malicious or non-malicious activity; and
- from internal or external sources.
A malicious internal threat could be a member of staff or a learner that wishes to cause disruption to school operations by exfiltration of data or launching a DDoS attack, while a malicious external threat could be a hacker or ransomware attempting to compromise school systems or access data.
A non-malicious internal threat could be a member of administration staff accidentally emailing Personal Data to the wrong recipient or without appropriate security. Generally there are no 'non-malicious external threats', however disasters like fire or flood could lead to destruction of data, and may be considered as other types of external threat.
Schools should consider the extent to which issues like this could be detected. For example:
| Threat Type | Threat Example | GDPR Article 33 Element |
| Malicious internal threat | Member of staff copies data, including Personal Data, to USB storage and removes it from school | Unauthorised access to data |
| Malicious external threat | Ransomware infects school systems and results in Personal Data being inaccessible by school | Unlawful loss of data |
| Non-malicious internal threat | Member of staff send data, including Personal Data, by email to the wrong recipient | Accidental disclosure of data |
| Other external threat | Fire destroys part of school, resulting in servers (and Personal Data stored on them) being destroyed | Accidental loss of data |
Whilst the ransomware and the fire would likely be detected quickly, the unauthorised data copying and email mistake may be more difficult to detect.
Breaches and Data Subjects
Though Data Controllers are required to notify the ICO of Personal Data Breaches within 72 hours of detection (with limited exceptions), the GDPR states (Article 34) that it is only necessary to notify Data Subjects where there is a high risk to their rights and freedoms.
The GDPR further states that it is not necessary to notify Data Subjects if:
- the Personal Data is unintelligible (e.g. encrypted); or
- the Data Controller has taken measures to minimise the likelihood of the high risk materialising.
Where notification is required, it is to be without undue delay, and describe in clear and plain language the nature of the Personal Data Breach, Data Controller contact details, the likely consequences of the Data Breach, and the measures the Data Controller is taking.
In determining whether Processing might represent a high risk to the rights and freedoms of Data Subjects, a Data Protection Impact Assessment is undertaken.
Schools must notify the ICO of any Personal Data Breach within 72 hours, and must notify Data Subjects (if there is a high risk to them) without undue delay. |