MarTech Audit Checklist and Stack Inventory Template

A MarTech audit is a structured review of every marketing tool the organization pays for: what it does, who actually uses it, what data runs through it, what it costs over its life, and what should happen to it next — keep, optimize, consolidate, replace, or retire. This page has the checklist for running one and an inventory template for recording it. The stack readiness assessment tells you whether an audit is your next step; the audit phase of the planning guide explains why each field matters.

Scope and sources

• Build the tool list from what you pay for, not from memory. Pull twelve months of vendor payments from accounts payable and corporate cards, then add the applications in your single sign-on catalog. Memory produces the tools people like; spending produces the ones that renew.

  How to verify: Compare the vendor list from twelve months of payments with the inventory.

  Pass when: Every recurring marketing vendor in the payments appears in the inventory, and every row has a payment or a documented reason it has none.

• Include the tools nobody bought centrally. Team subscriptions on a manager’s card, free tiers holding customer data, browser extensions with page access, and apps installed inside other tools. They carry the same data risk as contracted platforms and rarely appear on an architecture diagram.

  How to verify: Ask each team lead what their team signs into for marketing work, and list the apps installed inside the main platforms.

  Pass when: Each discovery is in the inventory with an owner, or recorded as removed.

• Name a business owner and a technical owner for every tool. The business owner answers for value and budget; the technical owner for access, configuration, and integrations. A tool with neither has no one to answer the audit’s questions.

  How to verify: Read the two owner columns.

  Pass when: Every row names two people, not teams, and both have confirmed.

• Write down the decision the audit has to support. A renewal season, a consolidation target, a new purchase, and a security review each need different depth. Naming the decision settles which fields are mandatory and when the audit is finished.

  How to verify: Read the first page of the audit document.

  Pass when: It states the decision, the date it is due, and who takes it.

Usage and adoption

• Measure active use from each tool’s own logs. Seats paid are not seats used. Pull last-activity dates from each admin console for the past 90 days, and record send or workflow volume where logins mean little. Low logins do not prove low value: a system that runs nightly with one administrator can be critical.

  How to verify: Export the user list with last-activity dates from each admin console.

  Pass when: Each row records licensed seats, seats active in the last 90 days, and a volume measure where logins do not apply.

• Compare the features in use with the tier you pay for. An enterprise edition kept for one feature is a negotiation point; a missing feature people work around by hand is a capability gap.

  How to verify: List the features of the current tier and mark the ones in active use.

  Pass when: The inventory records the tier and the features that justify it, or flags the tier for renegotiation.

• Talk to the heaviest and the lightest users. Logs show what happens, not why. The heaviest user knows the workarounds; the lightest knows why the tool was abandoned. Fifteen minutes with each beats a survey.

  How to verify: Check the interview notes against the user list.

  Pass when: Each material tool has notes from at least one heavy and one light user.

Capabilities and overlap

• Map each tool to capabilities, not to the vendor’s category. Email sending, segmentation, forms, attribution, consent capture: describe what the tool does for you in one vocabulary across the stack. Vendor categories overlap and change; capabilities are what the business needs.

  How to verify: Read the capability column across the inventory.

  Pass when: Every tool maps to capabilities from one shared list, with no vendor marketing names.

• Classify each capability as present, usable, adopted, effective, or governed. Present means a license claims it; usable means data, process, and skills make it work; adopted means people use it; effective means it moves an agreed outcome; governed means someone controls it. The gap between present and adopted is where most audit savings hide.

  How to verify: Read the state recorded for each capability you depend on.

  Pass when: Every capability has a state and the evidence behind it.

• Find the overlaps, and record why each one exists. Two form builders or three email senders may be waste, or may be deliberate: a regional team with its own compliance needs, a specialist tool a platform cannot replace. Consolidation is right only when it removes cost and coordination without breaking a capability someone relies on.

  How to verify: Sort the inventory by capability and read the rows that share one.

  Pass when: Every overlap has a stated reason and a proposed action.

Data and integrations

• Map every data flow in and out of each tool. Record source and destination, direction, method — native connector, iPaaS, reverse ETL, file — frequency, and who is told when it fails. An undocumented sync is the dependency that breaks the week after a tool is retired.

  How to verify: Compare the documented flows with the connectors and API keys listed in each tool’s settings.

  Pass when: Every active connector and key matches a documented flow with a failure owner.

• Check that identifiers and consent travel with the data. A flow that moves email addresses without their consent state turns a compliant source into a non-compliant destination. Record which identifier each flow matches on and where its consent comes from.

  How to verify: For each flow that carries personal data, trace one test record from source to destination.

  Pass when: The identifier matches, and the consent state arrives with the record.

• Write down what breaks if each tool is switched off. Reports, audiences, automations, and other tools that read from it. This is the dependency list every retirement or replacement plan starts from.

  How to verify: Read the dependency notes for every tool marked consolidate, replace, or retire.

  Pass when: Each lists its downstream dependents, confirmed with their owners.

Cost and contract

• Record the total cost, not the license. Add usage and credit charges, implementation and agency fees, and the internal hours spent administering the tool. A cheap license with a full-time administrator is not cheap.

  How to verify: Reconcile the cost column with twelve months of payments and an estimate of administration hours.

  Pass when: Each row has a yearly total split into license, usage, services, and internal time.

