Compliance · March 2026

ISO 27001 Requirements: Every Clause, Control, and Document You Actually Need

A practitioner’s breakdown of every mandatory ISO 27001 requirement—clauses 4 through 10, Annex A control categories, documentation you must produce, the Statement of Applicability, and how the risk assessment methodology ties it all together.

💫 Key Takeaways

• ISO 27001 has 7 mandatory clauses (4–10) that every organization must satisfy—no exceptions, no tailoring
• Annex A contains 93 controls across 4 categories (Organizational, People, Physical, Technological) in the 2022 revision
• The Statement of Applicability (SoA) is the single most important document in your ISMS—it links risk treatment to specific controls
• You need roughly 20–25 documented policies and procedures to pass a Stage 2 certification audit
• Risk assessment methodology must be defined before you assess anything—and it must be repeatable and consistent

ISO/IEC 27001 is the international standard for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS). Published by the International Organization for Standardization and the International Electrotechnical Commission, the current version is ISO/IEC 27001:2022.

Unlike frameworks that provide recommended practices (NIST CSF, CIS Controls), ISO 27001 is a certifiable standard. An accredited certification body audits your ISMS against the standard’s requirements. If you pass, you receive a certificate valid for three years, with annual surveillance audits in between.

The requirements matter because they are non-negotiable. Clauses 4 through 10 use the word “shall”—which in standards language means mandatory. You cannot claim conformity while skipping any of them. The Annex A controls, on the other hand, are a reference set: you choose which ones apply based on your risk assessment, but you must justify every exclusion in your Statement of Applicability.

These seven clauses form the backbone of every ISO 27001 implementation. Each one builds on the previous. Skip or half-do any of them, and your certification auditor will issue a nonconformity. Here is exactly what each clause demands.

Clause 4: Context of the Organization

Before you build anything, the standard requires you to understand your operating environment. This is not a philosophical exercise. It has four specific sub-requirements:

• 4.1 – Understanding the organization and its context. Identify external and internal issues relevant to your ISMS. External issues include regulatory requirements, market conditions, and threat landscape. Internal issues include organizational structure, culture, existing policies, and technical capabilities.
• 4.2 – Understanding the needs and expectations of interested parties. List your stakeholders (customers, regulators, employees, partners, shareholders) and document what each one expects from your information security program. A SaaS company’s customers might require SOC 2 reports; a bank’s regulator might mandate specific data residency rules.
• 4.3 – Determining the scope of the ISMS. Define exactly what your ISMS covers—which business units, locations, systems, and information assets are in scope. This is critical. Scope it too broadly and you’ll drown in controls. Scope it too narrowly and customers won’t trust the certificate.
• 4.4 – Information security management system. Establish, implement, maintain, and continually improve the ISMS. This is the overarching “you must actually build and run this thing” requirement.

Clause 5: Leadership

ISO 27001 makes it explicit: leadership cannot delegate security and walk away. The standard requires top management to be actively involved.

• 5.1 – Leadership and commitment. Top management must demonstrate commitment by ensuring the information security policy and objectives are established, integrating ISMS requirements into business processes, ensuring resources are available, and communicating the importance of information security.
• 5.2 – Policy. Establish an information security policy that is appropriate to your organization’s purpose, includes commitments to satisfy applicable requirements, and includes a commitment to continual improvement. The policy must be documented, communicated, and available to interested parties.
• 5.3 – Organizational roles, responsibilities and authorities. Assign and communicate responsibilities for ensuring the ISMS conforms to the standard and for reporting on ISMS performance to top management. In practice, this means naming who owns the ISMS—often the CISO or a virtual CISO.

Clause 6: Planning

This is where the standard introduces risk management as the engine that drives everything else. Clause 6 is dense, and auditors spend significant time here.

