How Long Should a Visa Agency Keep Client Data?

Most visa agencies keep everything. The application from 2019, the passport scan, the bank statements, the marriage certificate, the WhatsApp thread with the photographs of a child's birth certificate. Storage is cheap and deleting feels risky, so nothing goes.

The instinct is understandable and mostly wrong. A five-year-old passport scan does almost nothing for you: the passport has probably been replaced, the client's circumstances have changed, and if they come back you will collect current documents anyway. Meanwhile it sits there as something you can still lose.

That is the whole argument. Data you hold is data that can be breached, subpoenaed, mishandled by a departing employee, or exposed by a vendor. The size of an incident is set by how much you were holding when it happened, and the cheapest way to reduce it is to be holding less.

There is a legal dimension too — data protection regimes generally expect you to keep personal data no longer than necessary — but this article deliberately stays on the operational side. If you need the compliance framing, our guide to GDPR and data privacy for visa agencies covers lawful basis, subject rights and breach response. What follows is how to actually build and run the schedule.

You cannot delete what you cannot find, and almost every agency underestimates how many places client data lives. Before writing a single retention period, spend an afternoon listing them.

The list is usually longer than expected: your CRM or case system, the shared drive, the email accounts of everyone who has ever handled a case, sent-items folders, the accounting system, the payment provider, chat apps on personal phones, the scanner's local folder, a spreadsheet somebody built for last year's intake, the laptop of a consultant who left in March, and the backups of most of the above.

For each location, record three things: what categories of personal data it holds, who can reach it, and whether anyone can delete from it. That third column is the useful one. It usually reveals two or three places where deletion is currently impossible in practice, which is where your remediation work starts.

Do the same for third parties. Anyone who processes client data on your behalf — a document scanning service, an outsourced back office, a translation provider, a sub-agent — holds copies you are responsible for. Ask them, in writing, how long they keep data after a case closes and how they delete it. Our answer on where visa applicant data is stored covers what to expect from a platform vendor here.

The map is also the fastest route to a smaller problem. Most agencies find at least one entire category of copies that never needed to exist, and closing it off is a bigger win than any retention rule.

Retention periods are not a single number. They come from four separate clocks, and the longest applicable one wins for any given item.

The first is the service itself. While a case is live you obviously keep everything. The clock only starts when the case closes — approved, refused, withdrawn or abandoned — which means you need a definition of closed and a date recorded against it.

The second is financial. Tax and accounting rules in most jurisdictions require business records to be kept for a number of years, and invoices and payment records fall inside that. Confirm the actual period with your accountant for each country you operate in rather than adopting a number from an article. Note that this clock covers the transaction record, not the applicant's supporting documents.

The third is regulatory or professional. If you are a regulated adviser, your regulator or professional body may specify how long client files must be kept and in what form. This clock is often the longest, and it is the one most likely to have changed since you last looked.

The fourth is consent and contract. Marketing data you hold on the basis of consent lives only as long as that consent, and your own engagement terms may promise something specific to clients. Whatever you promised in writing is binding on you regardless of what the other clocks allow.

A fifth consideration is not a clock but a hold: if a dispute, complaint or investigation is live or reasonably foreseeable, you suspend deletion of the affected material until it resolves. Build that into the policy so nobody has to improvise it during a complaint.

Turn the clocks into a table. One row per category of data, with the trigger event, the period, the action at the end, and the owner. Keep the categories few enough that people can remember them.

A sensible starting structure separates four groups. Identity and supporting documents — passport scans, bank statements, certificates, photographs — are the highest-sensitivity, lowest-long-term-value group, and generally the first candidates for aggressive deletion after case closure. Case records — what was applied for, when, the outcome, the correspondence log — are lower sensitivity and higher long-term value, both for defending your conduct and for advising a returning client. Financial records follow the accounting clock. Marketing data follows consent.

That split matters because it lets you delete the dangerous material early while keeping the useful record. An agency that keeps a case summary and its correspondence log for years, but deletes the underlying identity documents shortly after closure, has most of the benefit and a fraction of the exposure.

Write the actual periods with your accountant and, if you are regulated, your professional body, and date the document. Then set a review date — annually is reasonable — because rules change and so does your business.

One practical warning: do not write a schedule you cannot execute. A policy promising deletion after a defined period, in an agency where deletion has never happened, is worse than no policy at all, because it is a written commitment you are visibly failing. Start with the periods you can actually enforce, then tighten.

The gap between a retention policy and reality is almost always deletion. Deleting a record in your case system does not delete the copy in an email attachment, the version on the shared drive, the file on a consultant's phone, or the backup taken last night.

