Home › Compliance › PCI-DSS
⚠️ PCI DSS v4.0.1 — only active standard since Jan 2025 — 51 future-dated requirements mandatory March 31, 2025 → Book now

PCI-DSS v4.0.1 Compliance Training
for Teams That Touch Card Data

PCI-DSS v4.0.1 is the only active standard since January 2025. All 51 future-dated requirements — including payment page script monitoring (Req 6.4.3), change-detection on payment pages (Req 11.6.1), and MFA for all CDE access — became mandatory March 31, 2025. If you're running your 2026 assessment against outdated training, your QSA will flag it. We deliver live, documented training that satisfies Requirement 12.6 and gives you the attendance records your auditor actually needs.

Personal — $150 → Executive — $390 → Business — $900 flat → Free PCI-DSS scoping assessment →
500+ professionals trained
6+ compliance frameworks covered
98% satisfaction rate
Live expert instructors, always
Requirement 12.6

Who needs PCI-DSS training?

PCI DSS v4.0.1 applies to every entity that stores, processes, or transmits cardholder data — merchants and service providers at every level. Merchant level determines your validation type, not your training obligation. Requirement 12.6 applies to anyone who touches the Cardholder Data Environment.

Merchant Levels
Level 1
6M+ Visa/Mastercard transactions/year
Full ROC with QSA assessment · Annual penetration test · Continuous monitoring
View Business tier →
Level 2
1M–6M transactions/year
SAQ A, A-EP, or D — QSA validation increasingly required by acquirers for Level 2 SAQ A
View Business tier →
Level 3
20,000–1M transactions/year
SAQ A eligible if fully outsourced; otherwise SAQ A-EP or D
View Business tier →
Level 4
Under 20,000 transactions/year
SAQ A or SAQ A-EP, depending on e-commerce model
View Business tier →
Service Providers
All service providers that store, process, or transmit cardholder data must complete SAQ D for Service Providers — 329 requirements. Annual QSA review for Level 1. No SAQ option for service providers.
SAQ Self-Scoping — Which form do I actually need?
SAQ A
Card-not-present, fully outsourced — ~22 requirements
E-commerce or mail/telephone order merchants who fully outsource all cardholder data handling to a PCI DSS-compliant third party. Your own systems never touch card data. No scripts on your payment pages. Redirect or hosted fields only.
SAQ A-EP
~191 requirements
E-commerce merchants whose website delivers or influences the payment page — including any merchant-hosted JavaScript, iframes, or server-side scripts that interact with the payment flow.
SAQ B–C-VT
Terminal-based — 41–249 requirements
Merchants using standalone POS terminals, dial-up terminals, or virtual terminal payment applications. Limited electronic cardholder data storage.
SAQ D — Merchants
329 requirements
All merchants who don't qualify for another SAQ type. Self-hosted payment processing, direct PAN handling, or complex multi-channel environments.
SAQ D — Service Providers
All service providers
No other SAQ applies to service providers. QSA validation required for Level 1 service providers.
📋 Download our SAQ self-scoping worksheet to find your exact SAQ type →
Dentists → Law Firms → Restaurants → Hotels →
The 12 Requirements · 6 Control Objectives

The 12 PCI-DSS Requirements — Grouped by the 6 Control Objectives

Requirement 12.6 requires documented security awareness training for all personnel with access to the CDE. Below is the full requirement map your QSA will reference during your v4.0.1 assessment.

