Client offboarding checklist for final files, ownership and access

After the final files arrive, confirm three things separately: the client can find and use the agreed version, a named person can manage its working location, and each remaining permission has an agreed purpose or an agreed ending. A delivery receipt answers the first question. It does not answer the other two.

Use a short record for the decisions that remain. Mark a row confirmed when the agreed result has been checked, rather than when you send a request. Keep an unknown administrator or an unanswered retention decision open, with a person and a next checkpoint, while other rows move forward.

Download the blank client offboarding CSV, the fictional worked CSV and the use notes and example references (TXT). The worked file keeps the same six row IDs across three snapshots, so you can follow what changed. These are records to adapt, not files that change account access.

A worked close-out with two rows still on hold

Ivo at Harbour Paper Studio has delivered Larkspur Gallery’s approved poster PDF and editable layout package v4. Nia is the client’s contact. Elliot manages the client’s named working locations. All people, businesses, dates, agreements and confirmation records in this example are invented. No files were transferred, permissions changed or messages sent through a real service.

At the first snapshot, S0 on 10 November 2026, the pack has been sent and all six checks are pending. By S1, at 14:00 on 11 November, the record reads:

Four confirmed rows do not mean four permissions were removed. One confirms receipt, one confirms who controls the location, one retains support access and one records an ending. The two held rows stop the overall record from being closed.

The CSV preserves S0, S1 and a later S2. Filter one snapshot at a time; its 18 data rows represent six checks at three points, not 18 separate assets. The TXT explains the invented agreement and evidence labels used below.

Confirm the recipient and the person who can manage access

Ask the recipient to identify the agreed pack and version, and confirm they can open the intended items through their own approved access. In this example, Nia’s reply names both v4 items. An acknowledgement such as “thanks, received” would not establish that the editable package was found as well as the PDF.

Then establish who will be responsible for that location after delivery, and who is authorised to administer access to it. Nia and Elliot can be different people. The person who requested the work, the person who received a link and the person who can change access need not be the same.

In this record, “owner” means the person responsible for the working location; “admin” means the person authorised to administer the specified access. Neither label decides copyright or contractual ownership. The record should point to the relevant agreement for rights questions rather than treating a role name or delivery receipt as a transfer of rights.

For OF-02, Nia confirms responsibility and Elliot confirms administration through the client’s approved process. No ownership-transfer operation is proposed or reported. If the final pack is still held only in the studio’s location, record that gap and agree the destination and responsible person before treating client control as confirmed.

An unknown role needs a small, concrete inquiry: “Who administers REV-OLD-01, and can that person confirm the authorised handling?” It should not be filled with the last person who replied to the project email.

Agree what stays before asking for access to end

Make the decision specific to the item, person and purpose. “Remove our access” is too broad when one correction still needs a limited support arrangement.

For OF-03, Nia and Ivo have separately agreed a correction that needs Ivo to read and comment on SUP-01. Elliot checks that named permission against agreement AG-02. The next review is 19 November 2026 at 10:00, with the example’s stated offset of +11:00. Recording that checkpoint neither extends the support scope nor makes access expire automatically.

OF-04 is different: Nia authorises the ending of Ivo’s editor access to BOARD-01 under AG-03. It does not authorise removing the support permission or deleting the board’s contents.

For each proposed change, record the current known access, the handling agreed, the authorising reference and the person responsible for the action. Ask the authorised administrator to establish what controls apply to the actual service and account. If a role or required control is unknown, keep the proposal separate from an instruction ready to carry out.

Dropbox’s freelancer offboarding guidance also raises final files, permissions and shared links as distinct close-out questions. It is provider guidance written largely for teams hiring freelancers. The record here is a service-neutral proposal; it does not assume Dropbox controls, or the same transfer and removal rules across other services.

The working-copy archive needs its own decision. At S1, Nia has not resolved the instruction applicable to ARC-01. OF-06 therefore stays on hold while she obtains the relevant agreement and requirements and replies to Ivo. An unanswered retention question is not an authorisation to delete. This checklist sets no storage period or deletion deadline.

Update only the rows the evidence supports

Keep the row ID when its status changes. That lets someone tell the difference between a resolved issue and an old issue that disappeared from the list.

Here is what happens to the three rows that concern ending access or resolving the archive decision. All times in the example use the explicit offset +11:00.

