October 31, 2025 was a hard deadline. Every ISO 27001:2013 certification expired that day — no extensions, no grace periods. Organizations that hadn't completed their transition to ISO 27001:2022 had to start the certification process over from scratch. That means if you're working toward ISO 27001 now, you're working with the 2022 version. There's no other version to use.
The 2022 revision is meaningfully different. Annex A shrank from 114 controls across 14 domains to 93 controls across 4 themes. Eleven entirely new controls were added to address threats that simply didn't exist in 2013 — cloud security, threat intelligence, configuration management, data leakage prevention. And auditors in 2026 are examining evidence that controls reduce actual risk, not just evidence that policies exist on paper.
This is the complete ISO 27001 checklist for the current standard.
Part 1: The ISMS requirements (Clauses 4–10)
Before Annex A controls, ISO 27001 requires you to build an Information Security Management System — a documented, active management framework for identifying, treating, and monitoring information security risks. Clauses 4 through 10 define what that framework must contain. These are mandatory for every organization seeking certification.
Clause 4: Organizational context
- Identify internal and external issues that affect your organization's ability to achieve ISMS objectives
- Identify interested parties (regulators, customers, partners) and their information security requirements
- Define the scope of your ISMS — which assets, business units, and locations are included
- Document the ISMS scope and its boundaries in writing
Scope definition is where auditors probe hard. A scope that conveniently excludes your most complex or highest-risk systems will raise questions. Your scope must reflect where the real information security risks live, not where compliance is easiest to demonstrate.
Clause 5: Leadership
- Top management demonstrates commitment to the ISMS — not just delegation to IT
- Information security policy approved and signed by top management, communicated to the organization
- Roles and responsibilities for information security defined and assigned
- Policy addresses objectives, compliance obligations, and continual improvement
Clause 6: Planning
- Information security risk assessment process documented — methodology, criteria for acceptable risk, risk owner assignments
- Risks identified, analyzed, and evaluated against defined criteria
- Risk treatment plan: for each unacceptable risk, document the chosen treatment (mitigate, accept, transfer, avoid) and the controls that implement it
- Statement of Applicability (SoA) prepared: lists all 93 Annex A controls, applicability determination, implementation status, and justification for any excluded controls
- Information security objectives defined and measurable
The SoA is arguably the most scrutinized document in an ISO 27001 audit. It's your formal declaration of which controls you've implemented, which you haven't, and why. Every excluded control needs a documented justification — not "doesn't apply" but a specific reason tied to your risk assessment. Auditors cross-reference the SoA against your risk treatment plan and against evidence of actual implementation. Gaps between "implemented" in the SoA and reality in the field are the most common critical findings.
Clause 7: Support
- Competence: staff with information security responsibilities have the required skills, training records maintained
- Awareness: all personnel understand the information security policy, their contribution to ISMS effectiveness, and the consequences of non-conformity
- Communication: processes for internal and external information security communications defined
- Documented information: ISMS documentation controlled — creation, update, distribution, access, retention, and disposal
Clause 8: Operation
- Operational processes planned, implemented, and controlled
- Risk assessments performed at planned intervals and when significant changes occur
- Risk treatment plans implemented and documented
Clause 9: Performance evaluation
- Monitoring and measurement of ISMS performance against defined objectives — with documented results
- Internal audit conducted at planned intervals by qualified, independent auditors
- Management review performed — inputs include audit results, risk assessment status, incidents, and nonconformities; outputs include decisions on ISMS changes
Clause 10: Improvement
- Nonconformities documented with root cause analysis and corrective actions
- Corrective actions verified as effective
- Continual improvement of ISMS suitability, adequacy, and effectiveness demonstrated over time
Part 2: Annex A controls — the 93 requirements
Annex A is the control catalog. The 2022 standard organizes 93 controls into 4 themes. Not every control applies to every organization — that's what the SoA determines. But you need to actively justify exclusions, and exclusions that don't hold up under scrutiny will fail your audit.
Check your information security policies against ISO 27001
PolicyAudit scans your security policy documents against ISO 27001:2022 requirements — identifying missing controls, vague language, and gaps that would fail a Stage 1 or Stage 2 audit. Free for up to 3 documents, no credit card required.
Scan your policies for free →A.5 — Organizational controls (37 controls)
The largest category. These cover policies, legal obligations, information security roles, supplier management, and incident handling — the administrative backbone of your ISMS.
Key controls that auditors examine closely:
- A.5.1 — Policies for information security: A documented information security policy, approved by management, communicated and available to all staff. This isn't just the ISMS policy from Clause 5 — it's the full policy set covering all the topics addressed by your controls.
- A.5.7 — Threat intelligence (new in 2022): Your organization must collect, analyze, and act on information about threats relevant to your risk environment. This doesn't require a full threat intelligence program, but you need a process for staying current on relevant threats and using that information in risk assessments.
- A.5.19 through A.5.22 — Supplier management: Information security requirements in supplier agreements, monitoring supplier compliance, managing changes in supplier services. Given that most breaches now have a third-party component, auditors scrutinize supplier security practices and contractual controls.
- A.5.23 — Information security for use of cloud services (new in 2022): Policies and procedures for acquiring, using, managing, and exiting cloud services. If you use AWS, Azure, GCP, or any SaaS platform with significant data, you need documented cloud security requirements and a process for evaluating cloud providers.
- A.5.24 through A.5.28 — Incident management: Planning, detection, reporting, assessment, response, and learning from information security incidents. Auditors want to see incident records, response procedures, and evidence that lessons from incidents fed back into the ISMS.
A.6 — People controls (8 controls)
People are consistently where security programs fall down. These eight controls address the human side: screening, terms of employment, awareness, disciplinary processes, and what happens when someone leaves.
- A.6.1 — Screening: Background checks on employees and contractors before they get access to information systems — proportional to the sensitivity of the role.
- A.6.2 — Terms and conditions of employment: Employees' information security responsibilities stated in employment contracts. This is often present in policy form but not reflected in actual employment agreements — a common gap auditors find.
- A.6.3 — Information security awareness, education, and training: Regular security awareness training, with records. Annual training completion rates are a metric auditors often ask for.
- A.6.5 — Responsibilities after termination or change of employment: Information security responsibilities that survive employment — NDAs, confidentiality obligations, return of assets. Offboarding checklists documenting access revocation are expected evidence.
- A.6.8 — Information security event reporting (new in 2022): A mechanism for employees to report information security events through appropriate channels. Most organizations have this, but many haven't documented who the channel goes to or how quickly reports must be escalated.
A.7 — Physical controls (14 controls)
Physical security controls covering secure areas, equipment security, and physical access. For remote-first or cloud-only organizations, many A.7 controls may genuinely not apply — but you'll need to document that in your SoA and justify it against your risk assessment.
Key controls:
- A.7.1 — Physical security perimeters: Defined security perimeters for facilities containing information systems.
- A.7.4 — Physical security monitoring (new in 2022): Continuous monitoring of premises for unauthorized physical access — CCTV, access logs, visitor records. This is new in 2022 and requires organizations to actively monitor physical access, not just control it.
- A.7.8 — Equipment siting and protection: Equipment positioned to reduce risks from environmental threats and unauthorized access.
- A.7.14 — Secure disposal or re-use of equipment: Media sanitization procedures before equipment disposal or reuse. Organizations regularly fail on this — old laptops and drives with data on them, no documented sanitization process.
A.8 — Technological controls (34 controls)
The largest new section in the 2022 revision. Technological controls cover user endpoints, access management, cryptography, vulnerability management, and monitoring. Several of the new 2022 controls live here, and this is where auditors increasingly focus their evidence requests.
Controls that generate the most findings:
- A.8.2 — Privileged access rights: Privileged access managed separately from regular access, allocated on a need-to-use basis, reviewed regularly. Most organizations have privileged accounts — the question is whether they're inventoried, whether their allocation is justified, and whether they're reviewed. Shared admin passwords and undocumented privileged accounts are common failures.
- A.8.5 — Secure authentication: Authentication controls based on access restrictions and information classification policies. MFA for remote access is effectively mandatory at this point — auditors will ask.
- A.8.8 — Management of technical vulnerabilities: Vulnerability scanning, patch management, timely remediation. You need documented patching timelines (critical patches within X days), evidence of scans, and records of remediation. "We patch when we can" doesn't pass a Stage 2 audit.
- A.8.9 — Configuration management (new in 2022): Documented, implemented, monitored, and reviewed configurations for hardware, software, services, and networks. This control catches organizations with undocumented configurations — systems built without documented standards and never reviewed for drift.
- A.8.12 — Data leakage prevention (new in 2022): Measures applied to systems and networks that process sensitive information to prevent data leakage. This doesn't require commercial DLP software, but you need to document how you detect and prevent unauthorized data transfers.
- A.8.15 — Logging: Logs produced, stored, protected, and analyzed. Log retention periods documented. This is often partially implemented — logging exists, but retention is undefined or logs aren't protected from modification.
- A.8.16 — Monitoring activities (new in 2022): Networks, systems, and applications monitored and anomalies investigated. The 2022 standard makes active monitoring a standalone control, not just an implied part of logging.
- A.8.23 — Web filtering (new in 2022): Management of access to external websites to reduce exposure to malicious content. DNS filtering, web proxies, or browser policy controls are acceptable implementations.
- A.8.28 — Secure coding (new in 2022): Secure coding principles applied to software development. If you develop software, auditors will ask how these principles are enforced — code review processes, SAST tools, developer security training.
Certification bodies report that auditors in 2026 are shifting from "does a policy exist?" to "does the control reduce actual risk?" That means they're asking for metrics: time-to-patch data, access review completion rates, incident detection times, training completion percentages. A well-written policy with no evidence of implementation no longer passes a Stage 2 audit. Prepare data, not just documents.
The 11 new controls you need to have covered
If you're migrating from ISO 27001:2013 certification, these are the controls that likely don't have existing implementations. They need to be addressed in your SoA with either an implementation or a justified exclusion.
| Control | What it requires |
|---|---|
| A.5.7 Threat intelligence | Process to collect and act on relevant threat information |
| A.5.23 Cloud services security | Policies for acquiring, using, and exiting cloud services |
| A.5.30 ICT readiness for business continuity | ICT continuity based on business continuity objectives |
| A.6.7 Remote working | Security measures for remote workers accessing company systems |
| A.6.8 Information security event reporting | Documented mechanism for employees to report security events |
| A.7.4 Physical security monitoring | Continuous monitoring for unauthorized physical access |
| A.8.9 Configuration management | Documented and monitored configurations for all systems |
| A.8.10 Information deletion | Deletion of information stored on systems when no longer required |
| A.8.11 Data masking | Data masking applied according to access control and information classification policies |
| A.8.12 Data leakage prevention | Measures to detect and prevent unauthorized data transfers |
| A.8.16 Monitoring activities | Active monitoring of networks, systems, and applications |
| A.8.23 Web filtering | Controls on access to external websites |
| A.8.28 Secure coding | Secure coding principles in software development |
Where ISO 27001 programs commonly fail
Risk assessment not connected to controls
The ISMS framework requires that your control selection flows from your risk assessment — you identify a risk, you choose a treatment, you select controls to implement that treatment. In practice, many organizations implement controls first (because they seem like best practice) and then reverse-engineer a risk assessment to justify them. Auditors can spot this — the risk assessment looks generic, the controls aren't tied to specific risks, the SoA doesn't reference risk treatment outcomes.
Supplier agreements without security clauses
Controls A.5.19 through A.5.22 require supplier security requirements in contracts and active monitoring of supplier compliance. Most organizations have supplier agreements, but most of those agreements don't include specific information security requirements, access controls, or incident notification obligations. Adding security schedules to new agreements is straightforward; going back to existing suppliers is harder — but auditors will ask for evidence of both.
Metrics that don't measure control effectiveness
Clause 9.1 requires measurement of ISMS performance. A lot of organizations measure activity (how many policies reviewed, how many staff trained) rather than effectiveness (what percentage of critical vulnerabilities patched within SLA, what percentage of access reviews completed on time, what's the mean time to detect incidents). Activity metrics are easy to generate. Effectiveness metrics require the underlying processes to be working — which is the point.
Internal audits that don't find anything
An internal audit that produces no findings is almost always a sign of an ineffective audit, not a perfect ISMS. Auditors who run internal audits often know the people and systems well, which makes it uncomfortable to document findings. External certification auditors will find something — it's better to find it internally first. A nonconformity found internally and corrected before the Stage 2 audit is a sign of a healthy ISMS. A nonconformity found only during the certification audit is a problem.
Find your ISO 27001 policy gaps before the auditor does
PolicyAudit analyzes your information security policy documents against ISO 27001:2022 requirements — identifying missing controls, weak implementations, and sections that wouldn't satisfy a certification audit. It checks against ISO 27001 alongside 12 other frameworks simultaneously. Free tier available, no credit card required.
Check your policies for free →ISO 27001 certification: the process
Getting certified requires passing a two-stage audit with an accredited certification body:
- Stage 1 (documentation review): The auditor reviews your ISMS documentation — scope, risk assessment, risk treatment plan, SoA, policies, and procedures. They're confirming your ISMS is documented sufficiently to proceed to Stage 2. Stage 1 findings (typically "observations" or "minor nonconformities") must be addressed before Stage 2.
- Stage 2 (implementation audit): The auditor verifies that what's documented is actually implemented. They interview staff, review logs, examine configurations, test access controls, and check that evidence matches your SoA claims. Stage 2 produces the pass/fail determination for certification.
- Surveillance audits: Once certified, annual surveillance audits verify that your ISMS continues to operate effectively. These are shorter than the Stage 2 audit but still require current evidence.
- Recertification: Full recertification audit every 3 years — similar in scope to the original Stage 2.