Crossbearing · standards comparison

ISO/IEC 27001 to PCI DSS

What you can reuse, what to extend and what is new when you add PCI DSS to ISO/IEC 27001.

Compare another pair

I already have I want to add

Two standards overlaid: reuse, extend or write new.

What carries over from ISO/IEC 27001 to PCI DSS

Much of your ISMS helps, but PCI DSS is a different kind of standard. ISO/IEC 27001 lets your risk assessment choose the controls; PCI DSS sets them, with fixed detail and frequencies — 12-character passwords, MFA into the cardholder data environment, daily log review, quarterly scans by an Approved Scanning Vendor — all applied to a tightly defined scope. Your policies, access control, cryptography, incident response and supplier management carry over. The new work is scoping the CDE and meeting every requirement in a way an assessor can test.

Of the 63 clauses and controls PCI DSS asks for: 59 to extend and 4 new.

59 Extend Keep what you have and add the new standard’s content.
4 New Nothing you have covers it: new work.

Clause and control numbers checked against ISO/IEC 27001 and PCI DSS themselves; descriptions are MajorCyber™’s own words. Mapping by MajorCyber™, last checked 27 October 2026. Going the other way? PCI DSS to ISO/IEC 27001

Built on your device, with the documents you tick below. Nothing is uploaded.

Do I need to rewrite my policies?

Mostly not. Keep your information security policy and topic-specific policies, and check each against PCI DSS. Every principal requirement asks for its policies and procedures to be documented, current, in use and known, with roles assigned, and the security policy must be reviewed at least every 12 months. Add what’s missing — often card data retention, key management and acceptable use of end-user technologies — and say which parts apply to the CDE.

Controls: PCI DSS v4.0.1 requirements, against ISO/IEC 27001 Annex A

Each PCI DSS v4.0.1 requirement, with the ISO/IEC 27001 controls and clauses that support it. Each requirement has several sub-requirements; the notes give the detail that most often needs adding.

