Ad Account Ownership & Access Audit for High-Spend Operations

Direct answer

An ownership audit maps legal owner, platform role, custody, operational control, and approval for assets. Synthesis/inference: audit entity, containers, accounts, Pages/channels, datasets/event APIs, catalogs/feeds, domains, payment profiles, users/partners, OAuth grants, tokens, automations, and approvers as one graph. Preserve evidence before changes. Use least privilege and retain owner recovery. Synthesis/inference: offboard only after replacement access, exports, dependency checks, reconciliation, and read-back.

Who this is for

Fit: Executives, finance/security leads, and operators managing high-spend Meta, Google, TikTok, or multi-platform programs with agencies, vendors, scripts, billing disputes, or sole-admin risk.

Not a fit: Seekers of guaranteed reinstatement, evasion, identity/payment rotation, forged verification, credential sharing, or unverified role instructions. Accounts may use first-party self-service.

Governance/evidence guidance; not legal, tax, insurance, forensic, or support advice. Record labels and verifier.

Decision model

Use five separate questions for every node in the graph. Do not collapse them into “the admin” or “the account owner.”

Synthesis/inference: client-owned accounts with agency partner access can be legitimate. Agency-owned containers require explicit contract, portability, billing, and termination evidence. Google distinguishes ordinary linked-manager access from the platform’s Owner designation. Google says a client-account user with administrative access can unlink the manager relationship. Neither establishes legal ownership or contract rights. [BC-S09]

Build the graph with nodes for legal entity, owner identity, portfolio/manager/business container, ad account, Page/channel, dataset/pixel/event API, catalog/feed, domain/endpoint, payment profile, agency/vendor, user, OAuth app/token, automation, and approver. Draw edges for owns, administers, bills, reads, writes, exports, approves, or depends on. Synthesis/inference: shared identity, payment, domain, dataset, feed, token, vendor, or approver can make accounts non-independent; test dependencies rather than assigning a concentration score. [RS-S17][RS-S18]

Diagnostic or control sequence

1. Set scope and authority. Evidence/input: platform list, legal-entity register, spend authority, contract scope, and incident ID if applicable. Owner: incident lead or governance owner. Action: name the audit boundary, date/time in UTC, regions, and authorized reviewers. Stop if the requester cannot identify the legal entity or authorized decision-maker; record the gap rather than collecting credentials.

2. Inventory objects and IDs. Evidence/input: platform exports, account lists, manager/portfolio views, Page/channel list, dataset/pixel and event API configuration, catalog/feed records, domains, payment profiles, and automation inventory. Owner: asset owner with an operator executor. Action: create one row per object with platform, object ID, entity, region, purpose, owner, role, dependency, and evidence location. Branch when a role label is unfamiliar: capture it verbatim and record the platform and account context.

3. Separate legal ownership from platform access. Evidence/input: contract, invoice, entity/domain records, vendor agreement, and platform role export. Owner: legal/business and finance owners. Action: reconcile owner, payer, administrator, and termination/transfer authority. Stop on conflict; route contract or legal interpretation to counsel.

4. Test owner-controlled recovery. Evidence/input: recovery contacts, MFA/SSO policy, known-clean device, user/session history, and provider recovery documentation. Owner: asset/security owner. Action: verify owner-controlled sign-in, required-object visibility, exports, and the displayed recovery path without a partner credential. Do not remove the last owner or all recovery paths. MFA is layered protection, not proof of a clean account; Synthesis/inference: it does not prove sessions, extensions, OAuth grants, tokens, or administrators are clean. [RS-S04][RS-S05][PR-P12]

5. Apply least privilege and separation of duties. Evidence/input: user/partner roles, action and API scopes, billing access, and approval matrix. Owner: security owner. Action: retain task-limited access; separate proposing, executing, funding, and approving high-impact changes where practical. Apply general controls: use phishing-resistant MFA where supported (CISA; NIST SP 800-63B), grant the minimum access needed for each user (Google Ads Help), and document break-glass access. Exact role names, granularity, token-expiry behavior, and owner-removal mechanics differ by platform; before acting, verify current mechanics in first-party documentation for the affected account type and region. The cited sources do not establish these specifics for Meta or TikTok.

6. Audit partners, agencies, and vendors. Evidence/input: partner IDs, manager links, agreements, invoices, service accounts, contacts, and termination clause. Owner: commercial and asset owners. Action: classify direct, partner, manager, or credential access; confirm exports, billing separation, notice, and unlink authority. Do not infer abuse; escalate sole-admin, opaque billing, or missing export evidence as custody risks.

7. Map shared dependencies before changing one. Evidence/input: domains/DNS, endpoints, payments, feeds, datasets, event APIs, OAuth apps, scripts, credentials, and linked entities. Owner: technical/measurement owner. Action: identify consumers and blast radius; freeze rotation or deletion of shared resources until an owner-approved reversible alternative exists. F5’s domain research supports connected DNS, certificate, email, and API dependencies, not frequency. [BC-S19]

8. Verify automation by read-back. Evidence/input: source, scope, budget ceiling, schedule, owner, logs, expected state, and independent alert. Owner: automation owner; approver: asset owner. Action: safe-scope test, change marker, one bounded mutation, and observed-versus-expected comparison. Google Ads Scripts are best-effort; a green run does not prove every mutation applied. [BC-S06] Stop on read-back conflict, budget expansion, or unclear blast radius.

