How to Audit and Rationalise a Martech Stack

A martech stack audit is not a search for the smallest possible number of tools. It is a structured decision about which marketing and customer capabilities the organisation needs, which platforms provide them, and whether each platform should be retained, remediated, consolidated, replaced or retired.

That distinction matters because tool count is a poor proxy for anything. A platform that looks redundant on a slide may be holding up a critical workflow. A platform everybody uses may still be expensive, insecure or ungoverned. A platform nobody has opened for four months may be essential during a seasonal campaign, a regulatory return or a product recall.

So the audit has to connect capabilities to owners, users, workflows, data, integrations, costs, contractual constraints and evidence of value. What it produces is a controlled portfolio decision, not a list of licences to cancel.

A stack audit establishes that change is justified. A marketing automation migration plan determines how to make that change without losing operational, customer or measurement integrity. This article covers the first job and hands the second one over at the point the decision is approved.

What This Audit Delivers

A completed audit should leave the organisation holding a capability map, a full vendor and contract inventory, named business and technical owners, a map of users, workflows, data and integrations, evidence of actual use, a fully loaded cost model, a risk and dependency assessment, a list of capability gaps and functional overlaps, one explicit decision for every platform, approved actions tied to renewal and termination dates, and a governance process that repeats.

None of that is exotic. It is ordinary portfolio management applied to a category of spending that usually escapes it. Technology investment is more reliably controlled when it is treated as a portfolio that is repeatedly selected, controlled and evaluated rather than as a series of individual purchases, which is the principle behind established investment management frameworks (1). That framework was written for United States federal bodies rather than marketing teams, so it supplies the discipline and not the specifics.

Building the Evidence Base

The first five steps produce the facts. Resist the urge to reach conclusions while collecting them, because the platform that irritates the most people is rarely the platform that costs the most or carries the most risk.

Step One: Define the Required Business Capabilities

Begin with what the organisation must be able to do, not with the products it already owns.

Capabilities usually include customer and account data management, consent and preference management, audience selection, content and asset management, campaign orchestration, activation across email, mobile or advertising, lead management, sales hand-off, experimentation, customer service communication, performance measurement, and identity and access administration.

Write each one as an outcome. “Send event-triggered service messages with the correct permissions” is more useful than “use an automation platform”. The first can be tested. The second only describes a product category that already exists in the building.

For each capability, record the business decision or customer outcome it supports, the teams that need it, the required service level, the data and regulatory constraints that apply, whether it is differentiating, necessary or optional, and what happens if it becomes unavailable.

This is the step that stops the audit protecting a platform purely because the organisation has already paid for it.

It is also the step most likely to expose that nobody has ever articulated the requirement. I spent years on the vendor side of enterprise personalisation deals, and the tell always arrived in the first meeting. Buyers would open by saying they wanted to improve the customer experience. I would ask what was wrong with the current setup, and the room would go quiet. They knew something was broken, because they could see it in their growth and performance numbers, but they could not name it. The budget was being signed for the advanced thing a serious digital team is supposed to own. I should disclose a commercial interest here, since I now run a business that sells to brand marketing teams, so treat this as a commercial view rather than a neutral one.

Step Two: Build the Vendor, Contract and Owner Inventory

Create one register covering every production, pilot, departmental and agency-managed platform. Include anything bought through marketing, IT, procurement, regional teams, agencies or a corporate card.

At minimum, capture the following for each entry.

Field	What to capture
Platform and vendor	Contracted product, edition and modules
Capability	The outcomes it is expected to support
Business owner	Person accountable for business value
Technical owner	Person accountable for configuration, access and continuity
Users	Licensed, active and dependent users
Critical workflows	Processes that would fail or degrade without it
Data processed	Customer, prospect, employee, campaign and operational data
Integrations	Upstream and downstream systems, APIs and file transfers
Licence cost	Subscription, usage and overage charges
Internal operating cost	Administration, engineering, support, training and governance
Migration cost	Expected cost of moving data, workflows and users
Exit constraints	Notice periods, export limits, deletion terms and lock-in
Evidence of value	Usage, operational outcomes and decision support
Risk	Security, privacy, continuity, supplier and skills risk
Recommendation	Retain, remediate, consolidate, replace or retire

The register should also hold contract start and end dates, renewal notice dates, minimum commitments, data export provisions, support arrangements and named subprocessors.

Two of those columns carry more weight than they look. Ownership is one. Inventories of systems, services and supplier-provided services sit inside the asset management outcomes of the NIST Cybersecurity Framework 2.0, which also treats roles, responsibilities and authorities, and the management of supplier risk, as governance outcomes rather than procurement paperwork (2). The framework describes outcomes and deliberately does not prescribe how to achieve them, so it justifies asking who is accountable without dictating your operating model.

