Who actually owns your company's accounts?
Most founders cannot answer this, and find out at the worst possible moment.
There is a question worth answering before you need the answer: if the person who set up your systems disappeared tomorrow, what would you lose access to?
For most small companies the honest answer is uncomfortable. The domain is in a founder's personal registrar account. The cloud account is on someone's personal card. The analytics property belongs to an agency that stopped replying in March. None of this is negligence, it is just what happens when things get set up in the order they became urgent.
Build the ownership map before you need it
One row per system. For each: who is the registered owner, which email address receives recovery mail, who pays for it, and who holds administrative access.
The rows that matter most are the ones underneath everything else — the domain, the identity provider, the payment method. Lose one of those and the systems above it become unreachable in sequence.
The recovery email is the whole game
Almost every account recovery path terminates at an email address. If that address is a personal one, or worse an address at the very domain you are trying to recover, you have a circular dependency that only resolves through a support queue and proof of ownership documents.
Company-controlled recovery addresses, on a domain you can prove you own, on an identity provider with more than one administrator. Everything else is detail.
Two administrators, always
A single administrator is a single point of failure with a calendar. People go on holiday, leave, fall out with the company, and occasionally have accidents. Two named administrators on every critical system, with the second one having actually logged in at least once.
Untested access is not access.
Personal cards are a liability, not a shortcut
Subscriptions on a personal card create a soft form of ownership that is very hard to unwind. When that person leaves, the card is cancelled, and the service lapses without anyone connecting the two events until something stops working.
Before you change anything, export the logs
If this audit turns up access that should not exist, the instinct is to revoke it immediately. Export the admin and login audit logs first. Retention is finite, revocation is the moment the record matters most, and unlike every other step in a cleanup, an expired log cannot be recovered.
The uncomfortable audit
Go through it honestly once. List every SaaS subscription, check who the owner is, check the recovery address, check the number of administrators, and check whether anyone who has left still has access.
Most companies doing this for the first time find at least one system nobody can get into, and at least one former employee who still can.