Business account access should reflect current responsibilities and provide a dependable recovery route. Knowing a password is not the same as owning an account, and a role called administrator can mean different things in different systems. Record the actual service, scope and authority.
This guide covers staff, suppliers and application identities. It helps a business maintain access without relying on shared credentials or undocumented recovery exceptions.
Build an operational account register
List important services, account owners, business purpose, billing contact and recovery arrangements. Include hosting, domains, email, analytics, advertising and connected applications. Link the register to the relevant asset and software inventories without treating a financial equipment schedule as a complete security record.
Record approval and support status separately. A service appearing on a list does not automatically mean that it is authorised, supported or secure. Identify dependencies and accounts that have no clear owner, then agree who will review them.
Separate identity from permission
Authentication establishes an identity through the service's supported process. Authorisation determines which actions that identity can perform. A successful login does not establish permission to view every organisation's records or change every configuration setting.
Create an access matrix covering roles, actions and relevant data boundaries. Include view, edit, export, approve and delete where applicable. Test the underlying service as well as visible controls, so a restricted action cannot be performed through another request path.
Check the resource scope of each role
Hosting permissions may apply to specific packages, while analytics and tag-management permissions can apply at different account or resource levels. Record the effective scope in the actual system. A handover statement saying administrator is incomplete without identifying what the person can administer.
Separate routine work from privileged administration where appropriate. Grant access for the agreed task and review temporary permissions when the task ends. Test supplier access with the intended account rather than assuming that a reassuring role name creates the required boundary.
Protect sign-in and enrolment
Use supported multifactor authentication for important accounts. Where an appropriate passkey method is available, review its device, enrolment and recovery arrangements. Passkeys can provide phishing-resistant authentication, but they do not make the surrounding device, recovery route or permissions invulnerable.
For invitations, verify the intended address, organisation and role. Establish what happens when the recipient signs in with another account or already belongs to several organisations. Membership and application permissions may be separate settings that need their own acceptance checks.
Plan recovery before access is lost
Record the service's supported alternatives when the normal second factor is unavailable. Backup codes, where provided, are sensitive and commonly single-use. Check what a code replaces, what credentials remain necessary and whether generating a new set invalidates the earlier set.
Store recovery material through an approved protected method and limit access. Do not put actual codes in a routine account register or handover document. Confirm who can authorise recovery and how the business will verify that the recovered account belongs to the right person.
Understand provider-assisted recovery limits
A provider may require access to a registered email address, a recognised device or additional evidence. The applicable process can vary between account types and protection settings. Read the current recovery route before treating support as an immediate fallback.
Rehearse a proportionate recovery scenario without disabling normal protections or exposing live codes. Check that the responsible people can locate the instructions and authorised contacts. Record gaps and correct them while the account remains accessible.
Manage application identities deliberately
An integration may operate without an interactive user through a service identity or another supported authentication mechanism. Give it a business owner, a defined purpose and limited permissions. Platform-supported managed identities can remove some stored credentials where available, but they are not a universal feature.
Record dependencies before changing or removing an application identity. A staff departure should not silently stop a business integration because it depended on that person's account. Separate ownership of the workflow from the individual who originally configured it.
Review joining, role changes and leaving
- Confirm the required access before an invitation is sent.
- Review permissions when responsibilities change.
- Identify supplier and temporary access that has expired.
- Check session revocation and other remaining access routes.
- Transfer necessary content and integration ownership.
- Verify the result in each affected service.
Password changes, blocked sign-in and session revocation can have different effects and timings. Follow the service's supported process and verify the outcome. Our WordPress maintenance guide covers application roles, while Giraffe Digital's digital strategy service can align account ownership with the wider operational handover.
