High-Spend Ad Resilience & Recovery Hub

Direct answer: treat the visible label as a state, not a diagnosis

High-spend advertising can fail through reachability, delivery, billing, verification, enforcement, takeover, automation, measurement, regional, or partner dependencies. A screen label is a state, not a diagnosis. Resilience here means bounded recoverability, not guaranteed continuity: a platform, bank, issuer, insurer, registrar, or other provider may control an outcome, while an operator can still control classification, evidence, custody, dependency mapping, reversible containment, official routing, reconciliation, verified restart, and learning. This is an executive risk map and an operator sequence. It does not provide evasion, account replacement, identity or payment rotation, fabricated records, cloaking, appeal spam, or support manipulation. [PR-P07][RS-S09]

The purpose is practical: executives can see what can fail together, who may act, and what remains unknown; operators can turn an alarming label into one bounded next action. It does not promise reinstatement, reimbursement, review timing, spend restoration, delivery, ROAS, or a platform decision. Agency and manager structures may be legitimate; determine a particular program from owner, billing, access, portability, and exit records. Synthesis/inference, not a prevalence claim; Google manager mechanics are operational, not legal ownership. [BC-S09]

Operating boundary: Platform decisions remain provider-dependent. A green screen, a successful login, a completed script run, or a case response can be an observation without proving that ownership, finance, measurement, and persistence are healthy. [PR-P09][BC-S06][RS-S19]

Public reports show language, not audited outcomes or prevalence. [VOC-F01][VOC-F05]

One operating model, two connected views

Executives map assets, decision rights, and exposure; operators run the incident sequence and acceptance gate.

Synthesis/inference: provider and user observations can diverge; an observed signal is neither diagnosis nor controllable result. [RS-S07][RS-S19]

Dated incident/current-label timeline

Executive view: map concentration before it becomes an incident

Asset ownership and shared dependencies

A paid-media program is an asset graph. Inventory containers, ad accounts, payments, identities, domains/endpoints, pixels/datasets, catalogs/feeds, applications, tokens, scripts, agencies, finance owners, and people authorized to pause spend or sign closure. For each item, record ID, legal entity, full-control owner, partner, billing owner, evidence location, dependencies, reversibility gate, and unknowns.

Diagram 1 — ownership and shared-dependency graph

[Legal entity / finance owner]
           | authorizes billing and closure
           v
[Owner identity] -------- administers --------> [Portfolio / manager / Business Center]
     |                                                |\
     |                                                | \---- [Ad account A] -- [campaigns/rules]
     |                                                |          |\
     |                                                |          | \--- [pixel/dataset] ---\
     |                                                |          |                       \
     |                                                |          |                        > [shared domain / endpoint]
     |                                                |          |                       /
     |                                                |          \--- [catalog/feed] ----/
     |                                                |
     |                                                \------ [Ad account B]
     |
     +---- [Payment profile] -------- shared by ---- [A and B]
     +---- [Agency or partner access] -- acts through --> [managed assets]
     +---- [Token / OAuth app / automation] -- changes --> [rules, feeds, events]

Shared dependency candidates: identity, payment profile, domain/endpoint,
partner access, token/OAuth app, catalog/feed, and human approval authority.

Text equivalent: a legal entity and finance owner authorize billing and closure. An owner identity administers a portfolio, manager account, or Business Center linked to ad accounts and their campaigns, rules, datasets, feeds, and endpoints. Payments, partners, tokens, and connected applications may span assets. This is a planning model, not proof of any relationship.

Synthesis/inference: nominally separate accounts or channels can share identities, payments, domains, vendors, tokens, policy exposure, or approvers. Test the graph. Resilience research supports hidden-bottleneck analysis by analogy, not an ad-account continuity score. [RS-S08][RS-S17][RS-S18][RS-S23]

The domain control matrix

The matrix is operating synthesis. Google distinguishes manager and user access from ownership; client administrators can unlink managers. This proves neither unsafe agency arrangements nor client legal ownership. [BC-S09]

Custody, finance, and decision rights

Access is not ownership. Client-controlled partner access, consolidated billing, and agency-created structures may be legitimate. The risk is unverified custody, billing entity, exports, partner removal, or contractual handoff. Record those as unknowns, not misconduct. [BC-S09][DRS-A31]

Before a material incident, establish decision rights in writing:

