PCI DSS is the payment industry's baseline of technical and operational requirements for protecting account data. Version 4.0 added new vocabulary, such as the customized approach and targeted risk analysis. This glossary defines the terms that cause the most confusion during scoping and assessment, using the PCI Security Standards Council's own wording as the base.
Which terms describe the data?
Account data. Cardholder data and sensitive authentication data together.
Cardholder data (CHD). The primary account number (PAN), alone or with the cardholder name, expiration date or service code.
Sensitive authentication data (SAD). Data used to authenticate a cardholder that can appear in a transaction. The Council's glossary says it may be transmitted or processed as part of a transaction, but not stored after authorization. Read the standard for the exact elements and rules.
PAN masking. Hiding part of the PAN when it is shown on screens, receipts or printouts. It applies when there is no business need to see the whole number. Truncation is the term for protecting a PAN that is stored, processed or transmitted.
Which terms define scope?
Cardholder data environment (CDE). The system components, people and processes that store, process or transmit CHD or SAD, plus system components that do not handle that data but have unrestricted connectivity to those that do. The second half surprises many teams. A machine that never touches a card number can still be in scope if it can reach one without restriction.
Segmentation. Isolating the components that handle CHD or SAD from systems that do not. Good segmentation shrinks scope, which shrinks assessment effort. It does not remove the need to prove the isolation works.
Data-flow diagram. A diagram of how data moves through applications, systems, networks and outside parties. Assessors lean on it to confirm where the CDE starts and ends.
Service provider. A business, not a payment brand, directly involved in processing, storing or transmitting CHD or SAD on behalf of another entity. That includes payment gateways, payment service providers and independent sales organizations.
Third-party service provider (TPSP). A provider of shared services to merchants and other service providers. SaaS, hosting and shopping-cart services fall here. Your TPSPs affect your scope, so ask for their evidence.
Which terms are new or changed in 4.x?
Defined approach. Implementing a requirement exactly as written.
Customized approach. Meeting the objective of a requirement by a different control that you design, then documenting how you assessed the risk and why your control meets the objective. It is a flexibility, not a shortcut, and the documentation burden rises.
Targeted risk analysis (TRA). A risk analysis aimed at a specific requirement, either because the requirement allows flexibility, such as how often an activity runs, or because you use the customized approach and must explain your choice.
Compensating controls. An alternative when a requirement cannot be met as written. The standard covers them in its appendices, and they are separate from the customized approach.
Future-dated requirements. New requirements in 4.x that took effect after the version's release. The Council has published guidance urging organizations to adopt them. Check the standard for each requirement's effective date.
Bespoke and custom software. Bespoke is built for you by a third party to your specification. Custom is built by your own team for your own use. Both matter for the software-development requirements.
Which terms describe the paperwork?
SAQ (Self-Assessment Questionnaire). The form some merchants and service providers use to self-report assessment results, in place of a full report.
ROC (Report on Compliance). The reporting tool that documents the detailed results of an assessment.
AOC (Attestation of Compliance). The official form merchants and service providers use to attest to the results documented in an SAQ or ROC.
PCI DSS v3.2.1 retired on 31 March 2024. The current documents live in the Council's library, with v4.0.1 among them.
What to do
- Write down every place account data enters, moves or rests, and draw it.
- Mark which systems have unrestricted connectivity to those places. That is your real CDE.
- Test your segmentation and keep the evidence.
- List your service providers and TPSPs and collect their AOCs and responsibility matrices.
- Decide per requirement whether you use the defined or the customized approach.
- Where you rely on flexibility, write the targeted risk analysis before the assessment.
- Confirm with your acquirer or card brand which SAQ or ROC applies to you.
Quick check
Is a system out of scope if it never stores card numbers?
Not necessarily. Under the Council's CDE definition, a system with unrestricted connectivity to components that handle account data can still be in scope. Segmentation is what removes it.
Does using a security tool make me PCI DSS compliant?
No. Compliance is validated through an SAQ or ROC and an AOC. Tools can help produce evidence for requirements, but they do not certify you, and we do not claim they do.
Sources
Last reviewed: 18 October 2026.