The other is the contract column. Where a supplier processes personal data on the organisation’s behalf, there must be a written contract or other legal act containing the required terms (3). An audit that records a renewal date but not whether the processor terms exist has recorded the cheaper half of the problem.

Step Three: Map Tools to Capabilities

Build a capability-to-platform matrix.

A platform may provide the primary implementation of a capability, provide a secondary or specialist implementation, partially support it, duplicate another platform, depend on another platform, be licensed but never configured, or be configured but no longer used.

Do not classify overlap from vendor category labels. Two products both described as automation platforms may serve different teams, data models or channels. Products bought under entirely different labels may quietly duplicate segmentation, reporting or content management.

For each capability, ask five questions. Is there an accountable primary platform? Is the capability adequately covered? Where is the same function implemented more than once? Are those implementations deliberately different? What would be lost if one of them disappeared?

The audit will often find duplicated analytics capability. Note it and move on. The full design of collection, transformation and reporting belongs to the marketing analytics architecture, not to the portfolio decision.

Step Four: Map Users and Operating Dependencies

Licence counts do not show operational dependency.

Record monthly and quarterly active users, roles and teams, frequency and seasonality of use, processes performed outside the platform because the configured process is inadequate, skills concentrated in one employee or supplier, service level expectations, manual workarounds, and the downstream teams that consume the outputs.

Interview operators as well as owners. An owner understands the contract. Campaign managers, analysts, developers and customer service teams understand the work.

Identify single-person dependencies explicitly. A capable platform still creates continuity risk when one person is the only one who understands its workflows, data model or integrations, and that risk does not appear anywhere on the invoice.

Step Five: Map Data Flows and Integrations

For each platform, document inbound and outbound systems, the fields and identifiers transferred, the transfer method, frequency and latency, transformation logic, authentication method, monitoring and failure handling, the data owner, retention and deletion behaviour, and the downstream consequences of missing, late or duplicated data.

A visual data flow map should distinguish authoritative sources from derived copies, and should show where customer preferences, suppression states and identity mappings are created or changed. Those are the fields that cause the most damage when a platform is switched off carelessly.

Where personal data is involved, reconcile the map against the organisation’s records of processing. Most organisations must document their processing activities to some extent, and the obligation is not uniform: organisations with 250 or more employees must document all processing activities, while smaller organisations need document only processing that is not occasional, that is likely to result in a risk to people’s rights and freedoms, or that involves special category or criminal offence data (4). The record itself covers matters such as the controller’s details, the purposes of processing, the categories of people and personal data, recipients, transfers and safeguards, retention schedules where possible, and a general description of security measures where possible (5).

For the collection and measurement side of these dependencies, see the guide to first-party data and measurement engineering.

Testing What the Stack Actually Earns

With the facts in place, three tests decide whether each platform is earning its position: is it used, what does it really cost, and what risk does it carry.

Step Six: Measure Actual Use

Use several forms of evidence rather than one. Logins and active users. API calls and data volumes. Workflows executed. Campaigns or assets created. Records processed. Reports viewed. Features used. Business processes completed successfully. Support tickets and incidents. Manual work displaced, or created.

Avoid a single percentage of features used. A product’s feature catalogue is not a statement of business capability. A platform can be excellent value because it performs three required functions reliably while dozens of optional features stay untouched.

The distinction worth building into the register is between licensed use, where access has been bought; configured use, where the platform has been set up; active use, where teams currently use it; dependent use, where a material process relies on it; and valuable use, where evidence connects that use to a required outcome. Most disputes about whether to cut a tool are really disagreements about which of those five words applies.

A platform can report healthy usage while the organisation uses only a small subset of the capability it is paying for. Logins and campaign volume do not establish that advanced functionality is required. Compare the capability actually used against the cost and complexity of a simpler alternative, and record that comparison rather than the impression.

Step Seven: Calculate Fully Loaded Cost

Licence fees are one component.

Fully loaded cost = licence and usage charges + implementation amortisation + integration and infrastructure cost + administration + engineering + support + training + governance + data operations + supplier management + expected exit or migration cost

Use the organisation’s own cost base. There is no defensible universal multiplier that converts a licence price into a total cost, and published ones tend to come from parties with an interest in the answer.

Separate fixed from variable costs, committed from avoidable costs, internal from external labour, shared platform costs, temporary dual-running costs, likely retirement savings and one-off remediation or migration costs. A cheap product can be expensive when it needs fragile integrations and specialist administration. An expensive licence can be economical when it replaces several systems and removes operating work. The audit should test both directions rather than assume either.

