Who Backs Up Documentation Files After Delivery?

Everyone in the chain assumes someone else is holding the master copy. The photographer assumes the client downloaded everything. The client assumes the studio keeps a backup indefinitely. Whoever received the delivery link assumes it still points somewhere, and that the folder behind it hasn't quietly become three different folders with three different names. None of these assumptions are unreasonable on their own, and none of them get tested until a drive fails, a laptop gets replaced, or the person who actually received the files leaves the organization. What breaks first is rarely the files themselves. It's the shared understanding of who was supposed to be keeping them safe, and that understanding only exists if someone actually said it out loud at delivery time instead of leaving it to be assumed.

Delivery transfers access to the files, not custody of them. Custody has to be assigned on purpose, usually to one named person inside the organization rather than a department, and it should be decided out loud at delivery time rather than discovered later when a drive fails. A photographer's own archive is a courtesy that can help in a pinch, never a substitute for the client keeping a durable copy of their own in a second, genuinely separate location.

What Does Delivery Actually Transfer, and What Doesn't It Transfer?

Delivery transfers access: a download link, a shared folder, or a drive handed to whoever received the shoot. It does not transfer custody. Custody means an ongoing responsibility to keep a working copy safe, current, and findable years later, and that responsibility only exists if someone has actually agreed to hold it. A separate service agreement might say more, but the delivery mechanism itself only ever promised the handoff.

A link works the day it's sent and often for a while after. It can expire, get buried in an inbox, or point to a folder that gets reorganized later on. None of that is a flaw in the delivery itself. It's what happens when access gets treated as though it were the same thing as a backup.

The safest assumption at delivery is that nothing beyond the files reaching the recipient has been guaranteed. Whether those files get copied somewhere durable, checked periodically, and kept in a format someone can still open years from now is a separate question entirely, and it stays unanswered unless someone actually asks it and answers it out loud. In practice, most of the confusion at delivery time comes from nobody ever raising this question, not from anyone deliberately dropping the ball.

That gap between handing something over and someone actually taking responsibility for it is where documentation quietly goes missing. It rarely disappears all at once. It disappears because everyone involved assumed the other side already had it covered.

Is a Photographer's Own Archive a Reliable Long-Term Backup?

A photographer's own archive is a courtesy, not a guarantee. Most studios keep completed jobs on hand for some period after delivery as a convenience if a client needs a re-download, but that isn't the same as a formal, indefinite backup commitment, and an honest studio says so plainly instead of implying otherwise.

Storage fails, equipment gets replaced, and businesses change how they operate over time. A studio that promises to hold every job forever is making a promise it may not be able to keep, and clients who rely on that promise without ever confirming it are trusting an informal habit, not a system built for permanence. A studio might also change ownership, retire an old storage system, or simply stop offering long-term hosting as part of its own business decisions, none of which has anything to do with how well the original shoot was handled.

What we can say honestly is this: we keep a working archive of recent jobs for a period that helps with a quick re-delivery, and we don't treat that archive as the client's permanent record. Once files are delivered, we consider the client the owner of record, and we recommend treating their own copy as the one that actually matters.

That distinction matters because a client who assumes we're the backup, indefinitely and without asking, is planning around a resource that was never designed to work that way.

What's the Difference Between the Delivery Link, the Working Copy, and the Master File?

Three different copies tend to exist after a delivery: the original delivery link, wherever it still points; the working copy someone actually opens and uses day to day; and the master file nobody has touched in a year. Treating any one of these as automatically identical to the others is where records quietly start to diverge. Confusing the delivery link with the master file, for instance, is an easy and common mistake to make.

The delivery link is the least reliable of the three. It can expire on a schedule the recipient never checked, sit behind a login that changes when someone leaves, or simply stop being current once a revised set of files goes out later. Treating it as the permanent record means trusting infrastructure that was built for a one-time handoff.

The working copy is whatever version someone is actually pulling from for a website, a grant application, or a print run. It tends to stay current because someone needs it to be, but it also tends to live somewhere ad hoc: a desktop, a shared drive folder with an informal name, a laptop belonging to one specific person.

The master file is supposed to be the authoritative copy, but it's often the one nobody opens, which means nobody notices when it goes stale, gets moved, or stops matching what the working copy has become. A record that's technically preserved but silently out of step with reality isn't much safer than no record at all.

Who Inside an Organization Should Own the Backup?

Backup responsibility belongs to a named person, not a department. A department can hold a folder without anyone in it actually checking that the files still open, are still current, or still live where the last person to touch them expected. Naming one person closes that gap; naming a department leaves it open by default.

When that named role sits vacant, the files themselves usually still exist. What disappears first is the knowledge of which folder is current, who last touched it, and whether a since-departed staff member's personal drive was actually where the real copy lived. The files survive. The map to them doesn't.

