Guide

PCI-DSS scope: 5 mistakes that cost fintechs an audit failure

PCI-DSS Level 1 fieldwork is brutal when you've gotten the scope wrong. The QSA spends Day 1 establishing what's in scope. If your interpretation differs from theirs by more than a tier, you've lost the report — sometimes you've lost the year.

Fintechs routinely walk into PCI fieldwork over-confident about their scope. The same five mistakes come up again and again. Here they are.

Mistake 1: Calling something "out of scope" because it doesn't store CHD

Storing card data isn't the only scoping trigger. Processing it triggers scope. Transmitting it triggers scope. Even systems that COULD impact the security of cardholder data (CHD) are in scope — that's the "connected-to" rule.

Your customer support tool that pastes card numbers into ticket bodies? In scope. Your monitoring system that has access to environments where CHD lives? In scope. Your shared admin laptops? In scope.

Scope is bigger than you want it to be. Get it right early.

Mistake 2: Tokenisation handwave

"We tokenise everything, so we're not in scope" is a quote I've heard at three different fintechs. None of them were right.

Tokenisation reduces scope, but only if implemented correctly. The token vault provider must be PCI-compliant. The de-tokenisation flow has to be auditable. Any system that handles either the original card OR the de-tokenisation key remains in scope. The vault doesn't make scope disappear; it relocates it.

Mistake 3: Missing CDE perimeter on the network diagram

Your CDE (cardholder data environment) needs a clear network perimeter. Most fintechs draw the perimeter loosely — "anything in our prod VPC" — which means everything in prod is in scope. That includes systems that have nothing to do with cards.

Tighten the perimeter. Segment the CDE. Use proper firewall rules. Document the diagram with a senior auditor's eye, not an engineer's.

Mistake 4: Forgetting third parties

Your QSA will ask about every third party that touches CHD. Your payment processor (obvious). Your fraud screening tool (yes, in scope). Your customer support tool (yes, if anyone pastes card numbers). Your incident response retainer (yes, if they get access during incidents).

Build the third-party inventory BEFORE fieldwork. Get their SOC 2 / PCI reports. Document the data flows. Anything missed becomes a finding.

Mistake 5: Believing your last year's scope still applies

Scope shifts every year. You added a new payment route. You changed cloud regions. You onboarded a new fraud vendor. Each one expanded scope without anyone explicitly approving the expansion.

Run a scope review every quarter. The product compliance gate (a Wednesday ritual in the Fintech CCO OS) catches most of these in real-time.

The Information Security & SOC 2 OS

General information about compliance and programme structure, not regulatory, legal, tax or financial advice, and no promise of any examination or audit outcome. Built from public frameworks; the professional judgement is yours.