• Incident lead: keeps the visible symptom separate from hypotheses; accepts or rejects the next authorized action.
• Operations executor: performs the one approved reversible change and records a read-back.
• Recorder and communications owner: maintains UTC chronology, evidence index, case IDs, decisions, and stakeholder updates.
• Finance owner: compares billed, bank/card, agency invoice, served-delivery, and authorization records; decides when a finance or issuer route is required.
• Asset owner or client approver: confirms custody, risk tolerance, spend freeze, restart authority, and closure.
• Platform liaison: maintains one accurate first-party case; this title does not imply special access.

Small teams may combine roles if decision rights remain explicit. Incident-management guidance supports named roles and handoffs; it does not prove faster advertiser recovery. [RS-S09][DRS-A03]

Bounded internal objectives

Set objectives only for advertiser-controlled actions: acknowledge, freeze risky owned automation, preserve evidence, restore owned telemetry, review access, or test recovery. These are not platform SLAs or promises of review, delivery, or ROAS by a deadline. [RS-S08]

Failure blast radius

The blast-radius table is synthesis/inference, not a probability table. [DRS-A01][DRS-A05][BC-S07][BC-S18]

Checklist 1 — quarterly executive control review

• Reconfirm legal entity, billing owner, full-control administrator, recovery contact, and partner relationship for each critical platform container.
• Update the graph for shared identities, payments, domains, endpoints, datasets, catalogs, feeds, tokens, applications, automations, agencies, and human approvers.
• Select one material asset and test export availability and a handoff record; mark provider-dependent steps and unknowns.
• Review authorized payment methods, invoices, agency billing, spend authority, finance owner, and reconciliation cadence.
• Review least privilege, recovery contacts, sessions, connected apps, extensions, tokens, and offboarding evidence. MFA is a layered control, not proof of a clean account. [RS-S04][BC-S10]
• Review automation scope, rollback, independent alerts, and read-back. Google Ads Scripts documents best-effort execution, so a completed run is not proof every intended mutation occurred. [BC-S06]
• Run one quarterly scenario from the six records below; document unavailable contacts, evidence, authority, or dependencies.
• Re-check every mutable first-party route for the affected account and region immediately before acting.

Six executable quarterly scenario records

These are tabletop exercises, not instructions to create production failures. Each record is an operating synthesis that uses the applicable evidence and official route; it does not predict an outcome.

Scenario 1 — suspected takeover / security state

• Trigger and state: unknown administrator, unusual spend, or unfamiliar session; classify as state 10, account takeover/security incident.
• Affected assets and shared dependencies: owner identity, portfolio/manager, payment profile, connected apps, rules, tokens, domains, event endpoint, and any linked accounts.
• Decision owner: asset owner approves access actions; incident lead coordinates; finance owner owns payment review.
• One bounded action: from a known-clean endpoint, preserve the current access and change record, then revoke one specifically identified suspect session or token under owner authority.
• Independent signals: second administrator’s view, platform access history, payment transaction IDs, automation logs, clean-device observation, and customer/finance symptom.
• Evidence: UTC timeline, audit exports, session/app list, admin/partner list, notices, transaction references, and the exact before/after read-back.
• Finance and communications decision: finance decides whether a transaction is suspected unauthorized; recorder gives factual scope updates without alleging cause.
• Recovery gate: password, MFA, and recovery-contact reset where applicable; persistence review; owner/admin confirmation; dependency checks; finance reconciliation; campaign/automation diff; test event/conversion; monitored restart; signed closure.
• Unresolved unknown: whether an unobserved token, app, endpoint, or provider-side review remains active.

Meta’s official compromised-account guidance makes password change and recent-login review a first-party starting point, but not proof that every linked business asset is clean. [BC-S10][BC-S11]

Scenario 2 — payment or transaction-risk lock

