Privacy & compliance

How long should you keep client files?

By Yungle·Updated ·4 min read

Key takeaways

  • For most client work, one to three years after a project closes — but having chosen, written down and enforced a period matters more than the number.
  • Split client files into deliverables, working files, personal data and financial records, and give each its own period.
  • Keeping everything forever is the quiet failure: under the GDPR it breaches storage limitation, and it turns a lost drive into a large breach.
Contents
  1. Both directions cost something
  2. How to pick a period
  3. Split "client files" into four
  4. Make something actually delete
  5. Tell your clients
  6. The compliance framing
  7. If the service decides for you

Long enough to do the job and meet your obligations, and no longer. For most creative and professional work that lands between one and three years after a project closes — but the exact number matters far less than having chosen one, written it down, and having something that actually deletes files when the date arrives.

Retention usually gets treated as a storage question. It is a risk question. Every file you keep that contains other people's information is a liability you carry, and most people carry far more than they realise.

Both directions cost something

Too short, and you cannot re-deliver when a client comes back, you have no evidence if the work is disputed, and you re-upload things at your own expense. The archetype is the expired link and a client who needs the file today.

Too long, and you hold personal data with no current purpose. Under the GDPR, storage limitation is a principle in its own right: personal data must not be kept longer than necessary. Eight years of client shoots on a drive, with no policy, is not thrift. It is a breach waiting for a lost laptop, with a great many people in it.

The second failure is more common and far less visible, because nothing goes wrong until it goes very wrong.

A link that expires on its own schedule, next to one that lasts until you decide otherwise.

How to pick a period

Four inputs, in this order:

Legal and tax requirements. Invoices and financial records have statutory retention periods in most countries — often around seven years. That applies to the records, not usually to the files. You need the invoice for the wedding, not 40 GB of RAW.

Contracts. Read what you signed. Some client contracts require deletion at the end of the engagement; others require keeping things for a fixed period. Both exist, and they pull in opposite directions.

Professional need. How often do clients genuinely come back? For wedding photography, for years. For a social campaign, a few weeks. Use your actual experience, not an anxious guess.

Liability window. How long could a dispute realistically arise? This is often what argues for keeping deliverables longer than feels necessary.

Then write one sentence. For example: "Client deliverables are kept for two years after completion. Working files and RAW originals are deleted six months after final delivery. Financial records are kept for seven years."

That is a retention policy. It does not need to be longer.

Split "client files" into four

The single most useful move is to stop treating client files as one thing:

  • Deliverables — the finished work. Keep these longest. They are small next to everything else, and they are what clients come back for.
  • Working files — RAW, project files, unused takes. Enormous, rarely needed after sign-off, and the bulk of both your storage and your exposure. This is where firm deletion pays.
  • Personal data — anything identifying people, photographs of them included. Governed by law, not convenience.
  • Financial records — invoices and contracts. Statutory periods, tiny files. Keep them and stop thinking about it.

One period for all four is how people end up deleting something they needed, or hoarding everything.

Make something actually delete

A policy nobody carries out is worse than none, because it creates a written expectation you are visibly failing to meet.

  • Put deliverables somewhere with an expiry you set, so deletion is the default rather than a chore. On a paid plan, nothing expires unless you give it a date — which means you choose the date per delivery instead of inheriting someone else's.
  • Put a reminder in the calendar for anything that needs judgement. Twice a year is enough.
  • Delete on a schedule, not on a feeling. "I'll clear it out when I need the space" is how eight years accumulate.
  • Ask about backups. Deleting the working copy while three years of backups keep everything is the most common way a retention policy achieves nothing.

Tell your clients

Two sentences in your terms and in your delivery email:

"Your files stay available until [date]. Working files are deleted six months after delivery — tell us if you need them kept longer."

That prevents the surprised email in year two, turns deletion into a stated policy rather than something that looks careless, and gives the client a chance to ask for an exception before it matters.

The compliance framing

If you handle personal data on a client's behalf, you are their processor, and retention is one of the things the processing agreement should specify. What that agreement needs to contain. For special-category data — health, biometrics, anything about someone's private life — the case for short retention is much stronger, and the obligations are sharper.

A pleasant coincidence: the compliant answer and the cheap answer are usually the same. Data you deleted cannot leak, needs no securing, and costs nothing to store. It is also the largest environmental lever you actually control.

If the service decides for you

Free transfer tiers commonly delete within one to two weeks. That is a defensible outcome reached by accident — good for minimisation, bad if you needed the file.

The question is not whether the period is right. It is whether you chose it. If a service's default does your retention thinking, you do not have a policy; you have a coincidence. Services differ a lot in what you can control, and it is worth picking one whose defaults match a decision you actually made. If you deliver to clients for a living, Yungle for creatives shows how that looks in practice.

Yungle

We build and run Yungle, and we write everything here. Comparisons name competitors and credit them, every claim about another company comes from that company’s own documentation, and where we fall short it says so. More about Yungle.

Read next