Who owns your cloud account?

There is one question worth asking before signing anything with a software supplier, and it is not about rates or timelines. It is: whose name is on the cloud account? The answer determines, more than any clause in the contract, how much freedom you have for the entire life of the system, because the account holder controls all of this.

• The infrastructure.
• The billing.
• The access.
• The logs.
• The backups.

Every other arrangement is a courtesy on top of that.

The arrangement where the supplier holds the account is common and it is usually not sinister. It is simply easier: the supplier already has an account, already has their tooling configured, and spinning up a project inside it takes an hour instead of a week of procurement. Both sides accept this at the start because it removes friction from exactly the moment when everybody wants to begin, and the consequences arrive much later.

What the account holder controls

It is worth being concrete, because the abstraction hides the stakes. Whoever holds the account can see and change every resource, can read every log, can grant and revoke access including yours, receives the bill and therefore sees the actual cost of running your system, holds the backups and controls their retention, and can delete all of it. Each of those is a normal administrative capability and together they constitute ownership in every practical sense.

The billing one deserves separate mention because it is the one that surprises people. If the supplier holds the account, you do not see what the infrastructure costs; you see what you are invoiced. Those two numbers may be identical, and in a reasonable relationship they are, but you cannot verify it and you cannot shop the hosting independently. A margin on resale is a legitimate business model and it is a different one from what most clients believe they are buying.

And the backups matter most at the worst moment. If a relationship ends badly, or a supplier goes out of business, or an invoice is disputed, the party holding the backups holds the leverage. We have been asked to help in two situations where a client could not obtain a copy of their own data, and in both the technical work was trivial and the resolution took months because it was not a technical problem.

Why migrating it later is hard

The obvious response is that the account can be moved when it matters, and technically that is true in a limited sense — some providers support transferring an account between organisations, and resources can always be rebuilt elsewhere. In practice neither path is quick. A transfer requires cooperation from a supplier at exactly the moment cooperation is least likely, and rebuilding means recreating infrastructure that has accumulated two years of undocumented configuration.

That undocumented configuration is the real obstacle. Over two years somebody adjusted a firewall rule in the console, raised a quota by opening a support ticket, installed a certificate by hand, and granted a permission to make an incident stop. None of it is in the repository, all of it is load-bearing, and a rebuilt environment is missing exactly the parts nobody remembers. The discovery process for that is weeks, and it happens under time pressure.

Which is why the configuration belongs in code

The defence against that is to declare the infrastructure in the repository rather than in a console, so that the environment can be recreated from the code. This is worth doing for its own sake — it makes a second environment cheap and a disaster recovery plan real — and it has the side effect of making the account question much less dangerous, because a fully declared environment can be stood up somewhere else in days rather than months.

The honest caveat is that no environment is ever a hundred percent declared. There is always a DNS record, a provider-side quota or a third-party webhook configured in somebody else’s dashboard. The useful target is not perfection but a written list of the exceptions, kept with the infrastructure code, so the gap is known rather than discovered. A list of nine manual items is entirely manageable; the same nine items unlisted are what makes a migration take a quarter.

The same question for everything else

The cloud account is the largest instance of a general pattern, and the pattern is worth applying across the board. The domain registration is the one that causes the most acute problems, because it is cheap, it is usually handled by whoever built the first website, and losing access to it means losing your email as well as your site. It should be registered to your company, with your billing, and the supplier given delegated access to the DNS records only.

The source repository is next, and the subtlety there is that having the code is not the same as having the repository. A supplier who hands over a zip file at the end has given you the code and kept the history — the commit log, the branches, the review conversations, the record of why each decision was made. That history is a substantial part of what makes a codebase maintainable, and asking for it afterwards is awkward in a way that setting it up correctly is not.

Then every third-party account the system depends on: the payment processor, the email sender, the error tracker, the analytics, the SMS gateway. Each should be in your name with the supplier invited, for the same reason as the cloud account, and because a key you cannot rotate is a key you do not control. The list is usually longer than anybody expects, which is itself an argument for writing it down at the start.

What a reasonable supplier will say

A supplier who intends a long and uncomplicated relationship will agree to this immediately, because it costs them very little and removes a source of future friction. The practical arrangement is that you hold the accounts and the billing, they are granted the access they need to work, and their invoice covers labour rather than resold infrastructure. Everything about day-to-day delivery is identical.

Where a supplier resists, the stated reason is usually convenience or tooling, and that is sometimes genuine — an agency with twenty small clients does have a real operational argument for standardising. It is worth hearing out, and it is also worth noticing that the cost of their convenience is being carried entirely by you. A reasonable middle ground for small engagements is that they host it their way and you hold the domain, the repository and a backup you have actually restored.

That last clause carries the weight. A backup you have never restored is a belief rather than a backup, and the restore is the only test of it. Performing one restore into a scratch environment, timed, with somebody from your own side doing the work, converts the most dangerous dependency in the arrangement into a known quantity — and it takes an afternoon.

Access is not the same as ownership

The most common reassurance is that you have full access to everything, and it is usually true and it is not the same thing. Access is granted, and anything granted can be withdrawn by whoever granted it. An administrator account inside somebody else’s organisation is still a guest, and the distinction only becomes visible on the day it matters, which is also the day it cannot be changed.

The practical test separates the two cleanly: can you remove the other party’s access without their cooperation? If yes, you own it. If no, you have access, however complete that access currently looks. That question takes a few seconds to answer per account and it reclassifies most arrangements people describe as ownership.

