The Pen Test Your Marketing Stack Never Got

The last security review covered the product. The application, the cloud accounts, the customer-facing login. Someone ran the test, the report got filed, the certificate went on the website, and everyone moved on.

Meanwhile, the marketing team spent that same quarter wiring a CDP into Salesforce, connecting an enrichment vendor, adding a chat widget that reads account history, and granting a new analytics tool access to the warehouse. Every one of those connections carries a token. Several of them can read customer records. None of them were in scope for the test that just passed.

That is the gap. The marketing and RevOps stack has quietly become one of the largest collections of customer data in the company, and it tends to sit just outside the line a penetration test is drawn around. The product gets tested. The thirty tools hanging off the product do not.

Why the marketing stack is the soft target

Walk the data path of a single inbound lead and watch where it goes. It enters through a form, lands in HubSpot or Marketo, syncs to the CRM, gets enriched by Clay or a data vendor, flows to Segment, lands in Snowflake, gets pushed back out to the ad platforms by a reverse-ETL job, and shows up in a dashboard a contractor built last spring. Each hop was a reasonable decision made by someone trying to ship a campaign. Added together, that one lead’s data now lives in eight systems, each with its own access model, its own admins, and its own idea of who is allowed to read it.

No single person drew that map. It assembled itself, one integration at a time, faster than anyone governed it. And because it is “just marketing tools,” it rarely makes the list of things a security team is asked to test.

The attacker does not share that distinction. To them, a marketing automation platform with read-write access to the CRM and a stale API token is not a marketing tool. It is a way in.

What a pen test of the marketing stack actually finds

Scope a test to that surface instead of the core application, and the findings are remarkably consistent. Three patterns recur, almost regardless of industry or stack size.

Over-scoped integration tokens. When two tools get connected, the path of least resistance is to grant the broadest permission that makes the integration work on the first try. A connector that needs to read contacts ends up with read-write access to the entire CRM, because that was the scope that cleared the error message. The token then lives inside a third-party SaaS connector nobody owns, and it does not expire. Multiply that by every integration added over three years and the stack is holding a drawer full of master keys, most of them cut wider than the lock they were made for.

Orphaned tools and standing access. The stack accretes. A tool gets trialed, half-adopted, and replaced, but the webhook it set up against the warehouse is still live. The admin who built the Zapier flow left the company a year ago, and their account is still active, still privileged, still reachable from the open internet. Nobody decided to keep these connections open. Nobody decided to close them either, which is the actual problem.

Customer data in places nobody mapped. PII moves from the CRM to the enrichment tool to the ad platform to a spreadsheet a contractor exported for one campaign and never deleted. Each transfer looked fine in isolation. The aggregate is customer data sitting in a half-dozen systems under six different access policies, with no owner who can say where all the copies are. A pen test finds the copies. The quarterly review does not, because it was never pointed at them.

None of this is exotic. It is the ordinary residue of a system that grew faster than anyone had time to govern. A test scoped to the marketing surface finds it precisely because it goes looking where the standard review stops.

A concrete version: a reverse-ETL job set up to push one audience segment to a single ad platform turns out to hold a warehouse credential with read access to every table, not just the audience it syncs. It was scoped that way in an afternoon two years ago, the person who built it has since moved teams, and the credential has not rotated since. Nothing has gone wrong yet. Nothing has to, until the connector vendor has a bad week and that key is suddenly someone else’s. That is the shape of almost every real finding. Not a dramatic hole in the wall, just a door left propped open long after anyone remembered installing it, in a part of the building security was never asked to walk.

Three questions worth answering before you scope one

You can predict most of what a marketing-stack pen test will surface by trying to answer three questions cold:

Which integrations can read customer records, and what is the real scope of each token? Not the scope you intended when you set it up. The scope that is actually granted right now.

Which tools and accounts are still connected to your data but no longer used, owned, or watched?

If one of your marketing SaaS vendors were breached tomorrow, which of your customers’ data would be inside the blast radius?

If those answers are hard to assemble quickly, the difficulty is the finding. The test simply makes it specific, and gives you a list you can work down.

What good looks like

Pen testing the marketing stack is not a larger version of the product pen test. It is aimed at a different surface: the integrations, the tokens, the data flows, and the human access surrounding the MarTech and RevOps tools. Done well, it has three traits.

The scope explicitly names the marketing SaaS layer, rather than treating it as out of bounds. The test runs on a cadence instead of once, because a stack that changes every month makes an annual test stale by the second sprint after it. And the findings flow back into how the stack is run: token scopes tightened to what each integration needs, orphaned connections cut, data flows written down and given an owner, offboarding that actually revokes the access a departing admin held.

A cadence like that is only realistic with automation. Continuous pen-testing tooling, like pentx.ai from our security partner CyberGlobal, re-checks the surface as it changes and flags what moved, so people spend their hours validating and fixing, not re-running the same scan by hand. The tool finds the delta. The operator decides what it means.

That last trait is the one that matters. The test is the easy part. The value is in what changes after the report lands.

Where this tends to break down

Two traps swallow most of the value, and they are worth naming so you can avoid them.

The first is treating the test as a checkbox. Run it, file the PDF, point to the certificate, repeat next year. A report nobody acts on is a cost wearing the costume of a control. The findings sit in a shared drive while the over-scoped token keeps doing exactly what the test said it could.

The second is scoping the marketing stack out from the start, on the logic that the real risk lives in the core application. That framing is how customer data ends up well protected everywhere except where it actually sits. The product is hardened. The forty integrations reading from it are not.

Underneath both traps is the same structural truth that runs through most of this work: the security of a marketing system is decided in the unglamorous layer nobody funds first. Not the firewall on the core app. The token scopes, the integration hygiene, the quiet question of who can reach what. Security built into how the stack is run tends to hold. Security bolted on as an annual event tends not to. The difference is not the tooling. It is whether anyone owns the layer between the tools.

If you take one thing from this

Your marketing stack holds customer data, admin access, and standing connections that a product-scoped pen test never sees. Test that surface on its own terms, on a cadence, and route the findings back into how the stack is governed. The goal is not a cleaner certificate. It is closing the gap in the layer where your customers’ data actually lives, before someone outside the building finds it first.

Next step

Katalor Security tests the surface most reviews skip: the MarTech and RevOps stack where customer data piles up. If you cannot say with confidence what your integrations can reach, that is the place to start. Schedule a scope call at sec.katalorgroup.com.