How to Run a 'Who Has Access' Audit at Your Startup (No IT Team Required)

A "who has access" audit is a systematic review of every person — current employee, ex-employee, contractor, or freelancer — who still has active credentials in your SaaS tools. For a startup without a dedicated IT team, this audit takes about 30 minutes the first time, and it almost always surfaces at least one account that should have been revoked weeks or months ago. This guide walks you through exactly how to run it.

Why Every Startup Needs This Audit

Research consistently shows that 89% of former employees retain access to at least one business application after they leave. For startups that move fast — contractors rotating in and out, interns who stayed three months, that agency you stopped working with — the problem compounds quickly.

Orphaned accounts aren't just a theoretical risk. In one widely cited case, a former Cash App employee accessed data on 8.2 million customers months after their termination because no one had revoked their credentials. You don't need to be Cash App's size for the same pattern to hurt you. A former contractor with lingering Figma access can download your design system. A departed engineer with an active GitHub seat can still read private repos.

Beyond security, there's a cost angle: every active seat you forgot about is a recurring charge. Slack, Notion, Linear, Figma — these add up fast at $10–20 per seat per month.

This audit is the foundation. It's what you run before you can automate anything.

Step 0: Map Your SaaS Stack Before You Start

Before you can audit access, you need to know what you're auditing. Open a spreadsheet and list every tool your company uses that requires a login. If you use Google Workspace or Microsoft 365 as your identity provider, start there — but don't stop there. Most startups have large amounts of shadow IT: tools that individuals signed up for with a work email or personal card and never told anyone about.

Work through these categories to make sure you've covered everything:

• Communications: Slack, Zoom, Loom, Intercom
• Design: Figma, Canva, Adobe CC
• Engineering: GitHub, GitLab, Vercel, AWS, Linear, Jira
• Docs / Knowledge: Notion, Confluence, Google Workspace
• Security: 1Password, Dashlane, Bitwarden
• Finance / HR: QuickBooks, Gusto, Deel, any HR tool
• Marketing: Webflow, HubSpot, Mailchimp, Ahrefs
• Other: Any API key or token your team might share

You probably have 15–30 tools at a 10–30 person startup. That's your audit surface.

The 4-Step Audit

Step 1: Pull the Member List from Each Tool

For each tool on your stack list, navigate to the admin settings and export or screenshot the current member list. You're looking for: name, email, role, and when they last logged in.

Most tools surface this under Settings → Members, Settings → Team, or in the billing section. Google Workspace's Admin Console gives you a full user list and last-login timestamp per user. GitHub's org settings let you see all members and outside collaborators. Figma's admin panel shows all members with their last active date.

Add each person's name and email to a column in your spreadsheet, tagged by tool. You don't need to be perfect here — you're building a picture, not an audit log for SOC 2. Speed matters more than completeness on your first pass.

Step 2: Build Your Current Headcount List

Pull your actual employee list as of today. If you don't have an HR tool, your payroll records or your own mental model works fine. Add contractors and active freelancers who should still have access. This is your "should have access" list.

The gap between this list and the member lists you pulled in Step 1 is where orphaned access lives.

Step 3: Cross-Reference and Flag Orphaned Accounts

Go tool by tool. For each person on a tool's member list, check: are they on your current headcount list?

Anyone who isn't should be flagged as orphaned. Create a tab or section in your spreadsheet: "accounts to revoke." Include the tool name, the person's email, their role in that tool, and the date you spotted it.

Pay attention to "outside collaborators" in tools like GitHub — these are often missed entirely because they don't appear in the main member list. Same with Figma's guest access, Notion's shared pages with external emails, and any Slack channel connected to an external workspace.

Don't try to contact the person first. You're not asking for permission — you're doing access hygiene. Move straight to step 4.

Step 4: Revoke Orphaned Access

Methodically remove every flagged account, tool by tool. For admin roles, revoke admin first, then remove the account entirely. For shared credentials (like a shared 1Password vault), rotate the password after removing the person's access — removing their account doesn't invalidate credentials they may have copied.

Document each revocation in your spreadsheet: tool, email, date revoked, revoked by. This becomes your audit trail if you ever need it for compliance.

The Tools Most Likely to Harbor Orphaned Access

Not all tools are equally dangerous. Based on how startups actually operate, these are the ones that accumulate orphaned accounts fastest:

GitHub — Outside collaborators often stay for months after a project ends. Engineers get added to repos on a per-project basis and rarely get removed. Check both org members and repo-level outside collaborators.

Figma — Guest access is easy to grant and never audited. A designer you worked with on a one-time project likely still has viewer or editor access to your main files.

