What PCI DSS is
PCI DSS is the security standard published by the PCI Security Standards Council for entities that store, process or transmit payment account data, and for systems that can affect the security of that data. The current version is v4.0.1. Version 4.0 was retired at the end of 2024.
The obligation to comply comes through your contracts. Merchants are usually asked by their acquiring bank, and service providers by the merchants and payment companies they serve. The payment brands and your acquirer decide which validation route applies to you.
The 12 requirements
Requirements that v4.0 marked as future-dated became mandatory on 31 March 2025 and are now assessed like every other requirement. They include MFA for all access into the cardholder data environment, controls on payment page scripts, automated log review and targeted risk analyses.
| Requirement | What it covers |
|---|---|
| 1 | Install and maintain network security controls |
| 2 | Apply secure configurations to all system components |
| 3 | Protect stored account data |
| 4 | Protect cardholder data with strong cryptography during transmission over open, public networks |
| 5 | Protect all systems and networks from malicious software |
| 6 | Develop and maintain secure systems and software |
| 7 | Restrict access to system components and cardholder data by business need to know |
| 8 | Identify users and authenticate access to system components |
| 9 | Restrict physical access to cardholder data |
| 10 | Log and monitor all access to system components and cardholder data |
| 11 | Test security of systems and networks regularly |
| 12 | Support information security with organizational policies and programs |
How readiness works with us
We map how payment account data enters, moves through and leaves your environment. From that we identify the cardholder data environment (CDE), connected systems and systems that can affect its security. We list your third-party service providers and which requirements each one manages, and we help you confirm the validation route with your acquirer.
We assess each applicable requirement against your current controls. We review network rules, configurations, access, logs, scan results, payment pages and documentation, and we interview control owners. The result is a gap list ranked by assessment impact and effort, with an owner for each item.
We work through the plan with your engineers. That can include tightening segmentation, enforcing MFA, setting up vulnerability scanning, adding payment page script controls, documenting targeted risk analyses and updating policies. We also look for ways to reduce scope before you build controls you may not need.
Before the assessment we test controls and evidence the way an assessor would. If you validate with an SAQ, we help your team work through it with accurate answers. If a QSA performs your assessment, we help answer requests and explain technical controls during fieldwork.
What you receive
Each engagement has a fixed scope agreed at the start. These are the outputs your team keeps.
Scope and gap assessment
- Account data flow diagrams and CDE inventory
- Status of each applicable requirement
- Prioritized remediation plan with owners and target dates
Controls and documentation
- Controls implemented or improved in your environment
- Policies, procedures and roles updated where gaps exist
- Service provider responsibility matrix
Evidence set
- Evidence organized by requirement for the assessor
- Targeted risk analyses documented where required
- Setup in your compliance platform if you use one
Testing and assessment support
- Pre-assessment testing results
- Support completing your SAQ
- Help with QSA requests during fieldwork
Control areas we commonly implement
Network security and segmentation
Network security controls, documented permitted flows and segmentation that isolates the CDE from other networks.
Secure configuration
Hardening standards for systems in scope, removal of default accounts and settings, and configuration records.
Access control and MFA
Need-to-know access, MFA into the CDE, privileged access limits and access reviews. We can deploy identity with Keycloak.
Vulnerability management and testing
Internal scanning, patching, and annual penetration testing through our application and cloud infrastructure security testing.
Logging and monitoring
Audit logs for in-scope systems, automated log review and alert handling. We deploy open-source monitoring such as Wazuh.
Payment page security
An inventory and authorization of scripts on payment pages, and detection of unauthorized changes to those pages.
Incident response
An incident response plan that covers suspected account data compromise, with defined roles and regular testing.
Service provider management
A list of service providers, written agreements, monitoring of their PCI DSS status and a clear split of responsibilities.
SAQ types and the Report on Compliance
Each SAQ sets its own eligibility criteria. Your acquirer or the payment brands confirm which route applies. Some SAQs also require quarterly external scans by an Approved Scanning Vendor (ASV).
| Validation route | Typically fits | Completed by |
|---|---|---|
| SAQ A | Card-not-present merchants that fully outsource all account data functions to PCI DSS compliant third parties, for example through a hosted payment page or iframe | Merchant, with a signed Attestation of Compliance (AOC) |
| SAQ A-EP | E-commerce merchants that outsource payment processing but whose website can affect the security of the payment transaction | Merchant, with a signed Attestation of Compliance (AOC) |
| SAQ B | Merchants using only imprint machines or standalone dial-out terminals, with no electronic account data storage | Merchant, with a signed Attestation of Compliance (AOC) |
| SAQ B-IP | Merchants using only standalone, PTS-approved terminals with an IP connection to the payment processor, with no electronic storage | Merchant, with a signed Attestation of Compliance (AOC) |
| SAQ C-VT | Merchants that key in transactions one at a time through a third party's web-based virtual terminal, with no electronic storage | Merchant, with a signed Attestation of Compliance (AOC) |
| SAQ C | Merchants with payment application systems connected to the internet, with no electronic storage | Merchant, with a signed Attestation of Compliance (AOC) |
| SAQ P2PE | Merchants using only hardware terminals managed through a PCI-listed P2PE solution, with no electronic storage | Merchant, with a signed Attestation of Compliance (AOC) |
| SAQ D | Merchants that do not meet the criteria of another SAQ, and service providers eligible to self-assess | Merchant or service provider, with a signed AOC |
| Report on Compliance (ROC) | Entities whose acquirer or the payment brands require an assessment by an assessor, often larger merchants and service providers | A Qualified Security Assessor (QSA), or an Internal Security Assessor where the acquirer allows it, with an AOC |
Who does what
We prepare your environment and evidence for validation. We scope, assess, help implement controls, test them and support your team during the SAQ or the QSA assessment. We do not sign SAQs, Reports on Compliance or Attestations of Compliance.
A QSA performs the assessment when a Report on Compliance is required and signs the ROC and its AOC. For an SAQ, an officer of your company signs the AOC. An ASV performs the external vulnerability scans. Your acquirer or the payment brands receive the results.
Your team owns the CDE and its controls. Control owners operate controls throughout the year, and one person on your side coordinates with the acquirer, the QSA and service providers.
Common questions
How long does readiness take?
It depends on your scope, your validation route and how mature your controls are today. During scoping we give you a plan with dates for each phase. Reducing scope early can shorten the remediation work.
Can you work with our compliance platform?
Yes. If you use Vanta, Drata or a similar platform, we work inside it. We map controls to requirements, connect integrations and upload evidence. If you do not use one, we organize evidence by requirement in a structure your assessor can follow.
Do you perform the PCI DSS assessment?
No. A QSA performs the assessment when a ROC is required, and your company signs the AOC for an SAQ. We prepare your team and support you during validation.
Can you do the penetration testing PCI DSS requires?
Yes. Requirement 11.4 calls for internal and external penetration testing at least once every 12 months and after significant changes, plus segmentation testing when segmentation is used to reduce scope. Our application and cloud infrastructure testing teams can perform it. Confirm with your QSA that the method meets their expectations.
Can you help after validation?
Yes, through a retainer. PCI DSS includes recurring tasks such as quarterly scans, access reviews, log review, targeted risk analysis updates and annual testing. We can help keep them on schedule and prepare for the next assessment.
What do we need to prepare?
A named owner on your side, your payment flows and providers, network and architecture diagrams, your last SAQ or ROC if you have one, and any communication from your acquirer about validation. An NDA can be in place before we start.
How to prepare
List every way you accept payments: websites, mobile apps, call centers, terminals and integrations. For each one, note the payment provider and whether account data touches your systems.
Gather what you already have: network and data flow diagrams, an inventory of in-scope systems, your service provider list, recent scan and penetration test reports, policies, and your last SAQ or ROC. Gaps are expected. The gap assessment exists to find them.
Confirm your merchant or service provider level and validation route with your acquirer. If you already work with a QSA, share their contact so we can align on scope and timing early.
Scope reduction and segmentation
The fewer systems that store, process or transmit account data, the fewer systems are in scope. Common approaches are to stop storing primary account numbers you do not need, use tokenization from your payment provider, move to a hosted payment page or iframe, or use a PCI-listed point-to-point encryption (P2PE) solution for terminals.
Segmentation can keep other networks out of scope when it is designed, implemented and tested as an effective boundary. Penetration tests must confirm that segmentation controls work: at least once every 12 months for merchants, and at least once every six months for service providers. Revisit the design after significant changes.
Outsourcing to a compliant provider reduces what you operate. You still need to manage that provider, including a written agreement and a clear record of which requirements they cover and which remain with you.