• Trigger and state: failed payment, risk label, unpaid balance, chargeback marker, or payment verification request; classify as state 7.
• Affected assets and shared dependencies: payment profile, card/bank rail, platform account, agency invoice, legal entity, campaign delivery, and any linked billing relationship.
• Decision owner: finance owner; platform liaison may submit the platform record; asset owner approves spend changes.
• One bounded action: preserve the exact billing state and reconcile one transaction against the platform record, authorized-user list, and relevant external record before any dispute choice.
• Independent signals: platform invoice/transaction ID, bank/card record, agency invoice, served-delivery export, authorized-user list, and current payment-state notice.
• Evidence: account/payment-profile ID, transaction ID, currency, date/time zone, invoice, served-delivery period, and actions already taken.
• Finance and communications decision: use the three-branch logic below; finance owns issuer/bank communication and counsel/contract routing where applicable.
• Recovery gate: correct access/ownership; payment-profile and authorization review; reconciled ledgers or named residuals; safe test path; monitoring and signed closure.
• Unresolved unknown: whether a provider, issuer, or agency will accept its own process or decision.

Google documents payment and chargeback suspension states; account and region details remain mutable. [PR-P11][BC-S07][BC-S08]

Scenario 3 — delivery-zero with no acknowledged incident

• Trigger and state: account remains accessible while impressions or clicks stop or materially fall; classify as state 3, delivery outage/underdelivery.
• Affected assets and shared dependencies: account, campaign, budgets, payment profile, verification/policy state, landing endpoint, catalog/feed, measurement pipeline, and shared parent container.
• Decision owner: incident lead coordinates; asset owner approves any delivery change.
• One bounded action: capture one delivery snapshot before changing any delivery setting.
• Independent signals: product-scoped status, second administrator, API versus UI, current payment/policy/verification notices, recent-change ledger, event/endpoint health, and customer symptoms.
• Evidence: delivery export, status URL, exact label, UTC time, budget history, recent changes, object IDs, and case ID if opened.
• Finance and communications decision: finance records exposure as observed spend/delivery information, not as a causal loss claim; communications labels cause as unknown unless evidence resolves it.
• Recovery gate: delivery test within authorized scope, measurement/event check, finance ledger review, monitored restart, and signed closure.
• Unresolved unknown: provider-side root cause, auction behavior, or account-level enforcement scope.

Search Engine Land reported some campaigns stopped serving in March 2025 while the cause and broad scope remained unclear; later status-page silence is an archive gap, not proof of concealment. [PR-P21][PR-P09]

Scenario 4 — reporting quarantine or data-isolation concern

• Trigger and state: report/API/backfill is stale, missing, or shows another advertiser’s product/data; classify as state 4 or 5.
• Affected assets and shared dependencies: report surface, API credentials, dashboards, Merchant Center/catalog data, finance reporting, analytics, and downstream executive decisions.
• Decision owner: data/measurement owner leads; privacy/legal owner decides sharing limits where applicable; asset owner approves changes.
• One bounded action: quarantine report-driven decisions for the affected scope while preserving the view and export.
• Independent signals: UI/API comparison, served-delivery export, billing ledger, affected report query, platform notice, and a second authorized viewer.
• Evidence: screenshots as supplemental context, raw export, query parameters, timestamps, missing fields, object IDs, and access history.
• Finance and communications decision: finance does not settle a performance or billing conclusion on the quarantined report; communications names the report/data scope rather than claiming system-wide delivery failure.
• Recovery gate: backfill/data integrity checked, distinct ledgers reconciled, event test if relevant, residual uncertainty documented, monitored decision restart, signed closure.
• Unresolved unknown: full scope of the affected dataset or whether a provider will characterize the event further.

The 2024 Google incident reported a small fraction of advertisers serving another Merchant Center account’s products and a reporting pause; it does not establish general prevalence. [PR-P18]

Scenario 5 — regional/legal/policy interruption

• Trigger and state: a statutory, regional, category, or document condition interrupts a market; classify as state 11 or 13.
• Affected assets and shared dependencies: country/entity, product category, verification record, catalog/creative, billing, regional audience, and alternate lawful demand channels.
• Decision owner: legal/business owner decides applicable scope; asset owner controls only authorized containment.
• One bounded action: classify the observed interruption as legal/policy or technical only when the retained evidence supports that framing.
• Independent signals: applicable notice, legal/entity/region record, current platform policy index, product-category status, and the platform route shown in the account.
• Evidence: region, legal entity, affected inventory, current policy/detail reference, notification, and chronology.
• Finance and communications decision: communicate the observed jurisdictional scope; finance records a contingency decision without forecasting CPM, revenue, or review result.
• Recovery gate: current entity/region condition reviewed, dependencies and measurement baseline checked, lawful restart approved, monitoring and signed closure.
• Unresolved unknown: local legal interpretation, platform eligibility, or future provider behavior.

