Quality Assurance Handbook

9.3 Data Subject Erasure Request Policy

9.3.1 Purpose

Scope

Responsibilities and Definitions

Procedure

Documentation

• Records of communications relating to a subject access request (Retained for 5 years)
• Records of communications resulting in an action to cease processing personal data (Retained for 5 years)

Appendices

• Provides all the information they require to locate the information the person wants;
• Provides sufficient information to verify the data subject’s identity.

It is unlikely that the first contact from the data subject will provide all the relevant information, in which case the Information Security Manager must write to the data subject requesting this.

Once the Information Security Manager has received all the information they need and sufficient information to verify the data subject’s identity, they have one month to provide the information requested.

Appendix 2 How to correctly identify a Data Subject

Before disclosing any personal information, the Information Security Manager must verify the identity of the data subject.

Whilst it is important that ICE GROUP does not send copies of personal information to people who are not the data subject, they must not appear obstructive. The DPA requires ICE GROUP to take “reasonable measures” to verify the identity of a data subject. The Information Security Manager should keep a record of what measures they take.

If the evidence is insufficient and requires further verification of the data subject’s identity, there are 2 options:

1. Telephone the individual and based on the information held about them ask two questions so as to confirm their identity.
2. Write to the individual and ask them to send the Information Security Manager a certified copy of their passport, driving licence or birth certificate (this option will take longer and it is also possible that the individual does not have a passport or drivers licence).

Appendix 3 Where to look for personal information

Based on their knowledge of the business area, the Information Security Manager should decide where ‘personal data’ about the individual concerned might be held and locate that information. They may need to search central filing systems electronic and manual, personnel records, shared drives, the Intranet, and/or private filing systems of particular individuals. If necessary, they must also ask colleagues to search their personal drives and e–mail accounts.

If staff are aware of other business areas that might also hold information about the person concerned, please tell the Information Security Manager as soon as possible so that they can arrange for these areas to be searched.

Appendix 4 Howto screen information & what can and cannot be disclosed as a result of a DSAR

Once the Information Security Manager has collected together the information, we hold about a data subject they must examine it in detail to establish if it should be disclosed. This must be done on a case-by-case basis for each individual piece of information. In some cases, they might have to disclose only parts of particular documents.

1. Check that the record is actually about the person concerned and not about someone else with the same name. Just because a record contains somebody’s names does not always mean that it is about them. For example, an e-mail might carry the subject line “Meeting about John Smith” but if the e-mail only contains details about whether people can attend the meeting the e-mail is not about John Smith. The Information Security Manager should only print out records/documents/e-mails which are about the person making the subject access request.
2. Screen out any duplicate records. For example, if there has been an e-mail exchange with some colleagues, the Information Security Manager only needs to print out the last e-mail in the exchange if copies of all the other e-mails are part of the last e-mail.
3. If a record was created by a member of staff acting in a private rather than an official capacity, only exceptional circumstances would justify its disclosure without their consent.If they are not prepared to disclose the record, do not disclose it. Please note however that ICE Group’s IT policies do not permit personal use of the computing facilities.
4. The Information Security Manager should only disclose information which is about the person making the subject access request. Where a document contains personal data about a number of individuals, including the data subject, they should not disclose the information about the third parties to the data subject. If the record is primarily about the data subject, with incidental information about others, they should redact the third-partyinformation.If the record is primarily about third parties withhold it if redacting is not possible. Alternatively, contact the third party to obtain consent to disclose the document if possible. Ensure that all correspondence in these matters is logged in the relevant folder in the ICT storage system (see appendix 5).
5. The records may contain correspondence and comments about the data subject from a number of parties, including private individuals, external individuals acting in an official capacity, and ICE Group staff. In these cases, we are required to balance the interests of the third party against the interests of the data subject and often omit or redact third party information.
6. Do not disclose information which would prejudice the prevention or detection of a crime. For example, if the Gardaí informed us that a member of staff is under investigation, but the member of staff did not know this, then we should not provide that information to the member of staff whilst the investigation is in progress. However, if the investigation is closed or if the member of staff has been informed that there is an investigation underway, then the information should be disclosed in response to a subject access request.
7. We should not disclose any records which contain advice from our lawyers, where we are asking for legal advice or which were written as part of obtaining legal advice.

Do not disclose information which is being used, or may be used in future, in negotiations with the data subject if the information gives away our negotiating position and disclosing the information would weaken that negotiating position.

The exemptions identified above are those most likely to apply to information held by the ICE GROUP. There are others and it is good working practice to research all Data Protection Act exemptions before responding to a DSAR (see ICO website for up to date information regarding exemptions).

