Email Account Inventory Template: Ownership and Access

An email account inventory should record the address, provider, owner, purpose, administrator, recovery routes, connected apps, forwarding, retention, critical dependencies, review cadence and offboarding plan for every mailbox you operate.

Verification note: This is a documentary guide checked against current sources on September 18, 2026. We did not hands-on test the named product or workflow during this review, so claims are limited to the cited documentation. Interfaces can vary by account, region, rollout, and app version.

The worksheet is useful before connecting a multi-account client, changing forwarding, leaving a job, or cleaning a long-neglected inbox. It reveals accounts whose ownership or recovery depends on another mailbox that may disappear, before a combined account routine hides that dependency.

Scope and method: this is an original Flick Editorial worksheet informed by provider access, forwarding, and permission documentation. It is not a penetration test, security audit, legal opinion, compliance certification, or guarantee of recoverability. Download the blank email account inventory CSV, store it according to your data policy, and never add secrets.

Core inventory table

Copy one row per account:

Field	Example of the required detail
Address	Full mailbox address
Provider	Gmail, Google Workspace, Outlook.com, Microsoft 365, other
Role	Personal, employer, client, project, recovery-only
Legal/operational owner	Person or organization that controls the data
Administrator	Self, employer IT, client admin
Recovery email/phone	Current, accessible, independently verified
MFA method	Authenticator, security key, device, recovery codes
Connected apps	App name, requested scope, connected date, owner
Forwarding/delegation	Source, destination, copy behavior, approver
Retention/export	Policy, legal hold, backup/export procedure
Critical dependencies	Banking, domains, billing, app stores, customer systems
Review cadence	Daily, weekly, quarterly, recovery-only
Offboarding action	Export, transfer, revoke, delete, retain

Do not place passwords, OAuth tokens, recovery codes, or client secrets in the worksheet. Store secrets in an appropriate password manager or security system; the inventory should point to the owner and process, not contain the secret itself.

Map recovery dependencies

Draw arrows between accounts:

• Which address resets which other account?
• Does a personal service depend on a work mailbox?
• Does an old domain control recovery for current accounts?
• Does one phone number or device represent a single point of failure?
• Who receives security alerts if the primary account is unavailable?

Fix circular or fragile recovery paths. A work account that will be disabled during offboarding should not be the only recovery method for a personal domain registrar or financial service.

Follow the current provider procedure rather than treating the worksheet as the recovery system. Google documents how to set recovery phone and email information, while Microsoft documents two-step verification and security information. Organization-managed accounts may expose different options or require administrator action.

Audit third-party access

For each connected app, record:

• feature you knowingly enabled;
• exact access requested;
• whether the app can read, modify, send, or delete;
• where tokens and copied data are stored;
• how to revoke access;
• how to request deletion from the third party;
• last date the connection was used.

OAuth token revocation is defined by RFC 7009, and Google’s accessible third-party connection guidance explains how users can review or remove account connections. Revocation stops future access through the revoked token; any vendor-held copies remain a separate deletion-policy and evidence question. Microsoft models application access through scopes and permissions, documented in its identity platform guide.

Use the email OAuth permissions explainer when the inventory reveals consent you do not understand.

Record forwarding and delegation

For each rule, record:

• source and destination;
• all messages or filtered subset;
• what happens to the source copy;
• why the rule exists;
• who approved it;
• expected end date;
• rollback and verification method.

Google’s Gmail API forwarding-settings guide requires a registered, verified forwarding address and an explicit disposition for the source message when forwarding new incoming mail. If you find a forwarding route you did not configure, treat it as a security incident and follow provider recovery guidance.

Do not confuse forwarding with delegated access or adding an account to a client. Each changes data flow and identity differently.

Classify operational risk

Mark each account:

• Critical: controls money, domains, legal records, production systems, app stores, or customer communication.
• Important: active work or personal history whose temporary loss would be costly.
• Replaceable: low-value subscriptions or project mail with a clear closure path.
• Orphan candidate: no clear owner, unused, inaccessible, or dependent on expired recovery.

Critical accounts need stronger MFA, tested recovery, current administrators, minimal third-party access, and an export/offboarding plan.

For every critical row, name a second authorized person or a documented recovery procedure where appropriate. “The founder knows the password” is not a continuity plan and should never be written into the inventory as one.

Turn the inventory into a review rhythm

Monthly or quarterly:

• verify recovery methods;
• remove unused connected apps;
• inspect forwarding and delegated access;
• confirm administrators and ownership;
• export where policy requires it;
• close replaceable accounts safely;
• update the next-review date.

For daily operations, use the multiple-account management guide. For boundary decisions, see separating work and personal email.

Flick’s current boundary

An account inventory is a prerequisite to Flick’s multi-account promise. Flick operates in normal mode, and direct Gmail is smoke-tested; other exposed provider rails are not marked smoke-tested in the current capability report. The dedicated Verified Finish rail is disabled. Connect only accounts you are authorized to control; employer, delegated, and shared mailboxes can have separate policies and authority models. The sample demo uses fabricated data and cannot audit a real account.

Bottom line

Inventory accounts before trying to unify them. Preserve ownership, recovery, permissions, forwarding, retention, and offboarding facts without storing secrets in the document. The result is a safer foundation for any combined review workflow.