ISO 27001:2022 Annex A holds 93 controls in four themes — Organisational (37), People (8), Physical (14) and Technological (34). PCI DSS v4 has 12 requirements. This library lists them all, with deep guides for the controls auditors probe hardest: logging, monitoring and vulnerability scanning.
Two frameworks, two very different rulebooks. ISO 27001:2022’s Annex A is a catalogue of 93 controls you assess against your own risks — which ones apply, and why the others don’t, gets recorded in your Statement of Applicability. PCI DSS v4 is contractual: its 12 requirements apply as written to every system in scope for cardholder data, and nobody negotiates them.
The tables below list every ISO 27001:2022 Annex A control and every PCI DSS v4 requirement. Four rows link to full guides: A.8.15 Logging, A.8.16 Monitoring activities, PCI Requirement 10 and PCI Requirement 11.3. They’re the deep guides because they’re the controls that can’t be satisfied with a document — each one demands something running every day, and each one is where auditors spend disproportionate time.
They also pair across frameworks. A.8.15 and A.8.16 ask for the same operating capability as Requirement 10: logs collected, retained and actually reviewed. A.8.8 (management of technical vulnerabilities) asks for what Requirement 11.3 makes explicit: scanning, internally and externally, on a schedule. If you face both frameworks, that overlap is where one piece of work satisfies two auditors.
| Control | Title |
|---|---|
| A.5.1 | Policies for information security |
| A.5.2 | Information security roles and responsibilities |
| A.5.3 | Segregation of duties |
| A.5.4 | Management responsibilities |
| A.5.5 | Contact with authorities |
| A.5.6 | Contact with special interest groups |
| A.5.7 | Threat intelligence |
| A.5.8 | Information security in project management |
| A.5.9 | Inventory of information and other associated assets |
| A.5.10 | Acceptable use of information and other associated assets |
| A.5.11 | Return of assets |
| A.5.12 | Classification of information |
| A.5.13 | Labelling of information |
| A.5.14 | Information transfer |
| A.5.15 | Access control |
| A.5.16 | Identity management |
| A.5.17 | Authentication information |
| A.5.18 | Access rights |
| A.5.19 | Information security in supplier relationships |
| A.5.20 | Addressing information security within supplier agreements |
| A.5.21 | Managing information security in the ICT supply chain |
| A.5.22 | Monitoring, review and change management of supplier services |
| A.5.23 | Information security for use of cloud services |
| A.5.24 | Information security incident management planning and preparation |
| A.5.25 | Assessment and decision on information security events |
| A.5.26 | Response to information security incidents |
| A.5.27 | Learning from information security incidents |
| A.5.28 | Collection of evidence |
| A.5.29 | Information security during disruption |
| A.5.30 | ICT readiness for business continuity |
| A.5.31 | Legal, statutory, regulatory and contractual requirements |
| A.5.32 | Intellectual property rights |
| A.5.33 | Protection of records |
| A.5.34 | Privacy and protection of PII |
| A.5.35 | Independent review of information security |
| A.5.36 | Compliance with policies, rules and standards for information security |
| A.5.37 | Documented operating procedures |
| Control | Title |
|---|---|
| A.6.1 | Screening |
| A.6.2 | Terms and conditions of employment |
| A.6.3 | Information security awareness, education and training |
| A.6.4 | Disciplinary process |
| A.6.5 | Responsibilities after termination or change of employment |
| A.6.6 | Confidentiality or non-disclosure agreements |
| A.6.7 | Remote working |
| A.6.8 | Information security event reporting |
| Control | Title |
|---|---|
| A.7.1 | Physical security perimeters |
| A.7.2 | Physical entry |
| A.7.3 | Securing offices, rooms and facilities |
| A.7.4 | Physical security monitoring |
| A.7.5 | Protecting against physical and environmental threats |
| A.7.6 | Working in secure areas |
| A.7.7 | Clear desk and clear screen |
| A.7.8 | Equipment siting and protection |
| A.7.9 | Security of assets off-premises |
| A.7.10 | Storage media |
| A.7.11 | Supporting utilities |
| A.7.12 | Cabling security |
| A.7.13 | Equipment maintenance |
| A.7.14 | Secure disposal or re-use of equipment |
| Control | Title |
|---|---|
| A.8.1 | User endpoint devices |
| A.8.2 | Privileged access rights |
| A.8.3 | Information access restriction |
| A.8.4 | Access to source code |
| A.8.5 | Secure authentication |
| A.8.6 | Capacity management |
| A.8.7 | Protection against malware |
| A.8.8 | Management of technical vulnerabilities |
| A.8.9 | Configuration management |
| A.8.10 | Information deletion |
| A.8.11 | Data masking |
| A.8.12 | Data leakage prevention |
| A.8.13 | Information backup |
| A.8.14 | Redundancy of information processing facilities |
| A.8.15 | Logging |
| A.8.16 | Monitoring activities |
| A.8.17 | Clock synchronisation |
| A.8.18 | Use of privileged utility programs |
| A.8.19 | Installation of software on operational systems |
| A.8.20 | Networks security |
| A.8.21 | Security of network services |
| A.8.22 | Segregation of networks |
| A.8.23 | Web filtering |
| A.8.24 | Use of cryptography |
| A.8.25 | Secure development life cycle |
| A.8.26 | Application security requirements |
| A.8.27 | Secure system architecture and engineering principles |
| A.8.28 | Secure coding |
| A.8.29 | Security testing in development and acceptance |
| A.8.30 | Outsourced development |
| A.8.31 | Separation of development, test and production environments |
| A.8.32 | Change management |
| A.8.33 | Test information |
| A.8.34 | Protection of information systems during audit testing |
| 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 |
| 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 |
| 11.3 | Internal and external vulnerability scanning |
| 12 | Support information security with organisational policies and programs |
Requirement 11.3 gets its own row and its own guide because it behaves like a standalone obligation: internal scans quarterly and after significant changes, external scans quarterly by an Approved Scanning Vendor, and — since v4 — authenticated internal scanning using privileged credentials.
Treating Annex A as the standard. It isn’t — it’s the appendix.
The mandatory part of ISO 27001 is the management system in the standard’s body: scope, leadership, risk assessment, internal audit, management review. Annex A is the catalogue that your risk assessment draws from, and the Statement of Applicability is where the drawing happens. Teams that print the 93-row list and work through it top to bottom build controls nobody’s risk justified and skip the SoA reasoning the auditor actually reads. Start from your risks, land on your controls — the list above tells you what’s available, not what’s required.
Most Annex A controls are decisions and documents. The ones that link above are operations — logs don’t collect themselves and daily review means daily. We run that layer: log management covering A.8.15 and Requirement 10’s collection and retention, monitoring through our SIEM covering A.8.16 and the review obligations, and vulnerability scanning for Requirement 11.3 and A.8.8. Your auditor sees controls operating with evidence attached, not policies describing what would happen if they did.
How many controls does ISO 27001 have?
93, in the 2022 revision of Annex A, arranged in four themes: Organisational (37), People (8), Physical (14) and Technological (34). The 2013 edition had 114 controls in 14 domains; the 2022 restructure merged and renumbered them.
Do we have to implement every Annex A control?
No. You assess all 93 against your risks and record which apply — and why the excluded ones don’t — in your Statement of Applicability. The SoA, not the full list, defines what your auditor tests.
Which controls map between ISO 27001 and PCI DSS?
The clearest pairs: ISO’s A.8.15 Logging and A.8.16 Monitoring activities line up with PCI Requirement 10 on logging and monitoring access, and ISO’s A.8.8 on technical vulnerabilities lines up with PCI Requirement 11.3 on vulnerability scanning. Build the capability once, evidence it twice.
Is PCI DSS a certification like ISO 27001?
No. ISO 27001 gives you a certificate from an accredited certification body. PCI DSS is a contractual standard — compliance is validated through self-assessment questionnaires or an assessor, at a level set by your acquiring bank and transaction volume.
Why do only some controls in the tables link to guides?
The linked controls have full pages — what the standard says verbatim, what evidence an auditor asks for, and the equivalent control in the other framework. The rest are listed so you can see every control in context; the deep guides cover the ones that demand 24/7 operation.
