SaaS inventory and access management

When someone leaves a small company, offboarding usually means: laptop returned, Slack deactivated, done. But what about GitHub? AWS console? Figma, Notion, Amplitude, the analytics dashboard, the payment processor admin panel?

Most small companies can't answer the question "what services does this person have access to?" There's no central list. People sign up for tools when they need them. Nobody tracks it. When someone leaves, the obvious things get revoked — email, Slack — and everything else stays active until someone notices. Sometimes that's months later.

This chapter gives you a system: inventory what you're actually using, map who has access to what, and build an offboarding process that doesn't leave gaps.

Why this matters more than you think

You're using more SaaS than you think. Try counting: email, calendar, docs (that's already three if you're on Google Workspace). Slack or Teams. GitHub or GitLab. AWS or GCP. Your CI/CD tool. Error tracking. Analytics. CRM. Support ticketing. Design tools. Project management. Password manager. HR software. Accounting. Banking. Marketing automation. Social media management. Video conferencing. Each team adds their own tools.

When companies do this exercise, the guess is usually "maybe 30 tools." The actual count tends to be north of 70. A 50-person startup that ran a proper audit found 140 SaaS applications — nearly three per employee.

Every one of these is a potential entry point. Every one stores some company data. And every one has its own user management that nobody's tracking centrally.

The shadow IT problem

Shadow IT isn't malicious. It's a developer signing up for a free tier of some monitoring tool because they needed it for a project. It's marketing trying out a new email platform. It's the CEO signing up for an AI writing tool with their work email.

The problem isn't that people use these tools. The problem is that nobody knows they exist until:

• The credit card gets charged and finance asks "what's this $200/month to some company called Datadog?"
• Someone leaves and you realize they were the only admin on a critical service
• A vendor gets breached and you're scrambling to figure out if you even use them

Access creep

People accumulate access over time. A developer gets admin access to staging to debug an issue, and that access never gets revoked. Someone joins a project temporarily and stays in the repo forever. The intern from two summers ago still has read access to your analytics.

This isn't about trust. It's about attack surface. Every account with access to your systems is a potential entry point if that person's credentials get compromised. And compromised credentials are common — people reuse passwords, fall for phishing, use insecure wifi.

The principle of least privilege isn't bureaucratic overhead. It's acknowledging that fewer access points means fewer ways in.

Building your SaaS inventory

This is unglamorous work, but it's foundational. You can't secure what you don't know exists.

Step 1: start with the obvious

List every service you personally use for work. Then ask your team leads to do the same. This gets you the bulk of your inventory quickly — the obvious stuff everyone knows about.

Create a spreadsheet with these columns:

• Service name
• URL
• Category (infrastructure, development, communication, productivity, etc.)
• Who owns the account (billing/admin)
• How we authenticate (individual accounts, SSO, shared credentials)
• Sensitivity (what data does it have access to?)
• Cost (free tier, paid, how much)
• Users (rough count)

Step 2: check your SSO/IdP

If you use Google Workspace, Okta, Azure AD, or any identity provider, check which third-party apps have been granted access. In Google Workspace:

Admin console → Security → API controls → Third-party app access

You'll find services you forgot about. Some employee connected their Google account to some random app three years ago, and it's still there.

Step 3: audit financial records

Pull your credit card and expense statements for the last 6 months. Every recurring charge to a software company is a SaaS tool. This catches the paid tools that slipped through.

Step 4: check DNS and email

Look at your email domain's SPF record and any DNS entries. Services often require you to add DNS records for verification. That Mailchimp CNAME you set up? That's a service in your inventory.

Check email aliases — are there addresses like [email protected] forwarding to some helpdesk tool?

Step 5: ask around

Send a company-wide message: "We're building an inventory of all the tools we use. If you've signed up for any software with your work email, please add it to [this form]."

People will remember things. The random Airtable base. The Calendly account. The AI transcription tool from that one meeting.

Tools for automated SaaS discovery

If you want to automate this process (or your company is growing past 50 people), there are dedicated tools that scan for shadow IT and build your inventory automatically.

Free or affordable options:

• Nudge Security — Continuous SaaS discovery via email analysis. Finds apps people signed up for with work email. Has a free tier for small teams.
• JumpCloud — Identity platform with built-in SaaS discovery. Free tier for up to 10 users and 10 devices. Good if you need an IdP anyway.
• Saasmetrix — Discovers SaaS through SSO integration and accounting system imports. Focused on SMBs.

Mid-market options:

