The terms a payment security team actually uses, defined in plain language by practitioners. For the full walkthrough, read the PCI DSS compliance guide, or browse the rest of the Learn hub.
The Payment Card Industry Data Security Standard. It applies to any entity that stores, processes, or transmits cardholder data, and to anyone whose systems can affect the security of that data. The current version is v4.0. It is a contractual obligation enforced through the payment brands and acquiring banks, not a government statute.
The PCI Security Standards Council, the body the major payment brands formed to maintain PCI DSS and its related standards, and to qualify the assessors and scanning vendors who validate against it.
The primary account number, and where present alongside it, the cardholder name, expiration date, and service code. Protecting cardholder data is the purpose of the entire standard.
The payment card number that identifies the issuer and the account. It is the core element of cardholder data and must be rendered unreadable wherever it is stored.
Full track data, the card verification value, and the PIN. Sensitive authentication data must never be stored after authorization, even in encrypted form.
The people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data, plus any connected system that can affect their security. The CDE defines the scope of a PCI DSS assessment.
The set of system components, people, and processes an assessment must cover. Scope is driven by the cardholder data environment, and reducing it is the main way to reduce the effort of an assessment.
Using network controls to isolate the systems that handle cardholder data from those that do not, so the unrelated systems fall outside the assessment scope. It is the practitioner's main lever for shrinking the CDE.
Replacing the primary account number with a surrogate value, a token, that has no exploitable meaning. Systems can reference a payment through the token without holding the actual PAN, which removes data from scope.
The twelve top-level requirements of PCI DSS, grouped under six control objectives, that together define how cardholder data must be protected, from network controls and encryption through access control, monitoring, and security policy.
The six plain-language goals that organize the 12 requirements: build and maintain a secure network, protect account data, maintain a vulnerability management program, implement strong access control, regularly monitor and test networks, and maintain an information security policy.
A classification, set by each payment brand and based mainly on annual transaction volume, that determines which validation path a merchant must follow. The thresholds belong to the brands and the acquirer.
An entity that stores, processes, or transmits cardholder data on behalf of others, or that manages components inside a client's cardholder data environment. Service providers have their own level structure.
A self-attested validation document for eligible merchants and service providers. Several SAQ types exist, each scoped to a specific way of handling cards, so an entity completes the one that matches how it accepts payments.
A full assessment of every applicable requirement, with evidence reviewed and controls tested by a QSA or Internal Security Assessor, documented in detail. Generally required for the highest-volume merchants and many service providers.
The signed summary that states the validation result. It is the document shared with acquirers and partners as proof of compliance. Both an SAQ and a ROC produce an AOC.
A firm and individual certified by the PCI SSC to perform PCI DSS assessments and produce a Report on Compliance. The QSA reviews evidence, tests controls, and attests to whether each requirement is in place.
An employee a company has trained and the PCI SSC has qualified to perform internal PCI DSS assessments. Larger organizations use the ISA option to build the assessment capability in-house.
A PCI SSC-approved company that runs the required external vulnerability scans against internet-facing systems, generally on a quarterly cadence. The ASV scans the perimeter; the QSA assesses the program.
The bank or processor that holds a merchant's account and routes its card transactions. The acquirer owns the program a merchant reports its PCI compliance into, including which validation documents are required.
An alternative control used when an entity cannot meet a requirement as written but achieves the requirement's intent through other means. Compensating controls are documented and reviewed by the assessor.
An option introduced in PCI DSS v4.0 that lets an entity meet a requirement's stated security objective with controls of its own design, validated against the intent rather than the specific prescribed method.
Compliance Command Center turns these concepts into a defensible, assessor-ready PCI DSS program, run by practitioners and leveraged by software.
See Compliance Command Center Read the guide