The Payment Card Industry Data Security Standard (PCI DSS) is the security framework that governs how organizations store, process, and transmit payment card data. It's maintained by the PCI Security Standards Council, a body founded in 2006 by the five major card brands: Visa, Mastercard, American Express, Discover, and JCB. If you're new to PCI compliance, the terminology can slow you down fast. This glossary defines the terms you'll encounter most often.
The security standard that defines how organizations must protect cardholder data. PCI DSS applies to any entity that stores, processes, or transmits payment card data — or that could affect the security of that data. The current active version is PCI DSS 4.0.1, released June 11, 2024. All 64 new or updated requirements introduced in version 4.0 became fully mandatory on March 31, 2025.
The independent body that develops and maintains PCI DSS and related standards. Founded in 2006 by Visa, Mastercard, American Express, Discover, and JCB, the PCI SSC sets the rules but does not enforce them directly — enforcement is handled by the card brands and acquiring banks. Think of the SSC as the standards body and the card brands as the enforcement arm.
The five payment networks that founded the PCI SSC and enforce PCI DSS compliance through their merchant and acquirer agreements: Visa, Mastercard, American Express, Discover, and JCB. Each card brand defines its own merchant compliance levels and validation requirements, which can vary slightly from brand to brand. When you process transactions across multiple brands, you're held to the most stringent level among them.
A classification that determines your PCI DSS validation requirements based on annual transaction volume. There are four levels:
Your level is set by your acquiring bank based on card brand thresholds. If you've experienced a breach, you may be moved to a higher level regardless of transaction volume.
A business entity that stores, processes, or transmits cardholder data on behalf of another organization — or that provides services that could affect the security of cardholder data. Payment processors, hosting providers, and managed security service providers commonly fall into this category. Service providers have their own PCI DSS compliance obligations and must maintain validation independently from the merchants they serve.
The financial institution that processes payment card transactions on behalf of a merchant and maintains the merchant's relationship with the card brands. Your acquirer is responsible for ensuring you meet PCI DSS compliance requirements. They set your merchant level, collect your compliance documentation, and can impose additional requirements beyond what PCI DSS minimums specify.
The bank or financial institution that issues payment cards to consumers. Issuers have their own PCI DSS obligations, particularly around how sensitive authentication data is stored prior to transaction authorization.
Getting your scope right is one of the most consequential things you'll do in a PCI compliance program. Scope too broadly and you're doing unnecessary work; scope too narrowly and you're exposed. The terms below define the boundaries.
Any information printed on or encoded in a payment card that is tied to the cardholder. The primary components of cardholder data are the Primary Account Number (PAN), cardholder name, expiration date, and service code. Of these, the PAN is the most sensitive — its presence in a system or data store is often what places that system in scope for PCI DSS.
The 14- to 19-digit number that identifies a payment card account. The PAN is the single most important data element in PCI DSS scoping. Any system that stores, processes, or transmits the PAN — or that could affect its security — is in scope for PCI DSS requirements. When stored, the PAN must be rendered unreadable through strong cryptography, truncation, tokenization, or hashing.
Security-related information used to authenticate cardholders and authorize transactions. SAD includes the full magnetic stripe or chip data, the card verification code (CVV/CVC), and PINs. Unlike cardholder data, SAD must never be stored after transaction authorization — even if encrypted. This is an absolute prohibition under PCI DSS, and it applies to issuers unless they have a specific documented business justification.
The people, processes, and technology that store, process, or transmit cardholder data or sensitive authentication data. The CDE also includes any system components that are connected to or could impact the security of those systems — even if they don't touch cardholder data directly. Defining your CDE accurately is the foundation of your entire compliance program. Everything inside the CDE is subject to PCI DSS requirements; everything outside it is not. This is why attack surface management matters for PCI — unknown assets that touch your CDE expand your scope without your knowledge.
The full set of system components, people, and processes subject to PCI DSS requirements. Scope includes your CDE plus any connected-to or security-impacting systems. Scoping errors — whether accidental or from outdated asset inventories — are among the most common sources of PCI compliance failures. A system missed during scoping is a system left unsecured.
The use of technical controls to isolate the CDE from other parts of your network. Effective segmentation can significantly reduce PCI DSS scope by preventing systems outside the CDE from accessing or impacting systems inside it. However, segmentation must be verified — simply claiming it exists is not sufficient. PCI DSS requires penetration testing to confirm that segmentation controls actually work and cannot be bypassed.
Systems that are not part of the CDE but are connected to it or can affect its security. Examples include authentication servers, logging systems, security monitoring platforms, and jump hosts used to access CDE components. These systems are in scope for PCI DSS even if they never touch cardholder data directly.
Systems that have no connectivity to the CDE and cannot affect its security. Achieving a meaningful out-of-scope designation requires demonstrating isolation through network segmentation and validating that isolation through penetration testing. If there's any doubt about whether a system is isolated, treat it as in scope until you can prove otherwise.
An individual or company certified by the PCI SSC to conduct official PCI DSS assessments. Level 1 merchants and many service providers are required to use a QSA for their annual assessment. QSAs produce a Report on Compliance (ROC) that documents how an organization meets each PCI DSS requirement. They are also authorized to perform other PCI-related assessments, including penetration testing scoped for compliance. You can find a current list of approved QSA companies on the PCI SSC website.
An employee who has been trained and certified by the PCI SSC to perform PCI DSS assessments internally. ISAs can conduct assessments and produce ROCs for their own organization, reducing the cost of annual compliance for some Level 1 merchants. However, ISA-produced ROCs must be signed by a company officer, and not all acquirers or card brands accept them in place of an external QSA assessment.
The formal documentation produced after a PCI DSS assessment conducted by a QSA or certified ISA. The ROC documents how an organization meets — or does not meet — each of the 12 PCI DSS requirements and their sub-requirements. Level 1 merchants are required to submit a ROC annually. A completed ROC is accompanied by an Attestation of Compliance.
A validation tool for merchants and service providers who are not required to undergo a full QSA assessment. SAQs are structured questionnaires that walk through relevant PCI DSS requirements based on how an organization processes payments. There are multiple SAQ types (A, A-EP, B, B-IP, C, C-VT, D, and P2PE), each designed for a specific payment environment. Choosing the wrong SAQ type is a common mistake that can result in under-scoped compliance programs.
A signed declaration that an organization has completed a PCI DSS assessment and, to the best of its knowledge, meets all applicable requirements. AOCs accompany ROCs and SAQs and are the primary compliance artifact that acquirers and card brands collect. An AOC without the underlying assessment documentation has limited value during a forensic investigation or dispute.
An alternative security measure that provides equivalent protection when an organization cannot meet a specific PCI DSS requirement due to a legitimate technical or business constraint. Compensating controls must be documented, reviewed and approved by a QSA, and validated annually. They cannot be used retroactively — if a required activity was missed in a prior period, a compensating control cannot cover that gap.
A company certified by the PCI SSC to perform external vulnerability scans of internet-facing systems. ASV scans are required at least quarterly under PCI DSS Requirement 11.3.2 and must be performed by a PCI SSC-approved vendor — they cannot be self-performed. The scan must return no vulnerabilities with a CVSS score of 4.0 or higher for the result to be considered passing. Halo Security from TrustedSite, LLC, is a PCI DSS Approved Scanning Vendor, which means our scan results are accepted for compliance validation.
PCI DSS requires two distinct types of vulnerability scanning. External scans — performed by an ASV at least quarterly — check internet-facing systems for exploitable weaknesses visible from outside your network. Internal scans — performed at least quarterly by qualified personnel — check systems inside the network perimeter. Under PCI DSS 4.0.1, internal scans must also be authenticated, meaning they use valid credentials to identify vulnerabilities that would only be visible to someone with system access. These are separate from penetration testing and serve a different purpose: they identify known vulnerabilities through automated means, not through active exploitation. External vulnerability management tools can help automate the continuous identification of issues between required scan cycles.
A structured security test in which qualified testers attempt to exploit vulnerabilities in your environment, simulating real-world attack techniques. Under PCI DSS Requirement 11.4, penetration testing must be performed at least annually and after any significant change to the environment. Testing must cover both network-layer and application-layer attack paths. Organizations that use network segmentation to reduce their PCI scope must also validate that segmentation through penetration testing — annually for most entities, and every six months for service providers. PCI compliance penetration testing must follow a documented, industry-recognized methodology and be conducted by qualified, independent testers.
A technical control that detects unauthorized changes to critical system files, configuration files, and application components. PCI DSS requires FIM for systems in the CDE. Any unexpected modification to a monitored file should generate an alert and trigger an investigation. FIM is particularly relevant in the context of PCI DSS 4.0's requirements around payment page integrity — unauthorized changes to a payment page's scripts or headers are exactly the kind of indicator FIM-style controls are designed to surface.
Security tools that monitor network traffic for suspicious activity or known attack patterns. An IDS alerts on potential threats; an IPS can also block them automatically. PCI DSS requires that all traffic entering and leaving the CDE be monitored, and that IDS/IPS alerts be reviewed in near real time. Keeping IDS/IPS signatures current is a specific PCI DSS sub-requirement — an outdated signature set defeats the purpose.
An authentication method that requires two or more independent verification factors before granting access. Under PCI DSS 4.0.1, MFA is required for all access to the CDE — not just administrative access. This was a significant expansion from prior versions and became mandatory on March 31, 2025. Phishing-resistant authentication factors (such as hardware security keys or passkeys) may satisfy MFA requirements in contexts where additional controls justify it.
A method of protecting cardholder data by replacing the PAN with a non-sensitive substitute value called a token. The token has no mathematical relationship to the original PAN and is meaningless if intercepted. Tokenization is one of the most effective ways to reduce PCI DSS scope — if your systems only ever see tokens and never the actual PAN, those systems may be removed from scope entirely, depending on how the tokenization solution is implemented. Tokenization is not the same as encryption: an encrypted value can be decrypted with the right key; a token cannot be reversed without access to the token vault.
PCI DSS requires that stored PANs be rendered unreadable using strong cryptography — currently defined as cryptographic systems and algorithms that meet industry-accepted standards and cannot be broken with reasonable resources. AES-256 and RSA-2048 are common examples. Weak or deprecated algorithms (such as DES, RC4, or MD5 used for security purposes) do not satisfy PCI DSS requirements. Encryption protects data at rest; TLS protects data in transit.
The cryptographic protocol that secures data transmitted over networks. PCI DSS requires the use of strong TLS (currently TLS 1.2 or higher; TLS 1.3 is preferred) for all transmission of cardholder data across open, public networks. Older protocols — SSL, TLS 1.0, and TLS 1.1 — are explicitly prohibited. Monitoring your TLS certificates for expiration and configuration drift is a practical compliance control, and it's becoming more operationally urgent as certificate lifetimes shrink toward 47 days. Halo Security's TLS certificate monitoring helps teams stay ahead of expirations and configuration issues that could affect both security and compliance posture.
The current major version of the PCI DSS standard. Version 4.0 was released March 31, 2022, and introduced 64 new or updated requirements — the most significant revision in over a decade. Version 4.0.1, a limited revision with no new or deleted requirements, was released June 11, 2024, and became the sole active version after December 31, 2024. All future-dated requirements from version 4.0 became mandatory on March 31, 2025. If you're currently undergoing a PCI assessment, it will be conducted against version 4.0.1.
The traditional method of achieving PCI DSS compliance: implementing the specific security controls defined in each requirement and validating them against the standard testing procedures. Most organizations follow the Defined Approach. It provides clear, prescriptive guidance but leaves less room for tailoring controls to specific technology environments.
A compliance pathway introduced in PCI DSS 4.0 that allows organizations to achieve the objective of a requirement using alternative controls of their own design, rather than implementing the specific controls prescribed by the standard. The Customized Approach requires organizations to define and document their control, perform a Targeted Risk Analysis to demonstrate it meets the requirement's objective, and have it validated by a QSA. It's designed for mature security programs with the internal capability to design, document, and defend alternative controls.
A formal, documented risk assessment required under PCI DSS 4.0 when an organization wants to set its own frequency for certain controls, or when pursuing the Customized Approach. A TRA must identify the assets being protected, the threats and vulnerabilities relevant to those assets, and the likelihood and impact of exploitation. It must be reviewed at least annually or whenever the environment changes significantly. TRAs are one of the most meaningful process changes introduced by PCI DSS 4.0 — they shift some compliance decisions from prescriptive rules to documented risk judgments.
A requirement introduced in PCI DSS 4.0 (mandatory as of March 31, 2025) that applies to e-commerce merchants who have payment pages that load and execute scripts in the consumer's browser. Organizations must maintain an inventory of all scripts on payment pages, ensure each script is authorized, and verify script integrity. The intent is to prevent web-based skimming attacks — where malicious JavaScript is injected into a payment page to steal card data as it's entered. Halo Security's JavaScript monitoring can help organizations detect unauthorized changes to scripts.
A requirement introduced in PCI DSS 4.0 (mandatory as of March 31, 2025) that requires e-commerce merchants to implement a mechanism to detect unauthorized modifications to HTTP headers and payment page content as received and loaded in the consumer's browser. This is distinct from server-side monitoring — it captures what the end user actually receives, which may differ if a third-party script or CDN has been compromised. Alerts must be generated at least weekly, or after any detected change.
A Report on Compliance (ROC) is a detailed assessment document produced by a QSA after an on-site evaluation of your PCI DSS compliance. It is required for Level 1 merchants and some service providers. A Self-Assessment Questionnaire (SAQ) is a self-completed validation tool for lower-level merchants who are not required to undergo a formal QSA assessment. Both result in an Attestation of Compliance (AOC), but the depth of validation — and the cost — differs significantly.
The CDE is the combination of people, processes, and technology that stores, processes, or transmits cardholder data or sensitive authentication data, plus any systems connected to or impacting the security of those components. Defining your CDE accurately determines your PCI DSS scope. Systems inside the CDE are subject to all applicable PCI DSS requirements; systems demonstrably outside it are not.
Most organizations subject to PCI DSS do. Requirement 11.3.2 requires quarterly external vulnerability scans performed by a PCI SSC-approved ASV. Under PCI DSS 4.0, this requirement was extended to SAQ A e-commerce merchants. The scans must return no vulnerabilities with a CVSS score of 4.0 or higher to be considered passing.
PCI DSS 4.0 introduced 64 new or updated requirements, the most significant revision since the standard was created. Key changes include mandatory MFA for all CDE access (not just administrative access), new requirements for payment page script management (Req. 6.4.3) and tamper detection (Req. 11.6.1), authenticated internal vulnerability scanning, a formal Targeted Risk Analysis process, and a new Customized Approach compliance pathway. All of these became fully mandatory on March 31, 2025. PCI DSS 4.0.1, released June 2024, is a limited editorial revision with no new or deleted requirements.
Both protect the PAN, but in different ways. Encryption mathematically scrambles the PAN and can be reversed with the correct decryption key — meaning the encrypted value still has a relationship to the original data. Tokenization replaces the PAN with a random substitute value (a token) that has no mathematical relationship to the original PAN and cannot be reversed without access to the token vault. From a PCI DSS scoping perspective, tokenization can be more powerful: if a system only ever sees tokens and has no access to the token vault, that system may be removable from PCI scope entirely.
PCI compliance has a lot of moving parts — and the stakes for getting it wrong are high. Whether you're preparing for your first assessment, working through the PCI DSS 4.0.1 transition, or looking for an ASV scanning partner to satisfy quarterly scan requirements, Halo Security can help guide you through it. Chat with one of our experts today.