• Lumos — Shadow IT discovery plus access request workflows. Good for companies outgrowing spreadsheets.
• Josys — Browser extension-based discovery. Catches apps that don't integrate with SSO.
• Auvik — Network-based SaaS discovery. Also does network monitoring if you need that.

Enterprise options (probably overkill for fewer than 100 people):

• Axonius — Full asset inventory including SaaS, devices, cloud resources.
• Grip Security — Continuous SaaS discovery with security scoring.

For most small companies, the manual approach (steps 1-5 above) works fine initially. Consider a tool when:

• You're adding employees faster than you can track manually
• You've had incidents caused by unknown SaaS accounts
• You need to prove compliance and manual spreadsheets won't cut it

Don't buy a tool to avoid doing the initial inventory work. You need to understand your landscape before you automate monitoring it.

The inventory template

Here's a practical template. You don't need fancy tooling — a spreadsheet works fine for companies under 100 people.

Service	Category	Owner	Auth method	Data sensitivity	Users	Monthly cost	Last reviewed
Google Workspace	Core	CTO	SSO	High - email, docs	All	$800	2024-01
GitHub	Development	VP Eng	SSO + MFA	High - source code	25	$500	2024-01
AWS	Infrastructure	CTO	IAM + MFA	Critical - prod	8	$3000	2024-01
Slack	Communication	CTO	SSO	Medium - internal chat	All	$400	2024-01
Figma	Design	Design Lead	Email/pass	Medium - designs	5	$75	2024-01
Notion	Productivity	PM Lead	SSO	Medium - docs	30	$150	2024-01
Amplitude	Analytics	Product	Email/pass	Medium - user data	10	Free	2024-01
Stripe	Payments	CFO	Email + MFA	Critical - financial	3	Transaction	2024-01

Categorizing by risk

Not all services are equal. Categorize by what happens if the service is compromised:

Critical — Breach means immediate serious damage

• Cloud infrastructure (AWS, GCP, Azure)
• Payment processing (Stripe, banking)
• Customer data stores (databases, CRM with sensitive data)
• Production deployment access

High — Breach means significant damage

• Source code repositories
• Email and authentication
• Internal documentation with confidential info
• HR systems with employee data

Medium — Breach means moderate damage

• Analytics and monitoring
• Project management tools
• Design tools
• Marketing automation

Low — Breach means minimal direct damage

• Public-facing social media
• General productivity tools
• Non-sensitive internal tools

Focus your security efforts on Critical and High. These need MFA, strong access controls, and careful offboarding.

Implementing least privilege

The principle: people should have the minimum access required to do their job. Not "access to everything in case they need it someday."

Practical implementation

Role-based access, not individual permissions

Create roles that match job functions:

• Developer: repos they work on, staging environments, development tools
• DevOps: infrastructure, CI/CD, production with audit logging
• Designer: design tools, shared asset libraries, view-only on code repos
• Product: analytics, project management, view-only where needed
• Admin: everything, with heavy logging and MFA

When someone joins, assign them a role. When they change teams, update their role. Don't accumulate permissions piece by piece.

Default to less access

When someone asks for access to something, the first question is: "Do you actually need write access, or would read-only work?"

Start with read-only. Upgrade to write if there's a real need. This sounds bureaucratic, but it takes 30 seconds and prevents access creep.

Time-bound access for temporary needs

Developer needs production database access to debug an issue? Grant it for 24 hours, not forever. Most platforms support temporary access or you can set a calendar reminder to revoke.

Separate accounts for high-privilege operations

Your CTO probably shouldn't use the same account for reading Slack and managing AWS root access. For critical systems, consider separate admin accounts that are used only for admin tasks.

Access review process

Set a quarterly calendar reminder: "Review access." For each critical service:

1. Export the user list
2. Compare against current employees
3. Check for role mismatches (does the marketing intern still have GitHub access?)
4. Revoke anything that shouldn't be there

This takes 2-3 hours per quarter. It's worth it.

The onboarding checklist

New employee joins. What happens?

Day 1 essentials

Before they arrive:

• Create email account
• Add to core communication tools (Slack, calendar)
• Add to password manager with appropriate vault access
• Prepare list of role-specific tools they'll need

On day 1:

• Walk through password manager setup and MFA enrollment
• Grant access to role-specific tools
• Document what access was granted (update your inventory)

The onboarding template

Create a checklist for each role. Here's an example for a developer:

Developer onboarding checklist