1
Build and Maintain a Secure Network and Systems
Req 1 — Firewall Configuration Standards
What it means:
You must install and maintain a firewall between the CDE and everything else. If it's not documented, it didn't happen.
Plain English:
Every system that touches card data must be behind a documented firewall. Personal devices, shadow IT, and unsegmented cloud instances fail this requirement on sight.
Req 2 — Default Credentials and Configurations
What it means:
No vendor defaults. No shared admin passwords. Every system in the CDE hardened before it goes live.
Plain English:
Change every default password before deployment. Document the hardening baseline. Your QSA will check for vendor default configurations during the first day of fieldwork.
Req 3 — Stored Cardholder Data Protection
What it means:
If you store PANs, cardholder names, or expiration dates, they must be encrypted at rest — and you must document the encryption algorithm, key management process, and key rotation schedule.
Plain English:
The PCI DSS rule: never store what you don't need. If you must store it, encrypt it with documented keys. PANs in plaintext spreadsheets on network drives fail this requirement and will show up in a forensic investigation.
Req 4 — Cardholder Data in Transit
What it means:
All data transmitted across public networks must use TLS 1.2 or higher. No cleartext HTTP for pages that receive or process card data.
Plain English:
If your payment page loads over HTTP or uses TLS 1.0/1.1, you're failing Requirement 4. Migrate to TLS 1.2 minimum — and document the migration.
2
Protect Account Data
Req 5 — Malware and E-Skimming Protection
What it means:
All systems must run current anti-virus software. Requirement 6.4.3 (mandatory since March 2025) specifically requires script inventory and integrity verification for all payment page scripts.
Plain English:
Magecart attacks work by injecting malicious JavaScript into your payment page — and it runs entirely in your customer's browser. The QSA will ask for your script inventory and change-detection mechanism. If you don't have one, you're out of compliance.
Req 6 — Vulnerability Management
What it means:
Patch management program with documented timelines. Critical patches within 30 days. Web-facing applications tested for vulnerabilities quarterly via ASV scan.
Plain English:
Your patch process needs a documented SLA. The QSA will ask for your vulnerability management policy and evidence that it was followed during the assessment period.
3
Maintain a Vulnerability Management Program
Req 7 — Access Control by Business Need to Know
What it means:
Only personnel with a documented business need can access cardholder data. Role-based access enforced, documented, and reviewed quarterly.
Plain English:
Every person with CDE access needs a documented justification. Offboarding procedures must revoke access within the timeframe specified in your own policy.
Req 8 — Authenticate Access
What it means:
MFA required for ALL access to the CDE (v4.0.1, mandatory March 2025). Minimum 12-character passwords. Automated revocation on termination.
Plain English:
MFA on every CDE account — not just admins. If your POS terminal access has no MFA, your QSA will note it.
Req 9 — Physical Access Controls
What it means:
Physical security controls for any location where cardholder data is stored or accessed. Visitor logs, badge access, camera coverage of CDE locations.
Plain English:
A data centre locked door isn't enough — the QSA checks visitor logs, badge access records, and whether physical access reviews were performed during the observation period.
4
Regularly Monitor and Test Networks
Req 10 — Log Monitoring and Incident Response
What it means:
Audit logs on all CDE systems, with automated review. Logging enabled, log retention for minimum 12 months, log review documented.
Plain English:
87% of breaches involve dwell time — the attacker is inside before detection. Audit logs are your only evidence of what happened and when. If your logs were turned off to save storage costs, that's a finding.
Req 11 — Network Testing and Security Scanning
What it means:
Quarterly ASV scans by an Approved Scanning Vendor. Annual penetration test. Change-detection monitoring on payment pages (Req 11.6.1, mandatory March 2025).
Plain English:
A passing ASV scan is your quarterly proof that your network perimeter is secure. The change-detection requirement (11.6.1) specifically covers payment page integrity — if you don't have it, you're non-compliant for e-commerce.
5
Maintain an Information Security Policy
Req 12 — Security Policy and Training
What it means:
Documented information security policy reviewed annually. Security awareness training for all personnel. Incident response plan tested annually. Third-party service provider documentation maintained.
Plain English:
This is where training compliance lives. Requirement 12.6 requires documented annual security awareness training for everyone with CDE access. Your attendance records are the primary evidence.
Real Threats

The threats that fail PCI-DSS assessments — and why training is the fix.