PCI DSS v4.0.1 requirements controls, with the ISO/IEC 27001 Annex A controls that support each
PCI DSS control	Supported by your ISO/IEC 27001	What to do
1. Network security controls
1.1 Network security policies, procedures and roles documented	5.1 Security policy set, approved and kept under review Partly covers it 5.37 Operating procedures documented Partly covers it 5.2 Security roles and responsibilities assigned Partly covers it Clause 7.5 Documented information Related	Extend Your policy set and roles carry over. PCI DSS wants the policies and procedures for network security controls documented, kept up to date, in use and known to everyone affected, with the roles for this requirement assigned and understood.
1.2 Firewalls and other network controls configured and maintained	8.20 Networks secured Partly covers it 8.9 Configurations managed Partly covers it 8.32 Changes controlled Related	Extend Your network security controls carry over. PCI DSS adds an approved configuration standard for every firewall and router in scope, an up-to-date network diagram and data-flow diagram, and a review of rule sets at least every six months.
1.3 Traffic into and out of the CDE restricted	8.22 Networks segregated Partly covers it 8.20 Networks secured Partly covers it	Extend Segregation carries over. PCI DSS wants traffic into and out of the CDE limited to what is necessary, and everything else explicitly denied.
1.4 Connections between trusted and untrusted networks controlled	8.20 Networks secured Partly covers it 8.22 Networks segregated Partly covers it 8.21 Network services secured Related	Extend Your network controls carry over. Put controls between untrusted networks and the CDE, stop direct public access to systems that store card data, and hide internal addresses.
1.5 Devices that reach both the internet and the CDE protected	8.1 User devices protected Partly covers it 6.7 Remote working secured Partly covers it	Extend Endpoint and remote-working controls carry over. Laptops that connect to both the internet and the CDE need security controls that users can’t switch off.
2. Secure configurations
2.1 Configuration policies, procedures and roles documented	5.1 Security policy set, approved and kept under review Partly covers it 5.37 Operating procedures documented Partly covers it 5.2 Security roles and responsibilities assigned Partly covers it Clause 7.5 Documented information Related	Extend Your policy set and roles carry over. PCI DSS wants the policies and procedures for secure configuration documented, kept up to date, in use and known to everyone affected, with the roles for this requirement assigned and understood.
2.2 System components hardened, with vendor defaults changed	8.9 Configurations managed Partly covers it 8.19 Software installation on live systems controlled Related	Extend Configuration management carries over. PCI DSS asks for configuration standards based on industry hardening guidance, vendor default accounts changed or removed, one primary function per server and only the services that are needed.
2.3 Wireless networks configured and managed securely	8.20 Networks secured Partly covers it 8.9 Configurations managed Related	Extend Your network controls carry over. Change wireless vendor defaults, including keys and passwords, for any wireless network connected to the CDE.
3. Stored account data
3.1 Data protection policies, procedures and roles documented	5.1 Security policy set, approved and kept under review Partly covers it 5.37 Operating procedures documented Partly covers it 5.2 Security roles and responsibilities assigned Partly covers it Clause 7.5 Documented information Related	Extend Your policy set and roles carry over. PCI DSS wants the policies and procedures for protecting stored account data documented, kept up to date, in use and known to everyone affected, with the roles for this requirement assigned and understood.
3.2 Account data kept to a minimum, with retention limits	8.10 Information deleted when no longer needed Partly covers it 5.33 Records protected Related 5.12 Information classified by sensitivity Related	Extend Deletion and records rules carry over. PCI DSS asks for retention limits on account data, and a check at least every three months that data past its retention period has been securely deleted.
3.3 Sensitive authentication data never kept after authorisation	8.10 Information deleted when no longer needed Related 5.12 Information classified by sensitivity Related	New Classification and deletion help, but this one is absolute: sensitive authentication data (full track data, card verification codes, PINs) must not be kept after authorisation, even encrypted.
3.4 Full card numbers masked on screen, copying restricted	8.11 Data masking Partly covers it 8.12 Data leakage prevented Partly covers it 8.3 Access to information restricted Related	Extend Masking carries over. Show no more than the first six and last four digits of a card number unless someone has a documented business need, and stop card numbers being copied with remote-access tools.
3.5 Stored card numbers made unreadable	8.24 Cryptography and key management Partly covers it 8.11 Data masking Related	Extend Cryptography carries over. Render stored card numbers unreadable with strong cryptography, keyed hashes, truncation or tokens, and use disk-level encryption only on removable media.
3.6 Keys that protect stored card data secured	8.24 Cryptography and key management Partly covers it	Extend Key management carries over. Keep key-encrypting keys separate from data-encrypting keys, in the fewest places, with access limited to the fewest custodians.
3.7 Key management across the whole key life cycle	8.24 Cryptography and key management Partly covers it	Extend Key management carries over. PCI DSS spells out each step: generation, distribution, storage, cryptoperiods, retirement, split knowledge and dual control for manual operations, and custodians’ written acknowledgement.
4. Data in transit
4.1 Transmission policies, procedures and roles documented	5.1 Security policy set, approved and kept under review Partly covers it 5.37 Operating procedures documented Partly covers it 5.2 Security roles and responsibilities assigned Partly covers it Clause 7.5 Documented information Related	Extend Your policy set and roles carry over. PCI DSS wants the policies and procedures for protecting data in transit documented, kept up to date, in use and known to everyone affected, with the roles for this requirement assigned and understood.
4.2 Card numbers sent over public networks strongly encrypted	8.24 Cryptography and key management Partly covers it 5.14 Rules for transferring information Partly covers it 8.21 Network services secured Related	Extend Cryptography and transfer rules carry over. Use strong cryptography and trusted, valid certificates wherever card numbers cross open, public networks, and keep an inventory of those keys and certificates.
5. Malicious software
5.1 Anti-malware policies, procedures and roles documented	5.1 Security policy set, approved and kept under review Partly covers it 5.37 Operating procedures documented Partly covers it 5.2 Security roles and responsibilities assigned Partly covers it Clause 7.5 Documented information Related	Extend Your policy set and roles carry over. PCI DSS wants the policies and procedures for protection from malware documented, kept up to date, in use and known to everyone affected, with the roles for this requirement assigned and understood.
5.2 Malware prevented, or detected and dealt with	8.7 Malware protection Partly covers it	Extend Malware protection carries over. Install anti-malware on every system at risk, and evaluate the ones you judge not at risk on a schedule set by a targeted risk analysis.
5.3 Anti-malware kept active, up to date and monitored	8.7 Malware protection Partly covers it	Extend Malware protection carries over. Keep it updated automatically, scanning or watching continuously, logging, and impossible for users to turn off without authorisation.
5.4 Users protected against phishing	8.7 Malware protection Partly covers it 6.3 Security awareness, education and training Related 8.23 Web filtering Related	Extend Awareness and filtering help. PCI DSS asks for technical anti-phishing mechanisms as well as training.
6. Secure systems and software
6.1 Secure development policies, procedures and roles documented	5.1 Security policy set, approved and kept under review Partly covers it 5.37 Operating procedures documented Partly covers it 5.2 Security roles and responsibilities assigned Partly covers it Clause 7.5 Documented information Related	Extend Your policy set and roles carry over. PCI DSS wants the policies and procedures for secure systems and software documented, kept up to date, in use and known to everyone affected, with the roles for this requirement assigned and understood.
6.2 Bespoke and custom software developed securely	8.25 Secure development life cycle Partly covers it 8.28 Secure coding Partly covers it 8.29 Security testing before release Partly covers it 8.27 Secure architecture and engineering principles Related 8.30 Outsourced development overseen Related Clause 7.2 Competence Related	Extend Your secure development life cycle carries over. PCI DSS asks for developer training at least every 12 months, a review of custom code before release, and techniques that stop common attacks.
6.3 Vulnerabilities found, ranked and patched	8.8 Technical vulnerabilities managed Partly covers it 5.7 Threat intelligence gathered and used Related 5.9 Inventory of information and assets, with owners Related	Extend Vulnerability management carries over. Rank new vulnerabilities by risk from industry sources, keep an inventory of bespoke software and its third-party components, and install critical patches within one month of release.
6.4 Public-facing web applications and payment pages protected	8.26 Security requirements for applications Partly covers it 8.8 Technical vulnerabilities managed Related 8.20 Networks secured Related	Extend Application security carries over. Put an automated solution such as a web application firewall in front of public-facing web applications, and authorise, inventory and check the integrity of every script on payment pages (6.4.3).
6.5 Changes to system components managed securely	8.32 Changes controlled Partly covers it 8.31 Development, test and live environments kept apart Partly covers it 8.33 Test data protected Partly covers it 5.3 Conflicting duties kept apart Related	Extend Change control and environment separation carry over. Never use live card numbers in test environments, and remove test data and accounts before systems go live.
7. Access by need to know
7.1 Access control policies, procedures and roles documented	5.1 Security policy set, approved and kept under review Partly covers it 5.37 Operating procedures documented Partly covers it 5.2 Security roles and responsibilities assigned Partly covers it Clause 7.5 Documented information Related	Extend Your policy set and roles carry over. PCI DSS wants the policies and procedures for restricting access documented, kept up to date, in use and known to everyone affected, with the roles for this requirement assigned and understood.
7.2 Access defined by role, least privilege and reviewed	5.15 Access control rules Partly covers it 5.18 Access rights granted, reviewed and removed Partly covers it 8.2 Privileged access restricted Partly covers it 8.3 Access to information restricted Related	Extend Access control carries over. Assign access by job role and least privilege, approve it, and review user accounts at least every six months.
7.3 Access enforced through access control systems	8.3 Access to information restricted Partly covers it 5.15 Access control rules Related	Extend Access control carries over. Enforce access through an access control system that denies everything not explicitly allowed.
8. Identification and authentication
8.1 Authentication policies, procedures and roles documented	5.1 Security policy set, approved and kept under review Partly covers it 5.37 Operating procedures documented Partly covers it 5.2 Security roles and responsibilities assigned Partly covers it Clause 7.5 Documented information Related	Extend Your policy set and roles carry over. PCI DSS wants the policies and procedures for identification and authentication documented, kept up to date, in use and known to everyone affected, with the roles for this requirement assigned and understood.
8.2 User IDs and accounts managed through their life cycle	5.16 Identities managed through their life cycle Partly covers it 5.18 Access rights granted, reviewed and removed Partly covers it 7.7 Clear desks and locked screens Related	Extend Identity management carries over. Give everyone a unique ID, allow shared accounts only by exception, remove leavers at once and inactive accounts within 90 days, and re-authenticate after 15 minutes idle.
8.3 Strong authentication for users and administrators	8.5 Secure authentication Partly covers it 5.17 Passwords and other secrets managed Partly covers it	Extend Authentication carries over. PCI DSS fixes the detail: passwords of at least 12 characters, lock-out after no more than 10 failed attempts, and changes every 90 days where a password is the only factor.
8.4 Multi-factor authentication for access into the CDE	8.5 Secure authentication Partly covers it 8.2 Privileged access restricted Related	Extend Secure authentication helps. Multi-factor authentication is required for all non-console access into the CDE and for all remote network access, not only where your risk assessment calls for it.
8.5 MFA systems set up so they can’t be bypassed or misused	8.5 Secure authentication Partly covers it	Extend Secure authentication helps. Configure MFA so it can’t be replayed or bypassed, uses at least two different types of factor, and grants access only when every factor succeeds.
8.6 System and application accounts and their secrets controlled	5.17 Passwords and other secrets managed Partly covers it 8.2 Privileged access restricted Related	Extend Secrets management carries over. Stop interactive logins to system and application accounts except by exception, keep their passwords out of scripts and files, and change them on a schedule set by a targeted risk analysis.
9. Physical access
9.1 Physical security policies, procedures and roles documented	5.1 Security policy set, approved and kept under review Partly covers it 5.37 Operating procedures documented Partly covers it 5.2 Security roles and responsibilities assigned Partly covers it Clause 7.5 Documented information Related	Extend Your policy set and roles carry over. PCI DSS wants the policies and procedures for physical access documented, kept up to date, in use and known to everyone affected, with the roles for this requirement assigned and understood.
9.2 Entry to facilities and systems with card data controlled	7.1 Secure perimeters Partly covers it 7.2 Entry controls Partly covers it 7.4 Premises monitored Partly covers it	Extend Physical controls carry over. Monitor individual access to sensitive areas with cameras or access control systems, keep the data for at least three months, and restrict network jacks and consoles.
9.3 Staff and visitor access authorised and managed	7.2 Entry controls Partly covers it 7.6 Rules for working in secure areas Related	Extend Entry controls carry over. Issue badges that tell staff from visitors, escort visitors, and keep a visitor log for at least three months.
9.4 Media with card data stored, moved and destroyed securely	7.10 Storage media handled securely Partly covers it 7.14 Equipment wiped before disposal or reuse Partly covers it 5.14 Rules for transferring information Related 8.13 Backups Related	Extend Media handling carries over. Classify media with card data, send it by secured courier, inventory electronic media at least every 12 months, and destroy it so it can’t be reconstructed.
9.5 Card-reading devices protected from tampering and swaps	7.8 Equipment sited and protected Partly covers it 7.9 Assets protected off site Related 6.3 Security awareness, education and training Related	Extend Equipment protection helps. Keep a list of card-reading devices, inspect them for tampering and substitution on a schedule set by a targeted risk analysis, and train staff to spot attacks on them.
10. Logging and monitoring
10.1 Logging policies, procedures and roles documented	5.1 Security policy set, approved and kept under review Partly covers it 5.37 Operating procedures documented Partly covers it 5.2 Security roles and responsibilities assigned Partly covers it Clause 7.5 Documented information Related	Extend Your policy set and roles carry over. PCI DSS wants the policies and procedures for logging and monitoring documented, kept up to date, in use and known to everyone affected, with the roles for this requirement assigned and understood.
10.2 Audit logs capture the events needed to spot and trace attacks	8.15 Logging Partly covers it	Extend Logging carries over. PCI DSS lists the events to log, including all individual access to card data, every action by administrators and changes to authentication, and the details each record needs.
10.3 Audit logs protected from change and deletion	8.15 Logging Partly covers it 5.33 Records protected Related	Extend Logging carries over. Restrict read access to logs, protect them from change, and back them up promptly to a central server that is hard to alter.
10.4 Audit logs reviewed for anomalies	8.16 Monitoring for anomalous behaviour Partly covers it 8.15 Logging Related	Extend Monitoring carries over. Review security events and the logs of critical systems at least daily, using automated mechanisms.
10.5 Log history kept and available for analysis	8.15 Logging Partly covers it 5.33 Records protected Related	Extend Logging carries over. Keep audit logs for at least 12 months, with the last three months immediately available.
10.6 Clocks synchronised across systems	8.17 Clocks synchronised Partly covers it	Extend Clock synchronisation carries over. Use time synchronisation technology, with time taken only from designated central sources and the time data protected.
10.7 Failures of critical security controls detected and handled	8.16 Monitoring for anomalous behaviour Partly covers it 5.25 Security events assessed and classified Related	Extend Monitoring carries over. Detect, alert on and promptly deal with failures of critical security controls such as firewalls, anti-malware, logging and change detection.
11. Security testing
11.1 Security testing policies, procedures and roles documented	5.1 Security policy set, approved and kept under review Partly covers it 5.37 Operating procedures documented Partly covers it 5.2 Security roles and responsibilities assigned Partly covers it Clause 7.5 Documented information Related	Extend Your policy set and roles carry over. PCI DSS wants the policies and procedures for security testing documented, kept up to date, in use and known to everyone affected, with the roles for this requirement assigned and understood.
11.2 Wireless access points found and rogue ones dealt with	8.20 Networks secured Related 8.16 Monitoring for anomalous behaviour Related	New Network monitoring helps. Look for authorised and unauthorised wireless access points at least every three months, and act on rogue ones.
11.3 Internal and external vulnerability scans, findings fixed	8.8 Technical vulnerabilities managed Partly covers it	Extend Vulnerability management carries over. Run internal scans every three months, authenticated, and external scans every three months by an Approved Scanning Vendor, rescanning until high-risk findings are fixed.
11.4 Internal and external penetration tests, findings fixed	8.8 Technical vulnerabilities managed Partly covers it 5.35 Independent review of security Related 8.29 Security testing before release Related	Extend Technical testing carries over. Follow a documented penetration testing method, test internally and externally at least every 12 months and after significant change, and test segmentation controls.
11.5 Intrusions and unexpected file changes detected	8.16 Monitoring for anomalous behaviour Partly covers it 8.19 Software installation on live systems controlled Related	Extend Monitoring carries over. Use intrusion detection or prevention at the CDE perimeter and critical points, and change detection on critical files at least weekly.
11.6 Unauthorised changes to payment pages detected	8.16 Monitoring for anomalous behaviour Related 8.32 Changes controlled Related	New Monitoring and change control help. Detect unauthorised changes to the scripts and security headers of payment pages as customers’ browsers receive them, at least weekly or as a targeted risk analysis sets.
12. Policies and programmes
12.1 Security policy known and current, with roles assigned	5.1 Security policy set, approved and kept under review Partly covers it 5.2 Security roles and responsibilities assigned Partly covers it Clause 5.2 Policy Partly covers it Clause 5.3 Roles Partly covers it	Extend Your policy set and roles carry over. Review the information security policy at least every 12 months, and give a named executive overall responsibility for information security.
12.2 Acceptable use rules for end-user technologies	5.10 Rules for acceptable use of information and assets Partly covers it	Extend Acceptable use rules carry over. Cover end-user technologies explicitly, including remote access and AI or other new tools, with approval for their use.
12.3 Risks to the CDE identified, evaluated and managed	Clause 6.1.2 Risk assessment Partly covers it Clause 8.2 Risk assessment in operation Related 8.24 Cryptography and key management Related 5.9 Inventory of information and assets, with owners Related	Extend Your risk process helps, but PCI DSS asks for something narrower: a targeted risk analysis for each requirement that lets you choose a frequency, plus reviews of cipher suites and of hardware and software at least every 12 months.
12.4 Compliance with PCI DSS managed by the executive	5.36 Compliance with security policies checked Partly covers it Clause 5.1 Leadership Related Clause 9.2 Internal audit Related	Extend Management commitment and compliance checks help. Service providers must give executive management responsibility for PCI DSS compliance and review, every three months, that people are doing the required tasks.
12.5 PCI DSS scope documented and confirmed	Clause 4.3 Scope Partly covers it 5.9 Inventory of information and assets, with owners Partly covers it	Extend Your ISMS scope and asset inventory help. Keep an inventory of in-scope system components, and confirm the CDE scope at least every 12 months and after significant change (every six months for service providers).
12.6 Ongoing security awareness training	6.3 Security awareness, education and training Partly covers it Clause 7.3 Awareness Partly covers it	Extend Awareness training carries over. Train people on hire and at least every 12 months, including on phishing and social engineering, and have them acknowledge the policy.
12.7 Staff screened before they join	6.1 Background checks before people join Partly covers it	Extend Screening carries over. Screen people who will have access to the CDE, within local law.
12.8 Risks from third-party service providers managed	5.19 Security in supplier relationships Partly covers it 5.20 Security terms in supplier contracts Partly covers it 5.22 Supplier services monitored and reviewed Partly covers it 5.21 Security across the ICT supply chain Related	Extend Supplier management carries over. Keep a list of service providers, get written agreements in which they acknowledge responsibility for the card data they handle, check their PCI DSS status at least every 12 months, and record who manages which requirements.
12.9 Service providers support their customers’ compliance	5.20 Security terms in supplier contracts Related	New Supplier contracts help. As a service provider, acknowledge in writing your responsibility for customers’ card data, and give them your PCI DSS status and responsibility split when they ask.
12.10 Suspected and confirmed incidents responded to at once	5.24 Incident management planned and prepared Partly covers it 5.26 Incidents responded to by procedure Partly covers it 5.25 Security events assessed and classified Partly covers it 5.27 Lessons from incidents applied Related 5.28 Evidence collected and preserved Related	Extend Incident management carries over. Add the payment brands’ and acquirers’ notification rules to the plan, test it at least every 12 months, have people available around the clock, and respond when card numbers turn up where they shouldn’t.

