Marketo audit: the European checklist nobody runs

Twice in the past month the same conversation arrived wearing two different outfits. One was a European enterprise asking whether their Marketo instance needed an audit. The other was a listing for a freelance Adobe architect, three days a week, six months, start as soon as possible.

Different budgets, different departments, almost certainly different approval routes. Underneath, the same sentence: we are no longer sure this thing is doing what we think it is doing, and we do not know what to buy.

Those are not the same problem, and buying the wrong one is expensive in a quiet way. So this piece does two jobs. It sets out what a Marketo audit should cover for a European enterprise, which is not what the available checklists cover. And it gives you a way to tell whether what you actually need is an audit, a pair of hands, or a decision.

What does a Marketo audit normally cover?

Read any of the audit checklists published by the large Marketo partners and you will find roughly the same five areas. Administration and system health. Program effectiveness. Lead management and scoring. Analytics and reporting. Strategic alignment.

That is a real service and it finds real things. Orphaned programs, scoring models nobody has touched since the person who built them left, smart lists that quietly contradict each other, a database where a third of the records have not been touched in four years. If your instance has been running for five years and has had three owners, this audit is worth its fee.

It also has a shape, and the shape tells you who it was built for.

An audit sold by your implementation partner is not an independent audit

Every one of those checklists comes from a Marketo implementation partner. Not most. Every one I could find on the first page of search results, in English and in Dutch.

Nobody involved is being dishonest. The audit exists because it is a good way to scope optimisation work, and optimisation work is a legitimate business that a lot of enterprises genuinely need. But it means the audit is answering a question with a fixed range of possible answers, and "this platform is wrong for you" is not in the range. An auditor cannot conclude that without invoicing themselves out of the next project.

If you are asking whether your instance needs tidying up, that range is fine. If you are asking whether to keep the platform at all, you are asking a question nobody in that market is structurally able to answer.

Your checklist was written for an American instance

The second thing about those five areas is what is missing from them.

I read the checklist currently ranking at the top of search for "Marketo audit". Five sections, several hundred line items, and exactly one line touching regulation: "review compliance with data regulations." No consent. No lawful basis. No data residency. No subprocessors. The others follow the same template closely enough that the omission is clearly structural rather than an oversight by one author.

This is not a criticism of the authors. They wrote for the market they sell into, and in that market the regulator is not the thing that wakes you up at three in the morning. In Europe it increasingly is. From 15 August the Dutch Cyberbeveiligingswet puts a set of these questions on the board agenda for entities in scope, and the CNIL and Garante decisions have already moved email open tracking into consent territory across two large European markets.

The standard audit checks the layers where value commoditises

The standard Marketo audit checks the layers where value commoditises and skips the one where it pools. There is a pattern in what gets left out, and it is not random.

The Value Gravity™ model splits a marketing stack into three layers. The Experience layer holds content engines, personalisation and creative generation. The Orchestration layer holds decision engines, journey routing and workflow. The Foundation layer holds the data model, identity, consent and governance. Value pulls downward, toward the layers with high switching costs and embedded governance, which is exactly why those layers are hard to move and expensive to get wrong.

Line the two lists up:

Six for six. That is the whole argument, and it is also why the six checks below are those six rather than another twelve I could have made up.

The six checks a European instance needs

A Marketo audit built for a European enterprise covers six areas: consent lineage, open and click tracking, lawful basis per program, data residency and the subprocessor chain, access and offboarding, and retention and deletion. All six sit in the Foundation layer, and none of them appear on the standard checklists in any depth. Each check below comes with the question to ask and what the finding usually looks like.

1. Consent lineage, not the consent field

A consent field is not consent evidence. Marketo stores the field reliably. The evidence behind it, which form, which version of which text, on which date, under which privacy notice, usually lives across form history, program membership, a changelog nobody exports, and somebody's memory.

Ask for a single record, picked at random by someone other than the person answering, and ask what that person agreed to and how you would prove it. The gap between the field and the proof is the finding.

I was called into one organisation that had run for years without a single privacy request. Then three arrived close together, a mix of access and deletion. Nobody could answer the question underneath them: when did these people agree to this, and how would you show it?

The instance had the consent field. The evidence sat somewhere else, spread across form versions, program membership and changelogs, and several pieces of it had never been recorded at all.

Two things came out of that engagement worth carrying into your own. The one-month deadline in Article 12 passed while they were still looking. Article 12(3) does allow two further months where a request is genuinely complex, but only if you tell the person inside the first month and give your reasons, and nobody does that while they are still hoping to find the answer. And to resolve three privacy requests, they brought in an external Marketo architect who then needed system access too, which is how a data protection problem quietly becomes an access governance problem.

The check costs an afternoon when nobody is asking. It costs considerably more once a clock is running.

This is also the check that decides migrations. Fields carry across. Evidence does not.