💳
E-skimming / Magecart Attacks
Malicious JavaScript injected into your payment page captures card numbers as customers type them. PCI DSS v4.0.1 Req 6.4.3 specifically targets this — script inventory and integrity verification became mandatory March 31, 2025. The average dwell time before detection is 204 days. Training your e-commerce team to recognise anomalous script behaviour is your first detection line — and Requirement 12.6 evidence.
🕸️
Weak or Missing Network Segmentation
Without proper segmentation, your entire corporate network is in scope for your PCI assessment. Reqs 11.4.5–11.4.7 require documented segmentation testing. If your CDE shares a network segment with your email server, HR system, or developer workstations, your QSA will include them in scope — dramatically increasing your compliance burden. Segmentation is the only way to reduce your CDE boundary. Without it, every system is a cardholder data system.
🔑
Default Credentials on CDE Systems
Requirement 2.1 specifically prohibits vendor-supplied defaults for all system passwords and security parameters. POS systems, payment terminals, and gateway integration accounts frequently ship with default credentials — and they are the first thing an attacker tries. Req 2.2.1 requires configuration standards for all system components. Default credentials found during fieldwork are an automatic fail — and they trigger forensic investigation into whether the system was accessed prior to the assessment.
📡
Unpatched POS Systems
Point-of-sale systems running outdated firmware and unpatched operating systems are the most common entry point for card-present breaches. Req 6.3.3 requires security patches installed within 30 days for critical vulnerabilities. POS terminals on the CDE network that haven't been patched in 12 months fail this requirement on sight. Staff who understand the 30-day patching SLA and know who to escalate to when a critical patch is announced are the difference between compliance and a breach that terminates your card-processing rights.
🤝
Third-Party Processor Compromise
Your payment processor's breach is your compliance event. PCI DSS Req 12.8 requires documentation of all third-party service provider relationships and their PCI compliance status — Attestation of Compliance on file, reviewed annually. If your processor's compliance lapses, you inherit the liability. Req 12.9.1 specifically requires a list of all third-party providers with their compliance documentation. Training your billing and operations teams to maintain the register — and to recognise when a processor's AoC has expired — prevents the most common gap found in assessments.
📋
SAQ Misclassification
Completing the wrong SAQ type is one of the most common PCI DSS compliance failures. SAQ A merchants who migrated to hosted fields without understanding v4.0.1's script susceptibility question may still require SAQ A-EP. Service providers completing merchant SAQs instead of SAQ D Service Providers are automatically out of scope. The QSA tests the accuracy of your scoping during fieldwork — an incorrect SAQ type means you were certifying controls that don't actually apply to your environment. Req 12.6 training covers SAQ type determination as Module 1.
PCI-DSS Scope

PCI-DSS Scope — What is actually in your CDE?

The Cardholder Data Environment (CDE) is the people, processes, and technology that store, process, or transmit cardholder data — and any system that connects to those systems.

In Scope
  • Any system that stores, processes, or transmits PANs, cardholder names, expiration dates, or service codes
  • Any system that connects to those systems — including jump servers, monitoring tools, and Active Directory that authenticates CDE access
  • Any device with access to the CDE network segment — including IT management workstations
  • Any mobile device, laptop, or remote access pathway that can reach CDE systems
NOT in Scope
  • Systems that only process loyalty points or gift card balances without PANs
  • Phone systems used for voice payments if card data is entered via a separate validated payment application
  • Corporate laptops that access the corporate network but never connect to a CDE network segment — if network segmentation is correctly implemented and documented
Network Segmentation — The Only Way to Reduce Scope
PCI DSS allows organisations to use network segmentation to reduce scope — isolating the CDE from the rest of the corporate network. Properly implemented segmentation means your corporate email server, HR system, and development tools can be out of scope. Requirements 11.4.5–11.4.7 govern segmentation testing. The QSA will test your segmentation during fieldwork — documentation of the segmentation architecture and the test results is your evidence.
Customized Approach vs. Defined Approach
PCI DSS v4.0.1 allows a Customized Approach for any requirement — instead of following the prescriptive control, you define an alternative control that meets the same objective and document a targeted risk analysis (Req 12.3.1). This is particularly useful for cloud-native architectures where the defined control doesn't map cleanly to your environment. Training your compliance team to write the risk analysis is part of the Req 12.6 evidence package.
🔗 Get our scope reduction guide + cardholder data flow map template →
📋 Free Download

Download the PCI-DSS SAQ Self-Scoping Worksheet + Cardholder Data Flow Map

Two documents your QSA will ask for:

📄
PCI-DSS SAQ Self-Scoping Worksheet
Step-by-step decision tree to determine your exact SAQ type — and the eligibility criteria for each. Covers SAQ A, A-EP, B, B-IP, C, C-VT, D Merchants, D Service Providers. Includes the v4.0.1 script eligibility question.
🗺️
Cardholder Data Flow Map Template
Network diagram template with labelled data flows. Shows where cardholder data enters, moves, and is stored — and where tokenization or P2PE breaks the PAN flow.
PCI-DSS v4.0.1 aligned QSA-ready format 2026 assessment year

No spam. One-click unsubscribe. From hello@secureveryone.com.

✓ Documents sent.

Check your inbox — and your spam folder.

Personal — $150 → Executive — $390 → Business — $900 flat →
How SecurEveryone solves this

PCI-DSS Requirement 12.6 training — live, documented, audit-ready.

