PCI DSS.
Define payment data and dependencies, clarify operational responsibility and agree suitable validation with the relevant authority.
- PCI DSS v4.0.1 · PCI SSC
- By Jonathan Bezdek
- As of: 10/22/2026
- Reading time: 7 min.
Short answer.
PCI DSS is the industry standard for protecting payment card data. It concerns merchants, service providers and systems processing such data or affecting its security. The current version is PCI DSS v4.0.1. Payment environment and role determine scope; the validation route is agreed with the acquirer or payment brand, for example through an SAQ or ROC.
PCI DSS 4.0 and the current version.
PCI DSS combines technical and operational security requirements for payment data. The PCI Security Standards Council, or PCI SSC, develops the standard and supporting tools. The relevant accepting entities, typically acquirers and payment brands, determine how compliance is validated in a specific payment programme; PCI SSC FAQ 1473 explains this division of roles.
PCI DSS v4.0.1 is the version listed in the official Document Library. According to the PCI SSC revision publication, v4.0 was retired on 31 December 2024. The date already set for new v4 requirements, 31 March 2025, remained unchanged. As of this page's publication, that date is in the past; it is not an upcoming implementation deadline.
Successfully completed validation does not replace ongoing protection. In practical organisation, changes to payment routes, applications and providers should trigger a fresh look at agreed scope. A new checkout integration may create different dependencies from the previously assessed solution even though the same company continues to accept payments.
Who PCI DSS applies to.
According to the PCI SSC overview, PCI DSS addresses more than organisations storing, processing or transmitting card data. Possible influence on the security of the Cardholder Data Environment, or CDE, is also considered. Merchants and service providers should therefore first describe their specific role and services actually provided.
Outsourced payment processing is not an automatic exemption. PCI SSC FAQ 1092 distinguishes potentially reduced direct requirements from continuing responsibility for suitable providers, agreed responsibilities and required validation. Even for hosted checkout, clarify with the relevant entity which prerequisites your chosen technical integration must fulfil.
Boundaries are demonstrated through effective measures, rather than merely a name in an architecture diagram. PCI SSC FAQ 1115 explains that connected systems and actual segmentation effectiveness must be examined. Excluding administrative access, supporting services or interfaces prematurely may produce an incomplete assessment scope.
Organise PCI DSS requirements in operations.
Implementation connects payment environment protection with traceable operational processes. The following six work areas offer editorial planning guidance, rather than reproducing the twelve official requirements or individual test points; their specific applicability is assessed against confirmed scope.
Make payment flows and scope understandable.
Trace where payment information arises, which components are involved and which people or providers can influence them. Record confirmed boundaries with their assumptions. An understandable description helps development, operations and the accepting entity discuss the same payment route.
Operate systems and changes securely.
Assign clear owners to the applications and infrastructure components involved. Connect changes with the question of whether new connections, functions or dependencies alter confirmed scope. For daily work, a traceable change history is more helpful than a snapshot compiled solely for the assessment date.
Limit data use and transmission.
As a practical starting question, examine which payment data the chosen process actually needs and where copies may arise. Include exports, logs and supporting processes. Detailed security planning must fit data types and purpose; a general confidentiality label does not explain these decisions.
Organise access with a clear audit trail.
Connect business responsibilities with technical capabilities actually granted. Consider service accounts, administrative access and suppliers alongside employees. For work organisation, clarify who approves access, who handles changes and what shows that access was revoked on time.
Examine operations and address findings.
Plan suitable records and assessments with payment environment owners. A single scan or penetration test describes only its own subject. For findings, record what change follows and how its effect will be checked, rather than equating a test result with all PCI DSS validation.
Include service providers and incidents.
Define operational contacts and procedures for anomalies. For outsourced services, your own tasks should remain understandable alongside provider commitments. PCI SSC FAQ 1576 explains that provider evidence must cover the services used; an arbitrary company document is not automatically sufficient.
Implement PCI DSS as an ongoing task.
Agree the role and validation route.
As a practical starting point, clarify your role, expected validation and responsible contact with the acquirer or payment brand before selecting a form.
Record one payment route.
Describe the data, applications, systems and providers involved from payment initiation to the operational records retained afterwards.
Confirm scope.
Examine relevant connections and components influencing security, and obtain professional assessment of the boundaries, including possible segmentation.
Embed tasks in operations.
Assign safeguards and shared responsibilities to specific people and connect implementation with suitable records.
Prepare consistent evidence.
Check that required records describe the same service, role and scope and that outstanding decisions have been handled traceably.
Track changes and subsequent assessments.
Agree required validation intervals and check after changes whether scope, provider evidence and operational responsibilities still fit.
PCI certification and the actual validation form.
Recognised PCI DSS validation uses the official documents provided for that purpose. An SAQ documents an eligible self-assessment, an ROC the results of the corresponding assessment route, and an AOC the associated attestation. Under PCI SSC FAQ 1220, arbitrary documents labelled compliance certificates are no substitute for official templates.
The accepting entity determines the required route; a Qualified Security Assessor, or QSA, may be involved in the relevant assessment. Under PCI SSC FAQ 1473, scope and applicability must be correctly assessed. Selecting an SAQ name therefore does not confirm that its eligibility criteria are met or all relevant requirements implemented.
Even the appropriate template must be used in its current version. PCI SSC changed the SAQ A rules effective 31 March 2025 and explicitly clarified that removing individual questionnaire test points does not remove underlying PCI DSS requirements. Agree validation timing and follow-up duties for your case rather than assuming a blanket certificate validity period.
Understanding other frameworks.
ISO 27001 addresses information security management within a defined scope; PCI DSS validation is a separate decision for the payment environment. CIS Controls supports general prioritisation of security work but does not define a PCI validation route. The GDPR concerns personal data processing and requires examination independently of payment data validation.
In Secani.
Secani provides its own editorial business catalogue for PCI DSS v4.0.1. The profile records CDE scope, merchant or service provider role and the agreed SAQ/ROC route, among other things. These working details support structured work; they replace neither official assessment documents nor confirmation of eligibility or the relevant entity's judgement.
Start with a specific payment route.
Choose a payment route actually used and name its business and technical owners. Record which services you provide yourself and which a provider handles. Then agree expected validation with the relevant entity before planning effort around an apparently suitable questionnaire.
Sources.
- PCI SSC – PCI DSS overview and audience
- PCI SSC – official Document Library
- PCI SSC – publication of PCI DSS v4.0.1
- PCI SSC FAQ 1473 – responsible entities and validation route
- PCI SSC FAQ 1092 – outsourced payment processing
- PCI SSC FAQ 1576 – service provider evidence
- PCI SSC FAQ 1220 – official documents rather than compliance certificates
- PCI SSC FAQ 1115 – connected systems and segmentation
- PCI SSC – changes to SAQ A effective 31 March 2025
- PCI SSC – SAQ bulletin of 15 October 2024
Frequently asked questions.
No, not automatically. Outsourcing can change direct scope; responsibility for suitable providers, clear responsibilities and required validation still needs separate consideration.
Not solely according to the effort desired. Eligibility criteria must be met, and the required validation route must be agreed with the accepting entity.
Arbitrary compliance certificates are not a recognised substitute for official documents. The agreed assessment route and associated official reports or attestations are decisive.
No. An ISMS certificate concerns its stated management system scope; requirements and the validation route for the payment environment require separate clarification.
Define the payment route.
Discuss how you can manage scope, tasks and evidence in Secani.
This page explains PCI DSS in our own words and replaces neither official PCI SSC documents nor professional assessment. Requirements of the relevant payment programme and decisions of the responsible entity must also be observed separately.