Inheriting a cloud account nobody set up properly

The account was created four years ago by a contractor who has moved on, or by a founder on a personal credit card at two in the morning. Things were added to it whenever something needed to ship. Now it runs production, nobody can say exactly what is in it, and as of this week — because of a promotion, a departure, or a customer's security questionnaire — it is yours.

This is one of the most common situations in small-company security, and one of the least written about. The advice that exists assumes you are setting up a fresh account with best practices from day one. You are not. You are standing in someone else's decisions. Here is a first week that makes the account knowable and closes the handful of doors attackers actually use, without breaking production.

First, the deal you have with your provider

One paragraph of theory, because it frames everything else. Every major cloud provider works on a shared-responsibility model: the provider secures the cloud itself — the data centres, the hardware, the underlying services — and you secure what you put in it: your accounts, your access keys, your storage settings, your data. Almost every small-company cloud incident happens on the customer's side of that line. It almost always comes through one of three doors: a credential that leaked, a person with more access than they needed, or a storage service set to public. Your first week is about those three doors.

Day one — find the accounts and take the root credentials

Billing is your map. Before you can secure the estate you have to know its edges. Finance's card statements and invoices will tell you how many cloud accounts, organisations, and subscriptions actually exist — there are usually more than anyone remembers, and the forgotten ones are the least maintained. List them all, even the "old test account" someone thinks is empty.

Then take control of the root of each. Every account has one all-powerful identity — the root user, the owner, the initial admin. Find out what email address it is tied to (if that address is a departed employee's inbox, fix that today), set a long unique password stored in the company password manager, and turn on Multi-Factor Authentication (MFA) — a second proof of identity beyond the password. Then stop using root for daily work; it is for account-level emergencies only. If the old team was doing everyday operations as root, that habit ends this week.

Day two — find out who and what can get in

List every human user and every machine credential in the account's Identity and Access Management (IAM) system — the service that controls who can do what. You are looking for four things:

People who have left. Their accounts get disabled today. This is the single highest-value action of the whole week.

Access keys nobody can explain. Long-lived machine keys accumulate like sediment — created for a script in 2023, owner unknown, still valid. Note when each key was last used. Unused for ninety days is a strong signal it can be retired; unknown and recently used means find what is using it before you touch it.

Admin rights as the default. In inherited accounts it is common that everyone is an administrator, because that was easier at the time. You will not fix all of this in week one. Fix the extremes: service accounts and third parties should not hold full admin, and any human admin without MFA gets MFA now.

Sign-in without MFA. Require it for every human, starting with anyone holding admin rights. Password-only cloud consoles are how most of these accounts are actually lost.

Day three — turn the lights on

Before changing anything else, make the account observable. Every provider has an account-level audit log — a record of who did what, when, in the account itself (different names, same job: CloudTrail on Amazon Web Services (AWS), Activity Logs on Microsoft Azure, Audit Logs on Google Cloud). Confirm it is on, covers every region, and is kept somewhere a compromised admin cannot quietly delete. Two reasons this comes so early: from this point on, your own changes are recorded — and if something was already wrong in the account, the log is what tells you the story afterwards.

Set a billing alert at the same time. A sudden cost spike is one of the most reliable early signs of a compromised account — attackers spin up compute for cryptomining — and the alert costs nothing.

Day four — find what is public

Now the third door: exposure. Two searches, both quick with the provider's own tools:

Public storage. List every storage bucket or blob container and check which are publicly readable. Some may be public on purpose — a website's assets. Any bucket holding backups, exports, logs, or customer files should not be. Public backup buckets remain one of the most common causes of small-company data exposure, year after year.

Open network doors. Check firewall rules — security groups — for services open to the whole internet (the address range 0.0.0.0/0). Web servers on ports 80 and 443, fine. Databases, remote-desktop, and administrative ports open to the world, not fine; restrict them to your network or put them behind a virtual private network (VPN).

What not to do in week one

The failure mode of the motivated inheritor is breaking production in the name of security. Three restraints:

Do not mass-delete. That unexplained server may be the cron job the invoicing process depends on. Tag unknowns as "unknown — investigating" and give yourself thirty days of watching before removal.

Do not rotate every credential at once. Rotating a key that a production service silently depends on is an outage. Rotate in order of risk — exposed or ex-employee credentials first — one at a time, watching what breaks.

Do not tighten permissions blindly. Move one service, watch, move the next. Wholesale permission changes in an undocumented account are indistinguishable from an incident, including in their effect on uptime.

Write down what you found

By the end of the week you will have lists: accounts, users, keys, public things, unknowns. Keep them. Those lists are the beginning of an asset inventory, and they convert the next questionnaire's "describe your cloud security controls" from a guess into an answer. They are also the honest baseline the next person inherits — which is, after all, the thing you wish you had been given.

When you want this ready to use

Sylvan Assurance's Cloud Security Assessment toolkit carries this from first week to standing programme: the maturity assessment across the cloud control domains, the remediation planning worksheets, and the evidence checklists that vendor reviews ask for — in editions for a solo operator, a team, or a multi-account estate, from $49. The companion Sylvan Press field guide, Cloud Security, covers the discipline in three volumes, from the shared-responsibility model to the templates.

The free cloud readiness check at sylvanassurance.com/free/cloud scores your account hygiene across the domains above in about five minutes. It runs entirely in your browser. Your answers are never transmitted.

Prefer the long form? The companion Sylvan Press title, Cloud Security, covers the same ground in depth.