As the Information Security Manager puts the information together, they may discover material which does not reflect favourably on us. For example, they may find documents which show that standard procedures have not been followed, or documents which may cause offence to the data subject. These documents must be disclosed. However, the Information Security Manager should bring their contents to the attention of the relevant manager and ensure that appropriate action is taken to address any issues they raise.

Staff must not destroy or refuse to disclose records. This is a criminal offence if it is done after you know a subject access request has been made.

Once the Information Security Manager has identified all the information that can be sent in response to a DSAR, one final review of this information as a collection must be made. This is to offset the risks often discovered by aggregating information. For example, the Information Security Manager may have identified that all the information they intend to release is unrestricted in its nature. However, once aggregated there is an inherent risk that additional information could be disclosed or at least interpreted. This must be taken into consideration before the final response is made.

Appendix 5 How to log the requests and responses

The Information Security Manager should logSubject Access Requests in the ICT storage system using the request for information log spreadsheet. Complete the information requested into the spreadsheet and allocate the next available unique reference number to the DSAR from the spreadsheet. This number should be used in all correspondence.

Create a folder for each DSAR –the filename should be made up from the reference number and surname of the applicant e.g. DSR001 –Smith. Each DSAR file should include the following;

• Copies of the correspondence between the Information Security Manager and the data subject and between the Information Security Manager and any other parties.
• A record of any telephone conversation used to verify the identity of the data subject.
• A record of the Information Security Manager’s decisions and how theycame to those decisions.
• Copies of the information sent to the data subject, for example if the information was anonymised keep a copy of the anonymisedor redacted version that was sent.

The folder should be kept for 5 years and then securely destroyed within ICE Group’s records management programme.

Appendix 6 Subject Access Request Template

I understand that you wish to exercise your rights under the Data Protection Act 2018 to:

[Please set out which right you are exercising]

ICE Group are obliged under the Data Protection Act 2018 to satisfy ourselves as to the identity of the person making the request. Accordingly, we require you to provide suitable proof of your identity, such as your original passport or a copy certified by a solicitor of your original passport, plus original utility bills from at least two service providers to your home address.

Also, in order to assist the ICE Group to locate the information which you are seeking in a timely and efficient manner, you should provide as much information as possible as to the type of data which you are seeking, the period during which the data has been held, the persons or departments who are likely to be holding this data and the sites and/or specific locations where such persons or departments are based.

Please send the completed form and any necessary evidence (as appropriate) to the Information Security Manager, ICE Group. We will endeavour to respond to your request as soon as reasonably practicable.

Regards,

Information Security Manager

Policy Compliance

Compliance Measurement

The ICT Dept. and/or Management will verify compliance to this policy through various methods, including but not limited to, periodic walk-throughs, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner.

Exceptions

Any exception to the policy must be approved by the ICT Dept. and/or Management in advance.

Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

9.4 Data Breach Policy

9.4.1 Purpose

Please note that General Data Protection Regulation (GDPR) is a Shared Service provided to Western Management Centre (WMC) by its parent company ICE Group.

All of the departments/companies within ICE Group can use these Shared Services as required. The main benefit of Shared Services relates to cost and efficiency management. From an operational perspective, the use of Shared Services avoids duplication and also can avoid potential different outcomes occurring.

Recital 37 of the EU General Data Protection Regulation 2016/679 states that a ‘group of undertakings should cover a controlling undertaking and its controlled undertakings, whereby the controlling undertaking should be the undertaking which can exert a dominant influence over the other undertakings by virtue, for example, of ownership, financial participation or the rules which govern it or the power to have personal data protection rules implemented. An undertaking which controls the processing of personal data in undertakings affiliated to it should be regarded, together with those undertakings, as a group of undertakings.’

ICE Group must have a robust and systematic process for responding to reported data security Incidents and Breaches. This policy is designed to standardize the ICE Group-wide response to any reported Breach or Incident and ensure that they are appropriately logged and managed in accordance with best practice guidelines. Standardised processes and procedures help to ensure ICE Group can act responsibly, respond effectively, and protect its information assets to the extent possible.

Overview

Data breaches are increasingly common occurrences whether caused through human error or malicious intent. ICE Group operations rely on the proper use of Confidential Information and Personally Identifiable Information (PII) on a daily basis. Managing risk and responding in an organized way to Incidents and Breaches is key to operations and required by Colorado state law.

Scope

This policy applies to all ICE Group staff.

Policy

General Information

A ‘Data Security Incident’ or ‘Incident’ shall mean an accidental or deliberate event that results in or constitutes an imminent threat of the unauthorized access, loss, disclosure, modification, disruption, or destruction of communication or information resources of ICE Group.
Common examples of Data Security Incidents include, but are not limited to, any of the following:

