What data a marketing agency actually needs
The minimum access platform by platform, five requests that should give you pause, and the six questions worth answering before you hand over the keys to your CRM and ad accounts.
Hiring a marketing agency almost always means handing over the keys to several things at once: the ad accounts, the analytics, the CRM, the website, the email list. It happens fast, in the first few days, and it is almost never discussed. This article is the conversation that should happen there.
It is not about distrusting your agency. It is about access having a correct shape — one that protects you, protects your customers and, once Chile’s Law 21.719 is in force on 1 December 2026, is also what the law expects.
Why nobody asks this
Because it lands at the worst moment. The access request arrives during onboarding, when the relationship is just starting and nobody wants to open with conditions. On the other side, the agency asks for everything at once because it is faster than asking piece by piece, and because it usually does not know upfront what it will need.
The outcome is nearly always the same: more is handed over than necessary, no record is kept of what was handed over, and nobody revisits it. Months later, nobody in the company can say who has access to what.
Access is not the same as data
Three things usually travel inside the same request, and they are not equivalent:
- Operational access to a platform. Being able to open Google Ads and change a bid. That is what an agency needs in order to work.
- Reading data. Seeing how many leads came in and which converted. Also necessary, but it can be narrowed far more than it usually is.
- Holding data. A copy of your database living inside an agency system. This is almost never required, and it is the hardest thing to undo later.
The principle that orders all three is minimisation: access and process only the information required to meet the goal of the service. If a narrower permission is enough, the narrower one is the right one.
The minimum access, platform by platform
| Platform | What usually gets asked for | What is actually enough |
|---|---|---|
| Google Ads | Account username and password | MCC link with the role the work requires |
| Meta Ads | Access to the personal profile | Business Manager access to the specific asset: ad account, page or pixel |
| Google Analytics | Administrator access | Read role, and edit only while measurement is being configured |
| CRM | A full user seat | Read the lead outcome, not the conversation history or sensitive fields |
| Website | Server and database access | Whatever the agreed work needs, for as long as it lasts |
| Email marketing | A full export of the list | Work inside the tool, without taking the list out of it |
The pattern repeats: nearly every platform has a permission system designed for exactly this, and nearly nobody uses it because sharing the password is faster. The difference shows up the day access has to be revoked, or the day someone has to explain who made a change.
Five requests that should give you pause
None of them proves bad faith. All five deserve an explanation before you say yes:
- Your username and password instead of their own access. It destroys traceability and makes revoking access mean changing your own password.
- Exporting the full contact list to “load it into our tool”. Most of the time the work can be done inside yours.
- Administrator access when the task is reading a report.
- Creating assets under the agency’s name — the pixel, the analytics property, the ad account, the domain. Created under yours and shared, the asset stays yours whatever happens to the relationship.
- A contract that never mentions data. If it only covers deliverables and fees, nothing is written down about what may be done with the information.
The part nobody plans: the ending
Every agency relationship ends at some point, and that is when you find out how it was built. Law 21.719 requires formalising the relationship with vendors that process data on the company’s behalf through a Data Processing Agreement (DPA), and one of the things that agreement has to regulate is, explicitly, the return or deletion of the data when the service ends.
In practice that means being able to answer three questions on the day the relationship is cut: which accesses get revoked and who revokes them, what copies of information exist outside your systems and what happens to them, and who owns each asset. If all three have written answers before you start, the ending is paperwork. If not, it is a negotiation at the worst possible moment.
Checklist before you hand over access
- What specific task requires this access?
- Is there a lower permission level that would do the job?
- Is it granted through the platform’s permission system, or by sharing a password?
- Are the assets — pixel, property, account, domain — under the company’s name?
- Is there a record anywhere of who has access to what?
- Does the contract say what happens to the data and the accesses when the relationship ends?
Six questions, ten minutes. That is less time than it takes to recover an ad account registered under somebody else’s name.
FAQ
- Does an agency need to be a user in my CRM? Usually not a full one. What an agency needs is to read the outcome of a lead — did it convert, what is it worth — not the conversation history or the customer’s personal details. Whether your CRM can express that difference varies; if it cannot, that is worth knowing before you grant access.
- Why should the agency not use my personal login? Because then nothing is traceable and nothing is revocable. Every action looks like yours, and when the relationship ends the only way to cut access is to change your own password. Permission systems such as Google Ads MCC or Meta Business Manager exist to avoid exactly that.
- Who is responsible if the agency mishandles the data? Under Chile’s Law 21.719 the company that decides the purpose and the essential means of processing is the controller, and the agency acting on its instructions is a processor. The controller does not stop being responsible for choosing its processors — which is why the contract and the DPA matter.
- What is a DPA? A Data Processing Agreement: the annex regulating subject matter and duration, authorised purposes, the controller’s instructions, confidentiality, security measures, subcontracting, incidents, international transfers and the return or deletion of data when the service ends.