A route from ISO/IEC 27001 to PCI DSS

01
What applies
- Ask your acquirer (or, as a service provider, the payment brands) for your level and how you must validate
- If you qualify for a Self-Assessment Questionnaire, work out which one
02
Scope the CDE
- Find everywhere account data is stored, processed or transmitted, and everything connected to it
- Use segmentation to shrink the scope, and plan to test it
- Document the scope and the in-scope inventory
03
Gap assessment
- Go through the 12 requirements against your Annex A controls, using this mapping
- Check each fixed frequency and technical detail, not just the topic
04
Close the gaps
- Typical work: MFA into the CDE, payment page script controls, authenticated internal scans, quarterly ASV scans, daily log review, key management
- Write a targeted risk analysis wherever PCI DSS lets you set a frequency
05
Validate
- Report on Compliance by a Qualified Security Assessor, or a Self-Assessment Questionnaire
- Send the Attestation of Compliance to your acquirer, and keep the controls running all year

Certification and audits

PCI DSS has no certificate. Compliance is validated each year with a Report on Compliance by a Qualified Security Assessor (or an Internal Security Assessor, where allowed) or a Self-Assessment Questionnaire, each with an Attestation of Compliance. The payment brands and your acquirer decide which you need.
An ISO/IEC 27001 certificate doesn’t replace PCI DSS validation: each requirement is tested on its own terms. ISMS records can still serve as evidence where they show the detail tested.
Where external vulnerability scans are required, an Approved Scanning Vendor must run them.

