MarTech Stack Audit: The Complete Framework
A step-by-step martech stack audit — inventory, overlap analysis, true cost per tool, and the kill/keep/consolidate decision matrix. With a free checklist.
What a Real Audit Answers (That an Inventory Never Will)
I sat in a budget review last year where a CMO proudly presented a spreadsheet of 47 marketing tools, tagged by department, owner, and renewal date. Her CFO asked one question: which of these should we cut? Silence. She had an inventory. She did not have an audit.
That distinction matters more than it sounds. An inventory is a list. It tells you what you own, who bought it, and when it renews. It is a procurement artifact. An audit is a decision document. It tells you what to kill, what to consolidate, and what to keep, with a dollar figure attached to each choice.
I've run this exercise at Novartis across a stack touching 1,200+ websites in 90 countries, and later for mid-market clients with 20 to 40 tools. The pattern is identical regardless of size: teams can name their tools. Almost none can say, with evidence, why they still pay for a third of them.
A real audit answers four questions a spreadsheet cannot: What does each tool actually cost once you count the hidden labor? Where do two or more tools do the same job? What happens if we cut this tool tomorrow? And who is accountable for making that call, not just documenting it?

Step 1: Inventory, The Fields That Actually Matter
You still need the inventory. It's the raw material for the audit, not the audit itself. But most inventories capture the wrong fields, the ones procurement cares about instead of the ones a decision-maker needs.
For every tool, capture: owner (the actual daily user, not the signatory), department, annual license cost, contract end date, integration count (how many other systems it feeds or pulls from), primary use case in one sentence, and last-quarter usage data pulled from login logs or admin consoles, not from asking someone if they use it.
That last field kills more tools than anything else. In one audit I ran for a healthcare marketing team, a $180K analytics platform had four active logins in ninety days. Nobody had lied about using it. Nobody had checked.
Step 2: Overlap Analysis, Mapping Capability Collisions
Once you have the inventory, stop organizing by vendor category and start organizing by capability. Vendors are happy to blur categories, an email platform that also does SMS, a CDP that also does personalization, a CMS with a bolted-on analytics module. If you audit by category, you'll miss the overlap sitting in plain sight.
Build a capability map instead: list every discrete function your stack performs (email send, SMS send, web personalization, lead scoring, attribution, A/B testing, form building, and so on), then mark every tool that can perform it, even partially.
In a 34-tool stack I audited for a B2B enterprise client, we found six tools claiming lead scoring capability and three doing web personalization. Nobody had designed that overlap. It accumulated over six years of point solutions bought to solve one team's urgent problem, with no one checking what already existed.
The output isn't a list of duplicates to delete on sight. It's a map of collisions that need a decision, which brings you to cost.

Step 3: True Cost Per Tool (It's Never Just the License)
License cost is the number everyone tracks and the least useful one. The real cost of a tool has four components, and three of them never appear on an invoice.
License cost is the sticker price, the number in the vendor contract. Integration cost covers the engineering and IT hours spent building and maintaining every connection that tool has to the rest of the stack, including the ones that break during every major platform update. Headcount cost is the labor consumed running or babysitting the tool: the analyst who manually exports data because the API integration was never finished, the admin who reconciles two contact databases every Monday. Opportunity cost is what your team isn't building because they're maintaining this tool instead.
When we ran true cost analysis at a pharma marketing client, a tool with a $60K license carried closer to $210K in fully loaded cost once we counted the 1.5 FTEs effectively dedicated to keeping it running and reconciled with adjacent systems. The license was 29% of the real number.
This is the calculation that turns a CFO conversation from defensive to strategic. Nobody wins an argument about SaaS spend with a list of subscription fees. You win it by showing the fully loaded cost of the tools you're keeping versus the ones you're not.
Step 4: The Kill / Keep / Consolidate Decision Matrix
This is the actual audit. Everything above is inputs. The matrix is where you make the call, and it needs to be explicit enough that someone outside marketing can follow the logic.
For every tool, plot two axes: capability overlap (does something else already do this, fully or partially) and true cost (fully loaded, from Step 3). Then apply a simple decision rule.
Kill: high overlap, high cost, low or no measurable usage. No mitigation needed beyond an offboarding and data migration plan.
Consolidate: high overlap, but the tool has a genuine edge case, a workflow, an integration, a team dependency, that the overlapping tool can't yet replace. Migrate the workflow, then kill the source tool on a set timeline, not an open-ended one.
Keep: low overlap, or overlap exists but the true cost is low and the capability is business-critical. Keep does not mean ignore. It means re-review at the next audit cycle.
The matrix only works if someone signs off on each row. A shared spreadsheet with a status column is not a decision. It's an inventory wearing a disguise.
How Often to Re-Run It, and Who Owns It
Stacks decay the same way data does: quietly, and faster than anyone expects. A tool that was essential eighteen months ago may have three overlapping replacements today, bought by teams who never checked what already existed.
Run the full audit annually, tied to your renewal calendar so kill decisions land before, not after, a contract auto-renews. Run a lighter version, inventory and usage data only, every quarter. That cadence catches the tools nobody uses long before they hit their renewal date and quietly re-up for another year.
Ownership has to sit with one person, not a committee. In every stalled audit I've seen, the reason was diffuse ownership: marketing ops owned the spreadsheet, IT owned the contracts, finance owned the budget, and nobody owned the decision. Assign a single accountable owner, usually the head of marketing ops or a digital transformation lead, and give them explicit authority to bring kill recommendations to the CFO and CMO jointly.
That single-owner model is the difference between an audit that produces a report and one that produces a lower bill.
Frequently Asked Questions
What is the difference between a martech inventory and a martech audit?
An inventory lists every tool you own, its owner, and its renewal date. An audit goes further: it maps capability overlap, calculates the true fully loaded cost of each tool, and produces a kill, keep, or consolidate decision for every line item. An inventory documents the stack; an audit changes it.
How often should we run a martech stack audit?
Run the full audit annually, timed to land before major contract renewals so kill decisions take effect instead of getting missed. Run a lighter quarterly check on usage data alone, since low-usage tools are the easiest and fastest cuts to justify.
Who should own the martech audit process?
One accountable owner, typically a head of marketing ops or a digital transformation lead, should run the process and bring kill recommendations jointly to the CMO and CFO. Splitting ownership across marketing, IT, and finance is the most common reason audits stall at the spreadsheet stage and never produce a decision.