• 6.1.1 – General. When planning for the ISMS, consider the issues from Clause 4.1 and the requirements from Clause 4.2 to determine risks and opportunities that need to be addressed.
• 6.1.2 – Information security risk assessment. Define and apply a risk assessment process. You must establish risk criteria (acceptance criteria, criteria for performing assessments), identify information security risks (applying the process to identify risks associated with the loss of confidentiality, integrity, and availability), analyze those risks (assess consequences and likelihood, determine risk levels), and evaluate them against your criteria.
• 6.1.3 – Information security risk treatment. Define the risk treatment process. Select appropriate treatment options (mitigate, accept, avoid, transfer). Determine all controls necessary to implement the chosen options. Compare your selected controls against the Annex A list to verify nothing has been overlooked. Produce the Statement of Applicability.
• 6.2 – Information security objectives and planning to achieve them. Set measurable security objectives at relevant functions and levels. For each objective, document what will be done, what resources are required, who is responsible, when it will be completed, and how results will be evaluated.
• 6.3 – Planning of changes. When you determine the need for changes to the ISMS, the changes must be carried out in a planned manner. This was added in the 2022 revision.

Clause 7: Support

The ISMS needs resources, competent people, awareness, communication, and documented information to function. Clause 7 covers all of that.

• 7.1 – Resources. Determine and provide the resources needed for the ISMS. Budget, tools, headcount—if you starve the program, you fail this clause.
• 7.2 – Competence. Ensure that people doing work under the ISMS are competent on the basis of appropriate education, training, or experience. Retain documented evidence of competence (training records, certifications, performance reviews).
• 7.3 – Awareness. People performing work under the organization’s control must be aware of the information security policy, their contribution to ISMS effectiveness, and the implications of not conforming.
• 7.4 – Communication. Determine what needs to be communicated about the ISMS, when, with whom, and who shall communicate it. In practice: you need a communication plan.
• 7.5 – Documented information. Create, update, and control all documented information required by the standard and by your own ISMS. This is the documentation requirement that catches most organizations off guard.

Clause 8: Operation

Clause 8 is where planning meets execution. Everything you designed in Clauses 6 and 7 must be implemented and controlled here.

• 8.1 – Operational planning and control. Plan, implement, and control the processes needed to meet ISMS requirements and implement the actions identified in Clause 6. Control planned changes and review unintended changes. Ensure outsourced processes are controlled.
• 8.2 – Information security risk assessment. Perform risk assessments at planned intervals or when significant changes occur. Retain documented results. In practice, most organizations do a full assessment annually and trigger ad-hoc assessments when there are major infrastructure changes, new products, or incidents.
• 8.3 – Information security risk treatment. Implement the risk treatment plan. Retain documented results. Auditors will compare your risk treatment plan to actual evidence of implementation—if you said you would deploy endpoint detection and response, they will verify it is deployed.

Clause 9: Performance Evaluation

The standard requires you to measure whether your ISMS is working. This is where many first-time implementations stumble—they build the system but forget to instrument it.

• 9.1 – Monitoring, measurement, analysis and evaluation. Determine what needs to be monitored and measured, the methods, when monitoring and measuring shall be performed, who shall do it, and when results shall be analyzed and evaluated. You need actual security metrics—not just “we feel good about our posture.”
• 9.2 – Internal audit. Conduct internal audits at planned intervals. The audit program must consider the importance of the processes concerned and the results of previous audits. Auditors must be objective and impartial—you cannot audit your own work. Many smaller organizations use an external firm for this, tying it into their broader IT security audit program.
• 9.3 – Management review. Top management must review the ISMS at planned intervals. The review must consider status of actions from previous reviews, changes in external and internal issues, nonconformities and corrective actions, monitoring and measurement results, audit results, and opportunities for improvement. Minutes must be retained as documented information.

Clause 10: Improvement

The final mandatory clause addresses what happens when things go wrong and how the ISMS evolves.

• 10.1 – Continual improvement. Continually improve the suitability, adequacy, and effectiveness of the ISMS. This is not a platitude—auditors expect evidence of improvement actions taken between audits.
• 10.2 – Nonconformity and corrective action. When a nonconformity occurs, react to it, evaluate the need for corrective action to eliminate the root cause, implement the action, and review its effectiveness. Retain documented information as evidence.

