How do I Respond to a Right of Access Request?
Overview
This article is intended to be used as a guide to how to respond to a Right of Access Request.
These guidance materials should not be taken as a substitute for legal advice, but we hope they will provide a useful point of reference.
This article covers:
- What is a Right of Access Request?
- What information needs to be included when responding to a Right of Access Request?
- Step 1 - Ensure you have a designated person to process Right of Access Requests
- Step 2 - Confirm the exact date when the Request was Submitted
- Step 3 - Confirm the Identity of the Data Subject Submitting the Request
- Step 4 - Create the Right to Access Report
- Step 5 - Redaction of Data that identifies 3rd parties
- Other required information to include
What is a Right of Access Request?
The "Right to Access" (sometimes referred to as a Subject Access Request or SAR) is a user right included within the most Data Privacy legislation (e.g. GDPR Article 15), which allows a data subject (a person) to request a copy of all the Personal information that is being held on them, along with specific additional information.
What information needs to be Included when responding to a Right of Access Request?
The information will vary depending on the jurisdiction you are operating in and the legislation in place. For example under GDPR the information must include:
- The personal data itself
- The purposes of processing the data
- The categories of personal data
- The recipients or categories of recipients with whom the data has been shared
- The period for which the data is likely to be stored, or an explanation of the criteria used if this isn't possible
- The right to lodge a complaint with a supervisory authority
- Where data wasn't collected from the subject, any information related to the source
- Where data is transferred to a 3rd country or international organisation, confirmation of the safeguards in place
- The data must be provided in a commonly used electronic form. The data cannot identify a 3rd party who is a data subject.
This article will discuss an advised process on dealing with such a request.
Step 1 - Ensure you have a designated person(s) to process Right of Access Requests
It’s best to ensure that all Data Access Requests are only dealt by a nominated person in your organisation. This can help to prevent any inadvertent data breaches following employees (albeit acting with best intentions) responding personally and inappropriately to a Right of Access request.
Step 2 - Confirm the exact date when the Request was Submitted
Again, time limits may vary depending on jurisdiction, but the GDPR imposes a 30 day time limit (Article 12 (3)) for a data controller to respond to a Right of Access Request. After receiving a request, it's therefore important to immediately confirm the exact date that the request was submitted. If a request was submitted over a weekend, or was emailed to a person who had no access to their mailbox for a period of time, there could be some delay before the request reaches the relevant person (e.g. Data Protection Officer) within an organisation to deal with the request. Knowing the exact date and therefore deadline to respond, will assist with prioritisation if multiple requests arrive in a short period of time.
Step 3 - Confirm the Identity of the Data Subject Submitting the Request
To avoid a potential data beach, the identity of the data subject who raised the Right to Access request must be confirmed before any personal information is shared with them.
At the bottom of this article we have provided a sample form which was produced with GDPR in mind. This is an example of a form that could be sent to a data subject in order to confirm their identity.
The existence of this right may lead to malicious individuals trying to gain access to sensitive and personal information on a person by assuming their identity and submitting a Right to Access request.
We would advise to take sensible measures to confirm the identify the person submitting the request. If a controller cannot confirm the identify of a data subject, they can refuse an Access Request or request additional information from the data subject to confirm their identity.
Step 4 - Create the Right to Access Report
Once you are confident that you have confirmed the identity of the Data subject and you are dealing with a genuine request, you can move on to prepare the Right of Access report.
Invenias includes a powerful report to specifically deal with a request of this nature. This report contains all personal data held on a person, taken directly from their Invenias record.
This report (along with all other Default Reports) can be customised on request by Invenias Professional Services. For more information and to discuss options please contact your Account Manager.
To run this report, open the Reporting menu from the Desktop shortcut:
Please note that to Print / Export / Email a report requires the User permission "View Reports".
Click into the Right of Access report and select the data subject using the People look up. At this point, ensure again you are selecting the correct person, especially if you have multiple People records with the same or similar name. In the people look up you can include columns such as Job title/ Company and contact fields such as Email 1/2/3.
Click "Run" and the report will be prepared and then previewed in the window on the right side of the page. This report can be edited in the preview window, and then exported to various formats such as .docx, .pdf, .xlsx etc. Note that when editing a report in preview, if you click to a different report, or run the report again, any edits made will be lost.
You can also run the report directly from the Person Record by opening the Person record for the person who has raised the request, then click into the Reporting Button in the Toolbar and select the Right of Access Report.
The layout of the report is listed below, if no data is held in a particular field/section, then the field/section will be hidden entirely in the report.
Personal Information
e.g. Name, Headline, Contact Details, Personal Details, Custom Fields
- Categories
- Off limits
- Package Sought
- Position History inc all package/ rates information
- Education History
- Personal Profile Internal/External
- Notepad
- Person Scoring
- Candidate Assignment History inc Candidate Scores
- Offers and Placements History
- Client Assignments History
- Referral Partner Assignments History
- Programme History
- References
Appendix A - Journal Items under GDPR
It's worth noting, that Recital 63 of the GDPR legislation states:
“Where the controller processes a large quantity of information concerning the data subject, the controller should be able to request that, before the information is delivered, the data subject specify the information or processing activities to which the request relates.” This note is particularly relevant if you have a large number of journal items stored on a person record.
All journal items that only include this person as the sole relation are included. I.e. If the Person record has journal items that were saved to other records as well as the person, these will not be included but can be reviewed by opening the Invenias record, clicking to the journal tab and reviewing the items to attach separately to the report.
As Emails are extremely likely to include signatures and information which will identify 3rd parties, these are not automatically included in the report. We would advise to view all email activity in the journal tab for the person record, open each item, then save separately to edit/redact (see next section) and attach to the response to the Right of Access request.
Documents
Note that the report also does not include any documents saved into Invenias as they cannot be exported and embedded into the report through automated means. We would advise to review the documents attached to:
- The Person Record
- References for the person
- Client or Candidate Assignments
- Offers/Placements for the Person
If after reviewing the documents there are any that contain personal data about the data subject, we would advise to redact any 3rd parties which are identified in the documents, or any data which could identify a 3rd party and attach to the response for the Right of Access request along with the main report.
Step 5 - Redaction of Data that identifies 3rd parties
After the report has been created, we would advise to thoroughly review all data in the Report and then undertake a process of redacting any reference to a 3rd party individual, that could breach the confidentiality of that 3rd party individual. Invenias has taken steps to mitigate the risk of a 3rd party being identified in the report by not including fields which clearly identify a 3rd party, e.g. “Reference From”. However, if a User inadvertently adds this data to any field e.g. Progress Notes, there is no automated means of checking and removing this content.
The following examples show how a 3rd party may be revealed inadvertently, requiring redaction.
Example 1
An email is attached as a journal item, the email includes a conversation chain where another person is openly discussed and containing numerous email signatures with contact details of the recipients.
E.g. “When Colin used to work with me at Invenias”.
Action - Redact the content exposing the 3rd party.
Example 2
Feedback is left from a 3rd party where they compare the data subject with another named individual.
E.g. “Colin didn’t perform as well in the interview as John Smith”.
Action – Redact the content exposing the 3rd party.
You may prefer to undertake this process by editing the report in the preview window, or printing the report, then manually editing/redacting, then scanning the edited document prior to submitting to the data subject.
It's understood that Personal data held by a controller may change for various reasons from the point that the request was submitted to when the Report is created and sent to the data subject. It is made clear in Data Privacy legislation in most jurisdictions that a User cannot amend or remove any personal data following a request which isn't part of a redaction process to exclude a 3rd party, or would otherwise not have been amended/removed if the Right of Access request hadn't been made. This is considered a criminal offence in certain jurisdictions.
Other Required information to include
In addition to the information stored in Invenias, where possible you should also take steps to check for data held in other systems you are using. E.g. Sharepoint, Office 365 Email.
We would advise to ensure that your Privacy Policy is updated to be compliant with relevant local legislation. This forms the central location where you can display the various compliance measures, definitions and categorisations required for compliance purposes.
When responding to the data access request we would advise to include a copy of supporting Documentation, e.g. your Data Privacy Policy, or a link to policies is they are publicly accessible on a website.
Your Privacy Policy can include the additional information required under the legislation in your jurisdiction you fall under, under GDPR this includes:
- The purposes of processing the data.
- The categories of personal data.
- The recipients or categories of recipients to whom the data has been shared with. E.g. Hiring managers in relation to Employment opportunities.
- The period for which the data is likely to be stored, or an explanation of the criteria used if this isn't possible.
- The right to lodge a complaint with a supervisory authority.
- Where data is transferred to a 3rd country or international organisation, confirmation of the safeguards in place.