When a Freelancer Leaves, Who Still Has Access to Your Figma, Notion, and GitHub?

When a freelancer wraps up and you stop paying their invoice, their access to your tools doesn't automatically stop. Figma seats stay open. GitHub org memberships persist. Notion workspaces stay shared. Slack remains active. For agencies and dev shops cycling through 10–30 contractors a year, this adds up to a sprawling list of former contributors who technically still have a door into your client work, your codebase, and your internal operations. Most of the time nothing happens. But "most of the time" is a bad security policy.

Why This Hits Agencies Harder Than Other Businesses

A full-time employee leaves once. A freelancer-heavy agency offboards people constantly — designers on 6-week projects, devs on 3-month engagements, copywriters on retainer who quietly stop responding. Each departure is a potential access leak, and the frequency means the problem compounds.

Verizon's 2025 Data Breach Investigations Report found that cybersecurity incidents from third-party access doubled between 2024 and 2025, from 15% to 30% of incidents. Freelancers and contractors are third-party access by definition. One study of 500 IT decision-makers found 50% of former employee accounts remain active more than a day after departure, and 32% of organizations take over a week to fully de-provision someone.

For an agency running five active freelancers at a time with 30% annual turnover, that's 1–2 people per month whose access you need to manually revoke across every tool they touched. The math is not on your side.

Tool-by-Tool: What Lingers After a Freelancer Leaves

Figma

A freelancer added as an Editor to your Figma org keeps that seat indefinitely after the project ends — unless an admin manually removes them. They can still open every file in the org, including client work for projects they were never involved in. Figma doesn't automatically expire external collaborators. The access is yours to clean up.

Notion

If you added a freelancer to your Notion workspace — to share a brief, a wiki, a project tracker — they remain a workspace member until someone removes them. They can browse everything their permission level allows, which in many smaller workspaces means most of the workspace. "Guest" access is scoped, but full member access is not.

GitHub

A freelancer added to your GitHub org as a member retains that membership after the engagement ends. Depending on your repo visibility settings, they may have read access to all private repos in the org — not just the one they worked on. If they were added as an admin or given direct repo write access, that persists too. GitHub org membership does not expire automatically.

Slack

Removing someone from Slack is usually the first thing agencies remember to do because Slack is visible — you see them in channels. But "deactivating" a Slack account is not the same as removing it. Deactivated accounts lose channel access but the profile persists and can be reactivated. More importantly, deactivating Slack does nothing about the 11 other tools the person also had access to.

1Password

If you added a freelancer to a 1Password team or shared vault — a common pattern for sharing staging credentials, API keys, or client login details — they remain a vault member until explicitly removed. Every credential in that shared vault is still readable by them after the engagement ends.

Linear, Vercel, and AWS Console

Linear workspaces, Vercel team memberships, and AWS IAM users or console access are almost never the first things on anyone's offboarding checklist. They're the second or third tier — tools you added the person to because it was convenient mid-project. They're also the ones most likely to still be active 90 days after the engagement ended, because nobody thought to check.

Three Scenarios That Play Out More Often Than You'd Think

The designer who kept the client work. A freelance designer finishes a 6-week branding project. You end the contract, stop sending invoices. Their Figma seat is still open. Three months later they launch their portfolio site — using mockups of your client's unreleased product. The client calls you. You have no contractual issue with the designer because the NDA covers intentional disclosure, not passively available access. But the relationship with the client is damaged anyway.

The dev with the production database. A contractor builds an integration for three months and is added to your AWS account for direct database access. The project ships, the engagement ends. A year later you discover they still have an active IAM user with read access to production. They haven't done anything with it, but you have no way of knowing what they've read.

The GitHub org ghost. A freelance developer is added to your GitHub org for a single private repo. The project ends, you forget to remove them. Six months later, you add a second private repo with a new client's codebase. Because they're an org member, they now have read access to that repo too — a client they've never worked with, code they were never meant to see.

The 5-Minute Audit You Can Run Right Now

This won't catch everything, but it will surface the most obvious gaps. Block 20 minutes and go through each tool:

Figma → Admin → Members → filter by "Editor." Sort by last active. Anyone who hasn't opened Figma in 60+ days and isn't a current contractor is a candidate for removal.

Notion → Settings → Members. Look for anyone listed as a member who isn't a current employee or active contractor. Guests are scoped, but full members can see broadly.

GitHub → Your org → People. Look for members who aren't on your current team. Check "Outside collaborators" too — these are repo-specific accesses that are even easier to forget.

Slack → Admin → Members → filter "Deactivated." Confirm that everyone deactivated has also been removed from shared channels. Then check active members for anyone not currently engaged.

1Password → People → Team members. Anyone who isn't currently employed or under active contract should be removed.

Linear → Settings → Members. Remove anyone not on a current project.

Vercel → Team settings → Members. Check for inactive members or outside contributors.

AWS → IAM → Users. Any IAM user for a contractor should have been time-limited or tagged. Look for users with last activity more than 90 days ago who aren't current employees.

Keep a note of who you remove and when. That's your audit trail if a client ever asks.

Why Manual Checklists Keep Failing You

The audit above works once. It breaks down as a repeatable process because it depends entirely on someone remembering to do it, knowing which tools the person had access to, having admin rights in all of them, and finding the time to do it on the same day the engagement ends — often the same day you're also dealing with final invoices, handoff calls, and the next project kicking off.

The failure mode isn't laziness. It's that removing someone from 8 tools manually is 8 separate tasks spread across 8 separate admin panels, all requiring context about which tools that specific person used. That context lives in someone's head, not in a system.

Agencies with high contractor turnover end up in one of two states: they do the audit reactively (after something goes wrong) or they hire someone whose job partly involves manually running through this checklist every time a contractor offboards. Neither is a good answer at $10–50k monthly revenue.

For deeper context on why this gap exists even in companies using proper HR software, see The Offboarding Gap: Why HR Software Won't Revoke Access. And if you want to see the full access-revocation approach for employees (not just contractors), how to revoke employee access automatically covers the step-by-step.

FAQ

Does ending a freelancer's contract automatically remove their tool access?

No. Stopping payment ends the financial relationship, not the access relationship. Every SaaS tool manages its own user list independently. Unless someone manually removes the person from each tool, or you have a system that does it automatically, the access persists indefinitely.

Is a freelancer keeping access to my tools illegal?

Retaining access to systems after an engagement ends without authorization can be a violation of computer fraud laws (the CFAA in the US, similar statutes elsewhere), depending on whether they actually access the systems. Simply having access that wasn't revoked is in a grey area. But if they use that access after the engagement ends — even for something that seems benign, like downloading their own work — it creates legal exposure for both sides. Don't rely on legal risk to do what an offboarding process should do.

What's the fastest way to lock down a freelancer who just left badly?

In order of priority: (1) GitHub — remove from org immediately, revoke any personal access tokens they may have created. (2) AWS / Vercel — deactivate any IAM users or team members with production access. (3) 1Password — remove from all shared vaults. (4) Figma, Notion, Linear — remove from team. (5) Slack — deactivate account. Do these in the first hour. The rest can follow.

How do I prevent this from happening again?

Keep a running access log: every tool a freelancer is added to during an engagement, noted in one place. When the engagement ends, that list becomes your offboarding checklist. Better: use a tool like Optserv that maintains this list automatically and fires the revocation in a single flow when you mark the contractor as offboarded.

Stop Auditing Manually. Automate the Offboarding.

Optserv tracks which tools each contractor has access to from the moment they're added, and revokes all of it in one action when they leave — Figma, Notion, GitHub, Slack, 1Password, Linear, Vercel, and more. No checklist. No browser tabs. No relying on memory at the end of a project.

Start for free at app.optserv.ai

Sources

• Verizon: 2025 Data Breach Investigations Report
• GoLeadingIT: 1 in 4 Ex-Employees Still Has Access to Company Data
• CloudEagle: How to Fix SaaS Offboarding Security Gaps
• Torii: How to Remove Users from Your Figma Account

By Optserv Team.