The U.S. TikTok interruption began around 03:30 UTC on 2025-01-19 and had a legal trigger; Cloudflare measured TikTok-related DNS traffic down by up to approximately 85%, with restoration after roughly 14 hours. This is U.S./DNS/date-bound infrastructure evidence, not TikTok Ads delivery telemetry. [PR-P22][PR-P25]

Scenario 6 — off-hours escalation with no asserted emergency service

• Trigger and state: material symptom arrives when the organization has not verified who is available; this can accompany any taxonomy state.
• Affected assets and shared dependencies: approval authority, finance contact, owner identity, platform liaison, status records, bank/issuer route, and communications channel.
• Decision owner: the documented asset owner or preassigned incident lead; if neither is reachable, the record states that authority is unavailable.
• One bounded action: open the incident record, capture the state, and use only an action already authorized in the decision-rights map.
• Independent signals: product status, second admin, payment/transaction record, current official route, and owned monitoring.
• Evidence: timestamp, attempted contacts, authority status, visible label, exports, and unavailable-evidence note.
• Finance and communications decision: give factual internal status and use official platform/issuer routes where applicable.
• Recovery gate: decision authority restored or documented, applicable acceptance checks complete, exercise finding assigned an owner/date, signed closure.
• Unresolved unknown: who is available, what authority exists, and when an outside provider will respond.

This scenario keeps availability, authority, and response-time assumptions separate from verified facts. [BC-S17][DRS-A21]

Operator view: a strictly linear incident sequence

Diagram 2 — Capture → Classify → Check → Contain → Official route → Reconcile → Verify/monitored restart → Learn/test control

CAPTURE
  exact label, IDs, UTC time, last-known-good export
      ↓
CLASSIFY
  select visible state(s); keep cause as a hypothesis
      ↓
CHECK
  compare independent signals: status, second admin, API/UI, clean device, owned telemetry
      ↓
CONTAIN
  preserve evidence; make one authorized reversible change or stop
      ↓
OFFICIAL ROUTE
  use the current first-party, account- and region-specific route
      ↓
RECONCILE
  compare billed, served, attributed, analytics, bank/card, agency invoice, backend settlement
      ↓
VERIFY / MONITORED RESTART
  complete acceptance gate; run limited authorized test with stop condition
      ↓
LEARN / TEST CONTROL
  record decisions, gaps, owner/date, then exercise the changed control

Text equivalent: capture before changing. Classify the visible state without turning it into a cause. Check distinct evidence streams. Contain only through a documented reversible action and preserve evidence. Use the official route. Reconcile financial, delivery, attribution, analytics, and business records separately. Verify recovery through the full acceptance gate; then use a limited monitored restart. Finally, learn through a blameless review and test the changed control. The sequence is intentionally linear because changing later steps before evidence capture can create new unknowns. It makes no claim about platform review timing. [RS-S09][RS-S10][DRS-A01]

Step 1 — capture before change

Open a factual incident record. Record platform and product surface; account, portfolio, manager, campaign, or asset IDs; exact visible label and raw error; UTC first-seen time; time-zone context; region and legal entity; last-known-good export; current administrator/partner state; payment, policy, and verification state; relevant request ID; status URL; support case ID; recent material changes; and customer-visible symptoms. Screenshots orient a reviewer but are supporting context, not a substitute for exportable records. Preserve notices, headers, audit history, billing details, event samples, and unavailable-data notes within the applicable process. [DRS-A01][RS-S03]

Checklist 2 — capture-before-change evidence

• Start an incident record with UTC time, reporter, platform surface, region, and observed business symptom.
• Record exact account/object IDs, visible label, detail/policy ID, raw error, request ID, and existing official case ID.
• Export authorized last-known-good and current campaign, delivery, measurement, billing, and permission state.
• Capture recent budget, payment, permission, destination, feed, automation, creative, tracking, and verification changes with actor and timestamp.
• Record full-control admin, partner, manager, billing, domain, token, and approval rights; mark gaps unknown.
• Preserve relevant notices, email headers, transaction references, and event samples; record what was unavailable and who will verify it.
• Do not submit passwords, MFA codes, cookies, government IDs, full payment data, remote-control access, browser data, or scripts to a recovery service. [BC-S18][DRS-A15]

Step 2 — classify state and competing hypotheses

