Blog

Most organisations audit their own access controls. Very few audit their agency's.

This is a strange gap, because the marketing agency is often the single external party holding the widest set of credentials you have issued to anyone. Not one system — a set. Ad accounts with live spend. Analytics with your full customer journey. A CRM holding the contact records of every lead they generated for you. Social accounts that speak in your name. Sometimes the domain registrar.

And the agency is doing exactly the same thing for five other clients, frequently out of one shared toolset, occasionally out of one shared login.

The risk is not that agencies are careless. Most are conscientious and the good ones are more disciplined than their clients. The risk is structural: the tools agencies use were mostly designed for a company managing its own data, then stretched to manage other people's. That stretch is where the exposure lives, and it is almost never on anyone's audit checklist.

Why the structure matters more than the policy

A single-company tool assumes one pool of contacts, one pipeline, one reporting view. Every design decision follows from that assumption.

An agency running six clients needs six pools that must never touch. The tools rarely offer that natively, so agencies improvise. The common workarounds are a custom field called "Client", a tagging convention, a naming prefix, six pipelines inside one account, or — the one that should concern you most — six separate logins that staff switch between.

Each of these works until it doesn't. And they all fail in the same direction: someone sees something they should not, or an action intended for one client executes against another.

The important point for a risk function is that these are conventions, not controls. A filter is a default view. A tag is a label. Neither is a permission. If the only thing separating your data from a competitor's is that someone remembered to apply the right tag, you do not have a control — you have a habit, and habits fail under deadline pressure, during holiday cover, and in the fortnight after someone resigns.

Four failure modes, in the order they usually appear

1. Permission scope that nobody revisits. Agencies are typically granted access when the relationship starts, at whatever level was convenient that week. Access is rarely reduced later. A contractor brought in for one campaign often receives the same visibility as the account director. Eighteen months on, nobody can reliably say who holds what.
2. Automation that crosses accounts. This is the one that causes actual damage. A follow-up sequence built for Client A fires against Client B's contacts because the trigger was scoped to a tag rather than to an account. The message goes out under the wrong brand, with the wrong offer, to people who never opted into it. If those contacts are in the EU or the UK, that is not merely embarrassing — it is a processing activity without a lawful basis, and the controller is you, not the agency.
3. Offboarding that never completes. When an agency relationship ends, the contract terminates and the access frequently does not. Ad accounts get transferred because spend makes them visible. Analytics, CRM seats, scheduled posts, shared drives and integration tokens are quietly forgotten. The exit interview covers deliverables, not credentials.
4. Staff turnover inside the agency. Your access list names a company. The people are not enumerated anywhere you can see. Agency turnover is high, and a departing employee's access is revoked at the agency's pace, not yours — assuming the agency's own offboarding is complete, which is the same problem one level down.

The question that separates a process problem from a structural one

There is a test worth applying before anyone buys new software, because plenty of organisations blame tooling for what is genuinely a process failure, then purchase a replacement and carry the problem across.

Would this still break if everyone were perfectly disciplined?

If the answer is no — if data only crosses between clients when somebody forgets a convention — then the fix is procedural. Write the convention down, enforce it at onboarding, audit it quarterly, and keep the tools you have.

If the answer is yes — if the separation you require cannot be expressed in the tool at all, no matter how careful everybody is — then it is structural, and discipline will not save you. Permission boundaries and automation scoping almost always fall on this side. Naming conventions almost never do.

The second test is direction of travel. A process problem improves as a team gains experience. A structural problem worsens as the agency grows, because every new client multiplies it.

What good separation actually looks like

Where separation is structural rather than maintained by hand, each client account holds its own contacts, pipelines, conversations and automations, and access is granted per account rather than globally per person. Agencies that reach this point usually move from a general-purpose tool to a dedicated agency CRM, because the boundary has to exist at the data layer rather than in a naming convention.

The second-order effects matter more than the feature list:

• Automations cannot reach across accounts, so the category of mistake that damages client trust stops being possible rather than becoming less likely.
• Reporting is correct by default, not correct once somebody remembers the filter.
• Client-facing access becomes safe to grant, because a client logging in can only ever see their own account.
• Offboarding becomes a single revocation rather than an archaeology exercise across nine systems.

None of this is exotic. It is ordinary functionality arranged around the assumption that the operator is running many businesses rather than one.

What to actually ask your agency

You do not need a formal audit to close most of this. Six questions will tell you nearly everything:

1. Is our data separated by permission, or by a tag or naming convention?
2. Which named individuals at your agency can currently access our accounts?
3. Can an automation built for another client execute against our contacts? What prevents it?
4. When a member of your staff leaves, what is the process for revoking our access, and how quickly?
5. If we ended the contract tomorrow, what is the complete list of systems where our access would need revoking?
6. Has an automation ever fired for the wrong client? What changed afterwards?

Question six is the useful one. An agency that answers it honestly is a better partner than one that claims it has never happened, because at sufficient volume it happens to everyone — and what matters is whether it was detected, and what changed.

The uncomfortable part

If you are the client, you are the data controller. The agency is your processor. Regulatory responsibility for a cross-client leak sits with you, regardless of whose CRM caused it and regardless of what your contract says between the two of you.

That asymmetry is the reason this belongs on a risk register rather than in a procurement checklist. You are accountable for a control environment you do not operate, cannot inspect directly, and in most cases have never asked about.

Asking is free. Start with question two.