Task	Tool	Access level	Completed
Create Google Workspace account	Google Admin	Standard user	☐
Add to company Slack workspace	Slack Admin	Member	☐
Invite to password manager	Passwork Admin	Team member	☐
Grant GitHub org access	GitHub Admin	Team member	☐
Add to relevant repos	GitHub	Write on assigned repos	☐
Create AWS IAM user	AWS Console	Developer policy	☐
Add to relevant Notion spaces	Notion Admin	Editor	☐
Add to error tracking	Sentry Admin	Developer	☐
Add to staging environment	CI/CD Admin	Deploy to staging	☐
Verify MFA enabled on all critical tools	—	—	☐

Customize this for your stack. The key is having a checklist that someone follows, not relying on memory.

The offboarding checklist

Someone leaves. What happens?

This is where most companies fail. They revoke the obvious things and miss half the access.

The golden rule

Offboarding should be faster than onboarding. If it took you 2 hours to grant access, it should take 30 minutes to revoke it — because you have a checklist.

Before their last day

• Export any data they have that the company needs
• Transfer ownership of shared docs, projects, accounts they administer
• Identify any services where they're the only admin (critical!)

On their last day

• Disable email account (don't delete — forward to manager for 30 days)
• Remove from Slack
• Revoke password manager access (this automatically rotates shared passwords they had access to, if you're using Passwork with proper vault structure)
• Go through your SaaS inventory and revoke access to every service
• Revoke VPN access
• Remove SSH keys from servers
• Revoke cloud console access

After they leave

• Rotate any shared credentials they knew (root passwords, API keys, shared accounts)
• Check for any personal accounts on company services (did they create a personal GitHub account that's still in the org?)
• Update your inventory to reflect access changes

The offboarding template

Task	Tool	Admin contact	Completed
Disable email	Google Workspace	IT	☐
Remove from Slack	Slack	IT	☐
Revoke password manager access	Passwork	Security Champion	☐
Rotate shared credentials they accessed	Passwork	Security Champion	☐
Remove from GitHub org	GitHub	VP Eng	☐
Delete AWS IAM user	AWS	DevOps Lead	☐
Remove from CI/CD	Jenkins/GitHub Actions	DevOps Lead	☐
Revoke VPN access	VPN provider	IT	☐
Remove SSH keys	Servers	DevOps Lead	☐
Remove from Notion	Notion	PM Lead	☐
Remove from Figma	Figma	Design Lead	☐
... (continue for all services in inventory)

Build this list from your SaaS inventory. Every service with user access needs a line item.

Using Passwork for access management

Your password manager is a central piece of access management. When set up correctly, it solves several problems:

Shared credential rotation on offboarding

When someone leaves, any shared passwords they accessed should be rotated. Passwork tracks who has accessed which credentials, making this straightforward. Services in shared vaults can be identified and rotated systematically.

Granular access control

Create vaults by team or by sensitivity level:

• Infrastructure vault: only DevOps and CTO
• Production credentials: senior engineers only
• Development credentials: all developers
• Marketing tools: marketing team

When someone changes roles or leaves, update their vault access. Their access to individual credentials follows automatically.

Audit trail

Passwork logs who accessed which credentials and when. During a security review or incident investigation, you can answer: "Who had access to this AWS key in the last 6 months?"

API access for automation

For larger teams, Passwork's API lets you automate onboarding/offboarding. Script the creation and removal of user access as part of your HR workflow.

Measuring success

How do you know this is working?

Inventory completeness

• Number of services in your inventory
• Last date each service was reviewed
• Target: review all critical/high services quarterly

Access hygiene

• Number of inactive accounts found during reviews
• Time from employee departure to full access revocation
• Target: complete offboarding within 24 hours

Least privilege

• Number of users with admin access on each service
• Number of access requests downgraded from write to read-only
• Target: admin users should be < 10% of total users on most services

Tricks that actually help

A few techniques that make this work smoother.

The "last login" zombie hunt

Most SaaS admin panels show last login dates. During your quarterly review, sort users by last login and look for accounts that haven't been used in 90+ days. These are either:

• Ex-employees nobody offboarded properly
• Active employees who don't actually need access
• Shared accounts nobody remembers

In Google Workspace Admin: Reports → User Reports → Accounts → Last Sign In. Export to CSV and filter.

In GitHub: Organization → People → sort by "Last active." Anyone showing "Never" or a date from last year is a candidate for removal.

The DNS CNAME trick

Many SaaS tools require you to add a CNAME or TXT record to verify domain ownership. Your DNS zone file is an accidental inventory of services you've integrated:

# Get all CNAME and TXT records for your domain
dig +short yourcompany.com CNAME
dig +short yourcompany.com TXT
dig +short _dmarc.yourcompany.com TXT

# Check common subdomains
for sub in mail email support help docs status; do
  dig +short $sub.yourcompany.com CNAME
done

That em1234.yourcompany.com pointing to sendgrid.net? You're using SendGrid. The zendesk1.yourcompany.com? Zendesk. These DNS records often outlive the person who set them up.

Email forwarding before deletion

When someone leaves, don't delete their email immediately. Set up forwarding to their manager for 30 days first. You'll catch:

• Password reset emails from services you forgot to revoke
• Invoices and receipts for subscriptions tied to their account
• External contacts still reaching out

In Google Workspace: Admin → Users → select user → Show more → Add auto-reply and forwarding → set forwarding address.

After 30 days, review what came in, clean up any orphaned accounts, then delete.

The "who signed up for this?" email search

When you find a SaaS tool you didn't know about, search company email for signup confirmations:

from:(*@notion.so OR *@figma.com OR *@airtable.com) subject:(welcome OR confirm OR verify)

This shows who created accounts and when. Useful for finding the actual owner of shadow IT.

Slack app directory audit

Slack tracks every app integration. Check Apps → Manage → Installed Apps. You'll find:

• Integrations nobody remembers adding
• Apps installed by people who've left
• Webhooks pointing to services that might have access to your Slack data

Remove anything that isn't actively used. Each integration is a potential data leak point.

The browser extension approach

For discovering what your team actually uses day-to-day, browser history is gold. You can't access employees' history directly (nor should you), but:

1. Ask the team to export their most-visited sites for work
2. Or use a SaaS discovery tool that works via browser extension (Josys, some others)
3. Or check your corporate proxy/firewall logs if you have one

This catches the tools that don't go through SSO and never hit the credit card — free tiers, personal accounts used for work, browser-based tools.

Workshop: build your inventory and access process

Block 3-4 hours for this.

Part 1: Initial inventory (90 minutes)

1. Create your inventory spreadsheet using the template above
2. Add all services you can think of
3. Check your SSO/IdP for connected apps
4. Review 6 months of company credit card statements
5. Send the company-wide request for tool disclosures

Part 2: Categorize and prioritize (30 minutes)

1. Assign sensitivity levels to each service
2. Identify services with no clear owner
3. Flag services with weak authentication (email/password only, no MFA)

Part 3: Create onboarding/offboarding checklists (60 minutes)

1. Build role-specific onboarding checklists
2. Build the universal offboarding checklist
3. Identify who's responsible for each revocation step

Part 4: First access review (60 minutes)

1. Pick your 5 most critical services
2. Export user lists
3. Cross-reference with current employee list
4. Revoke any access that shouldn't exist
5. Document what you found

Deliverables:

• Complete SaaS inventory spreadsheet
• Services categorized by sensitivity
• Onboarding checklist for at least one role
• Universal offboarding checklist
• First access review completed for critical services

Talking to leadership

If someone asks why you spent time on this:

"I built an inventory of every cloud service we use — we have 67 of them, more than we realized. I also created onboarding and offboarding checklists so we don't leave orphaned access when people leave. During the first review, I found 4 ex-employees who still had access to our systems. That's fixed now, and we have a process to prevent it."

Short version: "I mapped all our cloud services and fixed the access control gaps. Found some former employees with lingering access — that's closed now."

Self-check: did you actually do it?

Before moving on, verify you've completed these items.

Inventory

• Created SaaS inventory spreadsheet
• Added at least 30 services (you probably use more than you think)
• Checked SSO/IdP for connected apps
• Reviewed credit card statements for recurring software charges
• Assigned owner to each service
• Categorized services by sensitivity level
• Identified services with weak authentication

Access management

• Created onboarding checklist for at least one role
• Created universal offboarding checklist
• Identified who's responsible for each access change
• Completed access review for top 5 critical services
• Revoked any orphaned access found

Password manager integration

• Vault structure reflects team/role access needs
• Shared credentials are in appropriate vaults (not personal)
• Know how to rotate credentials when someone leaves

Process

• Calendar reminder set for quarterly access review
• Offboarding checklist linked/documented where HR can find it
• At least one other person knows the process

If you can check off at least 12 of these 15 items, you're ready to move on.

What's next

You now know what services you use and who has access to what. You have processes for granting and revoking access.

Next chapter: keeping your software updated and monitoring for vulnerabilities. Because outdated software with known CVEs is one of the easiest ways attackers get in.