Use the taxonomy below to record a visible state, then write at least one alternative explanation where the evidence permits it. A delivery-zero symptom may coexist with payment risk, policy enforcement, verification, parent cascade, endpoint failure, or a measurement misunderstanding. “Restricted,” “misconfigured,” and “permanent” do not make those causes certain. Public reports show this ambiguity in operator language; they do not establish platform-wide frequency. [VOC-G01][VOC-T01]

Complete 16-state taxonomy

State-specific companion routes are limited to verified existing AdsInfra slugs and do not replace this hub: /survival/facebook-business-account-hacked for a Meta security state; /survival/google-ads-billing-suspended for a Google billing state; /survival/tiktok-ads-not-delivering for a TikTok delivery symptom; /survival/meta-pixel-tracking-issues for a Meta measurement symptom; and /survival/google-ads-suspension-recovery for a Google enforcement symptom. Use these only after the state is classified; this hub remains the canonical treatment of custody, evidence, finance, dependencies, and acceptance.

Step 3 — check independent signals

Use signal types that can disagree: product-scoped status/history; a second administrator; UI and authorized API; a known-clean device for compromise hypotheses; owned delivery, event, analytics, CRM, and backend telemetry; customer or sales symptoms; notices and case records. A green status page is one observed provider signal, not a verdict. Provider and user views can differ, so preserve both without treating either as a root-cause proof. [PR-P01][PR-P02][PR-P09][RS-S19]

Step 4 — contain reversibly and preserve evidence

Containment limits unauthorized spend, data exposure, or risky change; it is not the same as fixing a provider-dependent state. The incident lead authorizes one reversible action, the executor records expected and actual read-back, and the record names rollback condition and next check. Do not let a plausible hypothesis become a destructive cleanup campaign. [RS-S03][RS-S09][DRS-A01]

Checklist 3 — reversible one-change containment

• Name incident lead, executor, recorder/comms owner, finance owner, and asset owner before a material change.
• State observed symptom, hypothesis, authorized reversible action, expected read-back, rollback point, and approval.
• Pause or reduce spend only within authority where unauthorized activity, material data exposure, or unsafe automation is plausible; record the exact state first.
• For a compromise hypothesis, use a known-clean endpoint and map sessions, tokens, extensions, connected apps, administrators, partners, payment methods, rules, and automations before broad cleanup. [PR-P12][PR-P24]
• Preserve logs and exports before revoking, deleting, relinking, rotating, or rebuilding a shared object.
• Do not create replacement accounts, rotate identities or payments to evade a restriction, submit fabricated records, cloak a destination, use anti-detect tools, or flood appeals. [PR-P07][PR-P10]
• Do not use blanket “reconcile before dispute” language. Apply the three-branch billing logic below.
• Stop when the observed read-back conflicts with the expected state or expands blast radius.

Step 5 — official routes, current labels, and anti-impersonation

The links below are canonical routes from the packets and were last checked 2026-07-19. Platform labels and paths can vary by account; country/region can affect TikTok business-verification document requirements, while TikTok transaction-appeal eligibility is case-by-case and can differ by account type. Verify what appears in the affected account immediately before acting. Navigate directly to the platform-owned domain. Treat inbound direct messages, unsolicited calls, or impersonating “recovery” offers as unverified; never send credentials, MFA codes, cookies, government ID, full payment information, browser data, remote-control access, or scripts to an inbound contact. [BC-S18][DRS-A15]

• Meta business portfolio restriction review: https://www.facebook.com/business/help/530209463124901/ — Meta, Request a review if you are restricted from advertising on Meta platforms. This is an official review route, not an outcome guarantee. [PR-P03]
• Meta compromised business portfolio: https://www.facebook.com/business/help/25302697499431030 — Meta Business Help Center, Recover a hacked or compromised business portfolio. Use only through the first-party page; it is not proof that every linked asset is restored. [BC-S11]
• Google Ads suspensions: https://support.google.com/adspolicy/answer/9841640?hl=en — Google Ads Help, Google Ads account suspensions overview. Verify current appeal eligibility in the account. [PR-P10]
• Google Ads billing/payment suspensions and advertiser verification: https://support.google.com/adspolicy/answer/13704200?hl=en — Google Ads Help, Billing and payment suspensions. The source identifies advertiser verification under Admin > Policy > Account as of the checked date; do not assume this applies to every account or region. [PR-P11]
• TikTok Account Health: https://ads.tiktok.com/help/article/account-suspensions?redirected=1 — TikTok for Business, About suspended ad accounts on TikTok. [PR-P13]
• TikTok business verification: https://ads.tiktok.com/help/article/about-business-verification?aadvid=72391499277 — TikTok for Business, How to verify your business on TikTok. Country/region document requirements vary; verify the current requirements for the affected account before submitting records. [PR-P14]
• TikTok Transaction Appeal: https://ads.tiktok.com/help/article/about-transaction-related-appeals — TikTok for Business, About transaction-related appeals. The source says availability may be case-by-case and can differ by account type. [PR-P15]

