GDPR Practitioner Guide 2nd Edition now out – click here for special offer
I wrote a few weeks ago discussing how DSAR volumes may have gone up in your organisation and that it’s probably not simply down to the GDPR Subject Access hurdles being lowered for Data Subjects. Since GDPR came into force in May 2018, Data Subjects now don’t have to pay a fee (in most cases). The information can be requested electronically. Data Subjects can make a DSAR to anyone in the Controller or Processor organisation. Data Subjects can even make a DSAR via Twitter if they are so inclined. Once made, GDPR Subject Access Requests must be delivered (again in most cases) within 30 days. Cynically, there is one way an organisation can still use to stop the clock ticking – verification of the data subject’s identity. Before you attempt to use it yourself, bear in mind that organisations who choose to verify a Data Subject’s identity, purely as a delay tactic, could find themselves in deep water if they’re not careful. Here’s why…
Identity verification is not an explicit mandatory requirement for a DSAR
Whilst not explicit, it is implicit. Whilst it is absolutely true a Controller must only provide personal data about a specific Data Subject to said Data Subject, there is nothing in Article 15 (Right to Access by the Data Subject) which explicitly states a specific identity verification process must be carried out before a GDPR Subject Access Request is initiated at a Controller or Processor. The only explicit mention of identity verification in the main body of the GDPR text is in Article 12(1) which states:
“When requested by the data subject, the information may be provided orally, provided that the identity of the data subject is proven by other means.”
That said, Recital 64 is explicit in identity verification, it is noteworthy that verification is still not a mandatory requirement. The recital states:
“The controller should use all reasonable measures to verify the identity of a data subject who requests access, in particular in the context of online services and online identifiers.”
The key terms in recital 64 are “should” (not “shall”) and “reasonable”. This is echoed in the ICO Guidance which states:
“If you have doubts about the identity of the person making the request you can ask for more information. However, it is important that you only request information that is necessary to confirm who they are. The key to this is proportionality.”
GDPR Subject Access – What is reasonable? What is proportionate?
As you will note in the ICO guidance it talks about doubt. If you have a completely unsolicited request from a Data Subject then it would be perfectly reasonable to ask for some form of verifiable means to identify that the person is whom they say they are. For example, if a Controller receives a DSAR by email and has the Data Subject’s home address on file then a recent utility bill showing the same address would be a proportionate identity mechanism. This would give the Controller a mechanism to verify identity.
An alternative mechanism could be to call the Data Subject, explain you have received their DSAR and then confirm their identity by going through some security questions. Again, this could be by confirming the Data Subjects address or could be through the use of question relating to their interactions with your company (E.g. what was the last item purchased and for how much).
Where the GDPR subject access request is likely to result in the DSAR material containing sensitive data then what would be considered reasonable and proportionate, naturally, must increase accordingly. In such a situation, it would be both reasonable and proportionate for a Controller to request multiple forms of identification and/or seek answers to multiple security questions – but only where the data subject’s identity is in doubt!
What is unreasonable? What is disproportionate?
Conversely, if you hold data that would not be likely to adversely affect the rights and freedoms of the Data Subject, requiring a Data Subject go through onerous steps to verify their identity would neither be proportionate nor reasonable. Requiring a Data Subject to present themselves at your head office building with a copy of their passport and driving licence would not be proportionate. Requiring a Data Subject send notarised copies of these documents by recorded delivery would not be proportionate.
If you are already in an ongoing conversation with the Data Subject about an issue (e.g. a Complaint which has escalated) then the identity of the Data Subject is already known to you – otherwise, you would not be dealing with their complaint. If you have just interviewed a prospective candidate for a role and have been interacting over email with this person, they are known to you. If they are unsuccessful for a role and they make a DSAR, immediately on receipt of rejection, it is neither reasonable nor proportionate to go through a further identification verification process. In the case of job applicants, there is typically an ID verification process to go through anyway so I would be questioning why this had not already been done!
GDPR Subject Access – Anything else to think about?
Remember, when asking for verification of identity you now need to keep this additional information the Data Subject has provided you secure. If you don’t normally process passports, driving licences etc and you’re now asking for this additional information, this is a whole load more personal data you need to manage and keep secure. How are you going to do that – and at what cost? If you are collecting this information when it is clear you already know who the Data Subject is (because of prior interactions) and you are only collecting this identity documentation to delay the inevitable, ask yourself:
“What if all this identity documentation gets compromised?”
What if you get hacked? What if these Data Subjects now have their identities stolen? What probably started off as a simple complaint which could have been resolved swiftly, has already turned into an avoidable GDPR Subject Access Request and quite possibly may also turn into a full-on AVOIDABLE personal data breach!
GDPR Subject Access – Delay tactic…probably best to think again…
The key takeaway is don’t ask for information you don’t need. Use identity verification processes that don’t require the collection of additional data – use the data you already have to verify the Data Subject’s identity. Most importantly. If you feel you need to use ID verification as a delay tactic, ask yourself why? What are you not able to fulfil the DSAR in the allotted time? Why are you getting so many requests? Find the answers to these questions and fix those issues – because it’s often better to fix the root cause of the problem than to paper over the issue and annoy your customers even more!
About The Author
About Fox Red Risk
Fox Red Risk is a boutique data protection and cybersecurity consultancy and Managed Security Service Provider which, amongst other things, helps client organisations with implementing control frameworks for resilience, data protection and information security risk management. Call us on 020 8242 6047 or contact us via the website to discuss your needs.
22301 22301:2019 article 28 awareness bcms BIA business continuity calculating risk change management ciso controller cybersecurity data breach data privacy Data Protection data protection by design data protection officer data protection service Data Subject Access Request DPO DSAR GDPR incident management information security leadership monitoring operational resilience Outsourced DPO Privacy processor risk risk appetite risk management ROI security security as a service small business strategic strategy Subject Access Request tools training transparency vciso virtual ciso
