When the Project Ends: How to Revoke Contractor Access Before the Agency Gets Burned

The project is done. The invoice is paid. The handoff Loom is in the Drive folder. What you probably haven't done: revoked the contractor's access to Figma, Notion, GitHub, Slack, and the four other tools they touched over the past six months. That access is sitting open right now — and it will keep sitting open until someone remembers to close it.

Why This Matters for Agencies Specifically

If you run a 10- to 50-person creative agency, dev shop, or design studio, your contractor roster cycles constantly. A typical project pulls in a designer for the brand kit, a developer for the build, a copywriter for the launch push. Each of them gets added to five or six tools. Most of those additions never get reversed.

For agencies managing client work, the stakes are higher than for a product startup. The files you're protecting aren't just yours — they're your client's unreleased campaign, their brand identity, their product roadmap. When a contractor's access lingers, you're not just exposing your own data. You're exposing your client's.

The Access Accumulation Problem

Here's how the pattern plays out. A contractor joins a project and the tool invites flow fast: add them to the project Slack channel, share the Figma file, give them access to the client's Linear board, create a Notion guest account, invite them to the GitHub repo, add them to the Google Drive folder.

The project ends. The contractor gets paid. And almost none of those invitations get reversed.

The reason is structural, not careless. The person who invited them — usually a project manager or the founder — isn't thinking about access management when the project closes. There's no trigger. No "project closed" event fires an access revocation workflow. The PM is already head-down on the next project.

Six months later, that same contractor might be working for a competing agency or one of your clients directly. They still have guest access to the Figma file with the unreleased brand identity. They can still read the Notion doc where you laid out the Q3 campaign strategy. They haven't done anything wrong — they just haven't been removed. And you have no idea.

This is the access accumulation problem. Every project you run adds to it. Almost no projects subtract from it.

Your Project-End Access Revocation Checklist

Run this on the day you mark a project complete — not a week later. The longer you wait, the more likely you are to forget the edge cases.

Step 1: Pull the tool list from memory and project notes Which tools did this contractor actually touch? Go through your project notes, Slack history, and your own memory. Common list for creative agencies: Figma, Notion, GitHub, Slack, Google Drive, Linear, Airtable, Miro, Loom, shared 1Password vaults, any client-specific tools they were granted access to.

Step 2: Screenshot current access levels before revoking Before removing anyone, take a screenshot of their current permissions. If they dispute something later, you have a record.

Step 3: Revoke workspace-level access first Slack and Notion both let you deactivate or remove guest accounts at the workspace level. Do this first — these tools carry the highest risk because they contain conversations, documents, and often links to everything else.

Step 4: Revoke file-level and repo-level access Figma, Google Drive, and GitHub require per-file, per-folder, or per-repo removal. This step is where agencies get lazy and leave gaps. Don't skip it.

Step 5: Rotate any shared credentials they had access to If the contractor used shared passwords, API keys, or service account credentials, rotate them at project end. This is non-negotiable if they had admin-level access to any client tool.

Tool-by-Tool: Where to Revoke and What Gets Missed

Figma The obvious move: remove them from the project. The non-obvious move: check if any files were shared directly with their personal email via "Share > Manage access." If you shared a client's Figma file directly (not through a team project), that invite lives at the file level and doesn't disappear when you remove them from the workspace. Also check shared prototype links — anyone with the link can still view even after access is revoked.

Notion Go to Settings > Members > Guests. Find the contractor and remove them. Removing a Notion guest removes them from all pages they were added to. However: they may have exported or saved content already. Notion doesn't log what was downloaded.

Slack Settings > Members, filter by "Guest." Deactivate the account. Deactivated guests lose access immediately, but their messages remain visible to your team. If they were on any channels with client information, note that they could have screenshotted or copied anything at any point.

GitHub Go to your org settings, then Teams. Remove them from any teams they're part of. Then check repo-level collaborators separately — direct repo invites don't automatically clear when you remove someone from a team. Two separate lists, two separate places to check.

Google Drive Check "Shared with [their email]" from your Drive search, and "Manage access" on any folders you shared directly. If your agency uses Google Workspace, also check the admin panel — they may have a guest identity in the directory that persists.

Linear, Airtable, and Miro Each of these has a workspace-level member list under Settings. Find it and remove them. These tools are frequently overlooked because they're used mid-project and forgotten — but Linear especially often contains unreleased roadmap items and client priorities.

1Password or Shared Password Vaults If they had access to a shared vault, remove them from the vault and rotate the passwords they could have seen. Removing someone from 1Password doesn't change the passwords they already know.

Building a Project-End Protocol That Actually Runs

The problem with ad-hoc access revocation is that it requires someone to remember at exactly the wrong moment. When a project closes, the team is already context-switching to the next one.

The fix is to make revocation a structural part of project close — not a separate task that gets scheduled and forgotten.

Option 1: Project-close template in your PM tool In Linear, Notion, or your PM tool of choice, create a "Project Close" task template that includes a required access revocation checklist. Every project gets this template when it moves to closed status. Assign it to the project lead. It doesn't close until the checklist is checked.

Option 2: Contractor offboarding form Create a short form — Notion, Typeform, or Google Form — that the project lead fills out whenever a contractor engagement ends. Fields: contractor name, project, tools they had access to. Form completion triggers the revocation steps. The ops person (or whoever handles this) can't mark the project complete without submitting the form.

Option 3: Optserv's contractor lifecycle flow Optserv lets you assign tool access to a contractor profile at project start. When the project ends, closing the contractor's profile in Optserv revokes access across connected tools — Slack, Figma, Notion, GitHub, and more — in a single flow. No list to remember, no manual removal, no missed invitations. For agencies running multiple concurrent contractors across multiple projects, this is the difference between a 30-minute revocation process per project and a one-click close. See also: the broader offboarding gap between HR software and IT tools.

FAQ

How long after a project ends do I have to revoke contractor access? Same day. The risk window starts the moment the engagement ends. If you can't run the full revocation checklist immediately, at minimum revoke Slack and Notion access the same day and schedule the rest for the following morning.

What if the contractor worked across multiple concurrent projects? Revoke access per project, not per person. If they're still active on another engagement, only remove access to the completed project's tools and files. Don't revoke everything until their last active project closes.

Do I need to tell the contractor I'm revoking their access? No legal requirement in most jurisdictions, but it's good practice to include a clause in your contractor agreement: "Access to company and client tools will be revoked within 24 hours of project completion." This sets expectations upfront and avoids confusion when someone tries to open a file they can no longer see.

What's the biggest access revocation mistake agencies make? Removing someone from Slack and assuming that's sufficient. Slack is social and visible — it feels like "the access." But Figma file shares, GitHub repo collaborator invites, and Google Drive folder shares are invisible and persistent. Most agencies don't check these consistently, and most contractors retain access to them long after a project closes.

Do contractors have any legal obligation to delete files after access is revoked? A well-drafted contractor agreement includes a clause requiring them to delete or return confidential materials at engagement end. That clause means nothing without access revocation — if they can still log in, the file is still theirs to use. Access revocation is the enforcement mechanism. For more on the access and audit side, see the agency contractor access audit checklist.

Build the Protocol Once, Run It Every Time

Optserv is built for agencies that cycle contractors fast. Assign tool access at project start, close it at project end — in one flow, across every tool. When a freelancer wraps up, you don't run a checklist. You close a profile.

Start free at app.optserv.ai →

Sources

• When a Freelancer Leaves, Who Still Has Access to Your Figma, Notion, and GitHub?
• The Agency Contractor Access Audit Checklist
• The Offboarding Gap: Why HR Software Won't Revoke Access