PCI DSS Compliance Guide: Scope, Requirements, and Readiness

Your checkout sends payment data to a provider, so is the rest of your environment outside PCI DSS scope? Not necessarily. The answer depends on the payment flow and on which systems, people, connections, and services handle account data or can affect its security.

PCI means Payment Card Industry, the broader payment ecosystem rather than a single standard. Within that ecosystem, PCI DSS means Payment Card Industry Data Security Standard, the baseline of technical and operational security requirements for protecting payment account data. The PCI Security Standards Council (PCI SSC) develops and maintains PCI DSS and related security standards. The current standard is PCI DSS v4.0.1. Use the official PCI DSS overview and PCI SSC Document Library for the standard, reporting templates, questionnaires, and current supporting guidance.

PCI DSS is one part of the PCI ecosystem

People often use “PCI” as shorthand for PCI DSS, but the PCI ecosystem includes separate standards and programs for different risks. They can overlap, but they are not interchangeable:

• PCI DSS addresses the security of environments that store, process, or transmit payment account data, and systems or services that can affect that security.
• PCI Software Security Framework (PCI SSF) addresses payment software and secure software lifecycle practices. See PA-DSS vs PCI DSS vs PCI SSF.
• PCI 3DS addresses security for environments supporting EMV 3-D Secure components. See the PCI 3DS readiness guide.
• PCI PIN Security addresses the secure management, processing, and transmission of PIN data and associated cryptographic keys. ControlSolid offers a PCI PIN Security gap assessment.
• Point-to-Point Encryption (P2PE) is a separate PCI program for validated solutions and components that protect account data from the point of interaction. See the PCI P2PE gap assessment.

Who PCI DSS applies to

The cardholder data environment (CDE) is the people, processes, and system components that store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD), plus system components with unrestricted connectivity to those components. PCI DSS applies to entities that store, process, or transmit account data, or that can affect the security of the CDE. See the PCI SSC glossary for the current terminology.

The CDE is the starting point, not necessarily the full PCI DSS assessment scope. Scope can also include connected-to or supporting system components and components that can affect CDE security. Those components may include cloud control planes, identity systems, deployment pipelines, security tooling, administrator workstations, and third-party services without making every such component part of the formal CDE definition. Review PCI SSC's modern scoping and segmentation guidance and its service-provider scoping FAQ.

A merchant accepts payment cards for goods or services. A service provider supplies services that involve account data, control or manage the CDE, or can affect its security. An organization can have more than one role. For example, a software company may be a merchant for its own subscriptions and a service provider for customers using its payment platform.

The two basic account-data categories

Cardholder data (CHD) consists of the primary account number (PAN), alone, or PAN together with cardholder name, expiration date, or service code. PAN is the defining element. Sensitive authentication data (SAD) includes full track data, card verification codes or values, and PINs or PIN blocks. PCI SSC provides the precise account-data definitions in the current standard and reporting documents in its Document Library.

The narrow issuer exception applies only to issuers and companies supporting issuing services where a legitimate issuing business need exists. See PCI SSC's SAD storage guidance. For a detailed visual treatment of CHD, SAD, and system categories, use the PCI DSS scope and segmentation guide.

What determines PCI DSS scope

Scope begins with the payment flow, not a questionnaire. Trace where account data enters, where it is transmitted or processed, whether it is stored, and where it could appear unintentionally. Then identify every system, connection, person, script, and service that supports or can affect those paths.

• Payment channels: e-commerce checkout, hosted fields, redirects, mobile applications, point-of-sale devices, telephone payments, APIs, and manual processes.
• Systems and connections: applications, databases, network paths, cloud management planes, identity providers, administrator workstations, CI/CD, logging, monitoring, backups, and security controls.
• Browser scripts: scripts that operate on or can affect an e-commerce payment page can create security responsibilities even when payment fields are hosted by another provider.
• Outsourcing: gateways, processors, cloud providers, managed services, and support vendors can perform controls, but their involvement does not automatically remove the merchant's obligations.

For each provider, confirm the exact service covered by its current validation evidence and document which requirements the provider performs, which remain yours, and which are shared. PCI SSC's guidance for merchants that outsource payment processing explains this responsibility. For deeper scoping and segmentation analysis, use the dedicated scoping guide rather than treating a provider's compliance status as the end of the analysis.

The 12 PCI DSS requirement families

PCI DSS organizes its controls into 12 requirement families. The following is an orientation, not replacement requirement text:

