You Inherited a Cloud Mess. Where Do You Start?

You just took over a cloud account (or ten) that someone else built over three years with no documentation, a rotating cast of contractors, and a Slack channel called #aws-help that hasn't been active since 2022. This is one of the most common situations in cloud security work, and it's uncomfortable because you're accountable for something you can't yet explain.

Here's how to get from zero visibility to a defensible position without boiling the ocean.

Stop guessing and get an inventory first

You cannot secure what you can't see. Before touching a single IAM policy, run an inventory pass:

• AWS: aws organizations list-accounts to see the full account structure, then Steampipe or AWS Config aggregators to pull resources across accounts into one queryable view.
• Azure: Resource Graph queries (az graph query) across subscriptions, since Azure's tenant/subscription model hides sprawl easily.
• GCP: gcloud asset search-all-resources at the organization level.

Cross-reference this against the billing data. Billing doesn't lie about what's running, even when tags and documentation do. If you see spend on a service nobody mentioned in onboarding, that's your first finding.

Find who can do what before finding what's broken

Misconfigurations get the headlines, but identity is where the real exposure usually lives in an inherited environment. Pull every IAM user, role, and service account and ask three questions: does this still need to exist, does it have access it doesn't use, and is it human or machine.

Run AWS IAM Access Analyzer or iam-lint-style tooling to flag unused permissions over the last 90 days. In practice, inherited accounts almost always have at least one IAM user with long-lived access keys that were supposed to be