Treat the account as an asset with a record
A purchased account is more than a username and password. It may arrive with a mailbox, recovery details, business information, verification records or other material needed to manage it. If those pieces are scattered across messages and personal notes, it becomes difficult to tell what was delivered, what was accepted and who is responsible for the account.
Start with a single asset register: a controlled record of every account the team has acquired. The register is not a place to store passwords. It is an index that identifies each account, explains its intended role and points authorised team members to the approved location for its secrets and supporting documents.
Keep the register focused on the purchase and its handover. It should help someone answer practical questions: Which platform is this account for? What did the seller provide? When was delivery accepted? Who may use it? Where are the recovery contacts and evidence stored? What should happen if the assigned operator leaves?
Before acquiring an account, check whether the intended transfer and use are permitted under the platform’s applicable terms. A tidy register cannot make a prohibited transfer acceptable, and an account’s purchase history should not be hidden from the people responsible for compliance. If the account cannot be used as planned within the platform’s rules, record that issue and resolve it before treating the account as an available working asset.
Give every record a clear identity
Use a consistent identifier for each entry, such as an internal label that connects the register, vault entry and evidence folder. The label should distinguish accounts without exposing a password, recovery code or other secret. A team may also record the platform, account type and intended business function, such as a permitted advertising account or a mailbox associated with registration.
Record the source in a way that supports later review. That may include the seller or supplier name, the purchase channel, and a reference to the relevant order or written agreement. Include what the seller said was included in the delivery: for example, login access, a mailbox, recovery contacts, account history or supporting files. Keep descriptions factual. If an item was not supplied or could not be checked, mark it as missing or unverified rather than filling the gap with an assumption.
The acceptance date belongs in the register because it marks when the team took responsibility for the delivered asset. Record who completed acceptance and who reviewed it, if those are separate roles. The register should also show the account’s current status, such as awaiting review, accepted, restricted from use pending clarification, active for an approved task, or retired. Define these labels internally so team members do not interpret them differently.
Avoid putting unnecessary personal information in the register. Store only what is needed to identify the account and manage the handover. Sensitive identity documents, full mailbox contents and private recovery data belong in appropriately controlled storage, not in a widely shared inventory.
Record delivery and acceptance, not just ownership
A seller’s message that an account is ready is not the same as a completed handover. Use a short acceptance checklist to compare the delivered items with what was agreed in writing. Confirm that the account can be accessed through the intended, permitted process; that the delivery format is understood; and that the recovery contacts and supporting materials described by the seller are either present or clearly marked as absent.
The delivery format matters. A seller might provide credentials through a secure transfer method, access to a mailbox, recovery information, or documents through a separate channel. Record what was received and where it was placed, without copying secrets into the register. If details arrive in separate messages, gather the relevant non-secret references and preserve the original purchase correspondence as evidence.
Acceptance should also include a basic condition review. Note visible issues that affect intended use, such as incomplete delivery, mismatched account details, an inaccessible associated mailbox or an unresolved restriction. Do not attempt to conceal a problem or bypass a platform’s checks. Pause use when the account’s status or transfer rights are unclear, and seek clarification through the appropriate seller or platform channels.
A written acceptance record protects the team from confusing “paid for,” “delivered” and “ready for work.” Those are distinct stages. The register can show the current stage and link to the evidence that supports it, while keeping account secrets in the vault.
Keep secrets in a vault, not in the register
Passwords, recovery codes, security answers, mailbox credentials and similar secrets should be stored in an approved password manager or other controlled secrets vault. Do not place them in chat threads, email drafts, shared documents or spreadsheet cells. Those places make it difficult to manage access consistently and can leave secrets visible long after the original task has ended.
The register should contain a vault reference, not the secret itself. That reference may be the internal account label or a link to the appropriate vault entry, provided the link does not grant access to people who should not have it. Keep permissions limited to people with a work-related need, and review access when roles change. A team should also know who is responsible for maintaining the vault entry and correcting stale information.
Separate the different kinds of access where practical. For example, the person who operates an advertising account may not need access to every document associated with the purchase or to a mailbox used for recovery. Assign access according to the task and the platform’s permitted account-management options. Do not use shared access arrangements to avoid platform requirements or to misrepresent who is operating an account.
If a secret is exposed in a chat or spreadsheet, treat that as a security incident rather than assuming that deleting the message has resolved it. Follow the team’s approved process for reviewing exposure and changing access where appropriate. Update the vault and register so the record reflects the action taken, without copying the exposed secret into the incident notes.
Store evidence separately and link it carefully
Purchase evidence and account access serve different purposes. Keep the agreement, order record, seller correspondence, delivery notes and acceptance checklist in a separate evidence repository with controlled permissions. The register can link to the relevant folder or document, but it should not become a copy of the entire purchase file.
Organise evidence by the same internal account identifier used in the register. This makes it easier to locate the right documents without relying on a person’s memory or searching through unrelated conversations. Preserve enough context to show what was offered, what was delivered and what the team accepted. If a message contains a password or recovery code, avoid duplicating that message into a broadly accessible evidence folder; preserve the non-secret evidence in a suitable way and keep credentials in the vault.
Evidence may also include screenshots or files that show the account’s condition at handover. Store them with care, especially if they contain personal data, identifiers or security details. Limit access to the people who need to review the purchase or manage compliance, and follow the organisation’s retention and deletion practices. Keeping every file indefinitely is not a substitute for a clear record.
A useful evidence folder is navigable, not merely full. Use descriptive filenames and brief notes that explain what a file supports. If an item is missing, record that gap rather than creating a placeholder that could be mistaken for proof. This is particularly important when a seller’s description and the delivered account do not match.
Name the people allowed to use the account
The register should identify who may use each account and for what work. Record a responsible owner for the asset and the authorised operator or team, along with any relevant limits on the task. For example, an account intended for a particular campaign workflow should not be treated as a general-purpose login for unrelated work.
“Who may use it” does not mean that every authorised person needs the same level of access. Where a platform offers role-based access or other supported permissions, use those options in line with the platform’s terms and the team’s security practice. If the account relies on a single login, keep the vault permissions narrow and document who is accountable for its use. Never share access with an outside person simply because they have the password.
Review the authorised-user field when assignments change, when an account is no longer needed, or when a concern arises about access. The record should make responsibility visible without becoming a log of every routine action. For operational activity, use the platform’s own records and the team’s established work-tracking tools.
A named owner also gives the team a clear point of contact for resolving missing recovery details, checking the evidence folder and coordinating a handover. Ownership is an administrative responsibility; it does not override platform rules or grant permission to transfer an account where transfer is not allowed.
Use a leaver rule that removes access cleanly
Decide what happens when a team member leaves before the situation occurs. The rule should assign responsibility for reviewing the person’s access to the register, vault, evidence repository, associated mailbox and any relevant platform account. It should also specify who confirms that the review is complete and where the completion is recorded.
On departure or role change, remove access that is no longer needed through the approved administrative controls. Review shared vault permissions, account assignments, recovery contacts and ownership records. Where a departing person is the only person who can manage a critical part of the account, arrange a documented handover before access ends, while respecting the platform’s supported processes. Do not rely on a former team member to remain available or to keep private credentials for the organisation.
If account access must be changed, follow the platform’s normal security and recovery procedures. Do not invent identity details, conceal a change in control or attempt to evade verification. If the account cannot be transferred or recovered in a way permitted by the platform, record the limitation and decide whether it can remain in use.
Close the loop by updating the register: change the authorised-user field, confirm the vault and evidence permissions, and note the handover or removal. A leaver rule is effective only when someone is responsible for checking each connected location, not just the main login.
Keep the system small enough to maintain
A register works when it reflects reality. Assign one role to maintain the inventory and make updates part of the purchase acceptance and team handover processes. When an account is added, changed, suspended or retired, update its status and links promptly. Periodically compare the register with the vault and evidence repository to find orphaned entries, stale permissions or missing records.
Keep the structure consistent across platforms such as Meta, Google Ads, TikTok Ads and associated mailboxes, while allowing for differences in account type and permitted access methods. Avoid assuming that a process suitable for one platform is automatically appropriate for another. Check the relevant platform terms and use its supported controls.
The goal is not to create paperwork for its own sake. It is to make each purchased account traceable: what was acquired, what arrived, where the secrets are kept, who is permitted to use it and what happens when responsibility changes. A register, a vault and a clear handover rule give the team a practical way to manage those questions without treating chat history or one person’s memory as the system of record.