Talk to usTry the demo

Retention and Erasure of Identity Data in Verification Callbacks

Privacy and biometric data

For: Privacy lead of a business that verifies identities and receives the results in its own systems

How long the identity data from a verification may stay in your systems, and how deletion and callback design follow from the answer.

You run a service that verifies identities and passes the result to your own systems, and the question that governs everything else is this: how long may the identity data that a verification produces stay in your systems? Deletion on request, deletion when the purpose ends, and the choice of what a callback carries are the parts of the answer: the less a callback carries, the fewer places you must clean later.

For information; not legal advice.

The article reads the General Data Protection Regulation, the guidance of the European Data Protection Board and of the UK Information Commissioner's Office, and then the retention rules that anti-money-laundering law, trust-service standards and remote-onboarding guidelines put on top. Quotations from legal texts are exact and kept short, and everything else is a paraphrase of the cited text.

Three duties that pull in different directions

The first duty is to keep identity data no longer than the purpose needs. Article 5(1)(e) of the GDPR describes personal data as "kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed". Article 5(1)(c) adds that data must be "adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed".

The second duty runs the other way: some laws require you to keep identity records for a fixed time. Anti-money-laundering law is the clearest example, and it applies to the firms that are obliged to verify their customers. Whether that firm is you or your customer decides who holds the duty.

The third duty is the right of the person to ask for erasure, which interacts with both of the first two. Article 17(1) gives the data subject the right to obtain erasure "without undue delay" where one of the listed grounds applies. Article 17(3) then switches the right off "to the extent that" processing is necessary for, among other things, a legal obligation or legal claims.

A retention and erasure design is the set of decisions that keeps these three consistent.

What the GDPR says about keeping data

The accountability rule comes first. Article 5(2) says that the controller "shall be responsible for, and be able to demonstrate compliance with" the principles, which include minimisation and storage limitation.

The ICO guidance on storage limitation makes the same point in practical terms. It says that you need to be able to justify how long you keep personal data, that you need a policy setting standard retention periods wherever possible, and that you should periodically review what you hold and erase or anonymise what you no longer need. It also warns against keeping data indefinitely "just in case", or where there is only a small possibility that you will use it. That guidance is written for the UK GDPR and carries a notice that it is under review after a change in UK law, so read it as a worked explanation of the shared principle, not as EU law.

Data protection by design and by default

Article 25 turns the principles into a design duty, headed data protection by design and by default. Article 25(2) says that the controller must implement measures so that, by default, "only personal data which are necessary for each specific purpose of the processing are processed". The same paragraph states that this "obligation applies to the amount of personal data collected, the extent of their processing, the period of their storage and their accessibility". For a verification flow, the four dimensions map to what the scenario asks the person to provide, what the system does with it, how long it stays, and who and what can read it.

The EDPB Guidelines 4/2019 explain what this means for deletion. Paragraph 53 says that if personal data is no longer necessary for the purpose it shall by default be deleted or anonymised, and that the controller should have systematic procedures for deletion or anonymisation embedded in the processing. Paragraph 54 describes anonymisation as an alternative to deletion, provided that the risk of re-identification is regularly assessed.

The guidelines list design elements for storage limitation that are useful as a checklist. They include clear internal procedures and functionalities for deletion, a test of whether anonymised data can be re-identified or deleted data recovered, automation of deletion, a justification for every period, enforcement of the retention policy with tests of whether the organisation follows it, a decision on what backups and logs need, and care with the flow of data and "temporary" copies.

The minimisation elements in the same guidelines add two ideas that matter for callbacks. The first is that the data flow should be efficient enough not to create more copies than necessary. The second is that the degree of identification can be minimised: where identification is no longer needed after an early step, the controller should delete or anonymise the data as soon as that point is reached.

The record of processing

Article 30(1)(f) asks controllers, where possible, to record "the envisaged time limits for erasure of the different categories of data". That sentence is the legal home of the retention schedule, and a later section builds one for a verification flow.

Erasure on request

Article 17(1) lists the grounds on which a person can obtain erasure. Three grounds bear most directly on a verification flow. The first is that the data are no longer necessary for the purposes for which they were collected or otherwise processed. The second is that the person withdraws consent and there is no other legal ground, and the third is that the data were unlawfully processed. A fourth ground, that the data have to be erased to comply with a legal obligation in Union or Member State law, applies where a law such as the anti-money-laundering rules requires deletion at the end of a period.

The exceptions are in Article 17(3). Two matter here: processing that is necessary "for compliance with a legal obligation which requires processing by Union or Member State law", and processing necessary "for the establishment, exercise or defence of legal claims". The ICO guidance gives the plain consequence: if you are required by law to process the data, the right to erasure does not apply to it.