2. Open and click tracking

After the CNIL and Garante decisions, email open tracking needs its own basis, separately from the mailing. Almost no audit checklist mentions this, because almost no audit checklist was written after those decisions or for those jurisdictions.

The operational question is not whether the pixel fires. It is what depends on it. If opens sit in a report, the fix is small. If opens feed scoring, routing and lifecycle movement, changing the consent model changes your revenue operations, and that is a different conversation with a different budget. The how-to for both countries covers the mechanics.

3. Lawful basis per program, not per database

Legitimate interest for one campaign and consent for another is perfectly workable. A smart list that unions both is not, and the smart list has no idea there is a difference.

Check whether basis is recorded at program level and whether anything downstream respects it. In most instances the answer is that basis was decided once, at the database level, several years ago, by someone who has since changed jobs.

4. Residency and the subprocessor chain

Where the instance actually sits, what the AI features route where, and whether anyone re-read the subprocessor list after the last feature was switched on.

Adobe documents its privacy request mechanics well. It says considerably less about residency, and the documentation for privacy requests carries a caveat worth reading closely: the Adobe Privacy Service route applies to instances onboarded to Adobe Identity Management, which is not all of them.

Fold the EU AI Act question in here. Predictive scoring and generative features that are already enabled were, in my experience, almost never classified by anyone before they were switched on, because switching them on took one click and no procurement.

5. Access and offboarding

Who can log in, who can export the database, and who could send to it. Logins that outlive employment because they were created with an email and password rather than through single sign-on. Partners and agencies holding admin because the role that matches the actual work does not exist. API keys nobody can attribute to a system anyone still uses.

None of this is exotic and all of it is findable in an afternoon. What makes it an audit finding rather than a to-do is that nobody owns the review, so it is never anybody's turn to do it.

From 15 August this stops being marketing hygiene for Dutch entities in scope of the Cyberbeveiligingswet. The detail, and what it looks like from the inside, is here.

6. Retention and deletion that actually executes

Right to be forgotten has to run across Marketo, the CRM, the warehouse and the export sitting in somebody's downloads folder from the last campaign review.

Most instances can prove step one. Ask for the full chain and watch where the answer becomes a description of intent rather than a description of a process.

Do you need an audit, or do you need a person?

There are three things you can buy here, and they are not interchangeable. Back to the two conversations at the top, because they resolve differently.

A decision. You know something is off, you do not know what, and the next real move depends on the answer. This is short, independent, and it ends with a written finding rather than a work plan. Weeks, not months. If you are considering a platform change, this is the only one of the three that is capable of concluding you should not.

A build. You know what needs doing and you need it done. Agency or contractor, both fine, and the fee follows the scope. The only failure mode here is buying a build when you have not made the decision, which is how six-month engagements turn into eighteen-month engagements.

A seat. You have the decision and the work, and what you are missing is someone senior enough to hold the architecture while it happens. Interim, part-time, inside the team.

The listing I mentioned at the top was for the third. Reading it, I am fairly sure the organisation behind it needed the first, because the requirement described symptoms rather than work. That is the common case. A role gets posted because something is not working and nobody has named what, and six months of day rate is an expensive way to run a diagnosis.

For the record, and because this article is otherwise going to be coy about it: I do the first, as a fixed three-week diagnostic. I take the third where the architecture question is genuinely open and the engagement is European. I do not do the second, which is the reason I am able to write the section above.

Adobe is not retiring Marketo

Adobe has not announced a retirement for Marketo Engage. AJO B2B Edition Prime, announced at Summit 2026 and generally available since Q2, runs on Marketo Engage data and sits above it rather than replacing it. Marketo is the foundation layer in Adobe's B2B stack, not the thing being deprecated.

The correction is worth a section because the rumour is currently driving decisions that do not need to be made. If you are considering leaving because you heard Marketo is going away, you are solving a problem you do not have, and you are about to spend eighteen months and a large budget on it. There are good reasons to leave a platform. That is not one of them.

Worth noticing where this rumour actually lives. In the executive track at Summit this year, nobody asked whether Marketo was going away. In the user groups it surfaces occasionally. Where I hear it most is outside the Adobe ecosystem entirely, from consultants and marketing leaders who do not work in the platform and are advising someone who does.

Adobe is careful about roadmap commitments, which is what you would expect from any vendor carrying enterprise contracts, and that care reads differently depending on where you are standing. Inside the ecosystem it sounds like normal discipline. Outside it, quiet sounds like an answer.

The other half of it is what people carry home from Vegas, which is the visible layer: the features, the product updates, the demo that worked. The decision you are actually facing sits underneath that, and nothing in April moved it.

What to do this week

Pick one record and try to prove its consent. Ask who can export the database and see how long the answer takes. Open the subprocessor list and check the date on it.

None of that needs a budget line, and it will tell you which of the three things you are actually buying.

---