This doesn't need to be a dedicated archivist or a formal records role. A communications lead, an office manager, a collection manager, or whoever already maintains the website and grant files can hold this as one clearly stated part of an existing job. What matters is that everyone else knows to route a new delivery, a staff departure, or a where-is-this-file question to that same person. Writing the arrangement down somewhere visible, even a single line in a shared document, keeps the responsibility from quietly evaporating the next time that person's job changes.

Without that single point of ownership, a delivery from a shoot two years ago becomes a scavenger hunt the moment the one person who remembered where it lived is no longer around to ask.

What Does It Actually Mean to Keep More Than One Copy in More Than One Place?

It means the same files exist in at least two separate locations that don't share a single point of failure, so one lost laptop, one failed drive, or one deleted account can't take the only copy with it. It's a habit of redundancy, not a specific tool, service, or format. That second location doesn't need to be exotic. It just needs to be genuinely separate from the first, not a second folder on the same device or a second login tied to the same account.

The logic isn't complicated. A single copy, however carefully stored, is one accident away from being the last copy that ever existed. Two copies in two genuinely different places mean the accident that takes out one of them almost never takes out the other at the same time, which is the entire point of keeping more than one.

This isn't a technical checklist, and it isn't something we specify for a client's internal systems. It's a decision worth making explicit at delivery: has anyone actually agreed that this file exists in more than one place, and does that second place belong to the organization rather than to a single person's own devices. Confirming that answer is a short conversation, not a project.

A single copy sitting on one device, however well organized the folder looks, is still a single point of failure no matter how carefully everything inside it has been labeled and sorted.

Why Do Documentation Files Usually Outlast the Staff Who Received Them?

Documentation files usually outlast a staff change. What doesn't survive is the knowledge of which folder is current, which version is the one actually in use, and who to ask when something looks off. The files sit exactly where they were left. The context for reading them walks out the door.

A departing staff member rarely deletes anything on the way out, but they also rarely leave a note explaining which of three similarly named folders is the real one, or that the copy on the shared drive is two revisions behind the one they'd been using locally. That context lived in their head, not in the file system itself. Even a well-meaning handoff conversation rarely captures every detail, since the departing person usually doesn't realize how much informal knowledge they're carrying until the questions start arriving after they're already gone.

Months later, someone new pulls up the folder for a grant application or a website refresh and finds several dated exports with no obvious hierarchy between them. Nothing is technically lost. Everything is just harder to trust than it should be, and confirming which version is current takes real time that a clear handoff would have saved. That confirmation step, comparing dates, opening a few files, asking around, is time nobody budgeted for, which is exactly why it tends to get skipped.

The fix isn't better software. It's a habit of documenting the handoff itself, not just the files, so the next person inherits an answer instead of a guessing game.

What Should You Ask For at Delivery So Backup Is Even Possible Later?

Ask for files organized in a way that makes sense to someone who wasn't at the shoot: clear, consistent naming, a simple folder structure, and a short note explaining what each set of files is for. Backup only works when the person handling it later can tell what they're looking at without asking around first.

A delivery with clean, consistent file names and a logical folder structure is far easier to back up correctly than a technically complete but disorganized one, because whoever inherits it later can tell at a glance what's current and what's an older pass or a duplicate. Volume doesn't help anyone if nobody can tell what they're looking at. A folder full of files named only by date or camera number forces every future user to open each one just to figure out what it actually shows.

We name and organize files at the point of delivery specifically so a new hire, a board member, or a staff member three years from now can open the folder cold and understand it. That small amount of extra care at delivery pays off far more than a rescue project later, when someone is trying to reconstruct which version is actually the real one.

A well-organized delivery is a gift to whoever inherits it, and inheriting documentation is exactly what happens the moment the person who first received it moves on to something else.

How Do You Check a Year Later That the Record Still Opens?

Once a year, open a sample of the delivered files on a current device, using current software, and confirm they still open correctly and still match what's actually on display or in use. If a file won't open, looks corrupted, or turns out to be an old version, that's the moment to flag it, not the moment a deadline arrives. This is a habit worth building into an existing calendar reminder or annual review, rather than treating it as a special project that needs its own planning.

This doesn't need to be elaborate. Pick a handful of representative files rather than the entire archive, and check that they open, look right, and are dated the way the record claims. A short annual check catches a quiet problem, a corrupted file, an outdated export, a broken link, while it's still a small fix instead of a scramble.

When a file fails that check, the fix is usually simple if it's caught early: pull a fresh copy from wherever the second, redundant location lives, or reach back out to whoever delivered the files originally if that copy is the only one still known to be good. Waiting until the file is actually needed turns a small fix into an emergency.

A record nobody has opened in years isn't really a record. It's a folder waiting to fail a test that nobody thought to run until it mattered.