Step Eight: Assess Security, Privacy and Continuity Risk

For every platform, examine identity and access controls, privileged user management, authentication and credential storage, security incidents and unresolved findings, data location and transfers, processor and subprocessor arrangements, retention and deletion, backup and recovery, audit logging, supplier viability, support and escalation, dependency on unsupported custom code, staff and supplier concentration, and exit and data portability arrangements.

For customer data specifically, the principles in the guide to the ethical use of consumer data set the standard the platform has to meet.

Risk does not automatically mean replacement. A platform can often be remediated through access changes, documentation, integration repair, contractual controls or better monitoring. The audit should compare the risk of keeping the platform against the risk of changing it, because migration carries its own failure modes and they are not smaller.

Reaching the Portfolio Decision

The evidence now has to produce a verdict for every platform, and a verdict that survives contact with the people who depend on it.

Step Nine: Identify Gaps and Overlap

A gap exists when a required capability has no adequate implementation. An overlap exists when several implementations serve substantially the same outcome.

Overlap is not automatically waste. It can be justified by different jurisdictions, different customer populations, resilience requirements, business unit autonomy, specialist functionality, a controlled transition, or incompatible service levels. Classify each one as deliberate and governed, temporary, poorly understood, avoidable, or actively harmful. Only the last two are candidates for immediate action.

Look for the less visible duplication as well: data ingestion, identity matching, consent storage, segmentation, reporting, experimentation and asset approval. Duplicated channel platforms are the easy find. Duplicated identity logic is the expensive one.

Where a capability might reasonably be provided by a dedicated platform, use the guides to customer data platform capability and CRM capability and operating model to examine those categories properly. The audit itself should stay neutral about which product category wins.

Step Ten: Classify Every Platform

Assign exactly one of five decisions.

Avoid retaining a platform by default simply because replacement looks difficult. Equally, do not select replacement because a newer product demonstrates well.

Every recommendation should state the evidence behind it, the assumptions it rests on, the capability gained or lost, the cost impact, the dependency impact, the risk impact, the decision owner, the decision date and the renewal or termination deadline.

Step Eleven: Test Proposed Changes Against Dependencies

Before approving any consolidation, replacement or retirement, run an impact test across users and processes, scheduled workflows, customer journeys, forms and landing pages, integrations and API clients, data exports, dashboards, permissions and suppressions, record retention, regulatory evidence, business continuity procedures and contractual exit constraints.

Exit constraints deserve particular attention, because they determine whether the decision is available at all. UK government technology guidance treats supplier lock-in as something to plan against rather than discover: it recommends supplier and technology agnostic requirements, attention to intellectual property implications, current documentation, handover and knowledge transfer obligations, and exit plans set early, reviewed regularly and supported by asset registers (8). That guidance operates on a comply or explain basis for central government rather than binding private organisations, but the questions it forces are the same ones a commercial renewal has to answer.

A proposed saving is not a saving if it removes a required capability, creates unbudgeted migration work, or pushes cost into manual operation somewhere less visible.

Step Twelve: Assign Decisions and Renewal Dates

Create a decision register holding the platform, the decision, the accountable executive, the business and technical owners, the approved budget, the dependencies still to resolve, the renewal notice date, the target completion date, the evidence required to close the item and the escalation route.

Work backwards from notice periods. A contract that renews automatically in ninety days usually needs a decision substantially earlier than that, to allow dependency checks, procurement, migration or negotiation to happen in sequence rather than in panic.

Begin the review before the contractual notice period, and before internal preferences harden around renewal. Renewal decisions often form through business reviews, stakeholder relationships, product confidence and operating experience well before procurement issues a formal notice, which means an audit that opens at the renewal reminder arrives after the decision has already been made somewhere else.

Turning the Audit Into Governance

An audit that happens once produces a clean stack for about two quarters. The value is in what replaces it.

Step Thirteen: Define a Recurring Governance Cycle

A practical cadence looks like this. Monthly, review new purchases, incidents, integration failures and material usage changes. Quarterly, review utilisation, cost, risk, capability gaps and remediation progress. Before every renewal, run a full decision review and dependency test. Annually, revisit the capability model, portfolio economics and strategic fit. After any major organisational or regulatory change, run a targeted reassessment.

Make the cadence proportionate to cost and risk. Applying the same review depth to a departmental scheduling tool and a customer data platform wastes effort in one direction and creates exposure in the other.