The words "to the extent that" in Article 17(3) deserve attention. They suggest a partial answer, not an all-or-nothing one: erase what no duty requires you to keep, and keep what a duty does require. That reading is a design choice, not a ruling, and for a particular case the advice of a lawyer who knows the national law is the right input.

The clock and the reply

Article 12(3) requires the controller to provide information on the action taken "without undue delay and in any event within one month of receipt of the request". The period may be extended by two further months where necessary, taking into account the complexity and number of requests, and the controller must inform the person of the extension within the first month together with the reasons. If the controller does not act, Article 12(4) requires it to say why, at the latest within one month, and to point to the possibility of a complaint and a judicial remedy.

Article 12(6) allows the controller to request additional information to confirm identity where it has reasonable doubts about who is asking. For a verification business this is a practical point, because the person who asks for erasure must be matched to a session or a record, and the request should not cause a new collection of identity data larger than the one it is meant to delete.

Backups and recipients

The ICO guidance on backups is candid about technology. It says that where a valid erasure request is received and no exemption applies, you have to take steps to ensure erasure from backup systems as well as live systems, and that the steps depend on your circumstances and your backup schedule. It adds that the key issue is to put the backup data "beyond use", so that it is held only until it is replaced under an established schedule, and that you must be clear with individuals about what happens to their data, including in backups.

Article 19 deals with onward copies. It requires the controller to communicate an erasure to each recipient to whom the data have been disclosed, "unless this proves impossible or involves disproportionate effort", and to tell the person about those recipients on request. A verification provider, a storage service and an analytics tool that received the data are all places that this article asks you to think about.

The duties that point the other way

Anti-money-laundering records

Regulation (EU) 2024/1624, the EU anti-money-laundering regulation, applies from 10 July 2027, except for a small group of obliged entities for which it applies from 10 July 2029. Its Article 77 lists what obliged entities retain, starting with a copy of the documents and information obtained in customer due diligence, including information obtained through electronic identification means. Article 77(3) sets the period at five years from the termination of the business relationship, from the date of an occasional transaction, or from the date of refusal to enter into a relationship or carry out the transaction. The same paragraph says that, without prejudice to retention periods under other Union legal acts or national law that complies with the GDPR, obliged entities "shall delete personal data upon expiry of the five-year period". Competent authorities may require further retention case by case where it is necessary for preventing, detecting, investigating or prosecuting money laundering or terrorist financing, and that further period shall not exceed five years.

Article 77(2) offers a way to hold less. Obliged entities may replace the retention of copies by the retention of references to the information, provided that the nature and method of retention let them supply the information immediately to competent authorities and ensure that it cannot be modified or altered. An obliged entity that uses this option must define in its internal procedures the categories for which it keeps a reference instead of a copy, and the procedures for retrieving the information.

Transfers of crypto-assets and funds

Regulation (EU) 2023/1113 has its own record rule in Article 26. It says that information on the payer and payee, or the originator and beneficiary, shall not be retained "for longer than strictly necessary", and sets the retention period at five years for the information it lists. After that period the providers must ensure that the personal data is deleted, unless national law determines when further retention is allowed, and any further period must follow an assessment of necessity and proportionality and may not exceed five years.

Remote onboarding guidelines

The European Banking Authority guidelines on remote customer onboarding speak to the same point from the side of the technology. Paragraph 26 says that documents and information collected during remote identification, where they must be retained under Article 40(1), point (a), of Directive (EU) 2015/849, should be time-stamped and stored securely, and that stored images, videos, sound and data should be available in a readable format that allows ex-post verification. Paragraph 49 is addressed to the case where an outsourced provider stores customer data such as photographs, videos and documents. It says that the institution should ensure that only necessary customer data is collected and stored in line with a clearly defined retention period, that access is strictly limited and registered, and that appropriate security measures protect the stored data.

Trust-service and identity-assurance standards

ETSI TS 119 461, the specification for identity proofing for trust services, treats retention as a requirement of its own. It says that evidence of the identity proofing process shall be retained for the necessary retention time given by the identity proofing context, and its example is a retention for as long as the applicant remains a subscriber plus some years. It then adds that at the end of that time the evidence and all personal data on the applicant shall be deleted. It also notes that retaining images of a human applicant can, depending on the context, be required, allowed, forbidden or limited in time. Finally, it asks that the applicant receive clear guidance on what data is kept and for how long.

The US digital identity guidelines add two statements about biometrics and video. They say that a provider shall have a documented and publicly available deletion process and default retention period for all biometric information, consistent with applicable regulations, and that it should support deletion of a subscriber's biometric information on request, except where restricted by regulation, law or policy. Where a session is recorded as video, they say that the provider shall publish its retention schedule and deletion processes for all video records.

Putting the duties together: a retention schedule by data class

