Why this one always slips
Granting access has a forcing function. Someone cannot start work, so it happens immediately.
Removing access has none. Nothing breaks. Nobody is blocked. No customer complains. The only signal that it has not happened is an absence, and absences do not generate reminders.
On top of that there is a small social cost. Revoking access feels like a statement about trust, particularly with a contractor you liked and might work with again. So it gets deferred, and deferred, and then it is eighteen months later and a developer who did one theme change still has admin.
Understanding both halves matters, because the fix has to address the structural problem and the social one. A checklist alone does not survive the awkwardness.
Solve the social problem first
The single most effective move costs nothing: agree the end date when the access is granted.
One line at the start of the engagement. "Access runs to the end of the project, and we remove it as standard when we close a project out. If you need it after that, just say and we will reopen it."
That sentence converts revocation from a judgement about a person into a policy that applies to everyone. Nobody is offended by a policy. Almost every professional contractor expects it, and many will think better of you for having one, because it signals you handle client data properly and they are also handing you their reputation.
This is the same move as proposing scoped access up front rather than being given the keys to everything, which we covered in giving clients visibility without giving them admin. Asking for less, earlier, is cheap trust.
Know what you granted
The main practical obstacle is that most stores cannot answer the question "what does this person have access to?"
Access accumulates from different directions over an engagement. A Shopify staff account at the start. Then a workspace invite. Then someone shares a spreadsheet. Then they are added to a supplier email thread. Then they get a login for the courier portal because it was quicker than relaying tracking numbers.
Six months later, whoever handles the offboarding remembers the first item and forgets the other four.
The fix is a per-engagement record, written at the point of granting rather than reconstructed at the end. It does not need to be sophisticated. A short list against the contractor's name, updated whenever something new is shared. The discipline is in adding to it in the moment, which takes ten seconds and is the only part that requires any habit.
The checklist
Work through this at close-out, in roughly this order.
- Shopify staff account. Remove rather than leave dormant. A dormant account is a live credential.
- Workspace or chat access. Remove from rooms, or remove entirely. If you want to preserve the conversation history, removing the person does not remove what they wrote.
- Shared documents and drives. The most commonly missed, because sharing is granular and invisible. Check the folders as well as individual files.
- Third-party tools. Courier portals, email platforms, analytics, ad accounts, anything they were given a seat in. This is where the per-engagement record earns its keep.
- Shared credentials. If a password was shared rather than an individual account created, that password now needs changing, and everyone else who uses it needs to know. This is the item people quietly skip because it is inconvenient.
- App and API access. If they installed anything or generated keys, review whether those are still needed and who owns them now.
- Payment and financial access. Rare for contractors and worth checking explicitly, because the consequences are the largest.
- Confirm in writing. A short note saying the engagement is closed and access has been removed. Protects both sides and creates a record.
The handover that should happen at the same time
Removing access without capturing knowledge trades one problem for another. Before the account goes:
- What did they set up that nobody else understands? Automations, integrations, scheduled jobs, anything running unattended.
- What is in their head about why? Not what they built, but the reasoning. This is what expires fastest and it is the expensive part to recover.
- What did they leave unfinished? Including things they meant to mention and did not.
Fifteen minutes on a call, written down as you go. Trying to retrieve this three months later means paying them again to remember, and they will remember less than you hope.
When the ending is not clean
Most engagements end fine. Occasionally one ends badly: a dispute, an unpaid invoice, a project that went wrong.
In that situation, remove access first and promptly, then have the conversation. This is not paranoia about the individual; it is that a live credential during a dispute is a risk to both parties, and removing it early removes the possibility of an accusation later.
Do it factually and without drama. "We have closed access as part of our standard close-out" is accurate, unremarkable, and true if you have the policy from the first section.
The best time to build an offboarding habit is during an engagement that is going well, because that is when it feels unnecessary and costs nothing to establish.
The audit worth running today
List everyone with access to anything, then mark each as current staff, current contractor, or neither. The third pile is your finding.
Most stores that have never done this find at least one account belonging to someone who stopped working with them over a year ago. It takes twenty minutes, requires no tooling, and is the highest-value security work available to a small store precisely because it costs nothing but attention.
The register, in practice
The per-engagement record only works if it is trivial to maintain, so keep the bar low. A short list against each contractor's name, in whatever your team already uses. One line per grant, added at the moment of granting.
Three columns are enough: what they were given, when, and by whom. That last one matters more than expected, because six months later the person who shared a folder is the only one who remembers it existed, and knowing who to ask beats reconstructing from scratch.
If maintaining a register sounds like more discipline than your team has, there is a cruder version that still beats nothing: whenever you grant a contractor access to anything, post it in the room where the engagement is discussed. No separate document, no new habit, and the search history becomes the register.
What you should get back, not just take away
Offboarding is usually framed as removal, which misses half of it. Some things belong to you and are sitting somewhere else.
- Source files. Design files, original images, anything where you have the output but not the editable version. Chasing this a year later is expensive and sometimes impossible.
- Accounts registered in their name. A domain, a service, a tool subscription set up on their email during the project. These are the ones that eventually expire without warning.
- Documentation of anything bespoke. Even a paragraph. Whatever they built that nobody else understands is a dependency you now own.
Ask for these while the relationship is warm and the invoice is fresh. Both facts make the request routine, and neither will be true in six months.
The recurring calendar entry
Even with a policy and a register, individual offboardings get missed, usually because an engagement ended vaguely rather than on a date. Work tapered off, the last invoice was paid, and nobody declared it finished.
The catch-all is a quarterly reminder in one person's calendar: review who has access to what. Fifteen minutes, four times a year.
It works because it does not depend on remembering at the right moment. Whatever slipped through gets caught within three months rather than within three years, and three months of unnecessary access is a completely different risk from three years of it.
Give it to a specific person rather than adding it to a shared list. This is the same principle that applies everywhere else in operations: a recurring task owned by everyone is owned by nobody, and access review is unusually easy to defer because nothing breaks when you do.
Common questions
When should contractor access be removed?
At project close-out, as standard. Agreeing the end date when access is granted removes the awkwardness, because revocation becomes policy rather than a judgement about the person.
What gets missed most often?
Shared documents and third-party tool seats, because sharing is granular and invisible. Shared passwords are a close second, since changing them is inconvenient and easy to defer.
Is it rude to revoke a contractor's access?
No, and most professionals expect it. A stated policy applied to everyone reads as competence rather than suspicion, and contractors handling client data generally prefer working with clients who have one.
What if we might work with them again?
Remove access anyway and say you will reopen it if they return. Reinstating takes minutes; a dormant credential is a live risk for however long it sits there.
What should we capture before removing access?
Anything they set up that runs unattended, the reasoning behind it, and whatever is unfinished. The reasoning expires fastest and is the most expensive thing to recover later.