Privacy statement & Legal Notices
GDPR access request policy
1 Introduction
1.1 Naigai Nitto Logistics (Europe) Ltd. (the ‘Company’) holds personal data (or information) about job applicants, employees, clients, customers, suppliers, business contacts and other individuals for a variety of business purposes.
1.2 Under the General Data Protection Regulation (‘GDPR’), individuals (known as ‘data subjects’) have a general right to request confirmation that we process their data, access to personal information or data that we hold or process about them and certain other information contained in our privacy notice, subject to certain exceptions. These requests are known as ‘subject access requests’.
1.3 The Data Protection Manager is Keigo Kato and is responsible for all data protection matters.
1.4 The Data Protection Manager is responsible for ensuring:
1.4.1 hat all subject access requests are dealt with in accordance with the GDPR; and
1.4.2 that all staff have an understanding of the GDPR in relation to subject access requests and their personal responsibilities in complying with the relevant aspects of the GDPR.
1.5 This policy provides guidance for staff members on how subject access requests should be handled and is intended for internal use. It is not a privacy policy or statement and is not to be made routinely available to third parties.
1.6 This policy is aimed primarily at those members of staff who are authorised to handle subject access requests. For other staff members, it provides guidance on:
1.6.1 what to do if you receive a subject access request (see paragraph 2 below); and
1.6.2 how to decide whether a request for information is a subject access request (see paragraph 3 below).
1.7 Failure to comply with the GDPR puts both staff and the Company at risk, and so the Company takes compliance with this policy very seriously. Failure to comply with any
requirement of the policy may lead to disciplinary action, which may result in dismissal.
1.8 If you have any questions regarding this policy, please contact the Data Protection Manager.
1.2 Under the General Data Protection Regulation (‘GDPR’), individuals (known as ‘data subjects’) have a general right to request confirmation that we process their data, access to personal information or data that we hold or process about them and certain other information contained in our privacy notice, subject to certain exceptions. These requests are known as ‘subject access requests’.
1.3 The Data Protection Manager is Keigo Kato and is responsible for all data protection matters.
1.4 The Data Protection Manager is responsible for ensuring:
1.4.1 hat all subject access requests are dealt with in accordance with the GDPR; and
1.4.2 that all staff have an understanding of the GDPR in relation to subject access requests and their personal responsibilities in complying with the relevant aspects of the GDPR.
1.5 This policy provides guidance for staff members on how subject access requests should be handled and is intended for internal use. It is not a privacy policy or statement and is not to be made routinely available to third parties.
1.6 This policy is aimed primarily at those members of staff who are authorised to handle subject access requests. For other staff members, it provides guidance on:
1.6.1 what to do if you receive a subject access request (see paragraph 2 below); and
1.6.2 how to decide whether a request for information is a subject access request (see paragraph 3 below).
1.7 Failure to comply with the GDPR puts both staff and the Company at risk, and so the Company takes compliance with this policy very seriously. Failure to comply with any
requirement of the policy may lead to disciplinary action, which may result in dismissal.
1.8 If you have any questions regarding this policy, please contact the Data Protection Manager.
2 Receiving a subject access request (non-authorised staff)
2.1 If you receive a subject access request and you are not authorised to handle it, you must immediately take the steps set out in paragraphs 2.3 (request received by email) or 2.4 (request received by letter) or 2.5 (request received orally). There are limited timescales within which we must respond to a request and any delay could result in our failing to meet those timescales, which could lead to enforcement action by the Information Commissioner and/or legal action by the affected individual.
2.2 For information on what amounts to a subject access request, see paragraph 3 below. If you are in any way unsure as to whether a request for information is a subject access request, please contact the Data Protection Manager.
2.3 If you receive a subject access request by e-mail, you must immediately forward the request to the Data Protection Manager at this e-mail address: keigo.kato.uk@naigainitto.com.
2.4 If you receive a subject access request by letter you must:
2.4.1 scan the letter;
2.4.2 send the original to the Data Protection Manager; and
2.4.3 send a scanned copy of the letter by e-mail.
2.5 If you receive a subject access request by telephone or in person you must:
2.5.1 make a detailed note of the request (including the data subject’s contact details) and if possible confirm the detail of the request with the data subject;
2.5.2 send the note of the request by e-mail to the Data Protection Manager.
2.6 You will receive confirmation when the request has been received by the Data Protection Manager. If you do not receive such confirmation, you should contact the Data Protection Manager to confirm safe receipt.
2.7 You must not take any other action in relation to the data access request unless the Data Protection Manager has authorised you to do so.
2.2 For information on what amounts to a subject access request, see paragraph 3 below. If you are in any way unsure as to whether a request for information is a subject access request, please contact the Data Protection Manager.
2.3 If you receive a subject access request by e-mail, you must immediately forward the request to the Data Protection Manager at this e-mail address: keigo.kato.uk@naigainitto.com.
2.4 If you receive a subject access request by letter you must:
2.4.1 scan the letter;
2.4.2 send the original to the Data Protection Manager; and
2.4.3 send a scanned copy of the letter by e-mail.
2.5 If you receive a subject access request by telephone or in person you must:
2.5.1 make a detailed note of the request (including the data subject’s contact details) and if possible confirm the detail of the request with the data subject;
2.5.2 send the note of the request by e-mail to the Data Protection Manager.
2.6 You will receive confirmation when the request has been received by the Data Protection Manager. If you do not receive such confirmation, you should contact the Data Protection Manager to confirm safe receipt.
2.7 You must not take any other action in relation to the data access request unless the Data Protection Manager has authorised you to do so.
3 What is a subject access request?
3.1 A subject access request is a request from an individual to be given confirmation that we process their data, and/or access to personal data which we process about him or her and certain other information contained in our privacy notice. For example, a letter which states 'please provide me with a copy of all the information that you have about me' will be a subject access request even though it does not expressly refer to personal data or to the GDPR.
3.2 All subject access requests should be immediately directed to the Data Protection Manager in accordance with paragraph 2 above.
3.3 A request can be for:
3.3.1 confirmation that their data is being processed;
3.3.2 access to the subject’s personal data; and
3.3.3 other supplementary information that is contained in the Company’s privacy notice.
3.2 All subject access requests should be immediately directed to the Data Protection Manager in accordance with paragraph 2 above.
3.3 A request can be for:
3.3.1 confirmation that their data is being processed;
3.3.2 access to the subject’s personal data; and
3.3.3 other supplementary information that is contained in the Company’s privacy notice.
4 Requirements for a valid request
4.1 For a subject access request to be valid, the following requirements must be satisfied:
4.1.1 we must be able to identify the individual making the subject access request and then verify that identity using reasonable means. Typically, we will request a copy of the individual's driving licence or passport to enable us to establish his or her identity and signature (which should be compared to the signature on the subject access request and any signature we already hold for the individual). We also ask for a recent utility bill (or equivalent) to verify the individual's identity and address. In the case of current employees, it may not be necessary to follow these requirements exactly, and reasonable means should be used to verify the identity of the person making the request. If the request is made orally, the identity of the data subject must still be proven by other reasonable means. If there is doubt about the identity of the data subject, we can request further information necessary to confirm the data subject’s identity;
4.1.2 we must be able to identify the information being requested. For example, if a subject access request is made by an individual who is both an employee and a customer, we can ask the individual to specify whether he or she is seeking access to human resources information, customer records or both. If the request relates to CCTV images, it may be necessary to ask the individual to supply a photograph of him or herself or provide a description of the clothing the individual was wearing at the time his or her image is believed to have been recorded on CCTV. We should also ask for details of the date, time and location to help narrow the search further (if such information is available).
4.2 If the individual makes a request that does not satisfy the above requirements the Data Protection Manager will write to him or her setting out in what respect the requirements are not satisfied.
4.3 In most cases, the request will be provided free of charge. The Data Protection Manager can charge reasonable administrative charges if the request is manifestly unfounded, excessive or repetitive. Alternatively, the Data Protection Manager can refuse to act on the request (in which case, see paragraph 5.3.)
4.4 In providing data to the data subject, the rights and freedoms of other data subjects must not be adversely affected. This includes trade secrets, intellectual property and copyright protecting any relevant software.
4.1.1 we must be able to identify the individual making the subject access request and then verify that identity using reasonable means. Typically, we will request a copy of the individual's driving licence or passport to enable us to establish his or her identity and signature (which should be compared to the signature on the subject access request and any signature we already hold for the individual). We also ask for a recent utility bill (or equivalent) to verify the individual's identity and address. In the case of current employees, it may not be necessary to follow these requirements exactly, and reasonable means should be used to verify the identity of the person making the request. If the request is made orally, the identity of the data subject must still be proven by other reasonable means. If there is doubt about the identity of the data subject, we can request further information necessary to confirm the data subject’s identity;
4.1.2 we must be able to identify the information being requested. For example, if a subject access request is made by an individual who is both an employee and a customer, we can ask the individual to specify whether he or she is seeking access to human resources information, customer records or both. If the request relates to CCTV images, it may be necessary to ask the individual to supply a photograph of him or herself or provide a description of the clothing the individual was wearing at the time his or her image is believed to have been recorded on CCTV. We should also ask for details of the date, time and location to help narrow the search further (if such information is available).
4.2 If the individual makes a request that does not satisfy the above requirements the Data Protection Manager will write to him or her setting out in what respect the requirements are not satisfied.
4.3 In most cases, the request will be provided free of charge. The Data Protection Manager can charge reasonable administrative charges if the request is manifestly unfounded, excessive or repetitive. Alternatively, the Data Protection Manager can refuse to act on the request (in which case, see paragraph 5.3.)
4.4 In providing data to the data subject, the rights and freedoms of other data subjects must not be adversely affected. This includes trade secrets, intellectual property and copyright protecting any relevant software.
5 Time limit for responding to a request
5.1 Once a valid subject access request is received, we have to respond without delay. ‘Without delay’ means that the request should be responded to as soon as possible, but within a month at most. You should make a note of when this period begins and when it will end.
5.2 The Data Protection Manager can extend the deadline for a response to up to three months where absolutely necessary, although a response will still be given to the subject within one month to explain why the longer deadline is necessary.
5.3 If we do not respond to a request without delay or within one month, then we will inform the data subject the reason why, and of their rights to make a complaint to the Information Commissioners Office (‘ICO’) and/or to seek a judicial remedy.
5.2 The Data Protection Manager can extend the deadline for a response to up to three months where absolutely necessary, although a response will still be given to the subject within one month to explain why the longer deadline is necessary.
5.3 If we do not respond to a request without delay or within one month, then we will inform the data subject the reason why, and of their rights to make a complaint to the Information Commissioners Office (‘ICO’) and/or to seek a judicial remedy.
6 Information to be provided in response to a request
6.1 The individual is entitled to receive a description of the following:
6.1.1 confirmation that we process data about him or her;
6.1.2 access to the personal data we process about him or her;
6.1.3 the purposes for which we process the data;
6.1.4 the categories of personal data concerned;
6.1.5 the recipients to whom we have disclosed or may disclose the data (particularly any recipients in third countries or international organisations, and where this is the case the appropriate safeguards used to protect the data);
6.1.6 the retention period for which the data will be stored (or the criteria used to determine that period);
6.1.7 the existence of their right to:
(a) request rectification or erasure of their personal data;
(b) request restriction of processing of their personal data;
(c) object to processing of their personal data; and
(d) their right to lodge a complaint with the ICO;
6.1.8 the existence, logic and consequences behind any automated decision we have taken about him or her; and
6.1.9 where the personal data was not collected directly from the data subject, information about the source of the personal data.
6.2 The information referred to in paragraph 6.1 must be provided in the form requested by the data subject. This can be orally, physically or electronically. For any further copies beyond the initial response, the Data Protection Manager can charge a reasonable administrative fee.
6.3 If the request is made electronically, the information should be provided in a commonly used electronic format. Where possible, the information will be provided by remote access to a secure self-service system
6.4 Any technical terms, abbreviations or codes contained in the personal data must be explained to the individual.
6.5 Where we process a large amount of data about the data subject, the Data Protection Manager may ask the data subject to specify the information the request relates to.
6.1.1 confirmation that we process data about him or her;
6.1.2 access to the personal data we process about him or her;
6.1.3 the purposes for which we process the data;
6.1.4 the categories of personal data concerned;
6.1.5 the recipients to whom we have disclosed or may disclose the data (particularly any recipients in third countries or international organisations, and where this is the case the appropriate safeguards used to protect the data);
6.1.6 the retention period for which the data will be stored (or the criteria used to determine that period);
6.1.7 the existence of their right to:
(a) request rectification or erasure of their personal data;
(b) request restriction of processing of their personal data;
(c) object to processing of their personal data; and
(d) their right to lodge a complaint with the ICO;
6.1.8 the existence, logic and consequences behind any automated decision we have taken about him or her; and
6.1.9 where the personal data was not collected directly from the data subject, information about the source of the personal data.
6.2 The information referred to in paragraph 6.1 must be provided in the form requested by the data subject. This can be orally, physically or electronically. For any further copies beyond the initial response, the Data Protection Manager can charge a reasonable administrative fee.
6.3 If the request is made electronically, the information should be provided in a commonly used electronic format. Where possible, the information will be provided by remote access to a secure self-service system
6.4 Any technical terms, abbreviations or codes contained in the personal data must be explained to the individual.
6.5 Where we process a large amount of data about the data subject, the Data Protection Manager may ask the data subject to specify the information the request relates to.
7 How to locate information
7.1 The personal data we need to provide in response to a subject access request may be located in several of our electronic and manual filing systems. This is why it is important to identify at the outset the type of information requested so that the search can be focused.
7.2 Depending on the type of information requested, you may need to search all or some of the following:
7.2.1 electronic systems, e.g. databases, networked and non-networked computers, servers, customer records, human resources system, email data, back up data, CCTV;
7.2.2 manual filing systems, e.g. the HR filing system, but only where the manual filing system falls within the definition of a ‘filing system’;
7.2.3 data systems held externally by our data processors, e.g. external payroll service providers;
7.2.4 occupational health records;
7.3 You should search these systems using the individual's name, employee number, customer account number or other personal identifier as a search determinant.
7.2 Depending on the type of information requested, you may need to search all or some of the following:
7.2.1 electronic systems, e.g. databases, networked and non-networked computers, servers, customer records, human resources system, email data, back up data, CCTV;
7.2.2 manual filing systems, e.g. the HR filing system, but only where the manual filing system falls within the definition of a ‘filing system’;
7.2.3 data systems held externally by our data processors, e.g. external payroll service providers;
7.2.4 occupational health records;
7.3 You should search these systems using the individual's name, employee number, customer account number or other personal identifier as a search determinant.
8 A relevant filing system
8.1 Paragraph 7.2.2 refers to a ‘filing system' as one of the systems that must be searched. A ‘filing system' is the name given to those manual filing systems that are subject to the GDPR because of the way they are structured. To be a relevant filing system, personal data must be accessible according to specific criteria. This could include chronologically ordered sets of manual records containing personal data.
8.2 Personal data that has been pseudonymised can still fall within the scope of the GDPR depending on how difficult it is to attribute the pseudonym to a particular individual.
8.2 Personal data that has been pseudonymised can still fall within the scope of the GDPR depending on how difficult it is to attribute the pseudonym to a particular individual.
9 Information to be supplied in response to a request
9.1 Once you have carried out the search and gathered the results, you will need to select the information to be supplied in response to the subject access request. The individual is only entitled to receive information which constitutes his or her personal data.
9.2 The type of information that will be classified as personal data is any information which identifies the individual (either directly from the data or from those data and other information which is in our possession or likely to come into our possession, such as information held by other companies, offices and branches).
9.3 Information about companies or other legal entities is not personal data. However, information about sole traders or partnerships will be, as the individuals within them are individuals. Personal data relating to deceased persons is not covered.
9.4 The right of access is subject to a number of conditions and exemptions, particularly where the personal data reveal information about another individual—this is covered in paragraph 10 below.
9.2 The type of information that will be classified as personal data is any information which identifies the individual (either directly from the data or from those data and other information which is in our possession or likely to come into our possession, such as information held by other companies, offices and branches).
9.3 Information about companies or other legal entities is not personal data. However, information about sole traders or partnerships will be, as the individuals within them are individuals. Personal data relating to deceased persons is not covered.
9.4 The right of access is subject to a number of conditions and exemptions, particularly where the personal data reveal information about another individual—this is covered in paragraph 10 below.
10 Disclosing personal data relating to third parties
If the requester’s personal data includes information that identifies a third-party individual (e.g. as a source or recipient of the requester’s personal data), you should consider:
10.1 Does the information relate to and identify the third party? In deciding this point, you should take into account:
10.1.1 the information you are disclosing; and
10.1.2 any information you reasonably believe the requester may have, or may get hold of, that would identify the third party.
10.2 If so, is it possible to comply with the request without revealing the third party’s information, e.g. by redacting (blanking out) names or editing documents?
10.3 If it is impossible to separate the third party’s information from that requested and still comply with the request, then you should consider whether the third party has consented to the disclosure of his or her information. It is good practice to ask relevant third parties for consent to the disclosure of their personal data in response to a subject access request. However, it may not always be appropriate to ask for consent, e.g. if to do so would inevitably involve disclosing personal data about the requester to the third party.
10.4 If the third party has not given consent, is it otherwise reasonable in all the circumstances to disclose without the third party’s consent? You should take into account the following (non-exhaustive) list of factors:
10.4.1 any duty of confidentiality that we owe to the third party;
10.4.2 any steps we have taken to obtain the consent of the third party;
10.4.3 whether the third party is capable of giving consent; and
10.4.4 any express refusal of consent by the third party.
10.5 The following additional factors should also be considered:
10.5.1 whether the third party is a recipient or one of a class of recipients who might act on the data to the requester’s disadvantage;
10.5.2 whether the third party is the source of the information;
10.5.3 whether the information is generally known by the requester; and
10.5.4 the importance of the information to the requester.
10.6 Ultimately, whether or not it is reasonable to disclose the third party’s information will depend upon all the circumstances and each request must be considered on a case-by-case basis.
10.7 Always keep a record of what you have decided to do and your reasons for doing it.
10.1 Does the information relate to and identify the third party? In deciding this point, you should take into account:
10.1.1 the information you are disclosing; and
10.1.2 any information you reasonably believe the requester may have, or may get hold of, that would identify the third party.
10.2 If so, is it possible to comply with the request without revealing the third party’s information, e.g. by redacting (blanking out) names or editing documents?
10.3 If it is impossible to separate the third party’s information from that requested and still comply with the request, then you should consider whether the third party has consented to the disclosure of his or her information. It is good practice to ask relevant third parties for consent to the disclosure of their personal data in response to a subject access request. However, it may not always be appropriate to ask for consent, e.g. if to do so would inevitably involve disclosing personal data about the requester to the third party.
10.4 If the third party has not given consent, is it otherwise reasonable in all the circumstances to disclose without the third party’s consent? You should take into account the following (non-exhaustive) list of factors:
10.4.1 any duty of confidentiality that we owe to the third party;
10.4.2 any steps we have taken to obtain the consent of the third party;
10.4.3 whether the third party is capable of giving consent; and
10.4.4 any express refusal of consent by the third party.
10.5 The following additional factors should also be considered:
10.5.1 whether the third party is a recipient or one of a class of recipients who might act on the data to the requester’s disadvantage;
10.5.2 whether the third party is the source of the information;
10.5.3 whether the information is generally known by the requester; and
10.5.4 the importance of the information to the requester.
10.6 Ultimately, whether or not it is reasonable to disclose the third party’s information will depend upon all the circumstances and each request must be considered on a case-by-case basis.
10.7 Always keep a record of what you have decided to do and your reasons for doing it.
11 Requests made by third parties on behalf of the individual
11.1 Occasionally we may receive a request for subject access by a third party (an 'agent') acting on behalf of an individual. These agents may include parents, guardians, legal representatives and those acting under a power of attorney or other legal authority. The agent must provide sufficient evidence that he or she is authorised to act on behalf of the individual.
12 Exemptions to the right of subject access:
In certain circumstances, we may be exempt from providing some or all of the personal data requested. These exemptions are described below and should only be applied on a case-by-case basis by the Data Protection Manager after a careful consideration of all the facts.
12.1 Crime detection and prevention: We may not have to disclose any personal data which we are processing for the purposes of preventing or detecting crime; apprehending or prosecuting offenders; or assessing or collecting any tax or duty. This is not an absolute exemption. It only applies to the extent to which the giving of subject access would be likely to prejudice any of these purposes. We are still required to provide as much of the personal data as we able to. For example, if the disclosure of the personal data could alert the individual to the fact that he or she is being investigated for an illegal activity (i.e. by us or by the police) then we do not have to disclose the data since the disclosure would be likely to prejudice the prevention or detection of crime, or the apprehension or prosecution of offenders.
12.2 Confidential references: We may not have to disclose any confidential references that we have given to third parties for the purpose of actual or prospective:
12.2.1 education, training or employment of the individual;
12.2.2 appointment of the individual to any office; or
12.2.3 provision by the individual of any service
This exemption does not apply to confidential references that we receive from third parties. However, in this situation, granting access to the reference may disclose the personal data of another individual (i.e. the person giving the reference), which means you must consider the rules regarding disclosure of third-party data set out in paragraph 10 before disclosing the reference.
12.3 Legal professional privilege: We may not have to disclose any personal data which is subject to legal professional privilege. There are two types of legal professional privilege:
12.3.1 ‘Advice privilege’ covers confidential communications between the Company and our lawyers where the dominant purpose of the communication is the seeking or giving of legal advice;
12.3.2 ‘Litigation privilege’ covers any document which was created with the dominant purpose of being used in actual or anticipated litigation (e.g. legal proceedings before a court or tribunal). Once a bona fide claim to litigation privilege ends, the documents in the file which were subject to litigation privilege become available if a subject access request is received.
If you think the legal professional privilege exemption could apply to the personal data that have been requested, you should refer the matter to the Data Protection Manager for further advice.
12.4 Management forecasting: We do not have to disclose any personal data which we process for the purposes of management forecasting or management planning to assist us in the conduct of any business or any other activity. Examples of management forecasting and planning activities include staff relocations, redundancies, succession planning, promotions and demotions. This exemption must be considered on a case-by-case basis and must only be applied to the extent to which disclosing the personal data would be likely to prejudice the conduct of that business or activity.
12.5 Negotiations: We do not have to disclose any personal data consisting of records of our intentions in relation to any negotiations with the individual where doing so would be likely to prejudice those negotiations. For example, if HR is negotiating with an employee in order to agree the terms of a redundancy package and the employee makes a subject access request, HR can legitimately withhold giving access to information which would prejudice those redundancy negotiations. The HR department must, however, disclose all other personal data relating to the individual unless that other personal data is also exempt from disclosure.
12.1 Crime detection and prevention: We may not have to disclose any personal data which we are processing for the purposes of preventing or detecting crime; apprehending or prosecuting offenders; or assessing or collecting any tax or duty. This is not an absolute exemption. It only applies to the extent to which the giving of subject access would be likely to prejudice any of these purposes. We are still required to provide as much of the personal data as we able to. For example, if the disclosure of the personal data could alert the individual to the fact that he or she is being investigated for an illegal activity (i.e. by us or by the police) then we do not have to disclose the data since the disclosure would be likely to prejudice the prevention or detection of crime, or the apprehension or prosecution of offenders.
12.2 Confidential references: We may not have to disclose any confidential references that we have given to third parties for the purpose of actual or prospective:
12.2.1 education, training or employment of the individual;
12.2.2 appointment of the individual to any office; or
12.2.3 provision by the individual of any service
This exemption does not apply to confidential references that we receive from third parties. However, in this situation, granting access to the reference may disclose the personal data of another individual (i.e. the person giving the reference), which means you must consider the rules regarding disclosure of third-party data set out in paragraph 10 before disclosing the reference.
12.3 Legal professional privilege: We may not have to disclose any personal data which is subject to legal professional privilege. There are two types of legal professional privilege:
12.3.1 ‘Advice privilege’ covers confidential communications between the Company and our lawyers where the dominant purpose of the communication is the seeking or giving of legal advice;
12.3.2 ‘Litigation privilege’ covers any document which was created with the dominant purpose of being used in actual or anticipated litigation (e.g. legal proceedings before a court or tribunal). Once a bona fide claim to litigation privilege ends, the documents in the file which were subject to litigation privilege become available if a subject access request is received.
If you think the legal professional privilege exemption could apply to the personal data that have been requested, you should refer the matter to the Data Protection Manager for further advice.
12.4 Management forecasting: We do not have to disclose any personal data which we process for the purposes of management forecasting or management planning to assist us in the conduct of any business or any other activity. Examples of management forecasting and planning activities include staff relocations, redundancies, succession planning, promotions and demotions. This exemption must be considered on a case-by-case basis and must only be applied to the extent to which disclosing the personal data would be likely to prejudice the conduct of that business or activity.
12.5 Negotiations: We do not have to disclose any personal data consisting of records of our intentions in relation to any negotiations with the individual where doing so would be likely to prejudice those negotiations. For example, if HR is negotiating with an employee in order to agree the terms of a redundancy package and the employee makes a subject access request, HR can legitimately withhold giving access to information which would prejudice those redundancy negotiations. The HR department must, however, disclose all other personal data relating to the individual unless that other personal data is also exempt from disclosure.
13 Consequences of failing to comply with a request
If we fail to comply with a subject access request or fail to provide access to all the personal data requested, or fail to respond within the time period, we will be in breach of the GDPR. This may have several consequences:
13.1 the individual may complain to the Information Commissioner and this may lead the Commissioner to investigate the complaint. If we are found to be in breach, enforcement action could follow (which could include monetary penalties);
13.2 if an individual has suffered damage, or damage and distress, as a result of our breach of GDPR, he or she may take us to court and claim damages from us; and/or
13.3 a court may order us to comply with the subject access request if we are found not to have complied with our obligations under the GDPR.
13.4 As set out above, if we fail to respond to a request within the time period, we must inform the data subject of the existence of the data subject’s rights to make a complaint.
13.1 the individual may complain to the Information Commissioner and this may lead the Commissioner to investigate the complaint. If we are found to be in breach, enforcement action could follow (which could include monetary penalties);
13.2 if an individual has suffered damage, or damage and distress, as a result of our breach of GDPR, he or she may take us to court and claim damages from us; and/or
13.3 a court may order us to comply with the subject access request if we are found not to have complied with our obligations under the GDPR.
13.4 As set out above, if we fail to respond to a request within the time period, we must inform the data subject of the existence of the data subject’s rights to make a complaint.
14 Contacts and responsibilities
14.1 This Policy will be reviewed annually by the Data Protection Manager.
14.2 Any questions regarding this Policy should be addressed to the Data Protection Manager.
14.2 Any questions regarding this Policy should be addressed to the Data Protection Manager.