9. Preserve evidence and reconcile finance. Evidence/input: logs, access history, notices, exports, transaction IDs, invoices, bank/card records, and chronology. Owner: recorder and finance owner. Action: preserve before destructive changes; record collector, UTC time, source, location, and unavailable evidence. Synthesis/inference: keep platform-billed, served-delivery, attribution, analytics/events, backend settlement, bank/card, and agency ledgers distinct. Use official platform and issuer/bank routes for suspected unauthorized activity; reconcile legitimate balance disputes first. Google warns that reversing a legitimate Ads balance can result in suspension. [DRS-A01][PR-P11][BC-S08]

10. Run a safe offboarding and handoff. Evidence/input: termination approval, owner sign-off, current graph, exports, billing, automations, and dependencies. Owner: legal/business owner; executor: operations owner. Synthesis/inference: preserve records; confirm receiving owner/recovery contact; grant/test replacement access; export permitted assets and logs; transfer/retire automations; reconcile invoices; remove one partner relationship at a time; revoke identified tokens/sessions; test owner access, events, billing, and evidence; document closure. Provider-controlled unlink/transfer branches to the provider. Never delete assets or evidence merely to end a relationship.

11. Accept or escalate the result. Evidence/input: audit rows, unknowns, read-backs, finance reconciliation, and owner confirmation. Owner: asset owner and incident lead. Action: classify controlled, observed, provider-dependent, or unknown. Accept only when ownership, owner access, custody, dependencies, least privilege, offboarding authority, and evidence location are documented. If provider mechanics are unclear, use the current account/region route and assign a first-party refresh owner; do not fill gaps from memory.

Evidence to preserve

• Legal entity, contract, billing entity, purchase orders, agency/reseller invoices, and written authorization.
• Object IDs and dated role/ownership/partner views for portfolios/manager containers, accounts, Pages/channels, datasets/pixels, event APIs, catalogs/feeds, domains, and payment profiles.
• User, partner, service-account, OAuth-app, token, session, extension, recovery-contact, and MFA/SSO records; never place secrets in the audit.
• Exportable campaign, creative, audience, catalog, event-schema, automation, and billing state, including last-known-good versions.
• Change logs: actor, UTC time, object, reason, approver, expected/observed state, rollback condition, and read-back.
• Notices, raw errors, IDs, status URLs, official case IDs, email headers, transaction references, bank/card records, and unavailable-data notes.
• Offboarding evidence: receiving-owner acceptance, access test, exports, invoice reconciliation, dependency check, token/session revocation, and closure sign-off.

NIST treats online accounts and cloud objects as digital-evidence preservation problems. Synthesis/inference: screenshots supplement, rather than replace, exportable records. Preserve only what legal, privacy, contractual, and retention processes allow. [DRS-A01]

What not to do

• Do not remove the last legitimate owner, revoke every administrator, or rotate all credentials simultaneously during stress.
• Do not delete or relink shared domains, payments, datasets, catalogs, feeds, or evidence before mapping consumers and preserving records.
• Do not ask for or send passwords, MFA codes, cookies, private keys, government IDs, full payment numbers, browser data, or remote-control access through an unverified channel.
• Do not rotate identities/payments, rent trusted accounts, create replacement accounts, cloak destinations, use anti-detect tools, forge documents, or flood appeals to evade enforcement. Meta has publicly described action against rented trusted accounts and fake “un-ban” services. [PR-P07]
• Do not treat “admin,” “owner,” “full control,” “partner,” “manager,” “business portfolio,” “Account Health,” or similar labels as universal. Capture and verify current first-party semantics.
• Do not treat MFA, a successful login, a green dashboard, a completed script run, or a support reply as proof of clean custody or recovered operations.

When to escalate

Synthesis/inference: Self-service is reasonable when one platform and a clear owner are involved, no unauthorized activity is suspected, dependencies are few, evidence is preserved, and the current first-party route answers the question.

Route to a qualified specialist, security responder, finance/counsel, bank or issuer, registrar, insurer/broker, or platform support when ownership, partner custody, payment authorization, token/session compromise, domain/data dependencies, regulated markets, evidence, or multiple entities are involved. Use one factual official case and preserve its ID and chronology. Counsel, insurer, issuer, and platform retain their decisions; no route guarantees reinstatement, reimbursement, timing, delivery, or performance.

FAQ

Is the person with “admin” access the owner?

No. Synthesis/inference: platform access, legal ownership, custody, and operational authority are separate fields. Google distinguishes ordinary linked-manager access from the platform’s Owner designation, and Google currently says a client-account user with administrative access can unlink the manager relationship. Neither platform state establishes legal ownership or contract rights; verify current mechanics and contract records. [BC-S09]

Is an agency-owned container automatically unsafe?

No. An agency relationship may be legitimate. Ask who owns, bills, exports, unlinks, and what the contract says about termination and portability. Missing evidence is an unknown, not an accusation. [BC-S09][BC-S22]

Should we remove a vendor immediately after a suspected compromise?

Preserve evidence, identify the suspect relationship, confirm owner authority, and avoid broad revocation. Then revoke one identified session/token/partner relationship with read-back and rollback. Responders may change the order when active harm requires it. Synthesis/inference informed by incident-preservation guidance. [RS-S02][RS-S03][DRS-A01]

What does “least privilege” mean here?

Give each identity, partner, app, and token only the actions and duration needed; separate approval from execution for high-impact changes; and review expiry/offboarding. [RS-S04][RS-S05][PR-P12]

Does a successful login mean the audit passed?

No. Synthesis/inference: recovery requires owner access, clean-persistence review, dependency validation, finance reconciliation, preserved evidence, bounded testing, monitoring, and sign-off. Access is one predicate, not the result. [BC-S06][DRS-A01]

Source appendix

All sources accessed 2026-07-19. Platform pages are mutable; use the accessed date and current account/region context when applying their mechanics.