Understanding Scope: Cardholder Data, Environments, and ICT Architectures

1. Why PCI Scope Matters for ICT Companies

In the previous module you saw what PCI DSS is and who governs it. In this module, we zoom in on scope:

> Scope = which systems, services, and data must meet PCI DSS requirements.

For ICT companies (cloud, SaaS, hosting, APIs), scope is often determined by architecture choices, not by whether you call yourself a “payment company.”

If your product or service:

• Stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD), or
• Connects to systems that do,

then you are likely in PCI scope to some degree.

In this short module (about 15 minutes), you will learn to:

• Define cardholder data and sensitive authentication data in PCI terms (PCI DSS v4.0 – current major version as of early 2026).
• Explain what a Cardholder Data Environment (CDE) is.
• See how cloud, SaaS, APIs, and hosting can pull you into scope.
• Understand how tokenization, encryption, and gateways can reduce scope (but not eliminate responsibility).
• Spot contract and risk allocation issues that lawyers and product teams must address.

Keep in mind: PCI DSS is not a law, but it is contractually binding through card network rules and merchant agreements. For ICT companies, that usually happens via customer contracts, partner agreements, and processor/gateway terms.

2. What Counts as Cardholder Data (CHD) and Sensitive Authentication Data (SAD)?

PCI DSS uses very specific terms. Getting these right is essential for scoping.

2.1 Cardholder Data (CHD)

Under PCI DSS v4.0, cardholder data includes:

1. Primary Account Number (PAN) – the long number on the card.
2. Any of these, when stored, processed, or transmitted with the PAN:

• Cardholder name
• Expiration date
• Service code (the 3‑ or 4‑digit number in the magnetic stripe data that specifies usage restrictions)

> Key point: If PAN is present in your system in any form (even logs), you are handling CHD.

2.2 Sensitive Authentication Data (SAD)

SAD is extra-sensitive data used to authenticate cardholders or transactions. PCI DSS is very strict about this. SAD includes:

• Full track data (magnetic stripe data or equivalent on a chip)
• CAV2/CVC2/CVV2/CID (the 3‑ or 4‑digit security code printed on the card)
• PIN and PIN block

Rules (simplified):

• SAD must never be stored after authorization (not even encrypted), except in very narrow, explicitly allowed cases (e.g., some payment processors with specific justifications).
• Merchants, SaaS providers, and most ICT companies must not store SAD after authorization under any circumstances.

2.3 Data That Is Not Cardholder Data by Itself

These items alone are not CHD or SAD, but can still be sensitive:

• Cardholder name on its own
• Billing address
• Email address

They become cardholder data only when linked to a PAN or used in a way that can be tied back to a specific card account.

> Practical tip: In design reviews, always ask: “Does PAN ever touch this system (even briefly or in logs)?” If yes, PCI scope is almost certainly involved.

3. Quick Classification Exercise: CHD vs SAD vs Other

Try classifying each item. Decide whether it is:

• A. Cardholder Data (CHD)
• B. Sensitive Authentication Data (SAD)
• C. Not CHD/SAD by itself

1. A database column storing `4111111111` (truncated PAN) with cardholder name.
2. A log line containing full PAN and expiration date.
3. A support screenshot showing the full 3‑digit CVV.
4. A CRM record with customer name, email, and billing address, but no PAN.

Scroll down for suggested answers.

---

Suggested answers (check yourself):

1. A. CHD – PAN (even truncated) plus name is CHD. Truncation may help reduce risk, but it’s still CHD if the PAN is recognizable as a card number and is used in payment context.
2. A. CHD – Full PAN + expiry is CHD. If this is in logs, your logging system is in scope.
3. B. SAD – CVV is SAD. Even a screenshot is a problem if stored after authorization.
4. C. Not CHD/SAD by itself – But still personal data and may be regulated by privacy laws (e.g., GDPR), just not PCI CHD.

4. The Cardholder Data Environment (CDE) and Connected Systems

PCI DSS uses the term Cardholder Data Environment (CDE) to define scope.

> CDE = the people, processes, and technologies that store, process, or transmit cardholder data or sensitive authentication data.

4.1 What Is Inside the CDE?

Systems are in the CDE if they:

• Directly store, process, or transmit CHD/SAD (e.g., payment API servers, databases with PAN, payment processing microservices), or
• Provide security services to systems that do (e.g., key management servers, authentication servers used only by payment systems).

4.2 Connected-to and Security-Impacting Systems

PCI DSS v4.0 also considers systems that are connected to the CDE or can impact its security:

• Connected-to systems – Any system that can communicate with the CDE (e.g., admin jump boxes, monitoring tools, CI/CD pipelines).
• Security-impacting systems – Systems that can affect the confidentiality, integrity, or availability of the CDE, even if they don’t handle CHD directly (e.g., Active Directory, DNS, centralized logging, hypervisors).

These may not be fully in scope for every PCI requirement, but they usually require risk analysis and some controls.

4.3 Visual Mental Model

Picture three concentric circles:

1. Inner circle – CDE: Databases with PAN, payment gateways you host, payment microservices.
2. Middle circle – Connected systems: App servers that call the payment microservice, bastion hosts, monitoring tools.
3. Outer circle – Enterprise systems: HR tools, marketing systems, general file shares.

> Scoping work is about drawing these circles accurately and then shrinking the inner circle where possible.

5. How ICT Architectures Pull You into PCI Scope

Let’s look at three common ICT patterns and how they affect PCI scope.

5.1 SaaS Platform with Built-in Payments

Scenario:

• You run a multi-tenant SaaS platform for online booking.
• Your backend receives full card details via your own payment form.
• You send those details from your servers to a payment processor.

Implications:

• Your web front-end, API layer, payment service, and database that touches PAN are all in the CDE.
• Your hosting environment (IaaS/PaaS), hypervisors, and some network components are in or connected to scope.
• You must meet many PCI DSS v4.0 requirements (or show that your cloud provider covers some of them via shared-responsibility documentation).

5.2 SaaS Using a Hosted Payment Page (HPP)

Scenario:

• Your platform redirects customers to a third-party payment page hosted by a PCI-compliant gateway.
• Card data is never posted to your domain.
• You receive only a token or transaction reference back.

Implications:

• Your systems do not see PAN or CVV.
• Your PCI scope is significantly reduced.
• You still must:
• Secure redirects / JavaScript includes (to avoid tampering that could skim card data).
• Manage contracts ensuring the gateway is PCI DSS compliant and assumes appropriate responsibilities.

5.3 API-First Fintech Product on Public Cloud (IaaS)

Scenario:

• You offer APIs that merchants call from their front ends.
• The API receives card data, tokenizes it, and stores PAN in an encrypted data store.
• You deploy everything on a major public cloud provider.

Implications:

• Your API layer, tokenization service, encryption keys, and data store form your CDE.
• The cloud provider is a service provider in PCI terms, but you are still responsible for your part of the stack (OS hardening, app security, key management, etc.).
• You need clear shared-responsibility documentation and contract clauses with the cloud provider, plus PCI attestation from them where relevant.

6. Scope-Reduction Tools: Tokenization, Encryption, and Gateways

ICT companies often try to reduce PCI scope, not eliminate it. Three key tools:

6.1 Tokenization

Tokenization replaces PAN with a random token that has no mathematical relationship to the original number.

• The token vault (where PAN is stored and mapped to tokens) is in the CDE.
• Systems that only see tokens (no PAN) can often be out of PCI scope, or subject to fewer requirements.

6.2 Encryption

Encryption protects CHD at rest and in transit.

• If a system can decrypt PAN (e.g., holds encryption keys or has access to them), it is still in scope.
• If a system only ever sees strongly encrypted data and has no decryption capability, it may be treated as out of scope (subject to proper segmentation and design).

6.3 Third-Party Payment Gateways and Processors

Using a gateway/processor can reduce your scope if:

• The card data entry happens on their infrastructure (e.g., iframe, hosted fields, or redirect to their domain).
• Your systems only receive tokens or transaction IDs, not PAN or CVV.

However:

• You must contractually ensure they maintain PCI DSS compliance and clarify who is responsible for what (e.g., incident response, card scheme fines, data breaches).
• If your code (e.g., JavaScript on your page) can intercept card data before it goes to the gateway, you may still be in scope.