Our 4-module live coaching curriculum takes you from SAQ type determination through to evidence package completion. Delivered by PCI-DSS-aware instructors who understand what QSAs actually check for. Individual attendance records for every participant.

PCI-DSS Training Track

Book the full 4-module track

All four modules covered in sequence — scoping, technical controls, incident response, evidence collection. Individual attendance records per module. SAQ gap report included.

✓ Individual attendance records per module
✓ SAQ type determination worksheet included
✓ Cardholder data flow map template included
✓ Evidence package structure for your QSA audit file
Book the full 4-module track →
Module 1
PCI-DSS Scoping and SAQ Self-Scoping
What it covers:
Merchant level determination, SAQ type selection (with v4.0.1 script eligibility), CDE boundary mapping, cardholder data flow inventory, segmentation architecture review.
Who it's for:
Compliance managers, CTOs, payment operations leads.
Evidence produced:
Scoping document, SAQ type decision log, cardholder data flow map draft.
Module 2
Network Segmentation Evidence and Technical Controls
What it covers:
Req 1 firewall documentation, Req 2 system hardening baselines, Req 11.4.5–11.4.7 segmentation testing evidence, ASV scan management, Req 6.4.3/11.6.1 payment page script inventory.
Who it's for:
IT directors, network engineers, compliance teams.
Evidence produced:
Segmentation test log, script inventory register, ASV scan results file.
Module 3
Incident Response per Requirement 12.10
What it covers:
Req 12.10 incident response plan structure, 72-hour early warning and 24-hour notification requirements, forensic evidence preservation, breach notification template review.
Who it's for:
IT directors, compliance managers, legal/operations leads.
Evidence produced:
Incident response plan draft, notification template set.
Module 4
Evidence Collection for QSA Assessment
What it covers:
SAQ completion walkthrough, AoC submission process, compensating controls documentation, ROC preparation for Level 1 merchants, evidence package structure and indexing.
Who it's for:
Compliance managers, internal audit leads, CISOs.
Evidence produced:
Completed evidence index, SAQ gap report, QSA interview prep notes.
What organisations like yours say

Testimonials

"
A dental practice received a phishing email that looked like it came from their payment processor — asking them to update their card-on-file storage credentials. Their front desk manager had been trained two weeks earlier on exactly this scenario. She flagged it to the compliance lead instead of clicking. We prevented a cardholder data exposure that would have triggered a PCI forensic investigation and potential loss of card-processing rights.
— Compliance Officer, Regional Dental Practice Group
"
A law firm handling real estate escrow was storing cardholder data for client payment processing — they didn't realise their practice management system was holding card-on-file for IOLTA billing. Their PCI scope was far larger than they assumed. After our scoping session, they restructured their payment flow, moved to a hosted payment gateway, and reduced their SAQ from D to A. The training was the trigger for a conversation that saved them from a QSA assessment at the wrong level.
— Operations Director, Mid-size Law Firm
"
A SaaS billing platform that handled recurring subscription payments was asked by an enterprise customer for their PCI DSS compliance documentation. They were in the middle of a SOC 2 assessment and assumed PCI would be handled separately. Our training helped them understand that their billing infrastructure was in CDE scope — and they structured their tokenization implementation correctly before their QSA review. They went from SAQ D to SAQ A with proper evidence in place.
— CTO, B2B SaaS Billing Platform
Pricing

Three tiers — one training obligation.

Every tier includes documented training evidence for your QSA assessment file. Module selection maps to your SAQ type.

Personal
$150
Single seat · One session
  • ✓ 60-minute personalised session
  • ✓ PCI-DSS Req 12.6 coverage
  • ✓ SAQ self-scoping fundamentals
  • ✓ Individual attendance record
Book Personal — $150 →
Executive — teams of 1–10
$390
Up to 10 seats · 90 minutes
  • ✓ 90-minute live group session
  • ✓ Modules 1–2: scoping + technical controls
  • ✓ SAQ type determination included
  • ✓ Cardholder data flow map template
Book Executive — $390 →
Business — unlimited users
$900
Unlimited seats · All 4 modules
  • ✓ All 4 modules — full curriculum
  • ✓ Unlimited participant attendance records
  • ✓ SAQ gap report per module
  • ✓ QSA evidence package structure
Book Business — $900 flat →
All sessions include individual attendance records for your QSA audit file. View full curriculum →
FAQ

