PCI DSS, and the cardholder data nobody meant to keep.
The Payment Card Industry Data Security Standard protects cardholder data across merchants, service providers and payment processors. Whether you are Level 1 or Level 4, the twelve requirements apply and the evidence has to exist. We scope the cardholder data environment, find the copies of it nobody intended, and tell you what has to change.
What is PCI DSS?
A set of security standards ensuring that every company which accepts, processes, stores or transmits credit card information maintains a secure environment. It is managed by the PCI Security Standards Council, founded by the major card brands. Version 4.0 became mandatory on 31 March 2024, introducing a customised implementation approach, expanded multi-factor authentication and new protections against payment page skimming.
- Force Contractual, not statutory Enforced by the payment brands and your acquiring bank rather than by a regulator. The consequence arrives through the merchant agreement.
- Cadence Continuous, not annual Annual assessment, quarterly scans and ongoing controls. Compliance is a state, and it lapses quietly between validations.
- Alongside SOC 2 and ISO 27001 Substantial control overlap, which means shared evidence if the programmes are scoped together and duplicated work if they are not.
Who needs to comply?
Six populations, and the volume threshold that people expect to exempt them does not exist. A merchant taking one card payment a year is in scope; the level only changes how compliance is validated.
- Merchants Any organisation accepting payment cards, at every transaction volume.
- Service providers Entities processing, storing or transmitting cardholder data on behalf of others.
- Payment processors Third parties processing card transactions as their core business.
- Payment gateways E-commerce platforms that handle card data in the checkout path.
- Hosting providers Infrastructure hosting systems inside a customer's cardholder data environment.
- Payment application vendors Software vendors shipping validated payment applications under PCI SSF.
The question worth asking early is not whether you are in scope but how much of your estate is. Scope is the whole argument: every system that touches cardholder data pulls itself and everything connected to it into the assessment, and the cheapest control on this page is a segmentation decision made before the data spreads.
How iDharma supports PCI DSS compliance
Six workstreams across the twelve requirements. The first one is where the money is: an assessment scoped against a cardholder data environment nobody has mapped is an assessment of the wrong thing.
Cardholder data inventory
Where cardholder data actually flows: primary account numbers, sensitive authentication data and service codes traced to their storage locations, transmission paths and retention. Including the copies in analytics tables, model training sets, prompts and inference logs.
Network segmentation documentation
The cardholder data environment boundary drawn and defended: network diagrams, firewall rules and the segmentation evidence that decides how much of your estate the assessor has to look at.
Access control and authentication
Role-based access to CDE systems, unique identifiers, and multi-factor authentication deployed across every access path v4.0 now reaches — administrative, remote and console alike.
Vulnerability management lifecycle
Patch management, anti-malware coverage and secure development practice, with scan results and remediation timelines held as evidence rather than reconstructed at assessment time.
Logging and monitoring evidence
Audit log retention, the review schedule and who performs it, intrusion detection configuration, file integrity monitoring and the penetration testing cadence.
Policy set and incident response
The full policy suite with version control and approval, plus the incident response plan, the awareness training and the annual risk assessment behind it.
Every activity is dated, owned and evidenced. That trail is what demonstrates continuous compliance rather than a point-in-time document set — which matters here more than under most regimes, because PCI DSS is validated annually and required daily.
Complete PCI DSS requirements coverage
The assessment tests all twelve requirements across the six security goals, and the sub-controls beneath them. Nothing in scope is left to a follow-up engagement.
- Network security Firewalls, secure configurations and the segmentation that defines the boundary.
- 8 of 8 by the assessment
- Cardholder data Storage minimisation, masking, encryption in transit and secure disposal.
- 6 of 6 by the assessment
- Vulnerability management Patching, anti-malware and secure development practice.
- 6 of 6 by the assessment
- Access control Authentication, authorisation and physical access to systems and media.
- 7 of 7 by the assessment
- Monitoring and testing Logging, log review, scanning, penetration testing and incident response.
- 5 of 5 by the assessment
- Policy and programme The information security policy, the risk assessment and the awareness programme.
- 3 of 3 by the assessment
Scoped for payment security compliance
Cardholder data mapping
CHD flows and CDE boundaries traced from the systems inwards, not from the questionnaire outwards.
ASV scan cadence
The quarterly external scan schedule, who owns it, and what happens to a finding between scans.
ROC and SAQ readiness
The evidence pack a QSA will ask for, assembled before the assessment rather than during it.
Multi-framework mapping
A crosswalk to SOC 2, ISO 27001 and NIST CSF, so one evidence set answers more than one auditor.
The 12 PCI DSS requirements
Organised under six security goals. The chip on each card names the goal it belongs to, so the six families above and the twelve requirements here read against each other.
1. Install and maintain network security controls
Firewalls and routers configured to protect the cardholder data environment, with the rule set reviewed rather than inherited.
2. Apply secure configurations to all system components
Vendor defaults changed, unnecessary services disabled, and a hardening standard that someone can be shown to follow.
3. Protect stored cardholder data
Storage minimised, the primary account number masked where displayed, encryption applied where it is kept, and the retention period enforced.
4. Protect cardholder data in transmission
Strong cryptography over open, public networks, including the internal paths people forget are open.
5. Protect all systems from malicious software
Anti-malware deployed, maintained and actually reporting, on the systems the standard reaches.
6. Develop and maintain secure systems and software
Security patches applied on a defined timeline, and secure development practice evidenced rather than asserted.
7. Restrict access to system components and cardholder data
Need-to-know access with role-based controls, and a review that removes the access nobody needs any more.
8. Identify users and authenticate access
Unique identifiers per person and multi-factor authentication, which under v4.0 now reaches all access to the CDE.
9. Restrict physical access to cardholder data
Physical security for systems and media, including the disposal path for anything that ever held card data.
10. Log and monitor all access
Audit trails across every access to system components and cardholder data, with a log review that a person performs and records.
11. Test security of systems and networks regularly
Vulnerability scanning on cadence and penetration testing with the scope and findings retained.
12. Support information security with policies and programmes
The security policy, the annual risk assessment, awareness training and an incident response plan that has been rehearsed.
PCI DSS v4.0 key changes
The major updates from v3.2.1, effective 31 March 2024. The first of the four is the one that changes how an assessment is argued.
Customised implementation
A targeted risk analysis replaces one-size-fits-all control frequency.
- Risk analysis sets control frequency
- Flexibility in how a requirement is met
- The analysis itself becomes evidence
Authentication enhancements
Multi-factor authentication expanded to all access to the CDE.
- MFA for administrative access
- MFA for remote and console access
- Phishing-resistant MFA encouraged
E-commerce and skimming
New duties around unauthorised code on payment pages.
- Detect and respond to unauthorised script
- Change detection on payment forms
- Protection against skimming attacks
Roles and responsibilities
Explicit documentation of who owns what.
- PCI DSS roles documented
- Accountability assigned per requirement
- Executive sponsorship recorded
v3.2.1 retired on 31 March 2024 and every entity validates against v4.0. A number of requirements carried future effective dates running to 31 March 2025 and were best practice until then — worth checking which of those your last assessment treated as optional.
Merchant compliance levels
The requirements do not change with volume; how you validate them does. The level is set by annual transaction count and by the card brand, not by you.
6M+ transactions a year
The heaviest validation path, and the highest exposure if it lapses.
- Annual on-site assessment by a QSA
- Or an internal auditor, if an officer signs
- Quarterly network scans by an ASV
- Report on Compliance and Attestation
- Risk: the top of the fine range
1M to 6M transactions a year
Self-assessment, with an on-site audit possible depending on the brand.
- Annual Self-Assessment Questionnaire
- Quarterly network scans by an ASV
- Attestation of Compliance
- On-site audit at the brand's discretion
- Risk: substantial fines and fee increases
20K to 1M e-commerce transactions
E-commerce volume is what puts you here, not total card volume.
- Annual Self-Assessment Questionnaire
- Quarterly network scans by an ASV
- Attestation of Compliance
- Risk: fines and reputational damage
Under 20K e-commerce, or 1M total
The lightest validation, and the one most often skipped entirely.
- Annual Self-Assessment Questionnaire
- Quarterly ASV scans where applicable
- Validation may vary by acquirer
- Risk: suspension of card processing
24-week implementation roadmap
A practical path to PCI DSS compliance with clear milestones. The weeks are indicative — the variable is how much of the cardholder data environment turns out to exist once you go looking.
-
Weeks 1-4
Scoping and discovery
The phase that decides the cost of every phase after it.
- Find every location holding or moving cardholder data
- Map the network and define the CDE boundary
- Inventory systems, applications and third-party connections
- Determine the compliance level and assessment type
-
Weeks 5-10
Gap assessment
Current state against all twelve requirements, honestly.
- Evaluate against each of the twelve requirements
- Identify non-compliant controls and missing evidence
- Prioritise remediation by risk and assessment date
- Build a remediation plan with named owners
-
Weeks 11-20
Remediation and testing
Where the findings stop being a list and start being work.
- Implement missing controls: MFA, encryption, logging
- Deploy network segmentation and access controls
- Complete the policy set and awareness training
- Run internal vulnerability scans and penetration tests
-
Weeks 21-24
Validation and attestation
The part that produces the document your acquirer wants.
- Engage a QSA or complete the SAQ for your level
- Execute the quarterly ASV network scan
- Produce the Report on Compliance or SAQ submission
- Submit the Attestation of Compliance to the acquirer
Non-compliance carries severe financial consequences
Card brands and acquiring banks enforce PCI DSS through contractual penalties. They escalate with merchant level and with how long the position persists, and a breach adds investigation, notification and legal costs on top.
$5,000 to $100,000 a month
Levied by the card brands for non-compliance or after a breach, rising with merchant level and with duration, and continuing until compliance is restored.
$0.01 to $0.10 per transaction
Acquirers may impose a fee increase on a non-compliant merchant. Across thousands of transactions a month it is a permanent margin cost, not a one-off penalty.
Termination of card acceptance
An acquiring bank may end the merchant agreement outright. Reinstatement means full validation and finding a new acquirer, which a compliance history makes harder.
$200 to $500 per compromised record
Forensics, notification, legal fees, card reissuance and fraud losses, before the class actions and the regulatory penalties that follow a breach.
Complete PCI DSS policy repository
Ready-to-use payment security policy templates aligned to PCI DSS v4.0, and mapped across to SOC 2 and ISO 27001 so one document set answers more than one auditor.
Network security
- Firewall Configuration Policy
- Network Segmentation Policy
- Wireless Security Policy
- System Hardening Standards
- Configuration Management
- Change Control Policy
+ 3 more policies
Data protection
- Cardholder Data Policy
- Encryption Standards
- Key Management Policy
- Data Retention Policy
- Secure Disposal Procedures
- Tokenisation Guidelines
+ 4 more policies
Access and monitoring
- Access Control Policy
- Multi-Factor Authentication Standard
- Password Policy
- Logging and Monitoring Policy
- Incident Response Plan
- Vulnerability Management Policy
+ 5 more policies
Frequently asked questions
Scope, the version change, the validation route for your level, and the two questions that decide how expensive this gets.
Who is PCI DSS mandatory for?
Every organisation that stores, processes or transmits cardholder data, regardless of size or transaction volume. That covers merchants, service providers, payment processors and anyone handling payment card information. It is enforced through contracts with acquiring banks and the card brands rather than by statute, which changes who comes after you but not whether it applies.
What is the cardholder data environment?
The subset of your IT environment that stores, processes or transmits cardholder data or sensitive authentication data, including the people, processes and technology that interact with it. Scoping it tightly is the single biggest lever on assessment effort: network segmentation isolates the CDE from everything else and keeps the rest of your estate out of the assessment.
What changed between v3.2.1 and v4.0?
v4.0 introduced a customised implementation approach, expanded multi-factor authentication, new e-commerce skimming protections and explicit documentation of roles. The change with the widest effect is targeted risk analysis: an organisation can now define control frequency against its own risk profile, which means the analysis becomes evidence in its own right. v3.2.1 retired on 31 March 2024.
How does PCI DSS relate to SOC 2 and ISO 27001?
PCI DSS is payment-specific and contractually required; SOC 2 and ISO 27001 are broader information security frameworks. Many organisations run all three, and the control overlap is substantial enough that evidence can be shared if the programmes are scoped together. Scoped separately, you will collect the same evidence three times.
What is the difference between an SAQ and a ROC?
A Self-Assessment Questionnaire is a validation tool for smaller merchants, typically Levels 2 to 4, to self-report compliance. A Report on Compliance is a detailed assessment document produced by a Qualified Security Assessor for Level 1 merchants, or for anyone choosing external validation, and involves evidence review, interviews and technical testing. Both end in an Attestation of Compliance submitted to the acquiring bank.
How often do we validate?
Annually, at every level, plus quarterly network scans by an Approved Scanning Vendor. Level 1 needs an annual on-site assessment; Levels 2 to 4 complete an annual SAQ. Between validations the work is continuous — log reviews, vulnerability management, access reviews and policy updates. Compliance is a state rather than an event, and the gap between the two is where most findings come from.
How long does implementation take?
Three to six months for initial compliance, depending on current security maturity, CDE complexity and merchant level. A Level 1 merchant needing significant remediation can take six to twelve months. Scoping and gap assessment in the first four to six weeks is what actually determines the timeline, because it determines how much there is to fix.
Do we need to comply if we use a payment processor?
It depends on the integration. A fully outsourced solution — a hosted payment page, or a redirect to the processor — where cardholder data never touches your systems puts you on the simplest questionnaire. If the data flows through your systems at all, even briefly, your obligations are broader. Tokenisation and point-to-point encryption reduce scope; they do not remove it.
What does v4.0 require for multi-factor authentication?
MFA for all access to the cardholder data environment — administrative, remote and console alike. It has to use at least two independent factors from knowledge, possession and inherence, and phishing-resistant methods are encouraged. Single sign-on on its own does not satisfy the requirement unless a second factor sits behind it.
How does PCI DSS apply in the cloud?
Every requirement still applies; who satisfies it depends on the service model. On infrastructure services you hold most of the controls, on platform services responsibility is shared, and on software services the provider holds the infrastructure. A provider attestation does not transfer your obligations for access management, encryption and logging — document the responsibility split explicitly, because an assessor will ask for it.
Where does AI touch PCI DSS scope?
In three places that routinely get missed. Cardholder data copied into a training set or a feature store is stored cardholder data. A model prompt containing a primary account number is cardholder data in transmission. And inference logs retained for debugging are a copy of both. Any of the three pulls the system holding it into the CDE, which is why the data inventory is the first workstream on this page rather than a later one.
What does an iDharma PCI DSS assessment cover, and how long does it take?
It is scoped before you are charged. The variables are your merchant level, how well the cardholder data environment is already understood, and whether card data has reached analytics or model pipelines. We tell you the shape of all three after a short scoping call.
Ready to achieve PCI DSS compliance?
Start with a scoping and gap assessment against all twelve requirements — the cardholder data environment as it actually is, the evidence you already hold, and what has to be built before validation.
This page is guidance on how we scope an assessment, not legal advice. The standard and its supporting documents are published in full by the PCI Security Standards Council; where a scoping call turns on the wording, go to them rather than to this page.