One complaint recurs in almost every review: the team is spending too much time operating the tool. Treat it as a signal rather than a verdict, because it can indicate a configuration problem, a process problem, a staffing problem or a product problem, and those have different remedies. Check the fully loaded cost and the configured process before concluding that the platform should go.

How to Measure the Audit Itself

Track the effects of the decisions using capability coverage, active usage, user dependency, workflow dependency, integration failure frequency, fully loaded cost, renewal exposure, data quality incidents, campaign lead time, retirement savings, capabilities lost or gained, and control or continuity incidents following each change.

Licence savings alone do not prove success. A rationalisation that reduces spending while increasing campaign delays, data incidents or operational risk has moved cost rather than removed it.

The Final Audit Checklist

Before closing the audit, confirm that every required capability has an owner; every platform has a business and a technical owner; shadow and agency-managed tools have been considered; actual use has been distinguished from licensed access; critical workflows and integrations have been mapped; costs include internal operation and exit; privacy, security and continuity risks have been assessed; every platform carries exactly one classification; proposed removals have passed dependency testing; decisions align with contractual deadlines; and governance and re-evaluation dates have been assigned.

The objective is not a fashionable stack diagram. It is a governed portfolio in which every platform has a defensible role, known dependencies, measurable operating consequences and an accountable decision behind it. Once that decision says replace or consolidate, the work moves to the marketing automation migration plan, and the audit’s job is done.

Frequently Asked Questions

References

1. United States General Accounting Office, Information Technology Investment Management: A Framework for Assessing and Improving Process Maturity. Executive Guide, reference GAO-04-394G, Version 1.1. Published March 2004; no last-updated date shown. Supersedes exposure draft AIMD-10.1.23. Not marked under review, withdrawn or superseded by a later edition. Not UK law: issued for United States federal investment management. https://www.gao.gov/products/gao-04-394g

2. National Institute of Standards and Technology, The NIST Cybersecurity Framework (CSF) 2.0. NIST Cybersecurity White Paper, reference NIST CSWP 29, DOI 10.6028/NIST.CSWP.29. Published 26 February 2024; no revision or erratum shown; status Final. Not UK law: a voluntary United States framework that describes outcomes rather than prescribing methods. https://csrc.nist.gov/pubs/cswp/29/the-nist-cybersecurity-framework-csf-20/final

3. Information Commissioner’s Office, Contracts. Regulatory guidance within the Guide to Accountability and Governance. No reference number. Publication date not shown; last updated 19 May 2023. The page carries an under review notice following the Data (Use and Access) Act 2025, and the ICO has indicated a consultation on replacement guidance during 2026 with final guidance expected in 2027. UK regulator guidance, not legislation. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/guide-to-accountability-and-governance/contracts/

4. Information Commissioner’s Office, Who needs to document their processing activities? Regulatory guidance within the Documentation chapter of the UK GDPR guidance. No reference number. Publication and last-updated dates not shown. The page carries an under review notice following the Data (Use and Access) Act 2025. UK regulator guidance, not legislation. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/documentation/who-needs-to-document-their-processing-activities/

5. Information Commissioner’s Office, What do we need to document under Article 30 of the UK GDPR? Regulatory guidance within the Documentation chapter of the UK GDPR guidance. No reference number. Publication and last-updated dates not shown. The page carries an under review notice following the Data (Use and Access) Act 2025. UK regulator guidance, not legislation. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/accountability-and-governance/documentation/what-do-we-need-to-document-under-article-30-of-the-gdpr/

6. UK Parliament, Data (Use and Access) Act 2025, section 70 and Schedule 4. UK Public General Act, reference 2025 c. 18. Royal Assent 19 June 2025. UK primary legislation. https://www.legislation.gov.uk/ukpga/2025/18/section/70

7. Secretary of State, The Data (Use and Access) Act 2025 (Commencement No. 6) Regulations 2026. UK Statutory Instrument, reference SI 2026/82. Made 29 January 2026. Commenced section 70 on 5 February 2026. UK secondary legislation. https://www.legislation.gov.uk/uksi/2026/82/made

8. Cabinet Office, The Digital, Data and Technology Playbook. UK government guidance, Version 2. Originally published 28 March 2022; Version 2 dated June 2023; last updated 20 June 2023. No later version published at the date of writing and no consultation open. UK government guidance, not UK law: it operates on a comply or explain basis for central government departments and arm’s length bodies and does not bind private organisations. https://www.gov.uk/government/publications/the-digital-data-and-technology-playbook

Position dated 29 July 2026. Regulatory guidance changes, and references 3, 4 and 5 above each carry a live under review notice following the Data (Use and Access) Act 2025. Confirm the current wording of any source before relying on it for a decision.