Common questions about PCI-DSS v4.0.1 compliance.

What are the different SAQ types and which applies to me? ▼
PCI DSS defines eight SAQ types — SAQ A is the smallest scope (~22 requirements) for fully outsourced card-not-present merchants using server-side redirects; SAQ A-EP (~191 requirements) for e-commerce merchants whose websites influence the payment page via JavaScript or iframes; SAQ B through SAQ C-VT for terminal-based merchants using standalone POS or virtual terminals; and SAQ D for all other merchants (~329 requirements). Service providers have only one option: SAQ D Service Providers. Eligibility for SAQ A tightened under v4.0.1 — e-commerce merchants using hosted fields must confirm their payment page is not susceptible to scripts running in the payment page context. Download our SAQ self-scoping worksheet to determine your exact type.
What are merchant levels and how do they affect my compliance obligation? ▼
Merchant level is determined by annual Visa/Mastercard transaction volume. Level 1 (6M+ transactions/year) requires a full ROC with QSA assessment and annual penetration test. Level 2 (1M–6M/year) uses an SAQ but acquirers increasingly require QSA-validated attestations rather than self-attestation for Level 2 SAQ A. Level 3 (20,000–1M/year) and Level 4 (under 20,000/year) use the applicable SAQ type. Service providers are categorised separately — all service providers complete SAQ D Service Providers, with annual QSA review required for Level 1 service providers. Merchant level determines your validation form, not your training obligation — Requirement 12.6 applies to anyone with CDE access regardless of level.
When did PCI DSS v4.0.1 become the only active standard? ▼
PCI DSS v4.0 became the only active version on January 1, 2025 — v3.2.1 was retired December 31, 2024. All 51 requirements that were previously future-dated best practices under v4.0 became mandatory on March 31, 2025. This includes Requirements 6.4.3 (payment page script management), 11.6.1 (change-detection on payment pages), 8.3.6 (MFA for all CDE access, no exceptions), 8.3.10 (12-character minimum passwords), and 12.3.1 (targeted risk analysis for every requirement). Every assessment completed in 2026 is against v4.0.1. If your compliance documentation still references v3.2.1, your QSA will flag it as a finding.
What are ASV scans and when are they required? ▼
Approved Scanning Vendor (ASV) scans are quarterly external vulnerability scans of all public-facing IP addresses that face the internet and all systems in the CDE. The ASV must be registered with the payment card brands. ASV scans cover your internet perimeter, web-facing systems, and any system that hosts or connects to the CDE — out-of-scope systems connected to the CDE by VLAN are still in scope for ASV if they're reachable from the CDE. External and internal scans are separate requirements; both are required quarterly. High-risk vulnerabilities identified by the ASV must be resolved and rescanned within 30 days; critical vulnerabilities within 90 days. Req 11.6.1 (change-detection on payment pages) became mandatory March 31, 2025 — if you have e-commerce, this is now required in addition to ASV scans.
What is network segmentation testing and why does it matter? ▼
PCI DSS allows organisations to use network segmentation to reduce scope — isolating the CDE from the rest of the corporate network. Without segmentation, every system connected to the CDE network segment is in scope. Reqs 11.4.5–11.4.7 govern segmentation testing: testing is required at least annually and after significant infrastructure changes. The QSA tests segmentation by attempting to reach cardholder data from out-of-scope network segments — if they can, the segmentation has failed and those systems are added to scope. Properly documented and tested segmentation is the single most effective way to reduce your PCI DSS compliance burden. Documentation of the segmentation architecture and test results (date, methodology, outcome) are your QSA evidence artefacts.
Further reading
SOC 2 overlap ↗ For Dentists → For Law Firms → For Restaurants →

PCI-DSS compliance isn't a once-a-year event. It's a continuous programme.

PCI DSS v4.0.1 requires ongoing evidence — quarterly scans, annual penetration tests, quarterly access reviews, annual training completion, and continuous monitoring. Your QSA will assess whether controls were in place and operating throughout the observation period. The annual SAQ or ROC is the output of a 12-month programme, not the start of one.

Personal — $150 → Executive — $390 → Business — $900 flat → data-ga-event="book_cta_click" data-ga-cta-location="compliance-pci-dss">Book your PCI-DSS Business session — $900 flat → Book a free PCI-DSS scoping assessment →
← Compliance programmes For Dental Practices For Law Firms SOC 2