Back to home

Resources

RBAC for Buying Teams: Protection, Not Bureaucracy

Role-based access in a buying team is not process overhead. It bounds leaks, kills shared logins, and makes incidents reconstructable. Here is how to structure it.

Published 2026-07-17 · 7 min read

Access control has a reputation problem in performance marketing. It sounds like something a compliance department invented to slow buyers down, and in teams that grew fast it usually got skipped: one shared login, one shared spreadsheet, everyone can see everything, ship it.

That works until it does not, and the failure is never gradual. Here is the case for role-based access in a buying team, made on operational grounds rather than policy ones.

The actual argument

RBAC is not primarily about trust. Framing it as "we do not trust the buyers" is the fastest way to get it rejected, and it is also wrong. Three better reasons:

It limits blast radius. Every credential is a potential incident. When one account is compromised or one person makes a mistake, the damage is bounded by what that identity could reach. With everyone holding everything, every mistake is a portfolio-wide mistake.

It makes attribution possible. If three people share a login, you cannot answer "who changed this budget" or "who pulled this export". Not because anyone is hiding — because the information was never captured. That makes every incident review guesswork and every performance discussion an argument.

It reduces cognitive load. This is the reason buyers actually appreciate once they experience it. A buyer who sees 300 accounts they do not run has to filter mentally before doing any work. A buyer who sees their own 18 accounts starts working immediately. Scoped access is a better interface, not just a safer one.

The fourth reason arrives later but arrives reliably: partners, networks and audits ask who has access to what. A team that can answer that in one screen is in a different position from one that says "everyone, basically".

The four roles

Most buying teams resolve cleanly into four roles. More than four and the model stops being memorable; fewer and you end up granting exceptions constantly.

Org admin

Owns: the organisation. Every team, every account, every policy, plus the roles themselves.

Should see: everything. Full portfolio performance, all buyers, all finance, all account connections, the audit trail.

Should not: be the default role for convenience. The most common RBAC failure in practice is that six people end up as admins because it was easier than reasoning about permissions once. If most of the team is admin, you do not have RBAC — you have a role label. Keep this seat count deliberately small and revisit it monthly.

Team lead

Owns: the performance of a defined group of buyers.

Should see: every account belonging to their buyers, per-buyer comparative performance, alerts for their group, budget and pacing across their scope.

Should not see: other teams' buyer-level performance, or org-wide financial detail such as payouts to people they do not manage. Cross-team performance visibility is a surprisingly common source of friction — comparative numbers without context get used as ammunition rather than information.

The lead is the role most often modelled badly. Leads need enough visibility to intervene before a buyer's spend slips, which means account-level detail, not a summary tile. A lead who has to ask someone else for detail cannot lead the number they are accountable for.

Buyer

Owns: their own accounts.

Should see: their assigned accounts in full — spend, revenue, ROAS, CPA, approvals and policy limitations, associated domains, and alerts for those accounts. Also their own performance history, because people manage what they can measure about themselves.

Should not see: other buyers' accounts and performance, organisation-wide financials, payout structures for other people, or account credentials they do not need.

That last one is worth expanding. There is a real difference between "can view this account's performance data" and "can access this account's login". Conflating them is how a departing buyer walks out with live access to twenty accounts. Performance visibility and credential access are separate grants and should be modelled separately.

Finance / admin

Owns: the money side — revenue, spend reconciliation, expenses, payouts.

Should see: full financial data across the organisation. Spend by account and buyer, revenue via postbacks, manual expenses, P&L, billing status.

Should not: have operational control over campaigns or account settings. Finance needs to read the numbers, not touch the levers. This is also the role where the read-only principle is most obviously correct: nothing finance needs to do requires the ability to change a campaign.

What shared logins actually cost

Shared credentials are the default state of a team that has not made a decision. The failure modes are specific and repeat across teams.

Attribution disappears. A budget gets changed, spend triples overnight, and there is no way to establish who did it or what they intended. The review turns into a meeting where three people each say it was not them, probably honestly, and nothing is learned. The same incident happens again a month later.

Offboarding becomes a manual audit. When someone leaves, you cannot simply revoke their identity, because their identity is the shared one. You have to rotate credentials everywhere and hope you found all of them. In practice, some are always missed, and access persists for months after departure.

One compromise is total compromise. A shared credential on a personal device, in a chat message, in a password manager export, is one leak away from exposing the whole portfolio. With scoped identities, the same leak exposes one buyer's set of accounts.

Alerts stop being actionable. If accounts are not owned by identifiable people, alerts get broadcast to a group. Broadcast alerts are read by nobody, because everyone assumes someone else is handling it. Ownership is what turns a notification into an action, and shared logins make ownership impossible to express.

Data over-exposure becomes permanent. Everyone sees payouts, margins, and other buyers' performance. That has second-order effects on team dynamics that are hard to unwind once they have started, and it makes the eventual move to scoped access feel like a downgrade rather than a fix.

Making it work in practice

Model account ownership explicitly. RBAC in a buying team is fundamentally about which accounts map to which person. Get the ownership map right and the permissions follow. Grouping accounts by buyer is the load-bearing structure — it drives the buyer's view, the lead's scope, and the alert routing all at once.

Separate read from write, and prefer read. Most people need to see data; far fewer need to change anything. This is why an observation-only tool is not a limitation — a platform that never signs into your ad account, and has no path to modify a campaign, cannot be the source of an accidental change, no matter who is logged in. The blast radius of the entire tool is bounded by design.

Route alerts by ownership, not by channel. An alert should reach the person who owns the affected account, plus their lead for critical severity. Everything else is noise that trains people to ignore alerts.

Review access on a fixed schedule. Monthly is enough. Check for people who left, people who changed teams, permissions granted "temporarily" six months ago, and admin count creep. Access reviews never feel urgent, which is exactly why they need a date rather than an intention.

Grant the minimum, then fix complaints. Starting restrictive and loosening on request produces a tighter final state than starting permissive and trying to claw back. It also surfaces what people genuinely need, rather than what they assume they need.

The objection worth answering

"This slows us down." Sometimes it does, marginally, on day one. What it removes is larger: the fifteen minutes a buyer spends filtering to their own accounts every morning, the meeting spent reconstructing who changed what, the credential rotation scramble after someone leaves, and the tail risk of a single leaked login touching everything.

The teams that resist RBAC hardest are usually the ones that scaled fast enough that everyone still remembers when three people ran everything. That memory is the problem. The access model that worked at three people is actively dangerous at thirty, and the transition is much cheaper before the incident than after it.

AdsTracker ships with these four roles built in — org admin, team lead, buyer and finance — with accounts grouped by buyer and alerts routed to the person who owns the account. AdsTracker has no way to change anything in Google Ads by design, so the whole system can be used for visibility without becoming a route to accidental campaign changes.

All articles