A single retention number for a verification session is almost always wrong, because the pieces of a session have different purposes and different legal drivers. A schedule that works splits a session into classes and gives each class its own owner, purpose, period and deletion route.

Raw capture. The images, video and document scans taken during the session are the most sensitive and the most voluminous class. They are needed while the check runs and, for an obliged entity, possibly for the legal retention period; the EBA and ETSI texts above show where such a need is stated. Outside such a duty, whether the raw capture may stay depends on a continuing purpose that you can justify and document. The EDPB guidance says that if personal data is no longer necessary for the purpose it shall by default be deleted or anonymised. The ICO guidance adds that you should consider whether you need to keep information to defend possible future legal claims, and that, unless there is some other reason for keeping it, personal data should be deleted when such a claim could no longer arise. For each class, therefore, assess the continuing purpose and the lawful basis, write them down with the period, and delete or anonymise the capture when the written purpose ends.

Extracted attributes. Names, dates of birth and document numbers read from the document are smaller but are what identifies the person. They are needed to open the relationship and, for an obliged entity, for its due diligence file.

Decision record. The verdict, timestamps, reason codes and an identifier of the session are the smallest class and the one with the longest useful life. They show that a check happened and what it concluded, and can often stay when the evidence is gone, provided that the identifier does not carry personal data.

Operational and audit records. The record that a deletion happened, and its cause, is the evidence for the accountability principle. It should say what, when, why and by whom, and should name the person only as far as the purpose requires.

Transient copies. Request logs, message queues, error trackers, caches and test environments that received a callback body are copies too. The EDPB guidelines name backups and logs and the "temporary" storage of copies as items to be decided, not left to defaults.

For each class, write down four things: the purpose, the legal driver if any, the period, and the route that deletes it. The schedule is also the basis for telling the person what you keep and for how long.

Who decides, and who deletes

Duration is not a detail that a vendor may choose for you. The EDPB Guidelines 07/2020 treat the duration of processing as one of the "essential means" that are reserved to the controller, together with the type of data, the categories of recipients and the categories of data subjects.

Article 28(3) of the GDPR requires the contract with a processor to stipulate duties that matter here. The processor processes the data only on documented instructions from the controller. It assists the controller, by appropriate technical and organisational measures and insofar as possible, in responding to requests to exercise data subject rights. And at the choice of the controller it "deletes or returns all the personal data" after the end of the services and deletes existing copies unless Union or Member State law requires storage.

The EDPB guidelines say more about that last duty. The controller can decide at the beginning whether data are deleted or returned, the contract should allow the choice to be changed before the end of the services, and the processor should perform deletion securely and confirm to the controller that it has been completed within an agreed timescale and in an agreed manner. If a legal requirement obliges the processor to keep copies, the guidelines say that the party who knows of it should tell the other as soon as possible.

In practice the contract and the product need to agree on four things: the scope of what is deleted, the triggers for deletion, the confirmation that the controller receives, and the proof of it that stays afterwards. Where retention is a setting of the controller and erasure is something the controller can call and observe, the confirmation can be tested; where deletion is a request to a support desk, the confirmation is harder to test.

Designing callbacks that carry less

A callback is a copy of identity data pushed to a server that you operate. Every copy has to be found and deleted later, so the design question is how little the first push needs to contain.

Send a signal, then fetch

The pattern with the smallest footprint is a callback that tells your system that something happened and names the session, after which your system asks for the result it needs, when it needs it. The data stays in one place while the signal travels, deletion happens in one place, and a lost or replayed signal that carries no identity fields and no results exposes nothing but an identifier. The cost is an extra call and a dependence on the data still being there when the call is made, which is a reason to fetch and store the part you need straight away and to design for the case where the data has been erased by the time you ask.

This pattern applies each of the four dimensions in Article 25(2): the amount of data, the extent of processing, the period of storage and accessibility. The amount pushed is reduced, the extent of processing is limited to what the receiving system needs, and the period of storage in the receiving system follows that system's own schedule.

Decide what the receiving system really needs

Many onboarding systems need only a handful of fields: the verdict, a few attributes that fill a customer record, and a reference to the evidence. If the evidence stays with the verification service for the period that the law requires, the receiving system may hold only a reference. That is close to the arrangement in Article 77(2) of the anti-money-laundering regulation, where an obliged entity keeps a reference instead of a copy, but only if it can supply the information immediately to competent authorities and the information cannot be modified or altered. Whether a particular arrangement meets those conditions is a question for the obliged entity and its supervisor. If the receiving system needs the full record, encrypt the body in transit and keep it out of logs, since a protected body that is written in clear text to a log defeats the protection. Article 32(1)(a) lists pseudonymisation and encryption among the measures to consider for security.

Keep identity data out of identifiers

