Technical and operational requirements to protect account data.
PCI DSS is the global data-security standard for protecting payment account data. This guide explains how scope is created, how validation differs by role and why outsourcing payment processing does not automatically remove every merchant security responsibility.

PCI DSS is not a government license or a general ISO-style management-system certificate. Validation depends on the organization’s role, transaction environment, account-data flow and applicable payment-brand/acquirer program rules.
Technical and operational requirements to protect account data.
Listed by PCI SSC as the current standard.
Merchant, processor and service-provider roles affect scope.
The accepted path depends on role and program requirements.
PCI DSS establishes baseline technical and operational requirements for secure handling, transmission and storage of payment account data. The scope extends beyond a checkout form to systems, people, networks and providers that can affect payment security.
Correct scoping starts with data flows and dependencies rather than a single product label.
The standard is relevant across the payment-card ecosystem, including merchants and service providers. The exact responsibility depends on the role and how payment data and payment functions interact with the environment.
Not storing card numbers does not automatically mean zero scope; redirect, iframe and script-based integrations can produce different responsibilities.
PCI SSC published v4.0.1 as a limited revision to clarify and correct v4.0 without adding or deleting requirements.
PCI DSS v4.0 was retired at the end of 2024, so current guidance should reference v4.0.1 and monitor future PCI SSC updates.
A full redirect, hosted iframe and merchant-controlled payment page do not have identical scope. Keeping account-data capture on a validated third party can reduce merchant exposure, but website integrity and payment-page security may still matter.
Select an SAQ based on the actual integration and eligibility criteria, not merely the payment-provider brand.
SAQs are self-assessment questionnaires for eligible scenarios. ROC refers to a report on compliance, AOC is an attestation of compliance, QSA is a qualified security assessor and ASV is an approved scanning vendor.
Organizations should follow the validation method accepted for their role and payment program.
| Term | Meaning | Typical use |
|---|---|---|
| SAQ | Self-Assessment Questionnaire | Eligible self-assessment |
| ROC | Report on Compliance | Detailed compliance assessment |
| AOC | Attestation of Compliance | Formal attestation |
| QSA | Qualified Security Assessor | Qualified assessor |
| ASV | Approved Scanning Vendor | Approved external scanning |
PCI DSS covers network security, secure configuration, account-data protection, transmission security, malware defense, secure development, access control, authentication, physical security, logging, testing and policy.
Sustainable operation matters: controls should work throughout the year, not only during validation.
Hosting layers can influence scope through administrator access, virtualization, control panels, backup, network segmentation and support operations. Responsibilities should be documented between merchant and provider.
Shared hosting, managed VPS and dedicated infrastructure do not present identical boundaries.
Storing account data increases scope and risk, and sensitive authentication data is subject to strict post-authorization restrictions. Designs that keep raw card data out of the merchant environment generally reduce exposure.
Tokenization can reduce risk but does not make every connected system automatically out of scope.
No. An ASV scan is a standardized external vulnerability scanning process delivered by an approved scanning vendor. Penetration testing is a different security-testing activity with different objectives and scope.
Accurate asset scope and remediation of findings are as important as the final pass result.
No. PCI DSS is payment-specific, while ISO 27001 addresses an organization-wide ISMS and SOC 2 provides assurance over service-organization controls. Multiple frameworks can apply at the same time.
| Framework | Focus | Relationship |
|---|---|---|
| PCI DSS | Payment account data | Direct payment security |
| ISO 27001 | Information-security management | Broader management system |
| SOC 2 | Service controls | Complementary customer assurance |
| CREST | Cybersecurity service capability | Security-service quality |
| FedRAMP | US federal cloud | Separate federal program |
No. Merchants and service providers in the payment ecosystem can also be in scope.
It can reduce scope significantly, but integration architecture and systems that affect the payment page can still matter.
PCI SSC lists v4.0.1 as the current standard; v4.0 was retired at the end of 2024.
No. Each SAQ has eligibility criteria.
No. They are different security-validation activities.
The path can involve self-assessment, QSA assessment, ROC/AOC and scans depending on the applicable program.
We do not claim to be a certification body or independent auditor. We can assist with technical readiness around servers, hosting, access, logging, backups and baseline security controls.