Salesforce Marketing Cloud Audit

A Marketing Cloud Audit That Ends in a Plan, Not a Slide Deck

A Marketing Cloud audit is a point-in-time assessment of an org you already own, across five domains: the data model, the journeys and automations, deliverability, permissions, and the integration layer. Twopir Consulting delivers it as a findings register — each item with evidence, a severity, an estimate of effort, and the business consequence of leaving it alone.

Request an Audit Marketing Cloud Consulting
  • 12+ Years of CRM and marketing platform delivery
  • 500+ Clients across six markets
  • 250+ Platform deployments delivered
Audit Scope
WHAT GETS REVIEWED Data model Extensions, keys, relationships, sprawl Domain 01 Journeys and automations What runs, what overlaps, what is dead Domain 02 Deliverability Authentication, reputation, complaints Domain 03 Permissions and security Who can do what, and who left Domain 04 Integrations Feeds, packages, credentials, failures Domain 05 TWOPIR AUDIT METHOD Evidence Every finding cites what we looked at Severity Business consequence, not a color code Sequence What to fix first, and why that order 2πr WHAT YOU RECEIVE A findings register you can act on without us Evidence, severity and effort against every item A remediation plan sequenced by impact Yours to run in-house, with us, or with anyone else
Scope

What a Marketing Cloud Audit Actually Examines

Five domains, reviewed in this order because each one constrains the next. There is no point tuning a journey that runs on a data model nobody can segment, and no point improving content that lands in a spam folder.

Domain 01

The data model and data extensions

Almost every other finding traces back here. We inventory what exists, establish which tables are actually in use, test whether the relationships hold, and work out why the contact count is what it is — which is usually the finding with the clearest monetary value attached.

  • Data extension inventory: what exists, what is referenced, what is dead
  • Relationship integrity and key strategy in Contact Builder
  • Duplication across extensions and within them
  • Retention policy, or its absence, and the storage it costs
  • Contact count growth attributed to a specific source
  • Consent and preference data: complete, current, and honoured
Domain 02

Journeys and automations

What is running right now, what it does, and whether anyone intended it. In an org more than two years old this inventory routinely turns up journeys nobody remembers commissioning, still sending to live customers.

  • Full inventory of journeys and their live versions
  • Overlapping entry criteria and missing suppression logic
  • Goals and exit criteria configured, or silently left empty
  • Contacts stranded on superseded journey versions
  • Automation Studio schedules, dependencies and failure history
  • Work duplicated between journeys and automations
Domain 03

Deliverability and sending

Whether the mail arrives, and whether the configuration will keep it arriving. Deliverability degrades gradually and becomes visible suddenly, so this domain is about trajectory as much as current state.

  • Sender authentication on every sending domain
  • Sending reputation trend and complaint rate
  • Bounce processing and suppression hygiene
  • Send classification, delivery profiles and sender profiles
  • Engagement distribution: how much of the list is genuinely active
  • List acquisition practices that put reputation at risk
Domains 04 & 05

Permissions, security and integrations

The two domains nobody reviews until something goes wrong. Together they answer a single question: if the person who built this left tomorrow, what would break and who could fix it?

  • Role and permission model against actual job functions
  • Users who no longer work there, and what they can still do
  • Business unit structure and cross-unit data access
  • Installed packages and API integration scopes
  • Credentials owned by individuals rather than by the organization
  • Inbound feed failure history and alerting — see integration
The Deliverable

Every Finding Arrives in the Same Shape

An observation without evidence is an opinion, and a severity without a business consequence is a color. Each item in the register carries all five columns, which is what makes the plan arguable rather than merely received.

The structure of an audit finding
FieldWhat it containsWhy it is there
FindingOne sentence stating what is true, in the platform, right now.If it cannot be written in one sentence it is usually two findings.
EvidenceWhat we looked at: the object, the query, the configuration screen, the date it was observed.So you can verify it yourself, and so it can be re-checked after remediation.
ConsequenceWhat this costs the business — in money, risk, staff time or lost performance.A severity rating with no consequence behind it cannot be prioritized against anything else.
SeverityCritical, high, medium or low — derived from the consequence, not assigned by feel.Critical means a compliance, security or revenue exposure that is live today.
RemediationWhat fixing it involves, roughly what effort it takes, and whether your team can do it.Many findings are yours to fix in an afternoon. We would rather say so than bundle them into a project.

No outcome figures on this page — see the claims note in the source header Last reviewed 23 September 2026

Process

Four Steps, and You Keep the Output

A bounded engagement with a named deliverable. The findings are yours whether you continue with us, take them in-house, or hand them to another partner entirely — which is the only arrangement under which an audit can be honest.

Step 01

Access and orientation

Read access to the org, a short session with whoever knows most about it, and the business context: what the platform is supposed to be achieving, and where it is visibly falling short.

Step 02

Examination

The five domains, worked through systematically rather than by following whatever looks interesting. Evidence captured against each finding as we go, not reconstructed afterwards.

Step 03

Severity and sequence

Each finding gets its business consequence, its severity and an effort estimate. Then they are sequenced — because some fixes are prerequisites for others, and doing them out of order wastes the work.

Step 04

Walkthrough and handover

A working session, not a presentation: we go through the register with your team, argue about priorities, and adjust. You leave with the register, the plan and the evidence.

12+
Years delivering CRM and marketing platform transformation
500+
Clients served across global markets
250+
Platform deployments delivered
98%
Client retention rate
Common Findings