1. Network security controls: define and enforce approved traffic paths around in-scope systems.
2. Secure configurations: remove insecure defaults and maintain hardened, documented configurations.
3. Stored account data: minimize retention and protect stored data according to its type and use.
4. Data in transit: protect account data when it crosses open or public networks.
5. Malware defenses: prevent, detect, and respond to malicious software where it presents risk.
6. Secure systems and software: manage vulnerabilities, patches, changes, and application security throughout development and operation.
7. Need-to-know access: limit privileges according to job responsibilities and business need.
8. Identity and authentication: identify users and systems, protect credentials, and use strong authentication.
9. Physical access: protect facilities, devices, media, and physical access to account data.
10. Logging and monitoring: record, review, and protect activity so suspicious events can be detected and investigated.
11. Security testing: scan, test, and verify controls, applications, networks, and segmentation on the required cadence.
12. Security governance: maintain policies, risk processes, responsibilities, training, provider oversight, and incident readiness.

Always assess against the current PCI SSC standard and applicable reporting document. A summary cannot show every applicability note, testing procedure, defined approach, or customized approach expectation.

Validation, reporting, and PCI DSS levels

PCI SSC publishes tools such as Self-Assessment Questionnaires (SAQs), Reports on Compliance (ROCs), Attestations of Compliance (AoCs), and external vulnerability scanning performed by Approved Scanning Vendors (ASVs). These are not interchangeable badges, and an organization should not casually select the shortest-looking option.

• SAQ: a self-assessment and reporting tool for an entity that meets all eligibility criteria for the applicable SAQ.
• ROC: a detailed record of assessment findings used when the applicable compliance program requires that reporting method.
• AoC: an attestation associated with the applicable SAQ or ROC reporting package.
• ASV scan: an external vulnerability scan by a PCI SSC Approved Scanning Vendor where required by the applicable pathway.

The payment brand, acquirer, customer, regulator, or other entity accepting compliance evidence sets or administers the applicable compliance program. Confirm its requirements, your eligibility, the expected reporting method, and submission instructions before work begins. PCI SSC's updated guidance states that merchants should consult the organizations managing their compliance programs to confirm the validation and reporting method. See the PCI SSC validation-method FAQ and current forms in the Document Library.

What “PCI DSS levels” means

PCI DSS itself does not create one universal merchant-level system. Payment brands, acquirers, and other compliance-accepting entities administer programs that may categorize organizations and set their validation and reporting obligations. Those obligations can depend on factors beyond transaction volume, so static level thresholds are not a reliable universal answer. Confirm your pathway with the applicable acquirer, payment brand, or other entity accepting your compliance evidence, using the PCI SSC validation-method FAQ as official context.

A practical PCI DSS readiness sequence

1. Confirm obligations. Identify your roles, payment channels, compliance-accepting entities, applicable program rules, validation method, and due dates.
2. Map account-data flows and scope. Follow CHD and SAD, identify the CDE and security-impacting dependencies, document providers, and test segmentation claims.
3. Assign control and evidence owners. Name accountable people for each applicable control family, system, provider dependency, and evidence set.
4. Assess gaps. Compare actual configurations, operations, and evidence with the current standard and reporting expectations.
5. Remediate. Prioritize changes that reduce account-data exposure and material security risk, then close documentation and evidence gaps.
6. Validate. Complete the required self-assessment or coordinate the independent assessment, scans, testing, attestations, and submission package.
7. Maintain. Monitor controls, collect evidence continuously, manage provider changes, and revisit scope when the environment changes.

For a more tactical preparation sequence, see the PCI DSS v4 readiness checklist.

Common PCI DSS mistakes

• Starting with an SAQ before confirming eligibility and the required reporting pathway.
• Assuming a compliant processor makes the merchant's website, integrations, people, and procedures compliant.
• Looking only for stored PAN and missing systems that process, transmit, connect to, or affect the security of the CDE.
• Ignoring browser scripts, tag managers, administrative access, cloud control planes, logs, backups, or support workflows.
• Treating a provider's AoC as proof that every service used and every customer responsibility is covered.
• Collecting policies just before validation instead of operating controls and preserving evidence throughout the period.
• Calling a readiness review, vulnerability scan, or penetration test a PCI certification.
• Allowing scope diagrams and responsibility matrices to drift after product, infrastructure, or provider changes.

Where readiness consulting fits

Readiness consulting helps an organization understand obligations, define a defensible scope, assess controls and evidence, prioritize remediation, and prepare for the applicable validation process. It is distinct from an official PCI DSS assessment or certification. When an independent assessment is required, it is performed by the appropriately qualified independent assessor under the applicable compliance program.

A readiness engagement can prepare scope, controls, evidence, and remediation priorities for that next step. The applicable compliance-accepting entity determines the validation and reporting evidence it will accept. Learn more about the PCI DSS gap-assessment process and its boundaries.

Frequently asked questions

Authoritative PCI SSC references

• PCI DSS overview and current version
• PCI SSC Document Library
• Sensitive authentication data storage guidance
• Responsibilities when merchants outsource payment processing
• Service providers that can affect account-data security
• Validation and reporting method guidance
• SAQ eligibility criteria

This article provides general readiness guidance. It does not determine applicability, scope, validation obligations, or compliance for a specific organization.