There is a middle state worth naming, because it is where many engagements actually sit: the account is in your name but only the supplier knows how to operate it. That is ownership without capability, and it fails in a quieter way — nobody can take anything from you, and nobody on your side can do anything either. The remedy is not legal, it is a documented runbook and one person on your side who has used it.

The invoice is a map of the system

A cloud bill is the most honest architecture diagram a system has, because it lists every resource that actually exists rather than every resource somebody intended. Reading it tells you what is running, how much of it, in which regions, and which lines have been growing — none of which is reliably available from a conversation or a repository, and all of which you cannot see at all if the account is not yours.

It is also where the surprises live. A line for a machine nobody remembers provisioning, a backup retention policy set to seven years by default, egress charges from a reporting job that reads a whole table every hour. None of those appear in a monthly status meeting and all of them are visible in thirty seconds to whoever receives the bill, which is an argument for that being you.

And it prices every future decision

Beyond the diagnostics, visible infrastructure cost is what makes engineering trade-offs discussable. Whether to add a cache, whether to keep three environments, whether a nightly job should run hourly — each of those has a number attached, and the conversation is completely different when the number is on a screen rather than inside somebody else’s margin. Teams that can see their own bill make better decisions about it, which is unsurprising and frequently overlooked.

A restore you have never run is a wish

Backups are the one item on this list where the paperwork and the reality diverge most often. A policy exists, a job runs, a dashboard is green, and none of that establishes that the data can be brought back — because the thing being tested is the write, not the read. The number of organisations that discover a corrupt or incomplete backup during the incident it was meant to cover is not small.

The test is specific and worth scheduling: restore the most recent backup into an environment you control, with somebody from your own side doing the work, and record how long it took and what was missing. Something will be missing — a schema change not captured, a file store not included, a secret needed to start the application. Finding out which on a planned afternoon is the entire point.

• Restored by your own people, not the supplier.
• Into an environment you control, from your own copy.
• Timed, and the time written down somewhere.
• Checked against a known record, not just booted.
• Repeated after any significant schema change.

The last item is the one that quietly expires. A restore proven in March does not prove anything in November if the schema has moved four times since, and backup completeness is exactly the kind of property that degrades without any signal. Once a year is a reasonable cadence for most systems; after a migration it is mandatory, because a migration is precisely when the backup and the live schema stop agreeing.

Write the exit into the agreement

Contracts tend to describe what happens while the relationship works and go quiet about how it ends, which is the opposite of where the risk sits. Three clauses cover most of it: what is handed over and in what format, within how many days, and at what cost. All three are uncontroversial at signing and all three are a negotiation afterwards, which is the whole reason to write them early.

Format is the clause that gets omitted and matters most. "All data" satisfied by a PDF export is technically compliance and practically nothing; the same clause specifying a database dump plus the file store plus the schema is a usable handover. It is worth naming the format precisely enough that there is no second interpretation, because the second interpretation is the one you will be offered.

None of this implies distrust and it is worth saying so when raising it, because the request can land badly if it arrives unframed. The accurate framing is that both sides benefit from knowing the terms in advance: the supplier gets a defined obligation with a price rather than an open-ended one, and nobody has to negotiate anything during a month when somebody is already unhappy.

Shared logins are not accountability

A single admin login used by four people at a supplier is the arrangement that makes every other control decorative.

• Nothing in the audit log attributes an action to a person.
• Access cannot be removed for one leaver without disrupting the others.
• The credential has usually been shared through a channel nobody wants to describe.

It is also, by a wide margin, the most common arrangement.

One identity per person, always

The fix is individual accounts for named people, which costs nothing on most platforms and takes an hour to set up. It makes the audit log mean something, it makes offboarding a single action, and it makes the question "who changed this?" answerable — which is the question that follows every unexplained production change and currently has no answer at all.

The related habit worth establishing early is a quarterly review of who has access to what. Supplier teams change without anybody telling you, and the normal state after two years is a list containing several people who left that company. Reading the list takes ten minutes, it is the cheapest security control available, and it is almost never done because nobody owns it — which makes naming an owner the actual work.

If it is already the wrong way round

Most people reading this are already in the arrangement they would not have chosen, and the useful response is not to start a migration. It is to reduce the dependency in the cheapest order: get the domain into your name, which is usually a form and a confirmation email; get a copy of the repository including its history; take a backup, restore it somewhere you control, and write down how long that took; and get the list of manual configuration items out of people’s heads and into a file.

Those four steps are days rather than months, they are each individually useful, and together they convert an open-ended dependency into a priced one. After them, moving the cloud account becomes a decision you can make on commercial grounds at a time of your choosing, rather than an emergency you discover you cannot afford.

And it is worth doing while the relationship is good, which is the part that gets postponed. Every one of these requests is routine and unremarkable when nobody is annoyed, and every one of them is a negotiation once somebody is. The best time to ask who owns the account is a quiet Tuesday in the middle of a project that is going well.

1. The cloud account, opened by you, supplier invited in.
2. The domain registered to your company, DNS delegated.
3. The repository in your organisation, with its history.
4. Every third-party account in your name, shared in.
5. A backup you have restored yourself, and timed.
6. A written list of the manual configuration items.

For what it is worth, this is how we work, and it is not generosity. A client who can leave at any time is a client who stays for the right reasons, and it means every renewal conversation is about whether the work is good rather than about what it would cost to escape. It also means we never have to be the supplier holding somebody’s data during a dispute, which is a position worth paying to avoid.