Access Controls Are Killing
Your Compliance Score

Back to blog

We've run compliance gap assessments across hundreds of startups preparing for SOC 2, GDPR, HIPAA, and ISO 27001. One finding shows up in almost every single one: access controls are broken. Not missing entirely — most companies have some form of access management. But the specific gaps that auditors look for, and that real breaches exploit, are consistently there.

The good news: these are fixable. Most access control gaps don't require buying new software or a six-month engineering project. They require policy decisions and some housekeeping. Here's exactly what auditors look for and how to fix it.

Gap #1: No Formal Least-Privilege Policy

The least-privilege principle means every user, service account, and system should have access to only what they need to do their job — nothing more. In practice, most early-stage startups give everyone admin access because "it's easier" and nobody's gotten around to tightening it up.

Auditors will ask for evidence of your access control policy and evidence that it's actually enforced. "We intend to follow least-privilege" is not evidence. What they want to see:

• A written access control policy that defines roles and permission levels
• Evidence that production access is restricted to those who need it operationally (not the entire engineering team)
• No standing admin access to production databases — just-in-time (JIT) access via tools like AWS IAM, Teleport, or Boundary is increasingly the expected standard
• Separation between your staging and production environments — developers shouldn't have the same permissions in both

The fix: Audit your current roles in AWS/GCP/Azure, GitHub, and key SaaS tools. Create a role matrix documenting what each job function needs access to. Revoke everything that doesn't match. This one afternoon of work can close a critical finding.

Gap #2: MFA Is Not Enforced Everywhere

Saying "we have MFA available" is not the same as saying "MFA is enforced." Auditors want to see that MFA is mandatory — not optional — for all access to systems containing sensitive data. This especially means:

• Your cloud console (AWS, GCP, Azure) — root account and all IAM users
• Source code repositories (GitHub, GitLab) — particularly for anyone with production deploy access
• Your identity provider (Okta, Google Workspace, Azure AD) — this is the master key to everything else
• Your production database access tools (any bastion host, database console, or direct connection)
• Your internal admin panels and dashboards

The fix: Enable MFA enforcement at the IdP level (not just "prompt for MFA" but "block login without MFA"). For AWS, use SCPs to deny actions if MFA is not present on the session. Run a report showing all users with console access — anyone without MFA is a finding.

Gap #3: Offboarding Is Inconsistent

Employee offboarding is one of the most consistently weak areas we see. Someone leaves the company, their Google Workspace account is suspended — but their AWS IAM credentials, their GitHub access, their Slack bot tokens, and their personal API keys are still active six months later.

Every framework requires timely revocation of access upon termination. "Timely" typically means within 24 hours for most controls, and immediately for privileged access. Auditors will select a sample of terminated employees and ask you to show that their access was revoked. If you can't, it's a finding.

The fix: Build a checklist-driven offboarding process and assign ownership. Minimum steps:

• Disable IdP account (Okta/Google/Azure AD) — this propagates to SSO-connected apps
• Revoke AWS/GCP/Azure IAM credentials manually (SSO doesn't always cover these)
• Remove GitHub organization membership
• Rotate any shared credentials or API keys the employee had access to
• Revoke VPN certificates and SSH keys
• Remove from all SaaS tools (Notion, Linear, Jira, Slack, etc.)
• Document the offboarding with timestamp and who performed each step

Gap #4: No Periodic Access Reviews

Access creep is real. People change roles, get promoted, join new projects — and their old access rarely gets cleaned up. After two years, your head of marketing might still have read access to production database backups from when they were briefly helping debug a customer issue.

SOC 2 CC6.2, ISO 27001 A.9.2.5, and HIPAA §164.308(a)(3)(ii)(B) all require periodic review and revalidation of access rights. Quarterly is the standard most auditors expect for privileged access; semi-annual is typically acceptable for general user access.

The fix: Schedule a quarterly access review. Export your user lists from AWS IAM, GitHub, and your top three or four SaaS tools. Have each team manager confirm which of their reports should retain which level of access. Document the review, the approvals, and any changes made. This creates the evidence trail auditors require.

Gap #5: Service Account and API Key Hygiene

Human user access gets the most attention, but service accounts and API keys are just as dangerous — and often worse, because no one is watching them. Common findings:

• AWS IAM service accounts with AdministratorAccess when they only need to write to one S3 bucket
• API keys that were created for a specific integration that no longer exists, still active in production
• Hardcoded credentials in source code (GitHub secret scanning should be enabled everywhere)
• Personal access tokens used for CI/CD instead of machine accounts, rotated never
• SSH keys with no expiry and no record of who they belong to

The fix: Audit all service accounts and API keys. For each one, document: what it's for, who owns it, when it was last rotated, and what the minimum-privilege scope should be. Delete unused keys. Rotate keys that haven't been rotated in over 90 days. Implement a key rotation schedule going forward — most frameworks expect at least annual rotation for long-lived credentials.

How Each Framework Maps These Requirements

The 30-Minute Access Control Sprint

If you want to make meaningful progress today, here's a prioritized list of actions you can take in about 30 minutes that will close the most common audit findings:

1. Enable MFA enforcement in your identity provider (Okta, Google Workspace, or Azure AD). This is usually a single toggle. Do it now.
2. Run an IAM credential report in AWS (under IAM → Credential Report). Look for any users with access keys that haven't been rotated in 90+ days or haven't been used at all. Rotate or delete them.
3. Enable GitHub secret scanning and push protection in your GitHub organization settings.
4. Pull your last 3 terminated employees from HR and verify their cloud and GitHub access was revoked. If any wasn't, fix it immediately and document it.
5. Create a shared doc with your offboarding checklist — even a simple Google Doc counts as a written procedure.

None of these require code changes or vendor purchases. They are purely operational. And when an auditor asks "walk me through your access control program," you'll have answers — and evidence — for every question they ask.