You should. The company that owns the product should own the root account of every service the product depends on, and the vendor should be a member of it — not the other way round. This is not a statement about trust. It is a statement about what happens when the relationship ends, when a key person leaves, when a card expires, or when somebody has to answer a regulator at short notice.
The common arrangement — vendor creates the accounts, vendor pays, vendor grants you access — feels convenient at the start and quietly converts an ordinary commercial disagreement into an operational emergency. Correcting it is administrative work, not a confrontation, and it is dramatically cheaper before there is a disagreement than after.
A payments product had been live for two years when its vendor relationship ended. The company owned the code. The AWS account, the domain, the TLS certificates, the Sentry project and the payment-provider account were all under the vendor's organisation. The code was never the problem.
The organisation is yours, billed to you, with at least two of your own people as owners. The vendor is a member with the access their work requires.
The root or management account belongs to a company address that more than one of your people can reach. Vendor engineers work through roles and users inside it, never as the root identity.
The registrar account is yours, the registrant contact is the company, and DNS is somewhere you can change records today. Domains are lost by expiry and by inaccessible mailboxes far more often than by disputes.
A current list of who can reach production, through what, and with what privileges. If nobody can produce that list in an afternoon, it is longer than anyone thinks.
You can obtain a complete, restorable export of your own data without asking anyone. Test it once. An export nobody has ever restored is a belief, not a backup.
Where backups live, who can restore them, how far back they go, and whether a restore has ever been performed. Under whose account they sit matters as much as whether they exist.
Identity and KYC, payments and payouts, email, SMS, monitoring, error tracking, analytics. Each one has an owner and a payment method, and each is a separate small dependency you either hold or do not.
Runbooks, architecture notes and decisions, stored somewhere you control rather than in the vendor's wiki. Knowledge held only in someone else's tooling is not knowledge you have.
Count how many of the answers above resolve to one named individual, on either side. That number is your real continuity risk, and it is usually higher than the org chart suggests.