Submit one factual, evidence-backed case or remediation record, separate fact from hypothesis, and follow a documented provider request for additional information. This does not imply a special channel or control over a review. [PR-P03][PR-P10][PR-P15]

Step 6 — reconcile ledgers separately

Keep these records separate: billed platform invoice/charge/balance; served delivery export; platform-attributed reporting/modeling; analytics/event pipeline; backend settled outcome; bank/card transaction; and agency invoice. A number may be accurate in its own system yet not map to the same entity, currency, time zone, campaign scope, or settlement point. [PR-P09][PR-P18]

Synthesis/inference — settled-cohort method: define a shared date range, time zone, object scope, event definition, and settlement cutoff; freeze the extract version; compare each ledger against that same cohort; record latency, attribution, consent, reconciliation, and data-quality limits. This method does not prove platform causality, revenue, fraud, or incrementality.

Billing worksheet

Three-branch billing logic

1. Suspected unauthorized activity: preserve transaction and access evidence; contain only within authority; promptly contact the official platform route and the issuer/bank fraud route. Neither route’s outcome is guaranteed. [BC-S07][BC-S08]
2. Legitimate platform-balance disagreement: reconcile the invoice, transaction ID, delivery history, authorized users, payment state, and applicable agency record; then use platform billing support. Do not reverse a legitimate balance casually: Google warns that a chargeback against a legitimate Ads balance can lead to suspension. [BC-S07][BC-S08]
3. Agency/reseller invoice mismatch: separate the agency invoice from platform charges; match entity, contract, period, account, and underlying service. Route contract-rights questions to finance and counsel rather than treating a platform dispute route as a contract remedy. Synthesis/inference from custody/billing separation. [BC-S09][DRS-A18]

Insurance is a contract boundary. Coverage, notice, exclusions, cooperation, and decision rights belong to the policy, broker, insurer, and counsel. This hub does not characterize coverage, predict reimbursement, or coach a claim. [DRS-A17][DRS-A18]

Step 7 — verify recovery and conduct a monitored restart

Use recovered only after the complete gate passes for the incident’s scope. Restored login, an active campaign, a case response, or a green dashboard can be positive evidence without satisfying the gate. A limited restart is an operating synthesis, not a provider promise.

Checklist 4 — complete post-recovery acceptance gate

• Password, MFA, and recovery-contact reset where applicable: use a known-clean endpoint; document the owner-authorized reset and recovery-contact review. [BC-S10][RS-S04]
• Persistence removal: review and remediate scoped sessions, administrators, partners, apps, OAuth grants, tokens, extensions, rules, scripts, automations, and unauthorized payment changes.
• Access and ownership: correct legal entity and designated owner retain required full-control access; document partner/manager links and offboarding rights. [BC-S09]
• Dependencies: check parent/child links, domain/endpoint, pixel/dataset, catalog/feed, conversion configuration, billing profile, and shared dependencies relevant to the incident.
• Finance: reconcile billed, served, bank/card, agency invoice, and authorized-user records, or name each residual, owner, and next provider-dependent step.
• Evidence: retain authorized exports, notices, access logs, payment records, case chronology, and unavailable-data notes under the applicable process. [DRS-A01]
• Automation and campaign diff: compare current campaigns, rules, scripts, feeds, and automations to the preserved before-state; investigate unexpected changes. Google Ads Scripts’ best-effort semantics make a run log insufficient by itself. [BC-S06]
• Test conversion/event: verify the intended limited path from event or destination to the defined record; document the result and its boundary.
• Staged restart: approve a low-risk, limited restart with monitoring and an explicit stop condition; do not assume a broad provider result.
• Monitoring: monitor spend, delivery, event arrival, relevant access changes, and the specific incident signal during the staged restart.
• Signed closure: asset owner, finance owner, and incident lead sign the closure scope, residual provider dependencies, and follow-up owners/dates.

