An account settings checklist to run before a ban, and the record to keep

Almost everything that makes an account loss survivable is a setting somebody could have changed in twenty minutes, on an ordinary afternoon, months earlier. Almost none of it can be changed once access is gone, and several of the routes back in require a verification step that takes days and cannot be started retroactively.

This is a settings pass. Run it once per account that matters, record what you find, and set a date to run it again.

What to take away

Recovery details that live on the same service you might lose are not recovery details.
Some appeal routes require verification you have to complete in advance. Find out which, before you need them.
The pass is worthless without the record. Write down what each setting says today, with the date.

First, list the accounts

Not all of them. The ones where losing access would cost you something you cannot replace: the accounts your customers reach you on, the ones holding work you have not copied elsewhere. Then the ones tied to money, and the ones used to sign in to something else.

Accounts to list and owners

Accounts customers reach you on
Accounts holding uncopied work
Accounts tied to money
Accounts used to sign in elsewhere
One named person per account

For each, write down one name. Not a team, not a department. The person who would be woken up.

The settings pass

Setting	What to check	What to record
Recovery address	Points at a mailbox on a different provider, controlled by the organization rather than by one person	The address, and who can read it
Recovery phone	Belongs to the organization or to a named person who will still be there	The number's owner
Two-factor method	Enabled, and not dependent on a single device	Method, and where the backup codes are stored
Backup codes	Generated, stored somewhere reachable without the account	Location, and who has access
Admin and role list	At least two people with full access, and nobody who left	Names, roles, and the date checked
Connected apps and tokens	Anything you no longer use is removed	What remains, and why
Sign-in with this account	Which other services depend on it	The list, and a plan to replace each
Notification address	Where enforcement notices go, and whether anybody reads that inbox	The address, and who monitors it
Legal or business contact	Filled in, and accurate	What it says today
Payout and billing details	Current, and pointing somewhere you still control	Last verified date
Data export	Requested at least once, so you know how long it takes and what it contains	The date and the size
Account status page	Located, and screenshotted while everything is normal	Where it lives, and today's state

The last row is the one nobody does. A status page is only useful as a comparison, and after an action it is often the first thing to disappear.

The actions that only work in advance

Four things cannot be done after an action, and each takes an hour or less now.

Four actions only in advance

Complete identity, business or domain verification
Take a full export to unrelated storage
Stop using the account as a sign-in method
Hold a route to your audience you own

Complete any verification the service offers. Identity, business or domain verification often gates the better appeal routes, and completing it takes days. Starting it during a suspension is usually not possible at all.

Take a full export and keep it somewhere else. Not a link to a download that expires. An actual copy, on storage the service has no relationship with.

Stop using the account as a sign-in method elsewhere. This is the cheapest single fix on the page and prevents one loss from becoming five.

Hold a route to your audience that does not need the service. Contact details you own, in a system you control. Everything else on this list limits the damage; this one is the only thing that preserves the relationship.

Where the notice will land

Find out today which address gets enforcement notices for each account, and whether a human reads it. Many missed appeal deadlines are not choices to ignore a notice, but notices sent to a shared mailbox nobody owned for a year.

Where the notice lands

Which address receives enforcement notices?

Yes

A human reads it and owns it

Missed appeal deadlines

A notice sent to a shared mailbox is the same failure that workplace policies make when monitoring goes undisclosed.

When a market imposes notice and internal complaint handling duties on services, they come from regimes like the one the European Union describes at its page on rules for online services. That regime applies only within its own scope. It tells you nothing about your service unless your service is covered.

The idea that a decision must be answerable is set out in a general account of notice.

Then find the appeal deadline in the service's own current documentation and write it next to the account. Many are short, and many services allow one appeal per action, so knowing the window in advance is what stops a rushed first attempt from spending it. What determines the outcome of that appeal is covered in what actually moves the outcome.

Review points

On a fixed cadence, quarterly for most organizations, for the whole list.
When anyone with access joins or leaves. This is the trigger most often skipped and the one that produces orphaned accounts.
When you add a platform, a market, or a new surface such as advertising or a storefront.
When account type changes, since upgrading can move you under a different rule set with different obligations.
After any enforcement action, on every account rather than only the one affected.

Record the date of each pass. The comparison between two passes is where you notice the admin who left, the recovery address that changed, and the token you forgot you granted.

When to run a review

Quarterly
Full list review
Access change
Anyone joins or leaves
New platform
New market or surface
Account type change
Different rule set
After enforcement
Every account, not just affected

Who owns this

When an organization holds accounts, not a person, write down ownership where people will look, plus what happens at handover. Put that in an internal document, not someone's memory. A structure is in the platform use skeleton.

Who owns this

Write ownership down where people look
Define what happens at handover
Keep it in an internal document
State expectations for personal accounts

If staff use personal accounts that identify the employer, state expectations out loud. That is the job of guidelines people actually use.

Nothing here states what any service currently requires or offers. Settings, appeal routes and deadlines change, so take each from the service's own current pages when you run the pass. The wider mechanics of what an action is and how it proceeds are in the eight outcomes.

Common questions

Is this worth doing for a personal account?

If losing it would cost you work, money or contacts, yes. The list shortens, but the recovery address and the sign-in row apply to everybody.

We use a shared login. Is that a problem?

It is the problem behind most of the failures on this page: no individual accountability, credentials that outlive employment, and a two-factor method tied to one person's phone. Prefer the service's own role delegation where it exists.

How long should the pass take?

Twenty minutes for the first account and less afterwards. The first run is slow because you are finding where the settings live, and that knowledge is most of the value.