Five Things We Find in Almost Every Org

Not a prediction about yours — a description of what recurs. These appear often enough that it is worth checking for them yourself before commissioning anything, and two of them have a directly quantifiable saving attached.

None of them indicate incompetence. They are what happens to any platform that has been in production for a few years while the people running it changed.

Contact count growing faster than the customer base — Usually a synchronized data source pulling an entire CRM object rather than a filtered view. Every contact or lead brought across counts as a contact in Contact Builder whether or not you ever message them. This is the finding most likely to pay for the audit.

Journeys running that nobody commissioned — Built for a campaign that ended, never switched off, still entering customers. In older orgs it is normal to find several — and occasionally one sending messaging the brand retired years ago.

Credentials belonging to people who have left — An integration authenticating as a former employee, which nobody dares rotate because nobody is certain what depends on it. A security exposure and a single point of failure in the same object.

Data extensions nothing references — Created for a one-off import, never cleaned up, now indistinguishable from the live ones. They cost storage, confuse everyone building an audience, and make every subsequent migration more expensive.

Deliverability drifting without anyone watching — Engagement slipping and complaint rates creeping up slowly enough that no single week looks alarming. By the time inbox placement is visibly affected, recovery takes months.

When to Audit

Five Situations Where Diagnosis Comes Before Anything Else

An audit is not always the right purchase. It is the right one when the honest position is that nobody can currently say what state the platform is in — because every other engagement then starts with guesswork priced as certainty.

You inherited the org — through a role change, an acquisition, or a partner who finished and left — and no documentation came with it.
Performance is declining and the team is out of hypotheses, so the next step is currently "try things".
You are about to migrate or re-platform, and nobody has established what is actually in use and worth taking.
A renewal is coming and you need to know whether the licenses and contact count you are paying for match what you use.
Something failed in a way that surprised everyone, and the real question is what else is configured the same way.
Related

Optimization

Acting on the findings: improving the performance of an org that already works, and measuring the change.

Managed Services

If the finding is that nobody is watching the platform between campaigns, this is who does.

Marketing Cloud Consulting

The practice page: architecture, edition selection and how a larger engagement runs.

Migration

When the audit concludes that the org should be rebuilt or consolidated rather than repaired.

Integration

Where most silent failures live — feeds, credentials and sync cadence.

Marketing Cloud Case Study

A worked example of the architecture-first approach on a real client engagement.

Common Questions

Questions About the Audit

Read access is sufficient for the examination itself — we are establishing what exists, not changing it. Where an org has multiple business units we need visibility across all of them, because cross-unit data sharing and permission inheritance are two of the places findings hide.

We also need a short session with whoever knows the org best. A great deal of what an audit establishes is intent: whether something is configured that way deliberately or by accident. The platform cannot tell us that.

An audit diagnoses. Optimization improves. The audit tells you what is true about your org and what it is costing you; optimization is the work of changing those numbers and measuring the change.

They are frequently sequential — audit, then optimize the things the audit found — but they are bought for different reasons. You buy an audit when you do not know what is wrong. You buy optimization when you know the numbers should be better.

Rarely, and we are wary of the reflex. A full rebuild is occasionally the right answer — usually after an acquisition, or where the contact model is so wrong that everything above it is compromised — but it is the answer we reach last, not first.

Most findings are cheaper to repair in place. Several will be things your own team can fix in an afternoon, and the register says so explicitly rather than bundling them into a project.

Yes, and a good number of clients do. The register is written to be actionable without us: each finding carries the evidence, the consequence and what fixing it involves, including whether it is within reach of an in-house administrator.

We would rather you fixed forty things yourself and brought us the four that need architectural work than paid us for all forty. That is also the only footing on which the severity ratings can be trusted.

It scales with the size of the estate rather than with the size of the business — the number of business units, the number of journeys and automations in flight, and how many integrations point at the org. A single-business-unit org with a handful of journeys is a substantially shorter exercise than a multi-brand estate with years of accumulated configuration.

We scope it after a short conversation about the shape of the org, and the scope is fixed before we start. An audit that expands as it goes is an audit whose findings you cannot budget against.

Frequently — that is a large share of this work, and it does not make the audit adversarial. The purpose is to establish what state the platform is in, not to assign blame for it. Most of what we find was a reasonable decision under the constraints of its time.

What we do not do is grade the previous partner. The register describes the org as it is today and what to do about it. If you want an opinion on the relationship, that is a separate conversation and not one an audit should be used to manufacture.

Next Step

Find Out What State the Platform Is Actually In

Tell us roughly how many business units and journeys are in play and how long the org has been running. That is enough to scope an audit and to say what it is likely to surface.

Request an Audit Marketing Cloud Optimization

Serving: US | Canada | UK | UAE | Australia | New Zealand

Relatable? We should definitely talk.

What we'll cover:

From CRM and integrations to custom apps and complex system architecture — we help you scale without chaos.
  • Identify revenue leaks across CRM, integrations, and GTM
  • Design and optimize complex systems (CRM to Custom Apps)
  • Apply practical AI to improve operations and pipeline conversion
  • Eliminate silos and build a unified revenue system
  • Assess GTM performance and key bottlenecks
  • Align teams with clear processes and ownership
  • Define a scalable RevOps model
  • Improve forecasting and reporting
  • Review your HubSpot/Salesforce setup for scale