CCPA Privacy FAQs: How far can a company go to validate the identity of an individual making a data subject access request?
The CCPA requires that a company allow Californians to access the information held about them, or, in some situations, request that the information that they provided to a company be deleted. In order to access or delete their information, a consumer must submit a “verifiable consumer request.”1 While the term implies that a business must take steps to “verify” that the individual who has made a request is indeed the person about whose information they would like the company to take action, the CCPA does not specify what steps it considers to be sufficient (or that it considers to be inadequate) to accomplish the verification. Rather, the Act directs the Attorney General to adopt regulations to help guide companies on how to accomplish consumer verification.2 If the Office of the Attorney General has not finalized regulations by the time that the CCPA goes into force, many businesses are likely to apply a sliding scale verification process under which they establish higher-threshold steps needed for verification (e.g., government issued ID) when a request might permit access to sensitive consumer information (or the deletion of important consumer data) and lower-threshold steps needed for verification (e.g., confirmation to an email address previously on file) when a request would permit access only to low-sensitivity consumer information (or the deletion of relatively unimportant consumer data).In comparison, in Europe the Article 29 Working Party – the predecessor to the European Data Protection Board – recognized that while there “are no prescriptive requirements to be found in the GDPR on how to authenticate the data subject,” controllers have an obligation to “strongly ascertain” the identity of a data subject before responding to a request regarding information.3 While in some situations, verifying the email address of a data subject (e.g., sending a communication to the data subject at the email address that a company has previously associated with the individual) may be sufficient to “strongly ascertain” identity, in other instances it would not. Specifically, email verification has well accepted vulnerabilities to impersonation and supervisory authorities have advised controllers that they should not assume that a data subject is who they say they are based upon the mere fact that an “email address matches the company’s records” and have advised gathering “further information,” prior to responding to the data subject’s request.4 In the United Kingdom, the Information Commissioner’s Office published a ‘Subject Access Code of Practice’ which provided guidance on (amongst a multitude of other things) how to confirm a requestor’s identity. In short, the Code recommended asking only for enough information to judge whether the person making the request is the individual to whom the personal data relates. What is reasonable may be circumstance specific. For example:
- If a company receives a written request from a current employee that is personally known, a phone call may be sufficient to satisfy the identity of the requestor. It would likely be unreasonable to ask them for additional proof of identity.
- If a company receives a request by email, and in that email the requestor provides an address which does not match the address a company has on record, it would be reasonable to confirm another detail which the company holds on record.
The means by which the request is delivered may also affect your decision about how far a company needs to go to confirm the requestor’s identity. For example, if a request is made from an email account with which a company has recently corresponded with the requestor, it may be reasonable (particularly if the personal information kept has no sensitivity) to assume that the request has been made by the requestor. On the other hand, if the request is made via a social networking website or on blank letter paper, it may be more prudent to check whether it is a genuine request.