Handle each surface deliberately. Primary system: use the platform's deletion or purge function and understand exactly what it removes and what it retains. Email: the honest answer is that attachments in mailboxes are the hardest surface to control, which is why the better fix is to stop documents arriving by email at all. Shared drives: consolidate into the case system and close the drive rather than trying to police it. Personal devices: a written prohibition on storing client documents locally, plus a workable alternative, is the only control that survives contact with a busy team.

Backups deserve a specific decision. Restoring a backup to surgically remove one client's data is usually impractical, and the accepted approach is to document that deleted data remains in backups until the backup rotation expires, to state that rotation period, and to ensure restored data is re-deleted. Write that down rather than pretending backups do not exist.

Decide too whether an item is deleted or anonymised. For statistics — how many applications for a destination, what the approval rate was — you rarely need identifiable data. Stripping identifiers while keeping the counts preserves your operational reporting without preserving the risk.

Finally, record the deletion. A log showing what was deleted, when and under which rule is what turns a policy into something you can demonstrate.

Retention limits how long data exists. Access control limits how many people can reach it while it does. Agencies obsess over the first and neglect the second, which is backwards, because the everyday risk is internal access, not archive volume.

The default should be least privilege: a consultant sees the cases they work on, a team lead sees their team's, finance sees payment records but not passport scans, and administrators can grant access but do not need routine access to documents themselves. This is exactly what corporate clients and institution partners probe during due diligence, and our answer on who can see your clients' data in a visa CRM covers the practical shape of it.

Make access reviewable. Somebody should be able to answer, without a project, who can currently see a given client's file. If that question requires a week of investigation, you do not have access control; you have a shared drive with a login page.

Run a short access review on a schedule — quarterly is realistic for most agencies. Look for accounts belonging to people who left, permissions granted for a one-off task two years ago, and partner accounts that outlived the partnership. This is dull and it is the highest-value hour in your security calendar.

The same principle applies to documents in transit. Sending a passport scan as an email attachment or a chat image creates copies you will never retrieve. A portal link that expires, with access tied to an account, is a retention decision as much as a security one, and it is why centralised document management does more for retention than any policy document.

Three recurring events test whether your policy is real.

A client asks you to delete their data. You need to find every copy — which is what the data map is for — decide what you are obliged to keep despite the request, such as records required by tax or regulatory rules, delete the rest, and tell the client plainly what was removed and what was retained and why. Doing this within a defined timeframe requires knowing where things are before the request arrives.

A staff member leaves. Revoke access the same day, not at the end of the month. Retrieve or wipe devices. Check for local copies, personal cloud accounts and forwarded email. Reassign their open cases so nothing sits in an inbox nobody monitors. A leaver's access is the single most common way old client data escapes an agency.

A partner relationship ends. Ask in writing for confirmation that they have deleted or returned the client data they hold, and record the response. Close their accounts in your system immediately, including any portal or referral logins. Partner accounts left active after a relationship ends are a quiet, long-lived exposure.

Each of these is easier when data was centralised in the first place. When client documents live in one access-controlled system rather than across drives, mailboxes and phones, revoking one account genuinely removes access. Anyvisa tripled its monthly capacity after moving to a single platform, and the reason retention and access became manageable at the same time is the same reason throughput improved: there was one place to look.

A retention policy that depends on someone remembering to do something on a Friday will not survive a busy season. The parts that can be automated should be.

The mechanics are unglamorous. Record a closure date on every case so the clock has a start. Tag data categories so a rule can act on them. Set a reminder or a scheduled job that surfaces cases past their retention period. Run deletion as a reviewed batch — someone approves the list, the system executes it, the log records it. Reserve the manual work for the exceptions: legal holds, disputed cases, clients who have asked for something specific.

Do not expect a platform to solve this on its own. A system can automate reminders and bulk actions inside itself, and a good admin panel gives you the roles and permissions the policy assumes. It cannot delete an attachment from a consultant's personal mailbox, and it cannot decide your periods for you. Those remain your decisions and your discipline.

Start small if the whole thing feels heavy. Pick the highest-risk category — identity and financial supporting documents on closed cases — set one period for it, and execute one deletion batch. The first batch is the hard one. After that it is routine, and the policy becomes something your agency does rather than something it wrote.

If you are choosing or replacing a system, ask the vendor directly about retention: what deletion actually removes, how long backups persist, what the access model looks like, and whether the audit log survives a record deletion. Our answer on whether VisaCRM is GDPR compliant covers our side of those questions, and you are welcome to bring the rest to a walkthrough.