Planning account recovery for business-critical marketing systems

For each business-critical marketing account, name the owner and deputy, record the service-specific recovery action and its dependencies, and define how emergency access is authorised and ended. Confirm that the named administrators can sign in again before returning the account to normal administration.

Identify the accounts that matter most

Start with accounts that can change a website, send customer messages, manage advertising or retrieve essential records. Examples of service names to record, where used, include Hootsuite, HubSpot, Mailchimp, Google Analytics 360 and Salesforce Marketing Cloud.

For each account, record its service name and business entity or business-controlled account identifier. Name the primary administrator and deputy, and record who controls the account and any supplier contact.

Record the sign-in arrangement separately from the service role. Note whether sign-in uses an identity provider such as Google Workspace, Microsoft Entra ID or Okta, or a direct service login; also record the assigned service role and who can change permissions.

Write down the service’s exact recovery route: its first action, any alternate method and any supplier route. Record where the instructions are kept, who can carry out each step and any proof or approval the instructions require.

List what must work before recovery can proceed, such as the recovery mailbox, sign-in service, recovery device or protected backup code. Record who controls each dependency and how the deputy can reach it independently of the account being recovered.

Keep instructions available to the deputy without exposing credentials or recovery codes to everyone who can read the account register.

Key Recovery Requirements by Service Type

Prepare for different failures

For a lost authenticator, an unavailable sole administrator, central sign-in failure or suspected compromise, record the relevant service-specific first action, the dependency to restore first, and the named alternate administrator or supplier contact. Create a separate route for each relevant failure rather than relying on a general label such as an approved method.

Recovery options vary by provider and plan. Keep recovery addresses, devices and backup codes current and protected; do not keep the only recovery code inside the account it is meant to recover.

Set an observable emergency-access trigger, such as the named administrator being unable to sign in and the deputy being unable to complete the documented recovery route. Name the custodian, who authorises release, the permitted use and where credentials and recovery codes are held in protected storage.

Limit emergency access to restoring named administrators and normal account control. Log who authorised and used it, why it was used and what changed; remove temporary administrator access and disable emergency access after the hand-back.

Confirm that the ordinary named administrators can sign in using their approved authentication methods. Record who confirmed the hand-back, the date and any unresolved dependency.

Keep the authorised people, failure routes, dependencies, check date and unresolved gaps in one controlled record. Assign responsibility for keeping it current and update it when the account, identity provider or service arrangement changes.

Check the route safely

For each account, have authorised people locate its instructions, identify the first recovery action and find the alternate administrator or supplier contact. Record the route checked, who checked it, the date, the result and any untested steps.

Attempt a live sign-in only if it is approved. A live campaign need not be disrupted just to check whether the plan is usable.

After a real recovery, review administrators, authentication methods, recent changes and active access. Check sessions and separately authorised applications where the service supports them; a password reset alone may not address these, depending on the service.

If compromise is suspected, involve the security team before altering potential evidence.

Separate account access from data restoration

Regaining a login does not restore deleted records or settings. Keep data-restoration arrangements in the separate backup plan.