Step 8 — learn and test the changed control

A blameless review records impact, UTC chronology, visible states, hypotheses, evidence, decisions, contributing conditions, unavailable evidence, finance/measurement residuals, communications, owner/date for each change, and a verification test. It does not remove accountability for deliberate misconduct or contractual responsibility. A written action without a drill, export test, handoff, read-back, or recovery test remains a hypothesis. [RS-S10][RS-S03]

Measurement, security, and continuity boundaries

Measurement is a production dependency

A campaign may remain visible while event freshness, consent, matching, deduplication, attribution window, modeled field, or downstream lead routing changes. A reporting delay may also coexist with continued delivery and backend orders. Do not manufacture a universal discrepancy percentage: platform event, analytics event, CRM record, and settled order are distinct data products. [PR-P18][RS-S07][RS-S08]

MFA is useful but not a clean bill of health

MFA is layered protection. It does not establish that a browser extension, session, cookie, OAuth grant, token, unknown administrator, partner link, payment method, destination, or automation is clean. First-party and security-provider sources support a cautious recovery posture and an inbound-impersonation warning; they do not prove that any individual outreach is malicious. [RS-S04][PR-P12][BC-S18]

Self-service readiness and evidence

Copyable evidence-register template

Copy this into an incident record. Do not put secrets in it.

Incident ID:
Reporter and UTC opened:
Platform and product surface:
Region and legal entity:
Visible state(s) from taxonomy:
Exact label/error and raw text:
Affected IDs (portfolio/manager/account/campaign/asset):
First-seen UTC / last-known-good UTC:
Observed impact (not presumed cause):
Independent signals checked and timestamps:
Admin/partner/owner/billing contacts and unknowns:
Recent changes (actor, UTC, object, action):
Payment/billing state and transaction references:
Policy/verification state and official route URL:
Exports/logs/notices retained; collector and location:
Evidence unavailable, reason, and verification owner:
Authorized bounded action; approver; expected read-back; rollback condition:
Official case ID and factual chronology:
Ledger/cohort scope for reconciliation:
Acceptance-gate owner and residual provider-dependent unknown:
Closure signature/date:

This template is an operating synthesis informed by evidence-preservation and incident-record practice. It does not create forensic proof, change retention duties, or establish a platform outcome. [DRS-A01][RS-S03]

Readiness self-assessment: deterministic score and exits

Score each item 0, 1, or 2. Score 0 if unknown/not present; 1 if present but untested, partial, or single-owner; 2 if documented, owned, and recently tested. Maximum: 20.

1. Owner/full-control admin, recovery contact, and partner map for each critical container.
2. Payment/billing entity, authorized-user list, and invoice-to-account reconciliation path.
3. Export and evidence-register location for campaign, access, billing, and measurement records.
4. Shared-dependency map for identity, payment, domain/endpoint, feed, token, automation, and approver.
5. One-change authority, rollback/read-back process, and change log.
6. Independent signals for delivery, event freshness, backend outcome, and access anomaly.
7. Documented official platform routes with current account/region check.
8. Billing branch owner for suspected unauthorized activity, legitimate balance, and agency invoice mismatch.
9. Post-recovery acceptance gate with access, dependency, finance, evidence, test, monitoring, and closure checks.
10. One completed tabletop or control test within the review cycle.

Score 0–8: continue with the named first-party route. Use the applicable current Meta, Google Ads, or TikTok official route listed above, complete the evidence register, and make no change outside your authority. If suspected unauthorized activity exists, use the official platform route and issuer/bank fraud route promptly. [PR-P03][PR-P10][PR-P13][BC-S08]

Score 9–20: A higher score does not establish a risk probability, qualification, service eligibility, or platform outcome; use the named first-party route and document residuals, owners, and next steps. Synthesis/inference.

Sources, freshness, and claims ledger

All sources below were accessed 2026-07-19. Mutable platform pages require a first-party re-check in the affected account and region immediately before acting. Every row gives the source’s URL, title, author/outlet, date or undated status, access date, evidence class, and a support boundary. Community rows are public self-reports, not audited outcomes.

Source appendix