An identifier that survives deletion must not itself identify anyone. A session key made of an email address, a phone number or a document number would keep personal data in exactly the place where it is meant to be gone. The ICO guidance is useful here: it says that pseudonymised data, for example key-coded data, will usually still permit identification, so the storage limitation principle still applies to it. A hash of an email address is therefore not a safe replacement. A random identifier issued by your own system carries no personal data in its own characters, but it is not anonymous while your systems hold the means to link it to the person. Recital 26 of the GDPR says that personal data which have undergone pseudonymisation, and which could be attributed to a natural person by the use of additional information, should be considered to be information on an identifiable natural person. So a linkable random identifier is pseudonymous personal data, and the storage limitation principle applies to it and to the records it points to until the link is destroyed.

Designing deletion you can show

The EDPB guidelines describe deletion as something that should be effective, automated and tested. That translates into five properties of a deletion procedure for identity data.

  1. It has triggers that do not depend on a person remembering: the end of the retention period, the end of the contract, and a request.
  2. It has a scope that lists every store and every recipient: the verification service, your database, the file store, the message queue, the logs, the backups and the people to whom you disclosed the data.
  3. It has a route for each store, whether deletion, anonymisation or putting data beyond use.
  4. It ends in a confirmation that can be read by a machine and kept as evidence.
  5. It is tested, including whether deleted data can be recovered, as the EDPB list of storage limitation elements asks.

Deletion takes time, and the interface should say so

Some stores answer at once and some do not, for instance a media store that must be reached through another network. An interface for erasure that returns a plain success once a request is accepted invites the caller to record a deletion that has not happened yet. A safer design reports distinct states, such as finished and in progress, lets the caller read the state again, and sends a completion event when the last part is done. The caller then branches on the reported outcome and not on the transport code, and records the completion event as the date of deletion.

A log that does not become a new store

The record that a deletion happened is evidence, and it is also data. Keep it to identifiers, the cause, the time and the actor, give it its own retention period, and do not copy into it the identity data that the deletion removed.

Hard cases

A rejected or abandoned applicant. Article 77(3) of the anti-money-laundering regulation counts the five years from, among other dates, the date of refusal to enter into a business relationship, so a rejected applicant is not automatically a deletion case for an obliged entity. For a business that is not an obliged entity, an abandoned session has no such driver, and the default is deletion once the purpose has gone.

Re-verification. The ETSI specification notes that when an identity document was used and no copy was kept, re-verification depends on the ability to obtain the document again from its identification. If your product relies on re-verifying a person later, decide whether that need justifies a longer period or whether a new session is the preferable design.

Withdrawal of consent. Article 17(1)(b) applies where consent was the basis and "there is no other legal ground for the processing". For identity verification, the basis is often a legal obligation or a contract, so a withdrawal of consent may not trigger erasure, and the reply to the person should say why.

Face data. Biometric templates and images raise the special-category rules on top of the retention rules; see the article on biometric data under the GDPR and UK GDPR in verification. The US guidelines, quoted above, call for a documented default retention period for biometric information. The ETSI note on images shows that the right period depends on the context.

Questions to put to your design

  1. Which classes of data does a session produce, and who owns the purpose of each?
  2. Which of them are held because a law requires it, and for how long, according to the law that applies to the obliged entity?
  3. What does your callback carry, and could it carry less and let the receiver fetch the rest?
  4. Where does a callback body land after your endpoint reads it: logs, queues, traces, test systems?
  5. Which identifiers outlive a deletion, and does any of them contain personal data or a hash of it?
  6. How does the system show that a deletion is finished, and what do you record when it is only in progress?
  7. What happens in backups, and what do you tell the person about it?

Where this sits in a verification flow

The steps in this article attach to a verification session on NeuroVision KYC, which gathers the identity part of the process in one session: document, selfie, liveness and face match, with the scenario assembled in an editor. Retention in days is a setting of each scenario, and erasure endpoints and an erasure confirmation webhook are available. In the callback settings of a scenario, the body can be encrypted with the secret key of the scenario, and a callback option omits names, document data and images from the session event and keeps the session identifier, which links to the session. With that option your system fetches the result by the identifier after the event arrives. The check results of database checks and of questionnaire checks stay in the callback whatever that option says.

When erasure is requested through the erase call, a call that finishes the destruction immediately answers in the same response, and if part of it cannot be confirmed in time, the system finishes the work itself and sends the erasure confirmation webhook. An erasure log lists what was destroyed, when, why and by whom, for a period you choose.

These controls are the product side of the schedule above, and the decisions about periods, causes and recipients stay with the business that is the controller. To see how these steps look in your own scenario, contact the team.

Sources

All sources were fetched on 27 October 2026.

Ready to talk?

Tell us what you are building and we will help you plan the integration.

Talk to us