PCI DSS Reference for US Payment Environments

The Payment Card Industry Data Security Standard (PCI DSS) governs security controls applied to any environment that stores, processes, or transmits payment card data in the United States. Administered by the PCI Security Standards Council (PCI SSC), the standard defines 12 core requirements organized across six control objectives, with compliance validation enforced through card brand rules rather than direct federal statute. This reference covers the standard's structure, how compliance is assessed, the environments it applies to, and the boundaries that determine which requirements apply to a given organization.

Definition and scope

PCI DSS is a private-sector security standard developed and maintained by the PCI Security Standards Council, a body founded in 2006 by American Express, Discover, JCB International, Mastercard, and Visa. The standard applies to any entity — merchant, service provider, or financial institution — that stores, processes, or transmits cardholder data (CHD) or sensitive authentication data (SAD). The current version, PCI DSS v4.0, was released in March 2022 and became the only active version as of March 31, 2024, superseding v3.2.1 (PCI SSC, PCI DSS v4.0).

The scope of the standard is defined by the cardholder data environment (CDE): the people, processes, and technology that store, process, or transmit CHD or SAD, plus all system components connected to or capable of impacting the security of the CDE. Scope reduction — through network segmentation, tokenization, or point-to-point encryption (P2PE) — is a central strategy for limiting compliance burden. Effective segmentation, when validated, can isolate the CDE from the broader corporate network and reduce the number of systems subject to full assessment.

PCI DSS compliance obligations in the United States are not directly mandated by federal statute. Enforcement flows instead through merchant agreements with card brands and through acquiring banks, which contractually require compliance as a condition of accepting card payments. State law intersects indirectly: the Minnesota Plastic Card Security Act and Nevada Revised Statutes § 603A impose statutory obligations that reference PCI DSS compliance, making adherence relevant to state-level liability exposure in those jurisdictions.

For practitioners navigating the broader landscape of US cybersecurity frameworks and where PCI DSS fits within it, the Infosec Providers provides a structured provider network of related standards and service providers.

How it works

PCI DSS v4.0 organizes its requirements across 12 high-level controls, grouped under six control objectives:

1. Build and maintain a secure network and systems — Install and maintain network security controls; apply secure configurations to all system components.
2. Protect account data — Protect stored account data; protect cardholder data with strong cryptography during transmission over open, public networks.
3. Maintain a vulnerability management program — Protect all systems and networks from malicious software; develop and maintain secure systems and software.
4. Implement strong access control measures — Restrict access to system components and cardholder data by business need to know; identify users and authenticate access; restrict physical access to cardholder data.
5. Regularly monitor and test networks — Log and monitor all access to system components and cardholder data; test security of systems and networks regularly.
6. Maintain an information security policy — Support information security with organizational policies and programs.

Compliance validation follows one of three assessment types, determined by transaction volume and entity type:

• Report on Compliance (ROC): Conducted by a Qualified Security Assessor (QSA) or internal assessors with an Internal Security Assessor (ISA) designation; required for Level 1 merchants (processing more than 6 million Visa or Mastercard transactions annually) and most Level 1 service providers.
• Self-Assessment Questionnaire (SAQ): A documented self-evaluation available in 9 variants (SAQ A through SAQ D and SAQ P2PE), differentiated by the merchant's payment channel and degree of cardholder data handling.
• Attestation of Compliance (AOC): A formal declaration accompanying either a ROC or SAQ to confirm compliance status to acquiring banks and card brands.

Penetration testing under PCI DSS Requirement 11.4 must occur at least once every 12 months and after any significant infrastructure or application change. The standard distinguishes between external penetration tests (targeting the perimeter of the CDE) and internal penetration tests (targeting internal network segmentation controls).

Common scenarios

E-commerce merchants using hosted payment pages: A merchant that redirects cardholders to a third-party payment processor for all card data entry may qualify for SAQ A, the lowest-scope assessment, provided no cardholder data touches the merchant's servers. This is one of the most common scope-reduction approaches for small and mid-sized online retailers.

Brick-and-mortar retailers with integrated POS systems: Merchants using point-of-sale terminals directly connected to corporate networks typically face SAQ C or SAQ D requirements, depending on whether card data is stored locally. Integration with inventory, loyalty, or ERP systems frequently expands CDE scope unless explicit network segmentation is documented and tested.

Service providers handling CHD on behalf of merchants: Third-party service providers — including cloud hosting companies, managed security service providers, and payment gateways — are classified separately under PCI DSS and subject to their own validation requirements. Level 1 service providers processing more than 300,000 transactions annually must complete an annual ROC and quarterly network scans by an Approved Scanning Vendor (ASV) (PCI SSC, Service Provider Levels).

Healthcare organizations accepting patient payments: Entities subject to both HIPAA and PCI DSS must satisfy the requirements of each framework independently; no provision of one standard satisfies obligations under the other. Payment acceptance systems in clinical environments require CDE scoping that accounts for clinical network architecture.

Decision boundaries

The primary decision that determines compliance pathway is whether an organization stores, processes, or transmits CHD or SAD directly. Organizations that outsource all payment processing to validated third-party service providers and never receive raw card data may have minimal PCI DSS obligations — but they must confirm third-party compliance status through vendor contracts and AOCs.

SAQ variant selection turns on the specific payment channel:

The boundary between SAQ A and SAQ C eligibility is frequently misapplied. An e-commerce merchant whose webpage loads third-party scripts that could theoretically redirect or capture card data — a vector known as a web-skimming or Magecart attack — does not qualify for SAQ A under v4.0. PCI DSS v4.0 Requirement 6.4.3 introduced new controls specifically targeting scripts on payment pages, reflecting this threat model.

Tokenization and P2PE solutions reduce but do not eliminate PCI DSS scope. A validated P2PE solution verified on the PCI SSC's published solution list may reduce applicable controls for the merchant, but the solution itself must maintain full compliance certification. Tokenization replaces CHD with a non-exploitable surrogate but does not address SAD captured before token substitution occurs.

Practitioners researching how PCI DSS interacts with federal information security frameworks such as NIST SP 800-53 or FedRAMP can reference the for orientation across the broader standards landscape. For guidance on locating qualified assessors and service providers verified in this network, see How to Use This Infosec Resource.