• Successful attempts to gain unauthorized access to an ICE Group system or Student or Educator PII regardless of where such information is located
• Unwanted disruption or denial of service
• The unauthorized use of an ICE Group system for the processing or storage of Confidential Information or PII
• Changes to ICE Group system hardware, firmware, or software characteristics without ICE Group’s knowledge, instruction, or consent
• Loss or theft of equipment where Confidential Information or PII is stored
• Unforeseen circumstances such as a fire or flood that could lead to the loss or misuse of Confidential Information or PII
• Human error involving the loss or mistaken transmission of Confidential Information or PII
• Hacking, social engineering, phishing, or other subversive attacks where information is obtained by deceitful practice

A “Data Security Breach” or “Breach” is any Incident where ICE Group cannot put in place controls or take action to reasonably prevent the misuse of Confidential Information or PII. A Breach is also an Incident where data has been misused.

Adopting a standardized and consistent approach to Incident management shall ensure that:

• Incidents are reported in a timely manner and can be properly investigated
• Incidents are handled by appropriately authorized and skilled personnel
• Appropriate levels of management are involved in response management
• Incidents are recorded and documented
• Organisational impacts are understood, and action is taken to prevent further damage
• Evidence is gathered, recorded, and maintained in a form that will withstand internal and external scrutiny
• External agencies, customers, and data users are informed as required
• Incidents are dealt with in a timely manner and normal operations are restored
• Incidents are reviewed to identify improvements in policies and procedures

Incidents can occur locally, in the cloud, or through third party service providers. Reporting and management of Incidents shall occur similarly. Third party providers shall also be governed by contract terms and liability as defined in their operational agreements.

Any contract breach that results in the misuse or unauthorized access to PII by a Service Contract Provider must be handled according to the General Data Protection Regulations.

Data Classifications

Incidents vary in impact and risk depending on a number of mitigating factors including the content and quantity of the data involved. It is critically important that ICE Group management respond quickly and identify the data classification of the Incident. This allows staff to respond accordingly in a timely and thorough manner.

All reported Incidents shall be classified as below in order to assess risk and approaches to mitigate the situation. Data classification shall refer to the following ICE Group data categories:

Public Data – Information intended for public and community use or information that can be made public without any negative impact on ICE Group or its customers. Student PII shall never be considered public data unless the data is Directory Information as defined by ICE Group policy.

Confidential/Internal Data – Information of a more sensitive nature to the business and educational operations of ICE Group. This data represents basic intellectual capital, applications, and general knowledge. Access shall be limited to only those people that need to know as part of their role within ICE Group. Employee and Educator PII (with the exception of PPSNs, financial information, or other critical information) falls within this classification.

Restricted/Highly Confidential Data- Information that, if breached, causes significant damage to ICE Group operations, reputation, and/or business continuity. Access to this information should be highly restricted. Student PII falls into this category of data. Employee or Educator Financial Information, Social Security Numbers, and other critical information also fall into this classification.

Incident Reporting (Incl. GDPR Report)

The following process shall be followed when responding to a suspected Incident:

• Reporting and the ensuing investigation must be prioritized.
• Confirmed or suspected Incidents shall be reported promptly to the Management. A formal report shall be filed that includes full and accurate details of the Incident including who is reporting the Incident and what classification of data is involved.
• Once an Incident is reported, the Information Security Team shall conduct an assessment to establish the severity of the Incident, next steps in response, and potential remedies and solutions. Based on this assessment, the Information Security Team shall determine if this Incident remains an Incident or if it needs to be categorized as a Breach.
• All Incidents and Breaches will be centrally logged and documented to ensure appropriate documentation, oversight, and consistency in response, management, and reporting.
• All Data Breaches relating to PII must be reported to the Data Protection Commission within 72 hours of the Breach being discovered. When reporting a Breach, the GDPR says you must provide:
  a) a description of the nature of the personal data breach including, where possible:
  b) the categories and approximate number of individuals concerned; and
  c) the categories and approximate number of personal data records concerned;
  d) the name and contact details of the data protection officer (if your organisation has one) or other contact point where more information can be obtained;
  e) a description of the likely consequences of the personal data breach; and
  f) a description of the measures taken, or proposed to be taken, to deal with the personal data breach, including, where appropriate, the measures taken to mitigate any possible adverse effects.
  g) The ICT team have a template report.

If a breach is likely to result in a high risk to the rights and freedoms of individuals, those concerned must be informed without undue delay
a) Describe the nature of the personal data breach and, at least:
b) the name and contact details for a point of contact where more information can be obtained;
c) a description of the likely consequences of the personal data breach; and a description of the measures taken, or proposed to be taken, to deal with the personal data breach and including, where appropriate, of the measures taken to mitigate any possible adverse effects.

