Dependency

Who should own the cloud accounts, the domain and the production data?

Access is not ownership. The distinction is invisible on any ordinary day and decisive on exactly one.

Short answer

Every account your product needs to run should be held in an identity your company controls, with a recovery address on a company mailbox — the domain and DNS first, then the cloud account, the database and its backups, then everything else. Being given admin access to somebody else's account is not the same thing: it can be withdrawn, and it cannot be inherited. Fix this while the relationship is comfortable, because after notice is given a routine transfer becomes a negotiating position.

#Access is not ownership

Ownership of an account
Control of the identity the account is registered to, the billing relationship, and the recovery contacts — such that no other party can withdraw your access, and such that the account survives the departure of any individual.
In plain terms You can get into it, and nobody else can take that away from you.

Admin access granted inside somebody else's organisation looks identical on an ordinary Tuesday. It differs in exactly three situations, and all three are ones you are trying to plan for: the relationship ends badly, the person who granted it leaves, or the company that holds it ceases to exist.

#What must be yours

In order. If you only do the first group, you have removed the category of risk that cannot be undone with money.

Group one — losing these stops your product

Deal with anything in this group before anything else on this page.

  • The domain registration Losing the domain is losing the product, the email, and every integration that resolves to it. There is no workaround.
  • DNS control Held separately from the registration, often somewhere else entirely.
  • The cloud account or organisation A sub-account inside a supplier organisation is not yours, however much access you have.
  • The production database and its backups Including the backup destination, which is frequently a different account again.

Group two — losing these costs money and months

  • The source repository organisation, with its history
  • CI/CD, and the secrets stored inside it
  • The payment provider account, including the settlement bank details
  • Email and transactional messaging, with the sending domain authenticated under your DNS
  • App store publisher accounts, if there is a mobile product
  • Error tracking, monitoring and analytics

Group three — the ones nobody checks

  • Recovery email and phone on every account in groups one and two A company account with a personal recovery mailbox is not a company account.
  • The billing relationship for each service — who receives the invoice
  • Any account created with a personal address “just to get started”
  • TLS certificates and anything that renews automatically
  • The company mailbox itself, and who can reset it

#The recovery address is the real key

The most commonly missed item on any ownership audit, and the one that quietly undoes all the others.

Suppose you do everything right: the cloud account is registered to the company, billed to the company card, and two of your own people are administrators. The recovery email on it is marek@ at a supplier's domain, because Marek set it up in 2022.

Whoever controls that mailbox can reset the account. Every other control you put in place is downstream of it.

So: go through group one and group two, and check the recovery contacts on each. Recovery email on a company mailbox that more than one person can reach; recovery phone on a company number rather than a personal mobile. It is an hour of clicking and it is the highest-value hour on this page.

#How to move them

  1. Inventory first, change nothing

    For each account: what is the registered identity, who is billed, and what are the recovery contacts? Most of this you can establish yourself by looking, without asking anybody.

  2. Create the company identities you will need

    A mailbox for each function — billing, technical, security — that more than one person can reach and that survives any individual leaving. Not a personal address with an alias.

  3. Transfer the registrations

    Domain first. Registrar transfers have a process measured in days, sometimes with a lock period, and they need cooperation from whoever currently holds it.

    This is why it is done before a relationship is ending, not after.

  4. Move the cloud organisation

    Depending on the provider this is an account transfer, an organisation invitation, or in the worst case a migration. Ask the provider rather than the supplier what the mechanism is.

  5. Point billing at the company

    A company payment method on every service. Where the supplier currently pays and rebills, that is a dependency dressed as a convenience.

  6. Fix recovery contacts, then verify

    Change them, then actually run a password reset on one account to confirm the email arrives where you think it does.

  7. Then, and only then, adjust access

    Add your own administrators, verify they work, and only afterwards remove anybody. Revoking before transferring can remove the only route into an account.

#How to raise it without a fight

The framing that works is continuity, not audit: "we need to be able to answer these questions to an investor, an acquirer or an insurer". It is true, it is not about the person you are asking, and it comes with a deadline that is not you.

It is also worth saying out loud that the current arrangement is a liability for the supplier too. Holding a client's domain in your own account is an obligation nobody at the agency asked for, and most are glad to hand it back. A supplier who resists a transfer of ownership has told you something important, and it is better to learn it now.

#Getting it right from the start

If you are setting up a new product or engaging a new supplier, four rules remove almost all of this permanently:

  1. The company creates every account. The supplier is invited into it. Never the other way round, however much slower it is on day one.
  2. Every account uses a company mailbox that more than one person can reach.
  3. Every service is billed to the company directly, not rebilled by a supplier.
  4. The contract says so — accounts remain company-owned, and any account created during the engagement is created in a company identity.

#What goes wrong

Treating admin access as ownership.

Instead Ask who could remove your access, and who the account would belong to if the supplier ceased trading. Those two questions settle it.

Fixing the account and leaving the recovery address.

Instead Check recovery email and phone on every account you cannot afford to lose. This is the control that overrides all the others.

Revoking access before confirming ownership.

Instead Establish, transfer, create your own route, verify, then revoke. In that order, always.

Raising it only when the relationship is ending.

Instead Do it on an ordinary Tuesday, framed as continuity. It is a five-minute conversation then and a negotiation later.

One person in the company holding everything.

Instead You have not fixed the problem, only moved it. Two people, and company mailboxes rather than individual ones.

#What this does not cover

What this does not do

  • Intellectual property ownership of the code, which is a contract question and moves separately from accounts.
  • Data protection responsibilities, which do not transfer just because an account does.
  • The mechanics of any specific provider. Each has its own transfer process and its own delays; ask the provider, not the supplier.
  • What to do when a supplier refuses. That is a commercial and legal question, and the only technical answer is to hold an independent copy of the data.

Check all of this in ten minutes.

The agency dependency check walks through ownership, delivery, third-party accounts, recovery and terms one question at a time. No account, no email, nothing submitted.

Open the dependency check Map what the system depends on