How to Audit Cloud Permissions in a Startup Without Slowing Everyone Down

Last year we onboarded a 14-person SaaS startup that had been running for three years. Their AWS root account was shared in 1Password. Seven people had AdministratorAccess. Two of them had left the company four months earlier. Their GitHub Actions pipeline used an IAM user with full S3 and EC2 rights. No one had rotated the key. This is not unusual. Startups move fast. Founders hand out access like coffee. The CTO creates an account for the new backend engineer. The frontend lead needs to peek at logs, so someone gives her admin rights. A contractor gets keys for a weekend migration and never returns them. Then something breaks. A database gets dropped. A bucket goes public. A bill spikes because someone launched a mining instance. The post-mortem always finds the same thing: too many people had too much power, and no one checked. Cloud permissions audits are not compliance theater. They are a hygiene task, like backups or dependency updates. They protect the company from itself. The good news is that a startup audit is small. You do not need a SOC 2 consultant. You need a checklist, an hour, and the courage to revoke access people do not use.

Start with identity inventory. List every human account, service account, and access key in your cloud organization. In AWS that means IAM users, roles, and identity center assignments. In Azure it is Entra ID users plus role assignments. In Google Cloud it is principals and IAM bindings across projects. Next, flag privileged roles. Any role that can delete infrastructure, read all data, or change billing rules is high risk. In AWS, AdministratorAccess and PowerUserAccess are obvious. In Azure, Owner and Contributor are the ones to watch. In Google Cloud, look for roles/owner and roles/editor. Then check usage. AWS IAM shows last activity for each user and role. Google Cloud has IAM Recommender. Azure shows last sign-in activity in Entra ID. If an account has not been used in 90 days, disable it. Do not delete it yet. Disable and wait a week. If no one complains, delete it. Finally, review service accounts and keys. These are the silent killers. An old S3 access key in a CI secret can sit unchanged for years. Find every long-lived key. Map it to a service. If it belongs to a human, delete it and use SSO. If it belongs to automation, move it to OIDC or rotate it immediately. The whole first pass should fit on one page. If it does not, your cloud setup is already too complex for a startup.

Reading every IAM policy by hand is a waste of time. Use the cloud provider's own data. In AWS, open IAM Access Analyzer. It creates findings for resources shared with external entities. It also shows unused access. Run the analyzer across your organization. Export the findings. Sort by account and principal. The top ten findings usually cover 80 percent of your risk. AWS IAM also has an Access Advisor tab for each user and role. It lists services and when they were last accessed. If a developer has not touched RDS in six months, remove the RDS permissions. Do this in small batches. Removing fifty permissions at once causes panic. Removing five per week is invisible. In Google Cloud, IAM Recommender suggests role removals and replacements. It will tell you that a principal can drop from Editor to Viewer, or that a custom role is overkill. Accept recommendations one by one. Do not bulk accept until you understand each one. In Azure, start with Azure Advisor security recommendations. Then use Microsoft Defender for Cloud if you have it. The free tier gives enough IAM visibility for most startups. If you want a single open-source tool, run Prowler. It produces a CSV or HTML report with severity scores. We use it during onboarding to show founders exactly what is exposed. It takes twenty minutes to run and finds issues that have been hiding for months.

Least privilege sounds expensive. It is not, if you design for speed. Create four standard roles. Read-only can view metrics, logs, and configs. Developer can deploy and manage non-production resources. Lead can change production with approval. Break-glass admin is for emergencies only, requires two people to unlock, and is logged heavily. Default every new hire to developer. Not lead. Not admin. Developer. If they hit a wall, they request elevation. The request should take one Slack message and a quick approval, not a Jira ticket and a calendar invite. Use groups, not individual bindings. Put engineers in an engineers group. Attach one policy to the group. When someone leaves, remove them from the group. This is faster and safer than hunting through role assignments. Set just-in-time access for dangerous actions. Need to fix a database at 2 a.m.? Request a two-hour admin window. The window closes automatically. The action is logged. The engineer keeps moving. Never share root or break-glass credentials. Ever. Store break-glass passwords in a sealed envelope or a split-secret vault. Test the recovery process once per quarter. If you cannot recover access in ten minutes during an outage, your plan is broken.

Audit quarterly. Anything less and accounts drift. Anything more and the team stops taking it seriously. The quarterly audit has four parts. First, review joiners and leavers. Remove access for anyone who left. Check that new hires got the right role, not the default admin role someone copied from a founder. Second, run the access analyzer or recommender again. New unused permissions appear all the time. Someone gets elevated for a migration and never gets demoted. Someone clones a role for a new project and inherits old rights. Third, rotate long-lived credentials. Any access key older than 90 days should be replaced. If you cannot rotate it automatically, put it on the calendar. Keys in CI pipelines are the highest priority. Fourth, review service accounts. Every service account should connect to one service. If the description says created by terraform module v0.4 and no one knows what it does, investigate. Delete it if it has no recent usage. Between quarterly audits, monitor for changes. Turn on CloudTrail, Azure Activity Logs, or Google Cloud Audit Logs. Set an alert when a new admin role is assigned. That alert is your early warning system.

The number one reason engineers bypass security is friction. If getting access takes longer than doing the work, they will find a shortcut. They will share keys. They will reuse admin accounts. They will put credentials in private repos. Your job is to make the secure path faster than the shortcut. Automate the common requests. A developer needs production read access for an incident. A bot grants it for one hour and posts the log to Slack. No meetings. No tickets. The same bot revokes it later. Document roles where engineers already look. Put the role definitions in your internal wiki or runbook. Explain what each role can do and how to request an upgrade. If engineers have to ask what a role means, the naming is wrong. Use infrastructure as code for IAM. Terraform, Pulumi, or CloudFormation makes changes visible. A pull request to add a permission gets reviewed like any other code. It creates a paper trail. It prevents shadow access. Run short training sessions. Fifteen minutes per quarter. Show the team how to request access, how to check their own permissions, and what to do when they see a shared credential. Security awareness beats security policy every time. At roqy, we help startups build this without hiring a full-time security engineer. A tight permissions setup pays for itself the first time it prevents a data leak or a production mistake. The trick is to start small, stay consistent, and never make security harder than the work it protects.