• Record renewal dates and notice periods. Auto-renewing contracts often require notice weeks or months before the term ends, so the deadline that matters is the notice date, not the renewal date. Note any price-increase clause and the data-export rights you have on exit.

  How to verify: Read each contract’s term, renewal, notice, and exit clauses.

  Pass when: Every contract has its notice date in a shared calendar with the owner invited, and its export rights are recorded.

• Flag consumption pricing and what happens at the limit. Credit-based and per-action pricing moves cost from the contract to usage. Record the unit, the rate, whether unused credits expire, and what stops when they run out; the glossary entry on consumption pricing lists the questions.

  How to verify: Read the order form and the current rate card for each usage-priced tool.

  Pass when: Each records the unit, rate, credit expiry, overage behaviour, and the spending limit in force.

Risk and compliance

• Confirm the data processing agreement and where the data goes. Every tool holding personal information needs a signed agreement, a known hosting location, and a subprocessor list. In Québec, communicating personal information outside the province first requires a privacy impact assessment, under section 17 of the private-sector privacy act as amended by Law 25.

  How to verify: File the agreement, hosting region, and subprocessor list against each row.

  Pass when: Every tool holding personal data has all three, and each transfer outside Québec has an assessment on file.

• Review who has administrator access. Former employees, agency staff who have moved on, shared logins, and accounts without multi-factor authentication. Administrator access to a marketing platform usually includes exporting the whole customer list.

  How to verify: Export the administrator and user lists and compare them with current staff and agency contracts.

  Pass when: No departed person or shared login remains, and every administrator signs in through single sign-on or multi-factor authentication.

• List the AI features and connectors each tool has switched on. Many platforms now send data to AI models, and some expose it to outside agents through MCP servers. Record which features are on, what data they can reach, and the OAuth scopes granted; the vendor MCP check shows what to ask.

  How to verify: Read each tool’s AI and connected-apps settings.

  Pass when: Every enabled AI feature and connector is recorded with its data reach and scopes, and an owner has approved it.

The decision

• Give each tool one action: keep, optimize, consolidate, replace, or retire. One action per tool, with the evidence behind it and an owner and a date for the next step. “Fix the process first” is a valid answer when the tool is fine and the way it is used is not.

  How to verify: Read the decision column.

  Pass when: Every row has one action, its evidence, an owner, and a date.

• Treat every replacement as a new system project. Under section 3.3 of the same Québec act, acquiring or overhauling a system that handles personal information requires a privacy impact assessment from the start of the project, and the new system must let people obtain their data in a structured, commonly used format. Elsewhere it is simply good practice. Run the stack readiness assessment before building the shortlist.

  How to verify: For each tool marked replace, look for the privacy assessment and the requirements document.

  Pass when: Both exist before the first vendor demo is booked.

• Retire tools with an export and a deletion record. Export what you must keep, get the vendor’s confirmation that the rest is deleted, remove the connectors and API keys, and cancel before the notice date. Keep the evidence with the inventory.

  How to verify: For each retired tool, look for the export, the deletion confirmation, and the cancellation.

  Pass when: All three are on file, and no connector or key to the tool is still active.

• Schedule the next review. An inventory is accurate on the day it is finished. Set a quarterly review of adoption, cost, and upcoming notice dates, and update the inventory whenever a tool is bought or retired.

  How to verify: Check the calendar and the inventory’s last-updated date.

  Pass when: A recurring review exists with an owner, and the inventory was updated after the last purchase or retirement.

The stack inventory template

One row per tool, filled in as you work through the checklist above; the fields follow the same order. The example is illustrative — a marketing automation platform at a mid-sized B2B company — and shows the level of detail that makes an inventory usable rather than decorative.

Frequently asked questions

How long does a MarTech audit take?

For a stack of ten to twenty tools, expect two to four weeks of part-time work, most of it spent waiting on admin exports, contract copies, and owner interviews rather than on analysis. A focused audit ahead of one renewal can take a few days.

How often should you audit a MarTech stack?

A full audit once a year, or before any major purchase or consolidation, with a quarterly review of adoption, cost, and upcoming notice dates in between. The inventory should change whenever a tool is bought or retired.

What is the difference between a MarTech audit and a stack assessment?

The stack readiness assessment on this site is a five-minute self-check across six dimensions that shows where the evidence is weakest. The audit is the evidence itself: the inventory, the data flows, and the contracts. When the assessment scores stack visibility below 70%, the audit is its recommended next phase.

Should you cancel tools that nobody logs into?

Not on login data alone. Check volume and dependencies first: a tool with one administrator can run nightly syncs that other systems rely on. Retire it once its dependency list is empty and its data has been exported.

Sources

The method and judgments are the author’s, drawn from stack audits and platform implementations. The one external rule on this page rests on this source, checked on October 10, 2026:

• Québec — Act respecting the protection of personal information in the private sector (P-39.1) — supports sections 3.3 and 17: privacy impact assessments before acquiring or overhauling a system that handles personal information, and before communicating it outside Québec.