“The single most common reason organizations fail their Stage 2 audit is not missing controls—it’s missing evidence. They implemented the control but never documented the process, the review, or the results.”

The 2022 revision reorganized the Annex A controls from 14 categories down to 4 thematic groups. This was partly cosmetic—many controls carried over from the 2013 version—but 11 entirely new controls were introduced, and several were merged. The total went from 114 controls to 93.

Here is what each category covers and why it matters for your implementation.

A.5 – Organizational Controls (37 controls)

This is the largest category and covers governance, policy, risk, compliance, asset management, access control, supplier relationships, incident management, business continuity, and more. Think of it as everything that requires process and policy rather than physical or technical implementation.

A.6 – People Controls (8 controls)

These controls cover the human element of information security: screening, terms and conditions of employment, awareness training, the disciplinary process, responsibilities at termination, confidentiality agreements, remote working, and information security event reporting.

People controls are straightforward to document but require operational discipline. Your auditor will ask for evidence that screening was performed for recent hires, that training was completed and acknowledged, and that terminated employees had their access revoked promptly. This last point—access revocation—is one of the most common nonconformities we see during security audits.

A.7 – Physical Controls (14 controls)

Physical security perimeters, entry controls, securing offices and facilities, physical security monitoring, protecting against environmental threats, working in secure areas, clear desk and clear screen, equipment siting and protection, security of assets off-premises, storage media management, supporting utilities, cabling security, and equipment maintenance.

For fully remote or cloud-native organizations, many physical controls can be addressed through your cloud provider’s certifications and your remote working policy. But you cannot simply declare them “not applicable” without justification in the SoA. Even a fully remote company has laptops, and laptops are physical assets that require protection.

A.8 – Technological Controls (34 controls)

This is where the technical rubber meets the road: endpoint security, privileged access management, information access restriction, secure authentication, malware protection, vulnerability management, configuration management, data masking, data leakage prevention, monitoring, web filtering, secure coding, and more.

The standard uses the phrase “documented information” rather than “document” or “record,” which is deliberately vague. But through years of audits and working with certification bodies, there is a practical consensus on what you need. I split these into two tiers: documents the standard explicitly requires you to retain, and documents that auditors practically always expect to see.

Tier 1: Explicitly Required by the Standard

Tier 2: Practically Required (Auditors Expect These)

• Access Control Policy – Who can access what, under what conditions, and how access is granted and revoked
• Asset Inventory – All information assets (hardware, software, data, people, facilities) with assigned owners
• Acceptable Use Policy – Rules for acceptable use of information and assets
• Incident Response Procedure – How security events are reported, assessed, responded to, and learned from
• Business Continuity Plan – How you maintain operations during disruptions, including IT disaster recovery
• Supplier Security Policy – Requirements for third-party vendors who handle your information
• Change Management Procedure – How changes to systems, infrastructure, and processes are controlled
• Data Classification Scheme – Categories for information sensitivity and handling rules for each level
• Cryptography / Encryption Policy – When and how encryption is applied to protect information
• Secure Development Policy – Secure coding standards, code review, and testing requirements (if you develop software)
• Internal Audit Program – Schedule, scope, and methodology for internal audits
• Communication Plan – Who communicates what about the ISMS, when, and to whom

Pro tip: Don’t create separate documents for everything. A single “ISMS Manual” can contain your scope, policy, roles, objectives, and communication plan. Auditors care about content, not the number of PDFs.

If there is one document that auditors study more than any other, it is the Statement of Applicability. The SoA is the bridge between your risk assessment and your actual controls. It is required by Clause 6.1.3 d) and must contain:

• Every control you have determined as necessary (whether from Annex A or other sources)
• A justification for including each control
• Whether each control is implemented or not
• A justification for excluding any Annex A control

