The short answer
PCI scope is the set of systems, processes, and people that store, process, or transmit cardholder data (CHD) — the scope of your PCI-DSS compliance obligation. Everything in scope must meet every applicable PCI-DSS requirement. Scope expansion is the primary cost driver in PCI programs; scope reduction is the primary savings lever. Every serious e-commerce merchant aims to keep scope as small as possible.
What brings a system into scope
- Stores CHD. Any database, file, log, backup, or spreadsheet containing a PAN, expiration date, service code, or sensitive authentication data.
- Processes CHD. Any code path that handles card data, even transiently in memory.
- Transmits CHD. Any network segment carrying card data, including over TLS.
- Connected to CHD systems. Systems that can reach, be reached by, or share infrastructure with the above — they fall into scope by adjacency unless segmented.
- Influences security. Firewalls, identity providers, logging systems, config management — anything that impacts the security of CHD systems is in scope.
Scope levels
- Category 1: CDE (cardholder data environment) — full in-scope. Systems that directly store, process, or transmit CHD.
- Category 2: connected-to / security-impacting. Not handling CHD directly but adjacent to CDE. Also in scope but lighter requirements.
- Category 3: out-of-scope. Segmented from CDE, no CHD passes through, no security impact.
The big scope-reduction techniques
1. Tokenization
Tokenization replaces real PANs with non-reversible tokens. Your database stores tokens; the tokens are meaningless outside the tokenization service. Your database and downstream systems fall out of scope. This is the single biggest scope reducer for e-commerce.
2. Redirect / iFrame checkout
If card data goes directly from the customer's browser to the processor (via iFrame or hosted payment page) and never touches your server, most of your web infrastructure falls out of scope. You qualify for SAQ A (smallest Self-Assessment Questionnaire) instead of SAQ D (full assessment).
3. Network segmentation
If the systems that do touch CHD are on a separate network segment (separate VLANs, firewalls, access controls, logging) from the rest of your infrastructure, the rest falls out of scope. Segmentation must be validated via penetration testing at least annually for Level 1 merchants.
4. Out-of-band handling
If you never see the card at all — fully hosted checkout, Apple Pay / Google Pay tokens only, or BNPL redirects — you fall out of most PCI scope regardless.
SAQ types by scope
- SAQ A: fully outsourced card acceptance (hosted checkout, iFrame). ~22 questions.
- SAQ A-EP: partially outsourced but merchant's site redirects/iFrames. ~191 questions.
- SAQ B / B-IP: card-present terminals only.
- SAQ C / C-VT: payment application or virtual terminal.
- SAQ D: everyone else. ~329 questions. The one you want to avoid.
Common scope creep traps
- Logging cardholder data into application logs. Even accidentally. Scan your logs.
- Caching pages with card data. Browser caches, CDN caches, session replay tools (Hotjar, FullStory).
- Session replay scripts on checkout pages. They capture the card input. Now in scope.
- Support agents viewing full PANs in admin tools. Tool is in scope, their workstations are in scope.
- Email receipts containing full card data. Mail server in scope.
How multiflow handles PCI scope for operators
We operate an iFrame + tokenized checkout by default. No full PANs reach your server, ever. Your operator portal shows tokens and last-4 only. Your PCI obligation reduces to SAQ A in nearly every case — the simplest compliance path available. Our infrastructure carries the CDE burden; your business does not.