Access Reviews

Purpose

Access control is one of the most effective security controls available. People leave, roles change, and permissions accumulate. Regular access reviews prevent:

• Data breaches: Former employees still having access to sensitive data
• Insider threats: People having access to systems beyond their role
• Compliance violations: Lack of documented access controls
• Accidental damage: Someone with unnecessary access accidentally deleting critical data

This guide explains how to build a sustainable access review process.

Context & Assumptions

Who this is for:

• Business owners and managers
• IT administrators managing user access
• Finance and compliance teams

Key assumptions:

• You have multiple systems (email, CRM, database, cloud storage, etc.)
• You have employees, contractors, and possibly vendors with varying access needs
• You don't have a formal identity and access management (IAM) system yet (or you're building processes around it)

What Access Needs Review?

Access means permission to use, view, or modify:

Key principle: If someone doesn't need it for their job, they shouldn't have it.

Building an Access Review Process

Step 1: Create an Access Inventory

Maintain a record of who has access to what:

Simple approach (spreadsheet):

Better approach (IAM tool):

• Tools like Okta, Azure AD, or Jumpcloud automate this
• Recommended for 50+ employees

Step 2: Define Access Levels (Roles)

Create standard roles to simplify review:

Example roles:

Using predefined roles makes review easier than individual permissions.

Step 3: Conduct Regular Reviews

Monthly Review (Quick)

When: Same day each month (e.g., first Monday) Duration: 30 minutes to 1 hour Action: Scan for obvious issues

1. Check new starters:

   • Do new employees have the right access for their roles?
   • Are they in correct security groups/teams?

2. Check departures:

   • Have people who left been offboarded?
   • Are their accounts disabled?
   • Have their manager access been transferred?

3. Check for disabled accounts still active:

   • Scan for users who haven't logged in 90+ days
   • Confirm they're still employed (or contractors still active)
   • Disable if no longer needed

Deliverable: A short list of issues to fix.

Quarterly Review (Comprehensive)

When: End of each quarter Duration: 2–4 hours for a 50-person company (delegate to system owners) Action: Deep review by system or department

Process:

1. Generate access report from each system:

   • Who has access?
   • What permissions do they have?
   • When was the access last used?

2. Distribute to system owners/managers:

   • "Here's who has access to [system]. Please verify that each person still needs it."

3. Collect feedback:

   • Managers review and confirm access is appropriate
   • Flag any questionable access

4. Remediate:

   • Remove unnecessary access
   • Update permissions if roles have changed

5. Document:

   • Record who reviewed what, what changes were made, when

Example email to managers:

"As part of our quarterly access review, please verify that the following people have appropriate access to [system]:

• Alice Johnson (Editor on Finance folder) — Finance team
• Bob Smith (Viewer on Finance folder) — Sales team

Please reply by [date] confirming whether this access is still necessary. If someone's role has changed and they need different access, let me know."

Step 4: Offboarding Process

When someone leaves, revoke access systematically:

Day 1 (When notice given or departure announced):

• Disable email (or restrict to no-reply)
• Remove from chat/communication platforms
• Notify relevant system owners

Last day:

• Backup email and files (if applicable)
• Disable all accounts
• Retrieve badges, keys, devices
• Change passwords for shared accounts

Week after departure:

• Confirm all system access is revoked
• Check for lingering access (e.g., lingering distribution list, shared drives)
• Audit for accounts under their name in external systems

Documentation:

• Maintain an offboarding checklist
• Record date/time each system was disabled
• Document who verified offboarding was complete

Managing Different Access Types

Cloud-Based SaaS (Email, CRM, etc.)

Review process:

1. Export user list from admin console
2. Compare against current employee/contractor list
3. Disable or delete accounts no longer needed

Tools:

• Built-in admin dashboards (Google Workspace, Microsoft 365)
• Okta or Azure AD (for centralized management across multiple SaaS apps)

Self-Hosted Databases & Servers

Review process:

1. Query active user accounts
2. Cross-reference against organization chart
3. Check last login date
4. Remove stale accounts

Risky: If someone's access to critical database is revoked without proper knowledge transfer, operations could be disrupted. Coordinate with technical team.

Cloud Storage (Shared Drives, Folders)

Review process:

1. For each shared drive/folder, list who has access
2. Check if access is explicit (user added) or inherited (group membership)
3. Remove individual access where possible; use groups instead

Best practice: Use group-based access, not individual permissions. Easier to audit and manage.

Example:

• Instead of: alice@, bob@, charlie@ have access to "Finance" folder
• Use: "Finance" group has access to "Finance" folder; alice, bob, charlie are members of "Finance" group

VPN & Network Access

Review process:

1. Check VPN account list
2. Verify active VPN users
3. Remove expired/unused accounts

Consideration: Remote workers may need VPN access even if they don't log in frequently (e.g., for disaster recovery). Clarify whether "last login" is a signal of unnecessary access or just infrequent use.

Common Pitfalls

• No documentation — "I don't remember who I gave access to." Result: Can't audit, can't remember to revoke.
• No onboarding/offboarding process — New people don't get access; departing people stay in systems. Chaos.
• Too infrequent reviews — Reviewing once a year means stale access for 12 months. Quarterly minimum.
• No business justification — "Why does this person have access?" If you can't answer, they probably shouldn't.
• Not using groups — Individual permissions don't scale. Use groups (departments, roles, projects).
• Forgetting about contractors — Contractors often have access that outlasts their contract. Set expiration dates.
• No audit trail — "Who gave them access? When? Why?" You need to be able to answer this for compliance.

Practical Example: 30-Person Tech Startup

Current systems:

• Google Workspace (email, docs, drive)
• Salesforce (CRM)
• GitHub (code repository)
• AWS (database and servers)
• Stripe (payment processing)
• Linear (project management)

Monthly review (30 min):

• Check Google Workspace for new/departed users
• Check Salesforce user list vs. employee list
• Check for disabled Google accounts still in distribution lists

Quarterly review (2 hours):

• Finance manager reviews Stripe admin access
• Tech lead reviews GitHub and AWS permissions
• Operations manager reviews Google Workspace and Linear
• Gather reports: "Here's who has access. Confirm all is needed."
• Remove any unnecessary access

Offboarding process:

• Day 1: Disable Google account, remove from GitHub, remove from Salesforce
• Within 1 week: Confirm AWS, Stripe, Linear access revoked

Tools:

• Spreadsheet for high-level tracking
• Google Workspace admin console (built-in)
• Salesforce admin console (built-in)
• GitHub organization settings (built-in)
• AWS IAM dashboard (built-in)

Cost: ~2 hours/month of IT admin time

Related Documentation

• Maintenance Strategy — Operationalize access reviews
• Security Audits — Broader security assessment
• Disaster Recovery — Related to data protection

This documentation is for informational purposes only and does not constitute security, legal, or compliance advice. For role-based access control and regulatory requirements specific to your industry, consult qualified professionals.