A personal Gmail address on a critical account warrants investigation, not a verdict on company rights. A company-domain address is no guarantee of control either. For infrastructure access continuity, require evidence that another authorised person can act without the original person’s mailbox, phone or help.
GitHub gives a concrete reason to look beyond everyday access: it warns that an organisation’s projects can become inaccessible if its only owner is unreachable. Several people using a service does not answer the management question of who can take responsibility when its administrator is unavailable.
Test continuity, not legal ownership
The inheritance test is a practical continuity exercise: can a second authorised person identify, access, recover, administer, pay for and transfer responsibility for a critical service without relying on the original person? It does not determine legal ownership or contractual rights, authorise access to a personal mailbox, or prescribe a provider’s account-transfer procedure.
Use the following review as a cross-system recommendation, not a universal provider standard. For each service, ask who can act, under whose authority, and through which verified route. An assurance that “we have the login” should not close the review.
Separate the control paths
Review account control, human access and software access separately. Automation identities are accounts or credentials used by software rather than a person. Recovery routes are the authorised email, phone and identity-verification paths used to regain control, including emergency access when normal administration is unavailable. Include custody of multi-factor authentication (MFA) methods, which require more than one type of authentication proof.
Identify the provider’s controlling roles and their holders.
Verify their own identity and appropriate permissions.
Assign responsibility and map dependencies before changes.
Verify authorised access to recovery channels and authentication methods.
Check billing access separately from administrative rights.
Record approvals and required vendor involvement.
Recommended review criteria, not a universal provider standard.
Verify each control layer independently. Evidence for one does not establish the others.Amazon Web Services (AWS) makes the recovery distinction explicit for its root user, the highly privileged account identity. Its guidance identifies the associated email account and phone number as recovery dependencies. It also includes the Domain Name System (DNS), which resolves domain names to services, email servers and telephone providers in the critical security perimeter.
Microsoft’s guidance for Entra ID emergency-access accounts cautions against registering MFA or password-reset methods to an individual user’s device or personal details. Together, these provider-specific recommendations direct attention beyond account permissions to the channels needed to restore access.
Start with services whose loss would stop work
Bound the first review by operational consequence. Include cloud accounts, domain registration and DNS control, source-code repositories, deployment services that release changes into operation, and critical vendor portals. Include services administered by external providers rather than treating outsourced administration as evidence of continuity.
Use a concise evidence record for each service. The following fields are a recommended working format. Assign an accountable business owner to resolve gaps even where a vendor performs the administration.
- Service and account identifier: specify the exact account or organisation.
- Accountable owner: name the person responsible for resolving continuity gaps.
- Named backup: identify the authorised person expected to act independently.
- Administration and recovery routes: record roles, procedure locations and dependencies.
- Billing contact: identify who can maintain payment and handle commercial queries.
- Last safe verification: record the date, what was demonstrated and what remains untested.
Keep passwords, recovery codes and other live secrets out of this record. Reference their approved custody arrangements instead. Require separate verification of billing and administrative access; a billing contact should not count as proof that someone can administer the service.
Find where one person remains indispensable
GitHub recommends at least two people hold the owner role in each organisation to address the risk of an unreachable sole owner. That is guidance for GitHub organisations, not a universal owner count. For other services, establish the appropriate backup role through the provider’s controls.
Trace each proposed backup route to its prerequisites. Check for a sole privileged owner, a personal phone holding the only available MFA method, or a vendor relationship that only the original person is authorised to manage. Mark an unresolved dependency as a gap, even if a backup person has been named.
Check for circular recovery dependencies: a recovery route that ultimately requires access to the service it is meant to recover. Trace the chain through email and identity systems rather than stopping at the recovery address. If the chain returns to the unavailable service, require a separately usable, authorised route before accepting the backup arrangement.
Create backup access without shared daily credentials
Give named people permissions appropriate to their responsibilities. Do not solve continuity by circulating a shared everyday administrator password. Where the provider supports it, separate routine administration from the highest-privilege identity rather than giving every backup unrestricted access.
For AWS accounts, that separation is explicit: AWS recommends limiting root-user use to tasks that require it and creating an administrative user for everyday tasks. This is privileged-access guidance, not an account-transfer procedure.
Document who may invoke emergency access, where the procedure is held and how authorised people obtain the required authentication and recovery methods. Microsoft’s Entra ID guidance calls for emergency-access procedures to be documented and current, and for validation that those accounts can sign in and perform administrative tasks. A written route still needs verification.
Rehearse safely before removing access
AWS identifies neglecting regular contingency-plan testing and alternate recovery methods as common root-account security failings. Alongside Microsoft’s emergency-access validation guidance, this supports checking more than the normal login. Use the following sequence to plan a safe rehearsal around each provider’s supported methods.
Approve safe actions and stop conditions. Preserve working access.
Have the backup use their own identity for an approved administrative action.
Use a safe, provider-supported method to check alternate routes.
Separate demonstrated access from reviewed but untested procedures.
Verify replacement access before revocation. Check dependencies before rotating secrets.
Do not disable working access or lock anyone out to simulate failure.
Prove the replacement route while working access remains intact.If testing recovery would risk interruption, stop and arrange a safe method with the provider or responsible technical team. Record a procedure review as a review, not proof of recovery. Set a review cadence appropriate to the service and revisit the record when people, roles or recovery arrangements change.
For a planned departure, demonstrate delegated access before revoking the leaver’s access. Handle automation credentials separately: identify dependent jobs and integrations, check how replacement credentials will be deployed, and rotate affected, scoped secrets only after those dependency checks.
Close each service review with a decision: accept the demonstrated route, assign responsibility for a specific repair, or explicitly accept the unresolved dependency. Do not mark access continuity as verified while the backup still needs the original person to act.