Common pitfalls

Assuming your ISO/IEC 27001 certificate covers card data. The ISMS scope may not include the CDE, and even where it does, PCI DSS tests set requirements, not a risk-based selection.
Under-scoping: missing systems that connect to the CDE or could affect its security, or relying on segmentation that hasn’t been tested.
Letting your risk assessment set frequencies PCI DSS fixes. Where PCI DSS does allow a choice, it needs a documented targeted risk analysis.
Missing the requirements that became mandatory on 31 March 2025, such as payment page script controls (6.4.3 and 11.6.1) and MFA for all access into the CDE (8.4.2).

ISO/IEC 27001 and PCI DSS at a glance

ISO/IEC 27001 and PCI DSS side by side
Fact	ISO/IEC 27001	PCI DSS
What it is	Certifiable standard	Industry standard
How it applies	Voluntary, often required by customers	Required by contract or programme rules
How you show it	Certification by an accredited certification body	Assessed under the scheme’s own rules
Where	International	International
Covers	Information security, Risk management, Audit & assurance	Information security, Audit & assurance, Application security
Issued or enforced by	ISO and IEC (joint technical committee ISO/IEC JTC 1/SC 27)	PCI Security Standards Council (PCI SSC); compliance programmes enforced by payment brands and acquirers
Current edition or status	ISO/IEC 27001:2022, amended by ISO/IEC 27001:2022/Amd 1:2024 (climate change considerations). The 2013 edition's certification transition has ended.	PCI DSS v4.0.1 (June 2024) is the active version. Requirements that were future-dated in v4.0 became mandatory on 31 March 2025.

Next steps on MajorCyber™

Sources

PCI DSS (standard overview) — PCI Security Standards Council
PCI SSC Document Library (PCI DSS v4.0.1) — PCI Security Standards Council
ISO/IEC 27001:2022 — Information security management systems — Requirements — International Organization for Standardization (ISO)

Open questions

We found no mapping between PCI DSS and ISO/IEC 27001 from the PCI SSC, so these links are MajorCyber™’s analysis, made at the level of PCI DSS’s 63 second-level requirements. The sub-requirements under each one can go further than the notes say: the standard itself is the authority.
The appendices (A1 for multi-tenant service providers, A2 for early TLS on POS POI terminals, A3 for designated entities) aren’t mapped here.

The whole comparison in one PDF, with the documents you ticked.

An educational comparison, researched and drafted with AI assistance. A mapping shows where work you have already done supports a requirement; it never means the requirement is met. Your certification body decides what conforms. No standard’s text is reproduced: buy the standards from ISO or your national standards body.