Notion — Workspace guests accumulate fast. Any external person you invited to comment on a doc is probably still there. Check Settings → Members → Guests.

1Password — When someone leaves, their account needs to be removed from vaults. Simply resetting your master password doesn't help if their account is still active. After removal, rotate any shared credentials they could have seen.

AWS / Vercel / cloud infra — These are the highest-risk. Former engineers with IAM access or deploy tokens can do serious damage. Check IAM users, access keys, and any API tokens that weren't rotated at offboarding.

Slack — Often the first thing revoked, but check shared channels with external workspaces — those don't always get cleaned up when an internal account is deactivated.

From One-Time Audit to Ongoing Automation

The spreadsheet audit works. It surfaces real problems and costs you 30–60 minutes. The issue is frequency: you need to run it again after every departure, every contractor rotation, and every quarter at minimum. At a 10-person startup that's manageable. At 25 people with high freelancer turnover, it becomes a real time sink — and the gaps between audits are where the risk lives.

The pattern that breaks the manual cycle is tying access revocation directly to your offboarding workflow. When someone's status changes in your HR system, the access revocation triggers automatically across every connected tool. No checklist. No person responsible for remembering. No gap.

This is exactly the problem Optserv is built to solve. When you mark someone as departed, Optserv kicks off the revocation flow across Slack, Notion, Figma, GitHub, 1Password, and any other tool in your stack — without requiring you to log into each one manually.

If you're not yet familiar with how automated access revocation works, What Is Automated Access Revocation? is a plain-English primer. For more context on why most HR tools don't handle this by default, see The Offboarding Gap: Why HR Software Won't Revoke Access. And if you work with freelancers specifically, When a Freelancer Leaves, Who Still Has Access? covers the contractor-specific risks in detail.

Manual Audit vs. Automated Access Lifecycle

The manual audit is the right starting point if you've never done this before. The automated approach is what you graduate to once you've seen what the audit uncovers and you don't want to run it manually every quarter.

Frequently Asked Questions

How often should I run a "who has access" audit?

Run it every quarter at minimum. Also run it after any significant personnel change — a termination, a contractor rotation ending, or an agency relationship wrapping up. If you're running it manually, quarterly is about the realistic cadence for a small team. If you automate it through your offboarding workflow, it effectively runs continuously.

Do I need special software to do a "who has access" audit?

No. A spreadsheet and admin access to each tool is all you need for the first pass. The tools above (GitHub, Figma, Notion, Slack, Google Workspace, AWS) all have member management pages built in. The limitation isn't the tools — it's the time it takes to check each one manually and the fact that you have to remember to do it.

What's the difference between an access review and a "who has access" audit?

An access review is the formal compliance term — it's what enterprise IAM systems (Okta, Lumos, Sailpoint) run on a scheduled basis to verify that each user's permissions are appropriate for their current role. A "who has access" audit is the lightweight founder-friendly version: you're not evaluating role-level permissions, you're simply checking whether people who shouldn't have access anymore still do. Start with the audit. Worry about formal access reviews when you're preparing for SOC 2.

What should I do if I find a former employee still has admin access somewhere?

Revoke immediately, no notification needed. You're not obligated to warn someone before removing their access to your systems — and waiting gives them more time to take action if they intended to. After revoking, check whether they may have exported data recently (most tools log this in activity history). Rotate any shared credentials or API keys they could have accessed. Document what you found, when, and what you did.

Is this an SOC 2 requirement?

Access reviews are explicitly required under SOC 2 Type II (CC6.1 and CC6.3 controls). The specific cadence varies, but quarterly reviews are the common standard auditors look for. Running and documenting your "who has access" audits is the evidence base for those controls — even if you're not SOC 2 certified yet, building the habit now makes the certification process significantly easier later.

Stop Running This Audit Manually

Optserv ties access revocation directly to your offboarding workflow — when someone's status changes, every connected tool gets updated automatically. No spreadsheet, no quarterly scramble, no orphaned accounts. Start for free at app.optserv.ai.

Sources

• Torii: "What Is Orphaned Access in SaaS?" (2026) — 89% of former employees retain app access after departure
• CloudEagle: "How to Fix SaaS Offboarding Security Gaps" (2026) — 30%+ of organizations take 3+ days to revoke all access
• CloudFuze: "Offboarding Risk: How Orphaned Accounts Create Data Breaches" — Cash App incident reference
• Pathlock: "Top User Access Review Software in 2026" — SOC 2 access review control standards (CC6.1, CC6.3)

Byline: Optserv Team