> Key message: Tokenization, encryption, and outsourcing move some scope and risk to others, but never remove your need for due diligence and secure integration.

7. Quick Quiz: What Is In Scope?

Test your understanding of scope and technologies.

8. Thought Exercise: Mapping Scope in a Simple Architecture

Imagine this architecture for a small ICT company:

• A React front end hosted on a CDN.
• A Node.js backend API running on containers in a public cloud.
• A PostgreSQL database for user accounts and order history.
• Integration with a payment gateway via:
• A hosted payment page (redirect), or
• A direct API call from your backend (you choose).

Task 1 – Hosted Page Option

1. Mark which components are likely in the CDE.
2. Mark which ones are connected systems.
3. Identify at least two contractual issues your lawyer should care about.

Task 2 – Direct API Option

1. Now assume the card data is posted from your front end to your backend API, then from your backend to the gateway.
2. Re‑do the CDE and connected-systems mapping.
3. List two extra technical controls you’d now need because your backend handles PAN.

---

Suggested discussion points (compare with your own):

Hosted page:

• CDE: Largely the gateway’s environment, not yours.
• Connected systems: Your front end and backend (because they can affect how customers reach the gateway page and could be used to inject malicious scripts).
• Contractual issues: Gateway’s PCI DSS status and attestation, incident notification, allocation of liability for card data breaches.

Direct API:

• CDE: Your front end (if it handles PAN), backend API, and any database or cache that stores PAN or logs it.
• Connected systems: CI/CD, monitoring, admin jump boxes, cloud control plane.
• Extra controls: Strong encryption of PAN in transit and at rest, stricter logging and monitoring, network segmentation, secure key management, additional access control, and stricter vulnerability management around the CDE.

9. Contracts, Responsibilities, and Risk Allocation

For ICT companies, scoping decisions become contract decisions.

9.1 Typical Roles

Depending on your business model, you might be:

• A merchant (e.g., you sell subscriptions directly).
• A service provider in PCI terms (e.g., you host or process payments for merchants).
• Both, in different contexts.

9.2 Key Contract Clauses to Watch

When you or your customers are in PCI scope, contracts often address:

• Responsibility for PCI DSS compliance:
• Who is responsible for which PCI requirements (e.g., physical security, network security, application security)?
• Is there a shared responsibility model (especially in cloud/IaaS)?

• Proof of compliance:
• Requirement to provide Attestation of Compliance (AOC) or Report on Compliance (ROC).
• Rights to audit or obtain third-party audit reports.

• Incident response and notification:
• Timelines and procedures for notifying about security incidents involving CHD.
• Cooperation in investigations and dealing with card brands/acquirers.

• Liability and indemnities:
• Allocation of card scheme fines, forensic costs, reissuance costs, and fraud losses.

> Takeaway: Technical scope reduction (e.g., using a gateway) must be matched by clear contractual allocation of PCI responsibilities and breach-related risks.

10. Flashcards: Key Terms Review

Flip the cards (mentally) to test your recall of core PCI scope concepts.

11. Final Check: Applying Scope Concepts

One more scenario to consolidate your understanding.

12. Wrap-Up: Linking Scope, Architecture, and Lawyering

You have now seen how PCI scope is shaped by:

• Data types: CHD vs SAD vs other personal data.
• System roles: CDE vs connected or security-impacting systems.
• Architectural choices: Direct handling of PAN vs tokenization, hosted pages, or gateways.
• Business roles: Merchant vs service provider.
• Contracts: How obligations and risks are allocated between ICT companies, merchants, and processors.

When you design or review an ICT product that might touch payments, ask:

1. Where does PAN or SAD actually flow? (including logs, backups, screenshots, and test data).
2. Which components form the CDE, and which can impact its security?
3. Can we reduce scope with tokenization, encryption, segmentation, or outsourcing?
4. Do our contracts match our technical design and shared-responsibility model?

Being able to map PCI scope from an architecture diagram and then translate that into contract terms and risk allocation is a core skill for ICT-focused lawyers, product managers, and security teams.

You can now move on to modules that dive deeper into specific PCI DSS v4.0 requirements and shared responsibility in cloud and SaaS environments.