In practice, most organizations create a spreadsheet or table with all 93 Annex A controls as rows, and columns for: control reference, control title, applicable (yes/no), justification, implementation status, responsible owner, and a link to supporting evidence.

Common mistakes with the SoA:

• Excluding controls without justification. If your SoA says “Not applicable” for A.8.12 (Data leakage prevention) but you process customer PII in a SaaS product, the auditor will issue a nonconformity.
• Treating the SoA as static. The SoA must be updated whenever your risk assessment changes, new controls are introduced, or controls are decommissioned. It is a living document.
• Disconnecting the SoA from the risk assessment. The auditor will trace specific risks from your risk register to treatments in your risk treatment plan to controls in the SoA. If those threads break, that is a nonconformity.

The risk assessment is the engine that drives your entire ISMS. Clause 6.1.2 requires you to define a methodology before you start assessing risks. The methodology must ensure that repeated assessments produce “consistent, valid and comparable results.” That is the bar. Here is what that means in practice.

What the Methodology Must Define

• Risk acceptance criteria. What level of risk does your organization accept without treatment? This is usually expressed as a threshold on your risk matrix (e.g., “risks rated Medium or below are accepted; High and Critical must be treated”).
• Criteria for performing assessments. When do you perform them? Annually? After significant changes? After incidents? All three are typical.
• Risk identification approach. How do you identify risks? Asset-based (identify assets, threats, and vulnerabilities for each), scenario-based (identify threat scenarios and assess impact), or a combination. ISO 27005 provides guidance but is not mandatory.
• Risk analysis method. Qualitative (High/Medium/Low), quantitative (dollar-value estimates), or semi-quantitative (numerical scales mapped to qualitative labels). Most organizations use semi-quantitative with a 5x5 likelihood-impact matrix.
• Risk evaluation process. How do you compare analyzed risks against acceptance criteria? Typically, you plot each risk on the matrix, and anything above the acceptance line goes into the risk treatment plan.

Risk Treatment Options

For every risk above your acceptance threshold, you must choose one of four treatment options:

The risk treatment plan must document which option was chosen for each risk, what specific controls implement that option, who owns the treatment, and the timeline for implementation. This plan is what your auditor will verify against operational evidence during the Stage 2 audit.

Understanding the individual clauses and controls is important, but the real insight is seeing how everything flows together. ISO 27001 is not a checklist—it is a system. Here is how the pieces connect:

This is the Plan-Do-Check-Act (PDCA) cycle that ISO management system standards are built on. Auditors are trained to follow these threads. They will pick a risk from your register, trace it to a treatment decision, find the corresponding control in your SoA, verify the control is implemented in operation, check that it is being monitored and measured, and confirm that any issues were corrected through the improvement process.

If any link in that chain is broken—a risk with no treatment, a treatment with no control, a control with no evidence, evidence with no monitoring—you get a nonconformity. The organizations that achieve certification smoothly are the ones that build these connections from day one rather than trying to retrofit them before the audit.

This is also why working with experienced practitioners matters. A virtual CISO who has taken organizations through the certification process understands how auditors trace these threads and can help you build an ISMS where every element reinforces the others. Similarly, aligning your ISO 27001 effort with a SOC 2 readiness program can create significant efficiency—many controls satisfy both frameworks simultaneously.

After participating in dozens of ISO 27001 certification audits—some successful, some not—patterns emerge. Here are the mistakes I see most frequently:

Ready to Start Your ISO 27001 Journey?

Whether you are starting from zero or transitioning from the 2013 version, we can help you build an ISMS that passes the audit and actually protects your organization.

Our free initial consultation includes: scoping discussion, gap assessment overview, timeline and cost estimate, and framework overlap analysis if you also need SOC 2 or other certifications.

Published: March 2026 · Author: Alexander Sverdlov

This article is for informational purposes only and does not constitute legal or professional advice. ISO 27001 requirements are based on the ISO/IEC 27001:2022 standard. Organizations should work with accredited certification bodies and qualified consultants for formal implementation and certification.