
Tools and providers
Part of Selecting paid social tools and suppliers through privacy, security and exit gates
Paid social agency setup: access, checks and handover
Paid social agencies tool implementation: a guide to client access, privacy, measurement, fictional tests, reversible release and handover.
| Implementation case | Decision to make | Evidence required before proceeding |
|---|---|---|
| Identity and channels | Keep account control with the client and grant named, limited access | Account permissions, linked assets and revocation route checked |
| Service and data | Configure only the contracted scope and reviewed data routes | Register complete; absent terms marked unknown; privacy review recorded |
| Measurement | Reconcile platform measures with finance records | Metric definitions, source exports and differences assigned |
| Workflow rehearsal | Test with fictional records and no media spend | Approval, failure, accessibility and retest evidence retained |
| Release and exit | Approve a capped, reversible production scope | Pause authority, rollback, handover and fallback ready |
Paid social agency setup: keep account control with the client
Keep the client administrator in control of the root business identity, billing profile and recovery route. Give access only to named agency users, choosing the least powerful role that supports their tasks. Avoid shared logins and supplier-owned assets whenever a client-owned arrangement is available.
Inspect the actual account and current permissions: supplier documents cannot confirm that a feature is enabled in this setup. Check the precise product, edition and account in its admin console, alongside these account access checks.
Client-Owned vs Supplier-Owned Access
Client-owned
- Root identity
- Client retains
- Billing profile
- Client controls
- Recovery route
- Client-owned
- User roles
- Least-powerful
- Revocation
- Client can revoke
Supplier-owned
- Root identity
- Agency retains
- Billing profile
- Agency controls
- Recovery route
- Agency-owned
- User roles
- Often shared
- Revocation
- Agency decides
Treat every channel as a separate implementation. Confirm current product names and account options in the admin console, then use the native tool for each channel. Check the live account before configuration rather than assuming an option is available in this client setup.
- Facebook and Instagramthe client's Meta Business Manager and Meta Ads Manager.
- TikTokTikTok Business Center and TikTok Ads Manager.
- LinkedInLinkedIn Campaign Manager.
- PinterestPinterest Ads Manager.
- SnapchatSnapchat Ads Manager.
- X: X Ads.
For each platform, record the client-owned ad account and linked Page or profile, then invite named agency users with the least access needed. Keep the asset register current, so ownership and user permissions can be checked against the account in use. This makes each channel's live access arrangement reviewable.
Map tracking events before enabling Meta Pixel or dataset, TikTok Pixel, LinkedIn Insight Tag, Pinterest Tag, Snap Pixel or X Ads website conversion tracking. Complete consent and privacy review, inspect a test event in native diagnostics, and confirm conversion events use matching identifiers. A connected tag alone does not complete these checks.
Where catalogue or product-feed advertising is supported, confirm feed owner, required fields, item identifiers and update process. Set each audience's approved source, purpose, exclusions and retention before creation. Platform tools include Meta Custom Audiences, TikTok Custom Audiences, LinkedIn Matched Audiences and X Tailored Audiences. Do not use live customer data or authorise spend for a test; retain evidence and note account limits.
Enable multifactor protection, log privileged changes and test revocation. NCSC social-media security guidance recommends controlling access, promptly removing leavers and planning recovery. Its user privilege guidance is a relevant security reference. Record who can revoke an agency partner if ordinary administrators are unavailable, and keep recovery responsibility with the named access and revocation route. The NCSC small business guide provides an additional official security reference.
Draw the boundary around service and data
Define the contracted service boundary before configuring tools. Put the agreed scope in an implementation register, map each integration to a stated purpose, and mark terms absent from the quote or contract as unknown. This prevents undocumented assumptions from being treated as approved service.
Record legal entities, product and edition, client-owned accounts and assets, country, currency, VAT treatment, billing period, media payer, authorised functions, prohibited uses, support route and exit deliverables. Match the register to the agreement rather than allowing implementation to widen it, and include legal entities as an explicit field.
Implementation Register Fields
- Legal entities, product and edition
- Client-owned accounts and assets
- Country, currency, VAT treatment
- Billing period and media payer
- Authorised functions and prohibited uses
- Support route and exit deliverables
For every integration, record its purpose, fields, people, source, recipient, party roles, access countries, retention, deletion and rights handling. Review cookies, pixels and comparable device access separately against applicable ICO storage and access guidance. A successful connection alone does not establish that deployment is permitted.
These England-focused steps use UK privacy and security sources. Confirm exact permission tables in the relevant product's official help centre or admin console, for the actual edition and account. Complete the privacy review before production use. This is implementation guidance, not platform documentation or legal approval.
Reconcile the measures before reporting
Publish a metric only when its definition and source can be checked against finance and platform records. For each reported field, specify the event, numerator, denominator, period, timezone, attribution setting, exclusions and source, then assign an owner and tolerance to every difference.
A platform-attributed conversion is an observation recorded by that platform, not proof of causal sales, even when an agency dashboard displays it. Retain decision logs and source exports so reviewers can reconstruct what was known at approval, then compare the result with finance evidence and the original platform record.
| Event | Numerator | Denominator | Timezone | Attribution |
|---|---|---|---|---|
| Purchase | Completed purchases | Sessions | Europe/London | 7-day click, 1-day view (typical default; confirm in the account) |
Rehearse the workflow without live exposure
Prove the workflow before relying on the tool in live delivery. Start in an empty account or use a sandbox test plan, with obviously fictional briefs and records that do not describe a real person.
Do not upload customer lists or authorise media spend to test whether controls work. Keeping live personal data and paid media out of early checks makes the exercise reversible and avoids using real-world records for rehearsal. Apply the ICO privacy review to the planned data route before moving beyond fictional records.
Rehearse the full route: create a draft, request approval, reject it, make a correction, approve it, export decision evidence and revoke the operator. Also test expired credentials, an unavailable integration and mistaken permission as failure cases. Record expected and observed results, time, tester, screenshot or log, defect owner and retest outcome; compare expected and observed results.
Have intended users complete critical tasks using a keyboard and relevant assistive technology. Apply pertinent WCAG 2.2 AA criteria to the interface and exported reports, with the Equality Act 2010 as the legal baseline in Great Britain. Automated scans and supplier statements do not replace users completing the actual approval and recovery routes.
Release a reversible scope and preserve an exit
Release only a capped, reversible production scope approved by the media payer, with named pause authority and evidence required for a restart. Implementation is complete only when the client can operate, inspect, stop and leave the service, supported by handover materials and a tested fallback.
Set pause conditions for unexpected spend, missing logs, inaccessible approvals, unauthorised access, data mismatch, an incident, a platform-policy change or a failed export. Keep rollback available. These conditions should be clear to the people with authority to pause activity and to approve a restart.
At handover, provide client-owned access, an access list, asset register, configuration record, metric dictionary, incident contacts and supplier documents. The exit pack must also include an export and deletion procedure plus a tested manual fallback, so the client can inspect and leave the service.
Schedule reviews covering leavers, permission changes, subprocessors, terms, retention and accessibility defects. Before publication or wider rollout, UK privacy or PECR counsel, security, accessibility, commercial and platform-contract reviewers must each clear the gate for their own area. Keep the relevant evidence with the implementation record.



