Subject Access Requests can present a significant burden on organisations. They are the most frequently exercised GDPR right and organisations need a clear process to handle subject access requests. This ensures they meet their statutory duties under the Data Protection Act and can cope with the work involved.
The risks from not having a process do not usually arise from organisations not knowing the right exists. It is that:
- requests are not recognised;
- they are sent to the wrong team;
- deadlines are missed;
- searches are too narrow or unnecessarily excessive;
- third-party information is mishandled;
- exemptions are poorly applied;
- disclosure is insecure.
Good SAR handling depends on a repeatable process, clear ownership and good information management.
What Is a Subject Access Request?
The right of access, which is commonly described as making a subject access request, gives an individual the right to:
- confirmation that their personal data are being processed;
- a copy of their personal data;
- supplementary information about the processing.
This supplementary information broadly includes matters such as purposes, recipients and retention information.
One issue organisations must factor in to their process is that person does not have to say “subject access request” or cite the GDPR. A request can be made verbally, in writing or through social media and can be made to any part of the organisation.
The Subject Access Request Process at a Glance
There are multiple steps involved in successfully completing a subject access request. Some of these are administrative, but it is important to go through each one so you can:
- have an audit trail of the steps you have taken if there are any complaints or concerns
- justify the refusal of a request on the grounds it is excessive (for example someone makes repeated requests)
- identify bottlenecks and improve your processes.
One of the things you should factor in to your process is regular updates to the requestor, letting them know you are still on track to comply with the request or, exceptionally, letting them know if there are any problems likely to cause a delay.
Recognise and Record the Subject Access Request
Requests can come via many routes, and you cannot require people to follow a particular process in order to exercise this right.
- do not need a particular form;
- can be verbal;
- can arrive through social media;
- can be received by any employee;
- do not have to mention “SAR”, “Article 15” or GDPR.
In essence if someone asks for some or all of their data outside of normal business as usual activity you should treat it like a subject access request.
Key organisational risks
- A request sits unnoticed in someone’s inbox.
- The person receiving the request simply refuses it because they think a particular process needs to be followed e.g. the requestor should contact a DPO
- The person receiving the request responds with what they have, but does not record the request, so a wider search, or provide the supplementary information required.
Good practice
Record:
- The date the request was received;
- The requester’s identity;
- What is requested (some people ask for quite specific information)
- Who the request is assigned to;
- The response deadline.
Understand What the Person Is Asking For and Who Is Asking
It’s important to understand what people are asking for, for a number of reasons.
Firstly, at this stage you can refuse, or consider refusing, some requests. For example:
- Requests that are repetitive e.g. someone is simply repeated a request that was responded to recently and no new information has come in
- Requests for the data of other people. People are only entitled to information about themselves, and you must not automatically give out the data of other people even they are the requestor’s child. There are exceptions if the requestor can show they have authority to act on the data subject’s behalf.
- Requests for things that are not personal data. For example, we often deal with requests from former employees. Sometimes they ask for copies of documents they have written. These are not usually considered personal data so do not fall within the scope of a subject access request
- What are known as manifestly unfounded or unreasonable requests. An example of this is when you get lots of identically worded requests simultaneously, which suggests you may be subject to a campaign or harassment not lined to a genuine desire to exercise a data right.
Secondly you can start to think about where to look for the information. IfF the requestor is a current or former employee then HR may need to be involved. If they are a customer then customer facing teams will need to be involved.
Finally, you can see if any clarification is needed or if you need the requestor to prove their identity. Organisations to ask for clarification where this is reasonably required, and the response period can be paused while waiting for that clarification. Although identity checks should not be your usual practice it is important to be sure you are not going to commit a data breach by sending data to someone who is not entitled to it. Unfortunately we have seen people make requests under false pretences such as pretending to be a family member, neighbour or former partner.
Ask only for enough information to establish identity where this is genuinely necessary.
For requests made through:
- solicitors;
- relatives;
- representatives;
- online SAR services;
confirm that the third party has authority to act. The ICO places the responsibility on the third party to provide evidence of that authority.
If people are unwilling to clarify their request or confirm their identity you can again close the request.
It is important to note clarification should help you understand the request. It should not be used simply to make a broad but valid request more convenient for the organisation.
Calculate the Deadline
A few requests will be closed by this stage but most will proceed to the next stage and you need to know by when you have to respond. The normal rule is:
Respond without undue delay and within one month of receipt
This means you must response as soon as possible and not use the full month if you can avoid it. In our experience going through the 12 steps can take time and unless the request is very light you will need most of the month in most instances. Remember it is a calendar month, not 30 working days, so unless you work weekends and bank holidays time is more limited than it appears.
The response period may be extended by up to a further two months where necessary because the request is complex or the person has made a number of requests. The requester must be informed appropriately, so do factor communications with the requestor into your timescales.
Define the Search Strategy
Once you know what has been requested then you can identify who holds the information and who can help with cross-system or organisation-wide searches.
Identify likely information locations:
- email;
- CRM;
- HR systems;
- shared drives;
- case-management systems;
- Teams/Slack or equivalent;
- paper records;
- CCTV;
- call recordings;
- archived systems;
- personal devices used for work where relevant.
Decide:
- search terms. This will typically be a range of identifiers such as the requestor’s name, nickname (Liz as well as Elizabeth for instance) and email address but you should also consider other identifiers like assigned reference numbers, national insurance number, telephone number etc.
- custodians; which teams or departments will have some personal data in either physical or electronic form
- date ranges; you should ensure you do not search for data created after the date the request was received. This can be important if the requestor is involved in an ongoing dispute like a complaint or grievance. IF the requestor has been specific ensure data from before their specific data range is not included.
- systems; as noted above data can be included in a range of systems and tools like Teams should not be ignored in any search. Sometime people also ask for metadata associated with them to be included in any data disclosed.
Conduct a Reasonable and Proportionate Search
Helpfully organisations must conduct a reasonable and proportionate search, but do not have to carry out searches that would be unreasonable or disproportionate to the importance of the information. This does not mean organisations can simply stop searching when the exercise becomes inconvenient, or stop at a certain point because there is a large volume of information.
Case Study 1
We dealt with a subject access request for a client who has appointed us as their data protection officer. The requestor asked for their personal data, and specified this should include anything with their initials. Unfortunately their initials were AS. We explained it was not reasonable or proportionate for us to examine any document with the letters AS in it because there are a large number of words in English containing ‘as’ within them.
Case Study 2
For another client we received a subject access request from someone who was referred to using a common abbreviation of their name (imagine Liz instead of Elizabeth). Because the abbreviation was so common a number of people both inside and outside the organisation were referred to in that way and we were unable to determine exactly who the abbreviation referred to in every instance. We explained to the requestor we would not be including instances where the abbreviation was used but we weren’t sure who it referred to as it would not be reasonable or proportionate to investigate each instance to the extent necessary to become certain.
Case Study 3
A requestor asked, as part of their request, for a copy of every document that has personally identifiable metadata associated with it. As this might include every document the requestor had ever opened, and the documents themselves might not contain any personal data about the requestor, we considered this was an unreasonable and excessive request – although we did provide their personal data generally.
You should document:
- where you searched;
- how; in many instances you still need to review documents found via an electronic search manually
- the search terms used;
- why those sources were chosen;
- why further searches would be disproportionate, if that conclusion is reached.
Identify the Requester’s Personal Data
Not every document mentioning the requester needs to be disclosed in full.
The right is to personal data, not automatically entire documents.
Explain:
A document may contain:
- the requester’s personal data;
- third-party personal data;
- organisational information;
- confidential material;
- legally privileged information.
The task is to identify what information is actually the requester’s personal data.
Review Third-Party Information
Third party information – information about other people – is explicitly excluded from disclosure under most circumstances. A record that you find after your search may contain information about:
- colleagues;
- relatives;
- complainants;
- witnesses;
- customers;
- clinicians;
- managers.
You should assess whether disclosure would reveal personal data about someone else and whether that information can or should be disclosed.
Examples will include emails, meeting minutes, internal reports, interview notes and even photographs.
When you find information containing data about other people you have four options.
- Disclose
- Redact third-party information
- Seek consent where appropriate
- Withhold the relevant information
Remember, even if you withhold a document you should generally include the existence of the document and a description of the requestor’s personal data it contains in the supplementation information you must provide alongside any data you do disclose. You should also explain the basis for your redactions or withholding the relevant document.
You should also be mindful of context. A person could be identified from the narrative of any document or record even if it does not contain direct identifiers. For example if someone makes a complaint about a colleague then the details of the incident being complained about could be enough to identify the complainant even if their name etc. were removed. You should be careful to check if a document can be effectively redacted or if, given the context, that is not possible.
When Disclosure Is Reasonable
When we approach a subject access request one thing we consider is if it would be reasonable to disclose data of a third party without redaction. Examples where we typically think it is include:
- Meeting minutes the requestor attended. They are likely to remember at least some of the people so hiding their identities is often not necessary
- Simple emails to or from the requestor from e.g. their line manager. The requestor is likely to recall details like their line manager’s name or email address and there is not likely to be a risk to disclosing that information.
However, each instance must be reviewed to ensure such disclosures are fair.
When Disclosure is NOT Reasonable
We would usually redact or withhold any document that the requestor has never seen before. Examples might include internal reports, complaints, or management data.
Consider Exemptions and Restrictions
Alongside third party data a number of other exemptions and restrictions on disclosure exist. Some of the main exemptions are:
- data subject to legal professional privilege;
- references in where they have been requested in confidence;
- health, education or social-work specific provisions;
- repetitive information
The ability to restrict disclosure of repetitive information is particularly useful in helping organisations manage the burden of requests and respond promptly. Examples of this type of information include:
- multiple emails containing no personal data beyond the requestor’s name and email address
- meeting minutes or agendas with only the requestor’s name or initials
- meta data associated with documents
A subject access request from an employee could contain thousands of records of these types. Crucially each instance will have been for broadly the same purpose and under the same lawful basis.
Instead of examining, redacting and listing each one you can provide one or two examples of each and explain to the requestor that you have multiple examples of the same data and are providing some examples of them to show what data you hold.
The ICO’s guidance on this point is useful and can be found here
Redact Carefully
Redaction is often preferable to withholding entire documents. Redaction must be approached with care, however, as poor redaction can lead to data breaches. To avoid this:
- ensure redactions are irreversible;
- remove hidden metadata where relevant;
- check comments, tracked changes and document properties;
Collate the Supplementary Information
It is a statutory requirement to provide more than the data the requestor asks for. Article 15 specifies what to include with the data itself, and the supplementary information should contain
- categories of personal data;
- purpose of processing;
- lawful basis for processing
- recipients if any, especially if data goes abroad;
- retention periods where known;
- source of information if not the data subject;
The ICO notes that this information may already be contained in the disclosure, but if it is not, it must be supplied separately.
We provide a template you can use to collate the core supplementary information, and where (and why) you have redacted or withheld any records. You can find out more and download the template here.
Quality Assurance
Now you have collated and reviewed your data, and compiled your supplementary information, conduct a final review before sharing the information.
Check:
- Is this the correct requester?
- Have all searches been completed?
- Is the disclosure complete?
- Are exemptions justified?
- Are redactions effective?
- Is third-party information protected?
- Is supplementary information included?
- Is the response understandable?
- Is the method of delivery secure?
For complex requests, or where you might need an expert review e.g. from HR a fresh pair of eyes can be invaluable in spotting duplication and errors. After all you are likely to have hundreds of individual records to disclose for even modest requests.
Disclose Securely
The sending organisation is responsible for ensuring the requestor received their information. Quite often the requestor will specify how they want their data to reach them but you should consider applying security measures to prevent inappropriate access.
Methods might include:
- secure portal;
- encrypted email;
- password-protected file with password supplied separately;
- secure post where appropriate.
Record and Close the SAR
One the data has been sent you can close the request. You should keep a copy of your records in terms of ID checks, searches done etc. alongside a copy of your supplementary data, which will also provide a record of what has been disclosed. As this point you can identify any key lessons and improvements to help you better manage future requests.
What If the Requester Is Unhappy
The Data Protection Act has been amended to give people a right to complain directly to the organisation processing their data, and the Information Commissioner’s Office expects people to do this before complaining to them. This in turn means organisations must have a mechanism to receive and consider these complaints.
You can find out more about this process here.
Common SAR Mistakes
There are a number of mistakes that many organisations make, but that can be avoided with a little bit of planning.
Missing or refusing requests
Staff look only for the words “subject access request” or require people to make requests in writing/to a specific person or contact point
Asking for unnecessary ID
This creates friction and additional personal data. If you know who the person is there is no need to formally request ID.
Searching everything indiscriminately
This creates a huge workload without better compliance. It will generate a lot of data that will have to be checked to confirm it does not contain any relevant personal data.
Searching too narrowly
This misses relevant information. Examples might include not checking teams chats even though you check email and word documents. Or you might exclude paper copies when you should include physical documents as well as electronic copies
Disclosing entire documents or not redacting enough
Instead of identifying the requester’s personal data sometimes whole documents are disclosed. This is not very fair to the requestor, as they should be able to access and understand their data easily, and it creates the risk of a data breach by the sending organisation
Over-redacting
You should not withhold information without a proper basis. Sometimes people say things they shouldn’t and it can be awkward or embarrassing to disclose it. These are not good enough reasons to withhold information.
Forgetting supplementary information
It is quite common for a response to include records but not the supplementary information required by the GDPR.
Sending information insecurely
If data is lost in transit then an otherwise compliant response becomes a new data breach.
Failing to record reasoning
This makes decisions difficult to defend in the event of a complaint, and it reduces the data available to identify efficiencies or improvements to your processes.
Subject Access Request Checklist
You can follow this checklist to help make sure you follow each step of the process – and you can download your own copy below.
Receive
☐ Recognise request
☐ Record date
☐ Assign owner
☐ Calculate deadline
Clarify
☐ Understand scope
☐ Verify identity if necessary
☐ Confirm third-party authority
☐ Clarify request if reasonably required
Search
☐ Identify systems
☐ Identify custodians
☐ Define search terms
☐ Conduct reasonable and proportionate searches
☐ Record search methodology
Review
☐ Identify requester’s personal data
☐ Identify third-party information
☐ Consider exemptions
☐ Redact where necessary
☐ Check special-category/sensitive information
Respond
☐ Include supplementary information
☐ Quality assure disclosure
☐ Send securely
☐ Meet deadline
Close
☐ Record outcome
☐ Retain decision rationale
☐ Record exemptions/redactions
☐ Address complaint if received
Download your copy of the checklist here
Conclusion
Subject access requests become much easier to manage when organisations treat them as a defined process rather than a burden or emergency. Recognising requests early, setting a clear search strategy, conducting reasonable and proportionate searches, carefully reviewing third-party information and documenting decisions all help organisations meet their legal obligations while avoiding unnecessary work and disclosure risks.