In the invented EV-05 record, Rowan records ending REV-OLD-01 at 11:30 on 12 November. Elliot separately checks the named link at 11:45 and records it as unavailable. The row then becomes Confirmed at S2. Its scope is that link; it does not certify the removal of all other routes, downloaded copies or backups.

For a real row, agree what will count as a useful check before the action. Record what the authorised person did, what was checked afterwards, who checked it and the evidence reference. Confirm that the access the client needs still works. Keep the check within material and accounts the participants are authorised to use.

Ask the administrator to consider the access routes relevant to the service, such as a separate review link or a wider folder permission where applicable. Do not infer that one changed permission ends every route. If a check fails, a required role remains unknown or unexpected sharing appears, record the result and route it to the client’s authorised contact. A sent request, an unavailable check or silence from the client is not a successful ending.

At S2, five checks are confirmed and OF-06 remains on hold. The board-access and old-link endings have evidence in the example. The archive decision does not. The 19 November support checkpoint remains in OF-03; it has not happened yet.

Send a close-out note that leaves the remaining decision visible

The note should tell the client what they now have, which arrangements remain and what still needs an answer. It should not turn a partial result into “everything is closed”. For the fictional S2 record, Ivo could write:

Nia, the agreed poster PDF and editable layout package v4 are in LARK-FINAL-01, and your receipt is recorded in EV-01. You remain responsible for that location, with Elliot administering access.

The agreed endings for my BOARD-01 editor access and REV-OLD-01 are recorded in EV-04 and EV-05. My limited SUP-01 support-notes access remains for the separately agreed correction, with Elliot’s review set for 19 November at 10:00+11:00.

ARC-01 remains open: please obtain the applicable retention instruction and reply by 12 November at 16:00+11:00. No deletion is authorised in this record. I will update OF-06 when the decision and any required check are recorded.

This draft summarises the stated agreements; sending it does not create a missing agreement or establish that a requested action happened. If the client asks for another deliverable in reply, record that request and its agreed handling separately instead of silently widening the support row.

Use the CSV without turning a proposal into evidence

Start with the blank file and one item you need to resolve. You do not need to reproduce all six checks if your project has different needs.

1. Identify the pack, location, permission or link precisely. Use references its readers are authorised to see, and name the recipient, operational owner and administrator separately.
2. Record what is currently known and the proposed handling. Write “Unknown” or “Unverified” where appropriate; a filled cell is not confirmation.
3. Add the agreement reference and the person responsible for the authorised action or inquiry. Keep unresolved prerequisites on Hold, with a next owner and checkpoint.
4. After the check, record its actual result, scope, evidence, checker and time. Use Confirmed only for the outcome that row describes. A retained arrangement can be confirmed without being ended.
5. Keep a dated version or your organisation’s approved history. Review the latest snapshot for current work; keep earlier records available for the people entitled to see them.

The CSV does not send reminders, obtain consent, grant or revoke permissions, or create an audit history automatically. Its notes file explains the columns and status values. It also describes every fictional reference, so you are not being asked to find evidence that exists only in an unnamed folder.

If you use a spreadsheet, import identifiers, references, timestamps and free text as text and compare them with the source file. These CSVs have been structurally checked as local files; opening, saving and shared editing in Office or Excel have not been tested. Keep credentials, recovery codes and secret tokens out of the record. Follow your tool’s approved plain-text handling for added values that might be interpreted as formulas.

Questions before you close the record

What if the client asks me to delete every copy?

Record the request and identify the files, locations, person authorised to decide and applicable agreement or requirements before agreeing the action. If the scope is unclear, keep it on Hold with a named follow-up. Do not promise that a checklist or a single access change erases every downloaded copy or backup.

Does naming the client as owner transfer the rights in the files?

No transfer is performed or established by this record. Its operational owner field identifies responsibility for the working location. Refer any question about intellectual-property rights or contractual ownership to the relevant agreement and appropriate advice rather than treating a completed cell as the answer.

Can I close the whole record while one row is on hold?

In this proposed workflow, confirm the resolved rows and leave the overall record open. State the outstanding decision, responsible person and next checkpoint in the close-out note. OF-06 at S2 shows that a useful partial handoff can coexist with an unresolved archive decision.

Choose one outstanding item and fill its row with the person who can resolve it. If your work is still at the brief, production or delivery-check stage, use the freelance project checklist for those earlier checks. Return to this record when the final files have arrived and the remaining question is who manages what next.