• The GDPR recognises that it will not always be possible to investigate a breach fully within 72 hours to understand exactly what has happened and what needs to be done to mitigate it. Article 33(4) allows you to provide the required information in phases, as long as this is done without undue further delay.
• If ICE Group is acting as a data processor, the requirements on breach reporting should be detailed in the contract between ICE Group and the Data Controller, and vice versa (required under Article 28).

Classification

Data Breaches or Incidents shall be classified as follows:

Critical/Major Breach or Incident – Incidents or Breaches in this category deal with Confidential Information or PII and are on a large scale (ICE Group-wide). All Incidents or Breaches involving Student PII will be classified as Critical or Major. They typically have the following attributes:

• Any Incident that has been determined to be a Breach
  Significant Confidential Information or PII loss, potential for lack of business continuity, ICE Group exposure, or irreversible consequences are imminent
• Negative media coverage is likely, and exposure is high
  Legal or contractual remedies may be required
• Requires significant reporting beyond normal operating procedures
• Any breach of contract that involves the misuse or unauthorized access to PII by a Service Contract Provider

Moderately Critical/Serious Incident – Breaches or Incidents in this category typically deal with Confidential Information and are on a medium scale (e.g. <100 users on the internal network, application or database related, limited exposure). Incidents in this category typically have the following attributes:

• Risk to the ICE Group is moderate
• Third party service provider and subcontractors may be involved
• Data loss is possible but localized/compartmentalized, potential for limited business continuity losses, and minimized ICE Group exposure
• Significant user inconvenience is likely
• Service outages are likely while the breach is addressed
• Negative media coverage is possible but exposure is limited
• Disclosure of Educator or Employee PII is contained and manageable

Low Criticality/Minor Incident – Incidents in this category typically deal with personal or internal data and are on a small or individualized scale (e.g. <10 users on the internal network, personal or mobile device related). Incidents in this category typically have the following attributes:

• Risk to the ICE Group is low
• User inconvenience is likely but not ICE Group damaging
• Internal data released but data is not student, employee, or confidential in nature
• Loss of data is totally contained on encrypted hardware
• Incident can be addressed through normal support channels

Incident Response

Management response to any reported Incident shall involve the following activities:

Assess, Contain and Recover Data

All security Incidents shall have immediate analysis of the Incident and an Incident report completed by the Information Security Team or their designee. This analysis shall include a determination of whether this Incident should be characterized as a Breach. This analysis shall be documented and shared with the HR Manager, the affected parties, and any other relevant stakeholders. At a minimum, the Information Security Team shall:

Assess Risk and Incident Scope

All Incidents or Breaches shall have a risk and scope analysis completed by the Information Security Team or their designee. This analysis shall be documented and shared with the Information Security Team, the affected parties, and any other relevant stakeholders. At a minimum, the Information Security Team shall:

Notification and Incident Communications

Each security Incident or Breach determined to be ‘moderately critical’ or ‘critical’ shall have communication plans documented by the Management Senior Leadership, and their designees to appropriately manage the Incident and communicate progress on its resolution to all effected stakeholders. At a minimum, the Information Security Team shall:

Post-mortem Evaluation and Response

Each Incident or Breach determined to be “moderately critical” or “critical” shall have a post-mortem analysis completed by the Information Security Team and their designees to appropriately document, analyse, and make recommendations on ways to limit risk and exposure in the future. At a minimum, the Information Security Team shall:

Incidents or Breaches. An activity log recording the timeline of Incident management shall also be completed. Reporting and documentation shall be filed and managed through the office of the Information Security Team. Each of these four elements shall be conducted as appropriate for all qualifying

Audit Controls and Management

On-demand documented procedures and evidence of practice should be in place for this operational policy. Appropriate audit controls and management practice examples are as follows:

• Archival completed Incident Reports demonstrating compliance with reporting, communication and follow-through
• Executed communication plans for Incident management
• Evidence of cross-departmental communication throughout the analysis, response and post-mortem processes

Policy Compliance

Compliance Measurement

The ICT Dept. and/or Management will verify compliance to this policy through various methods, including but not limited to, periodic walk-throughs, video monitoring, business tool reports, internal and external audits, and feedback to the policy owner.

Exceptions

Any exception to the policy must be approved by the ICT Dept. and/or Management in advance.

Non-Compliance

An employee found to have violated this policy may be subject to disciplinary action, up to and including termination of employment.

Failing to notify a breach when required to do so can result in a significant fine up to 10 million euros or 2 per cent of your global turnover. The fine can be combined the DPC’s other corrective powers under Article 58. It is vital to follow the breach reporting policy and procedure in place to ensure ICE Group detect and can notify a breach, on time; and provide the necessary details to all relevant parties.