In this guide 6 sections
Keep the cloud account in your company’s name and give the managed provider a limited role inside it, so you own the data, the bill and the exit. Use the provider’s own account only when you accept a documented export, a named escrow contact and a written offboarding process for the day you leave.
Start with who owns the account
The owner of a cloud account is whoever is named on the root login and card, and they can close it, reset every password and read every file. All other access is lent. That matters because every later question about deletion, billing and exit traces back to the root login rather than to the contract you signed with the host.
There are two shapes. Either the provider hosts you inside their own account, or they work inside an account you opened yourself and hold an IAM role you granted. Only the second keeps your keys.
Ask for the root email address and who holds its multi-factor device, whether that is a phone, a hardware key or an authenticator app. Shared mailbox means shared control.
- Whose name and card sit on the account
- Who receives the root login email
- Where the multi-factor device lives
- Whether your company can list every user and role
Separate the power to delete from the power to bill
A good setup splits duties. The provider needs rights to patch servers, restart services and restore a snapshot, but not to delete the database volume or backup vault, and that gap protects you. Write the split into the contract as named roles: a deployer role that can patch and restart, and a separate break-glass role that needs a second approver.
Billing deserves its own thought. A provider who runs up a large bill through a mis-sized cluster should not hide it, so cost budgets and billing alerts must reach your finance lead.
Ask how deletion protection is set. Termination protection on instances, object lock on backup buckets and a waiting period on key deletion each stop a single slip from becoming a lost business.
Plan how access is revoked on the day you part ways
Exit is where control is tested. If the provider leaves tomorrow, someone must remove their users, rotate database passwords, API keys and signing certificates, and revoke the VPN tunnels into your network. Name that owner before the first invoice.
Ask for an offboarding runbook in writing that names each credential, says where it lives and gives the order of changes for the day of exit. Vault secrets get forgotten. Check too that nobody at the provider holds a personal access token with no expiry, since long lived tokens outlast the staff who created them.
Run a small drill once a year. Keep it boring. Disable one provider user and see what stops working, then write down every surprise, because each surprise is a dependency the provider documented badly or not at all.
- Named users and roles to remove
- Database, API and storage keys to rotate
- DNS and domain registrar access
- Backup copies and who can read them
- Monitoring tools that hold read access
Ask what the provider documents
Documentation is the part of a managed service you cannot see until you need it, so ask for the network diagram, service list, backup schedule and restore steps. Knowledge in one head leaves too.
Describe infrastructure as code where possible, because Terraform or CloudFormation files in your own repository let a new team rebuild the setup, which console screenshots never do.
Ask for monthly change records. Even a short list helps. These records also show whether the provider changed a security group or resized a database without telling you, which is the sort of drift an audit asks about. Request the audit log export too.
Make the decision with a short test
Put four questions to each option. Can we export data within a week, remove the provider without their help, see every change, and learn who pays when a mistake deletes data?
Your own account suits SaaS companies facing audits or investor questions about customer data, while a provider account fits a small internal tool where speed beats control. Test the export clause first.
Put the answers in the contract schedule. Ask the signatory to read them aloud. If any answer is vague, treat that row as a no until the provider shows you evidence from a real restore or a real export.
Hosting control checklist
One page, a row per control: account owner, root login holder, deletion protection, billing alerts, offboarding runbook, infrastructure code, backup restore proof and data export. Each row also holds your answer, the provider’s answer, the evidence seen, an owner and a review date, with a final box recording the verdict.
Open a blank worksheet to printQuestions owners ask
Can a managed provider work inside an account I own?
Yes. Create the account, add the provider’s engineers as users with limited roles, and use role-based access, separate billing contacts and organisation-level policies that most large clouds support. Keep the root login yourself.
What happens to my data if the provider shuts down?
If the data sits in their account, you depend on their export terms and on how quickly you can act, but in your account only the maintenance changes. That is why you hold it.
Does owning the account mean I must run it myself?
No. Ownership and operation are separate. You can hold the account and still hand day-to-day patching, monitoring and restores to a provider under a written scope, with access limited to what that scope needs.