Transfer Research Files Before You Close the Account

An implementation checklist for lab-staff file offboarding is an exit-file walk, not a security essay. Revoke access only after ownership and copies are named. Prefer transferring every research object the departing person still answers for. Reject a same-day account close that orphans maps.

External collaborator permissions still own share-in. SSO join-and-leave still owns leftover login. The security essay mentions offboarding inside a longer access-and-backup piece. This page only walks research files. It does not design the identity connector. It does not complete 21 CFR Part 11.

Revoke Is Last Not First

Implementation checklist for lab-staff file offboarding is the gate a PI runs before a student, technician, or contractor loses access. The outcome is not a closed account. The outcome is a named remaining owner for every map, record, and copy the departing person still held, plus a revoke that happens after those names exist. If revoke comes first, the lab inherits a lockout. The files may still exist. Nobody remaining can find or claim them.

The search asks for a lab staff offboarding checklist for research files. Drop the product brochure. The walk below is an operational heuristic. It is not a legal termination statute. A PI who only asks IT to disable the account will discover the unpublished constructs after the password is already dead.

Walk the Exit-File Checks

Run the walk while the departing person can still open their own objects. Do not start after the last day if you can avoid it.

1. Inventory the objects. List maps, experiment records, instrument files, and personal exports the person created or still owns. Checkpoint: the list is written. “Everything in their folder” is not a list.
2. Assign a remaining owner to each object. The owner is a person who will answer questions next month, not a shared mailbox. Checkpoint: every row has a remaining name.
3. Name remaining copies. Write where else the same object lives: a team folder, a core submission, a laptop, a USB stick. Checkpoint: copies are listed even when the answer is “none known.”
4. Move or re-permission the authoritative copy. The remaining owner must open it before the departing account is closed. Checkpoint: a remaining person opens the object today.
5. Collect or destroy unofficial copies according to lab policy. Checkpoint: a laptop or personal cloud copy is either transferred or written as an accepted residual risk. Do not invent a wipe you did not do.
6. Revoke access last. Close the account, shared links, and group memberships after the five checks pass. Checkpoint: the departed account cannot open the objects, and the remaining owner still can.

If any checkpoint fails, stop. Do not revoke to meet an HR calendar if the remaining owner has not opened the files. A calendar is not verification. What read-only means is useful if the person needs a short read window during transfer. That definition is not this walk.

A worked fail is a graduating student whose SnapGene folder lived only under their university account. IT revoked on the last day. The PI inherited a permission error and a nickname list in email. Intake of those files was never done. Offboarding failed at the owner checkpoint. The fix is a remaining owner who opened each object while the student could still share. A second fail is a contractor who exported every map to a personal drive and then left. Inventory missed the export. Revoke of the lab account was tidy and irrelevant.

Expected Result and Verification

The walk is done when a remaining person can open every named object and the departed account cannot. Verification is not an HR ticket marked complete.

• Every listed object has a remaining owner who opened it.
• Known copies are named, including “none known.”
• The departed account cannot open the authoritative copies.
• A later experiment can cite those objects without asking the person who left.

Common failures are a group folder that still uses the departed person as the only admin, a personal cloud copy nobody wrote down, and a revoke that happened before the remaining owner logged in. Those failures look like clean offboarding in IT. They are missing science. If verification cannot be completed, access is not ready to close. The files are not yet the lab’s.

Hold Permissions After Transfer

Use a permission surface after transfer, not as proof that transfer happened. After the walk, a workspace such as ZettaNote can hold the experiment records and ZettaFile can hold the project files under a remaining account. Official product language includes access levels and team file storage. Those are places the transferred objects may live. They are not an offboarding certificate. Official product copy mentions 21 CFR Part 11. Software alone does not complete that regulation. Closing an account is not a compliance event. This page does not claim a Zetta SSO feature; leftover login stays on the SSO sibling. Golden Gate is not a Zetta feature and does not belong here.

If the PI still closes accounts first and hunts files later, you do not have an exit process. You have a lockout habit. Name the owner. Name the copies. Then revoke.

Academic calendars create a special fail. The student is gone, the university account is closed by central IT, and the PI learns about it from a bounce. That calendar is not this walk’s enemy. Surprise is. Ask for a file inventory two weeks before the last day. If central IT will revoke on a fixed date, finish owner and copy checks before that date or request a short read-only window. Read-only is a transfer aid. It is not a substitute for a remaining owner. A read-only departing account that still holds the only admin bit on a folder is still a lockout waiting to happen.

Company offboarding adds export risk that this walk must name and then hand to the IP page. A departing contractor who already downloaded unpublished maps is not fixed by closing the notebook. Write the residual copy as a known fact. Then score export on the cloud-IP sibling if the lab is deciding whether the next contractor should have had download at all. This page does not score export policy. It only refuses to pretend revoke erased a copy that already left. Identity leave on the SSO sibling can run the same week. Run it after the remaining owner can open the authoritative files. Two siblings, two jobs, one calendar.

Frequently Asked Questions

Should a departing account be closed before files are reassigned?

No. Name the new owner and remaining copies first. Revoke is last. A closed account cannot finish the transfer.

Is this the same walk as collaborator share-in?

No. Share-in decides who may enter. This walk decides how someone leaves. The direction is the opposite job.