Someone left, or you joined, and now you hold credentials to infrastructure you did not build and nobody fully documented. This is a week-one plan that prioritises the things that are expensive or dangerous to discover late.
The governing principle: inventory before optimisation. Every instinct will be to turn off the thing that looks wasteful. Do not, until you know what depends on it.
Day one: access
Before anything else, establish who can get in.
Enumerate every human and machine identity. Users, roles, service accounts, API keys. For each: who owns it, when it was last used, and what it can do.
Revoke anything belonging to someone who has left. Check last-used first — an active key belonging to a departed employee is running something in production, so find the caller before revoking. A key unused for ninety days can go immediately.
Find long-lived credentials. Static access keys, particularly any with broad permissions, are the highest-risk thing you have inherited. Note them now, plan replacement later.
Turn on audit logging if it is off. CloudTrail, GCP audit logs, Azure activity logs. If it is not enabled you have no record of what happens next, and you will want one. It does not backfill, so this is genuinely a day-one task.
Check for a root account with no MFA. Rare but catastrophic.
Day two: what exists
You cannot manage what you have not found.
List every account, project and subscription, including ones outside the main organisation. Standalone accounts created for a trial and never absorbed are common and invisible from the org console.
List every provider, not just the cloud. AI providers, data platforms, developer tooling, communications. The card statement is the authoritative source here, not anyone's memory — reconcile twelve months of transactions against what you have found.
Identify the payment methods. A personal card in a provider account is both a cost problem and a continuity risk.
Day three: what it costs
Now attach numbers.
Get a total per provider for the last three months. Three months, not one, so you can see trend rather than a snapshot.
Find the top ten line items. These will be most of the spend and are where your attention belongs.
Look for flat lines. A cost that does not vary with traffic is either a subscription or something idle. Idle infrastructure — endpoints, instances, provisioned capacity — is the most common inherited waste, and it is billing whether or not anyone uses it.
Look for growth. Anything trending up without an obvious reason is the thing that will become a problem on your watch.
Day four: ownership
Map spend to teams or services as far as tagging allows. Where tagging is absent — and it usually is — note that as a gap rather than trying to fix it this week.
Find the unowned. Resources with no tags, no recent access, and no obvious purpose. Build a list; do not act on it yet.
Identify single points of failure. Anything only the previous owner understood. This is the real handover risk and it is worth writing down while the question is still fresh in people's minds.
Day five: baseline and monitoring
Establish a baseline so you can detect change. Without one, everything that happens next is indistinguishable from normal, and you have no way to tell whether something you did caused a change.
Set up detection before you start changing things. This ordering matters. If you begin turning off resources in week two with no monitoring, you will not know whether a subsequent cost movement was your change or something unrelated.
Set a budget with an alert on each material provider — a rough one is fine, it can be refined.
What not to do in week one
Do not turn things off. The unowned resource that looks obviously idle is the one that runs quarterly and someone will notice in eleven weeks.
Do not rearchitect. You do not yet know why decisions were made.
Do not promise savings. You will be asked. "I will have an inventory by Friday and recommendations the week after" is the right answer.
Week two onward
With an inventory and a baseline you can start: retire genuinely unowned resources with a notice period, replace static credentials with roles, introduce tagging, and consolidate personal accounts into the organisation.
The reason week one is inventory-only is that every one of those actions is safe with a map and risky without one.
StackSpend is built for exactly this position: read-only connections you can set up yourself in an afternoon without a security review, every provider in one total, and a baseline per service from the first day — so week two starts with detection already running rather than with a spreadsheet.
FAQ
What should I do first when inheriting a cloud account?
Audit access. Enumerate every credential, revoke anything belonging to people who have left after checking it is not in active use, and enable audit logging if it is off — it does not backfill.
How do I find cloud accounts nobody told me about?
Reconcile twelve months of card and expense statements against the accounts you have found. Standalone accounts and personal provider signups do not appear in the organisation console.
Should I turn off unused resources straight away?
No. Something that looks idle may run on a monthly or quarterly schedule. Build the list in week one, give a notice period, and act once you have a baseline that will show you the effect.
How long before I can make changes safely?
Once you have a complete inventory and a working baseline — realistically the start of week two. Detection before modification, so you can attribute any change in spend to the thing you did.
