Updated: 29 September 2026
What is PCI DSS and why does it exist? PCI DSS (Payment Card Industry Data Security Standard) is a set of security requirements created by Visa, Mastercard, American Express, Discover, and JCB through the PCI SSC (Security Standards Council), applicable to all organisations that store, process, or transmit payment card data. A cardholder data breach carries measurable financial consequences: acquirer fines (USD 10,000 to USD 500,000 per incident), loss of the right to accept cards, compensation to card issuers for fraudulent transactions, and incident response costs.
PCI DSS is not optional for organisations handling card payments – it is a contractual condition of the acquiring relationship. The current version is v4.0.1 (a minor revision of v4.0, published June 2024). All new requirements introduced as “best practice” in v4.0 became mandatory from 31 March 2025.
PCI DSS v4.0.1 – at a glance:
- The 12 PCI DSS requirements are grouped into 6 goals: build and maintain a secure network, protect cardholder data, maintain a vulnerability management programme, implement strong access control measures, regularly monitor and test networks, and maintain an information security policy
- 31 March 2025: new requirements became mandatory – including 11.3.1.2 (authenticated internal vulnerability scans), 6.4.3 (payment-page script inventory and integrity controls), and 11.4.1 (documented penetration testing methodology)
- SAQ (Self-Assessment Questionnaire) versus ROC (Report on Compliance): Level 1 merchants and Level 1 service providers require a ROC from an accredited QSA; others may use the appropriate SAQ for their payment model – subject to acquirer acceptance
- The CDE (Cardholder Data Environment) defines the assessment scope – systems outside the CDE are not subject to PCI DSS; scope reduction through tokenisation or P2PE is the most widely used strategy for reducing compliance cost
- PCI DSS compliance does not guarantee security – TJX, Target, and Equifax were all certified at the time of their breaches; compliance is a minimum baseline, not an end goal in itself
- Patronusec, as an accredited QSA, delivers PCI DSS certifications for merchants and service providers at all levels – from scope assessment through gap analysis to Attestation of Compliance
Table of Contents
What does each of the 12 PCI DSS requirements mean in practice?
Requirement 1 – Secure network configuration
Firewalls, network access control, documented firewall rules with business justifications, and CDE segmentation from the wider environment. The most common challenge: re-certifying firewall rules every 6 months and ensuring the network diagram is current on the day of the assessment.
Requirement 2 – Secure system configurations
Change default passwords, disable unnecessary services and protocols, document baseline configurations per system type. Most common challenge: maintaining current baseline configurations throughout the full certification year.
Requirement 3 – Protection of stored account data
Do not store SAD after authorisation, encrypt PAN in databases, mask PAN on displays. Most common challenge: inventorying every location where PAN may be stored – logs, backups, temporary files, test databases.
Requirement 4 – Protection of data in transit
TLS 1.2 or higher for all connections transmitting CHD; SSL, TLS 1.0, and TLS 1.1 are prohibited. Most common challenge: inventorying all transmission paths and confirming end-to-end encryption in integrations with third-party providers.
Requirement 5 – Protection against malicious software
Anti-malware on systems commonly targeted by malware, regular signature updates, anti-malware audit logs. From v4.0.1: a risk assessment is required for all system types, not only “commonly affected” ones.
Requirement 6 – Secure systems and software
Vulnerability management, SDLC controls, code reviews for payment applications, WAF, and new in v4.0.1: an inventory of third-party scripts on payment pages with integrity verification (6.4.3). This is the most common blocking finding since 31 March 2025.
Requirement 7 – Restrict access to system components
Least privilege for every account, role-based access control, documented business justification for each access level. Most common challenge: regular access reviews and prompt removal of inactive or unnecessary accounts.
Requirement 8 – Identification and authentication
New in v4.0.1: MFA required for ALL access to the CDE (8.4.2) – not only remote access as in v3.2.1. This is the requirement most commonly catching organisations in their first v4.0.1 assessment. Most common challenge: implementing MFA for administrative access from the internal network.
Requirement 9 – Physical security
Access control to data centres and server rooms, CCTV at terminal locations, terminal tamper protection, device inventory. Most common challenge for retail networks: managing devices across hundreds of locations.
Requirement 10 – Logging and monitoring
Audit logs for all operations on CHD, centralised SIEM, 12-month retention (3 months immediately available online). Most common challenge: completeness of logging – organisations often log the application but not network infrastructure or database access events.
Requirement 11 – Security testing
Quarterly external ASV scans, quarterly internal scans (authenticated from 31 March 2025 – Requirement 11.3.1.2), annual penetration test with documented methodology (11.4.1), annual segmentation testing. Three new mandatory requirements from 31 March 2025.
Requirement 12 – Security policies and programmes
Annual information security policy review, awareness programme, TPSP management (12.8), and incident management (12.10). Most common challenge: 12.8 – a current AOC for every Tier 1 TPSP, plus Responsibility Matrices for each.
Patronusec Insight: Requirement 6.4.3 is the most common blocking finding in first assessments conducted after 31 March 2025. A typical e-commerce payment page loads dozens of third-party scripts – Google Analytics, Meta Pixel, chat widgets, A/B testing tools, cookie consent managers, CDN scripts – each must be inventoried with a business justification and subject to integrity verification (Sub-Resource Integrity hash or CSP nonce). In our gap analysis engagement, we audit the client’s payment pages and identify every script requiring inventory and integrity controls before the QSA sees them during Stage 1.
How do you determine the CDE scope – and when does reducing it make commercial sense?
The CDE (Cardholder Data Environment) comprises all systems that store, process, or transmit payment card data, as well as systems that could affect the security of that data (connected-to systems). The broader the CDE, the more systems are subject to all 12 requirements – and the higher the assessment cost.
Three strategies for reducing CDE scope:
Tokenisation via a certified PSP: If your e-commerce platform uses an iFrame payment element (Stripe, Adyen, WorldPay) and your systems never see the PAN, your scope may reduce from SAQ D (300+ questions) to SAQ A (approximately 22 questions). This is the most common and cost-effective scope reduction strategy.
P2PE (Point-to-Point Encryption) via a certified solution: For environments with physical terminals, a PCI-certified P2PE solution reduces the assessment scope for the merchant operating the terminals. Card data is encrypted from the terminal to the processor’s HSM – your systems see only ciphertext.
Network segmentation: CDE systems isolated from the rest of the infrastructure through firewalls and strict traffic rules. Segmentation must be technically verified through penetration testing (Requirement 11.4.4) – a network diagram without a technical test does not satisfy the requirement.
Patronusec Insight: The most frequent scoping error we see is an organisation assuming its systems are outside the CDE because they do not “see” the card number. But a web server serving a payment page – even one with an iFrame from a separate provider – may be connected-to the CDE if it can influence the security of the payment environment, for instance through a compromise that injects a malicious script. Requirement 6.4.3 exists precisely because of this risk. In our scope assessment engagements, we map the actual CDE boundary including connected-to systems that organisations frequently overlook.
Not sure which systems are actually in scope for PCI DSS and how to reduce the scope before the assessment?
Patronusec, as an accredited QSA, conducts CDE scope assessments – mapping the CDE, identifying connected-to systems, and evaluating scope reduction opportunities before the formal assessment begins.
What are the most important changes from v3.2.1 to v4.0.1?
| Requirement | What changed | Mandatory from |
|---|---|---|
| 6.4.3 | Inventory and integrity controls for payment-page scripts | 31 March 2025 |
| 8.4.2 | MFA for all CDE access (not only remote) | 31 March 2025 |
| 11.3.1.2 | Internal vulnerability scans must be authenticated | 31 March 2025 |
| 11.4.1 | Penetration testing methodology must be documented before the test | 31 March 2025 |
| 12.3.4 | Annual review of hardware and software against EOL status | 31 March 2025 |
| Customised approach | New option: define your own controls to meet the requirement’s intent | From v4.0 (March 2022) |
FAQ – PCI DSS 12 Requirements
Must I comply with all 12 requirements?
All 12 requirements potentially apply, but which aspects are applicable depends on your CDE scope and payment model. SAQ A (full outsourcing of card processing) contains approximately 22 questions and excludes many requirements as inapplicable. SAQ D contains 300+ questions. The appropriate SAQ – or the need for a ROC – is determined by your acquirer and card scheme.
What is the difference between an SAQ and a ROC?
An SAQ (Self-Assessment Questionnaire) is self-certification – the organisation assesses its own compliance and signs the document. A ROC (Report on Compliance) is a formal report issued by an accredited QSA following an independent assessment. Level 1 merchants and Level 1 service providers require a ROC. Others may use an SAQ, subject to acquirer acceptance.
What is tokenisation and how does it reduce PCI DSS scope?
Tokenisation replaces a PAN (primary account number) with a token that has no mathematical relationship to the original card number. If your systems see only tokens and never the PAN, those systems may be excluded from the CDE. Effective tokenisation via a certified PSP can dramatically reduce the assessment scope – in some cases from SAQ D to SAQ A.
How long is an AOC (Attestation of Compliance) valid?
12 months. The certification cycle must be renewed annually. During the year, quarterly ASV scans and internal vulnerability scans must be maintained continuously – not only in the weeks before the annual assessment.
What changed in Requirement 8 (authentication) in v4.0.1?
The key change: MFA is now required for all access to the CDE (Requirement 8.4.2) – not only for remote access as was the case under v3.2.1. This means administrators who log into CDE systems from within the internal network must also use MFA. This is the most common gap found in organisations assessed under v4.0.1 for the first time.
How much does PCI DSS certification cost with Patronusec?
Pricing depends on merchant or service provider level and the technical environment. After a free 30-minute scope-assessment call, we provide a fixed-price quotation with a phase breakdown (gap analysis, assessment, post-audit support). For clients engaging us for both penetration testing and the PCI DSS assessment, we offer preferential combined pricing.
PCI DSS certification – free consultation
Patronusec, as an accredited QSA, certifies merchants and service providers at all PCI DSS levels – from SAQ A through to Level 1 ROC – in fintech, e-commerce, and financial services.
In a free 30-minute consultation we will help you:
- Determine your merchant level and the appropriate SAQ or ROC for your environment
- Assess your CDE scope and identify scope reduction opportunities before the assessment
- Identify which new v4.0.1 requirements need immediate action in your environment
- Provide a transparent, fixed-price project quotation with a phase breakdown
Free consultation | PCI DSS certification | Gap analysis | Penetration testing | Vulnerability scans
