What a Cloud Security Audit Actually Checks, Step by Step

You can't audit an account you forgot exists. Start by pulling every cloud account and project from your billing console, not just the ones your team mentions in standup. Cross-reference that list against your IAM console for service accounts, API keys, and integrations, and flag anything with no clear owner tag.

Most teams find at least one forgotten staging environment or an old contractor's access token still active during this step. That alone is often worth more than the rest of the audit combined, because it's the kind of gap that doesn't show up in a compliance checklist at all.

Having a vulnerability scanner running is not the same thing as closing what it finds. Pull your last three months of scan results and check how long each finding actually sat open before someone fixed it, not how long your policy document says it should take.

If you want an external yardstick, the U.S. government's own patch directives are a reasonable one: federal agencies are required to remediate a critical, internet-facing vulnerability within 15 days and a high one within 30¹. A small team doesn't need to hit that exactly, but if your open findings are sitting for months, that's the gap to close first.

It's tempting to fold access review into the infrastructure pass, but it gets skipped when you do that, because reviewing every IAM role's actual permissions is slower and less satisfying than checking a firewall rule. Do it as its own pass.

Look specifically for roles with broader permissions than anyone remembers granting, credentials that have never been rotated, and API keys embedded directly in code or config rather than a secrets manager. Any of those three, found in a real account, tells you more about your actual risk than most of the rest of the audit.

A team proving three or four recurring controls to one or two customers can usually keep evidence in a shared folder and update it by hand each quarter. That changes once you're proving a growing set of controls to a growing list of customers who each want their own SOC 2 report or security questionnaire answered.

At that point, rebuilding the same screenshots every audit cycle stops being a rounding error and starts eating real engineering time, which is when it's worth automating evidence collection instead of collecting it by hand each time.

A handful of habits turn a real audit into theater:

• Auditing to check a compliance box rather than to find and fix real gaps
• Assigning no owner to a finding, so it sits open until the next audit surfaces it again
• Testing against a staging environment that doesn't match production's actual configuration
• Treating the audit as a once-a-year event instead of a standing part of how you ship

Any one of these will make the next audit find the same problems as the last one.

A five-person team can usually run the full inventory, patching, and identity review in an afternoon, because there aren't many accounts or roles to check, and the same one or two people who set things up can just look at them again. The main risk at that size is skipping the exercise entirely because everything feels too small to matter.

Once you're past a few dozen engineers, the same steps take real coordination: multiple teams own different services, roles get granted for a one-off project and never revoked, and no single person remembers what every account is for anymore. At that stage, the inventory step stops being a personal memory check and becomes a genuine cross-team exercise, which is usually the point where it's worth putting a recurring owner and a shared tool behind it rather than relying on one person's notes.