IDV and Mastering the Three States of Data, Part 1: Data at Rest


The issues involved with the handling of customer data are of paramount importance in today’s digital landscape. Organisations must navigate a delicate balance between using customer data for business purposes and respecting individuals’ privacy rights—or else risk significant financial and reputational harm. Among the sundry items a business must take into account are obtaining informed consent for processing of biometrics, being transparent about data collection and usage practices, implementing robust security measures to protect customer data, and providing individuals with control over their own data.

Understanding the different states of data is crucial for maintaining its security and integrity. We can categorise data into three distinct states: data at rest, data in transit, and data in use. Each state represents a unique phase in the lifecycle of information, with its own set of considerations and risks. By understanding these states, companies can effectively implement measures to safeguard data throughout its journey. 

This 3-part blog series will delve into each state within the context of the identity verification (IDV) industry. We will cover the privacy, regulatory, and ethical questions to ask about:

Data at rest:
– How long the IDV provider retains data

Data in transit:
– The legality of international transfers of data that the IDV provider makes

Data in use:
– How the IDV provider trained its AI
– How the IDV provider uses data after completing the identity check for you
– The BIPA risk
– Common GDPR errors

Having to change IDV vendors after implementation can cost serious time and money. Make the  right choice the first time around and buy from a supplier who respects data privacy and ethics at every stage.

Safeguarding your customers’ data

Responsible data retention—in other words, properly handling data at rest—involves only holding on to customer data for as long as necessary and securely disposing of it when no longer needed. The days of storing data for the sake of it should be long gone, yet time and again we hear of organisations keeping data around with no justification. 

Your organisation should additionally adhere to jurisdictionally applicable data protection regulations, such as GDPR in the EU or CCPA in California, and prioritise data anonymisation and aggregation to minimise risks associated with data breaches or unauthorised access. Ultimately, ethical data retention practices foster trust, accountability, and respect for individuals’ privacy rights in the digital ecosystem.

Each company should have an active data management plan which assesses all the data held by the organisation, including by its suppliers, and determines whether that data needs to be held still, where it is stored, and in what state it is stored (encrypted, anonymised, or other).  

It all comes back to you

Let’s tie these insights back to IDV. As the buyer and de jure data controller of an IDV solution, your organisation, at the end of the day, is the party that’s legally responsible for adhering to data retention standards and regulations. Even if your data is held by a third party, it is you who would be on the hook for damages related to thefts or breaches.

The regulators’ perspective

In the EU, GDPR regulators tend to look closely at retention periods, so you need to justify them. Saying you are keeping data in case you need it in the future is not good enough. There is sometimes a conflict between financial services regulations, which often mandate record keeping periods, and the GDPR which strongly encourages deletion. Typically, the trick is to look at the wording of the financial regulations carefully; they mandate the keeping of “records,” but records of an IDV transactions does not have to include the biometrics or even photos of the customer in question from each IDV transaction, just validation that the IDV was performed. 

Questions to ask your IDV provider:

  1. Does your platform allow us to set automated data deletion rules? 
  2. What is the shortest period that we can set?
  3. How long is the data retained in your engines themselves? (Data is often held in engines separately to the main platform.)
  4. What is your data deletion policy for Illinois residents, including any backups?
  5. Can you prove that you do delete when you say you do?
  6. Can we delete all biometric and photo data from the records you keep for us?
  7. Is data held in backup, and for how long? (In order for an organisation to recover data and the results of checks in the event of a severe incident, the organisation will need to make copies of data into backup. Typically the data resides in backup for a set period, say 30 or 60 days. When you delete data from the main platform, the backup data will not usually be deleted. So you need to ask how long that backup retention period is. The risk of storing data in backup is much lower because the backup data cannot be accessed via the platform, which from a security perspective is normally the weakest link, but you still need to ask the questions.) 
  8. Is data held in your training database? If so, for how long?

About the post:
Images are generative AI-created. Prompt: Three little pigs, one sleeping, one running, one working on laptop. Tools: Craiyon (fka DALL-E Mini), ChatGPT.

About the author:
Peter Violaris is Global DPO and Head of Legal EMEA for IDVerse. Peter is a commercial technology lawyer with a particular focus on biometrics, privacy, and AI learning. Peter has been in the identity space for 6 years and before that worked for London law firms.

x Logo: Shield Security
This Site Is Protected By
Shield Security