ISO/IEC 27001:2022 has two layers of requirements. The first is seven mandatory management-system clauses, numbered 4 through 10, that every certified organisation must satisfy in full. The second is 93 reference controls listed in Annex A, which you select or exclude based on your own risk assessment. No one implements all 93 by default, and no auditor expects you to. The clauses build the machine; the controls are the parts you fit into it.
I find that most people who ask about "requirements" are actually asking one of two things: what do I have to write down, or what do I have to do? The answer to both is in Clauses 4 through 10. Annex A tells you what to do about specific security risks once the system is running.
Clauses and controls
The distinction matters because auditors treat them differently. A gap in Clause 6.1.2 (your risk assessment methodology) is a nonconformity against the standard itself. A gap in Annex A control 8.28 (secure coding) might not be a finding at all, provided your Statement of Applicability explains why you excluded it and your risk assessment supports that decision.
Think of it like the driving test. Clauses 4 through 10 are the mandatory manoeuvres: everyone does them, no exceptions. Annex A is the road: the examiner picks a route based on the conditions, and you handle whatever comes up. You do not drive every road in town.
Clauses 4 through 10
Every clause builds on the one before it. Skip one and the rest do not work properly. I have summarised them below with what an auditor actually looks for at each stage.
| Clause | Title | What it requires | What auditors look for |
|---|---|---|---|
| 4 | Context of the organisation | Define your scope, identify interested parties (customers, regulators, staff), and understand the issues that affect your ISMS | A scope statement that names specific sites, services, and boundaries. A list of interested parties and their requirements. Vague scopes ("all of our business") attract questions. |
| 5 | Leadership | Top management demonstrates commitment, sets an information security policy, and assigns ISMS roles and responsibilities | A signed policy, evidence that management actually reviews the ISMS (not just signs off on it), and named individuals with defined authority. |
| 6 | Planning | Conduct a risk assessment, produce a risk treatment plan, and write a Statement of Applicability (SoA) | A documented risk assessment methodology, a risk register with actual decisions (accept, treat, transfer, avoid), and an SoA that maps each Annex A control to a justification. |
| 7 | Support | Provide resources, ensure competence, maintain awareness, manage communication, and control documented information | Training records, an awareness programme, a document control process. The standard does not prescribe a format for any of this. |
| 8 | Operation | Execute the risk treatment plan, run the risk assessment at planned intervals, and manage changes | Evidence that controls from the SoA are actually implemented, not just listed. Operational records showing the system runs day to day. |
| 9 | Performance evaluation | Monitor, measure, analyse, and evaluate the ISMS. Conduct internal audits and management reviews. | Internal audit reports (covering every clause and every applicable Annex A control over the cycle), management review minutes with defined inputs and outputs per Clause 9.3. |
| 10 | Improvement | Handle nonconformities with corrective action, and drive continual improvement | A corrective action log, evidence that root causes are identified and fixes verified, and some mechanism for improvement beyond just fixing problems. |
That is the entire management-system skeleton. Three clauses (1, 2, 3) exist in the standard but they cover scope of the document, normative references, and terms and definitions. They do not contain auditable requirements, so I have left them out.
Clause 6: where most implementations stall
If I had to pick one clause that causes the most trouble, it is Clause 6, specifically 6.1.2 (risk assessment) and 6.1.3 (risk treatment). The standard requires you to define a risk assessment methodology that produces "consistent, valid and comparable results" [1]. That sounds reasonable until you realise it means you need to decide, before you start, how you will identify risks, how you will score them, and what threshold triggers treatment.
Most founders write two pages for this. One page is fine. The methodology does not need to be complex, but it does need to exist, and you do need to follow it. I once audited a company whose risk register had 247 rows and zero treatment decisions — that is a list, not a risk assessment.
The output of Clause 6 feeds everything else. Your risk treatment plan determines which Annex A controls you implement. Your Statement of Applicability (SoA) documents each of the 93 controls with a justification for inclusion or exclusion. The SoA is probably the single most scrutinised document in a Stage 2 audit.
Annex A
Annex A is not a checklist. It is a reference set of 93 information security controls organised into four themes [2]:
| Theme | Controls | Examples |
|---|---|---|
| Organisational | 37 | Information security policies (5.1), threat intelligence (5.7), cloud services (5.23) |
| People | 8 | Screening (6.1), information security awareness and training (6.3) |
| Physical | 14 | Physical security perimeters (7.1), equipment maintenance (7.13) |
| Technological | 34 | Access control (8.3), secure coding (8.28), data leakage prevention (8.12) |
The 2022 revision restructured these from the 14 domains and 114 controls of the 2013 version, adding 11 new controls that reflect current threats: threat intelligence, cloud services, monitoring activities, web filtering, secure coding, data masking, data leakage prevention, information deletion, configuration management, ICT readiness for business continuity, and physical security monitoring [2].
You do not "pass" or "fail" Annex A controls individually. You include or exclude each one in your SoA based on your risk assessment. If you exclude a control, you need a reason. "We do not have a physical office" is a valid reason to exclude physical perimeter controls. "We did not get round to it" is not.
For details on the four themes, see the four categories of ISO 27001 controls. For the full Annex A structure, see what is ISO 27001 Annex A.
Mandatory documentation
The standard mandates specific documented information, but it is less than people expect. The mandatory set includes the ISMS scope, the information security policy, the risk assessment methodology, risk assessment results, the risk treatment plan, the SoA, information security objectives, evidence of competence, operational planning records, risk assessment outputs, internal audit results, management review outputs, and corrective action records [1].
That sounds like a lot, but in practice a lean implementation for a 20-person SaaS company might produce 8 to 12 documents plus a risk register and a few logs — the standard does not require separate policies for every topic. I usually tell founders to start with a single information security policy, an acceptable use policy, and a handful of procedures, and add more only if the risk assessment calls for it.
For the full document list, see mandatory documents for ISO 27001.
Not required
This is worth saying because consultants and tooling vendors routinely oversell the requirements:
- The standard does not require a specific document format. Your risk register can be a spreadsheet.
- The standard does not require a specific risk assessment framework — you do not need ISO 27005 or NIST or FAIR, just a method that produces consistent, comparable results.
- The standard does not require you to implement all 93 Annex A controls; you implement the ones your risk assessment tells you to.
- The standard does not require you to hire a consultant — plenty of small companies self-implement successfully.
- The standard does not require perfection, just a system that finds problems and fixes them, which is what continual improvement means in practice.
Calibre's audit approach
At Calibre, we audit against Clauses 4 through 10 and your declared SoA. The Stage 1 audit checks whether your documentation is complete and your scope makes sense. The Stage 2 audit checks whether the system actually works: are the controls implemented, do people follow the procedures, does the risk assessment drive real decisions? If something is missing, we raise a nonconformity (major or minor), and you fix it with a corrective action before the certificate is issued.
The whole point is that the requirements are a framework, not a prescription. Two companies in the same industry with the same headcount can have very different ISMSs, both perfectly valid, because they assessed different risks and chose different treatments. The auditor's job is to check that your logic holds, not to impose a template.
FAQ
No. You include or exclude each control in your Statement of Applicability based on your risk assessment. Most small tech companies apply 60 to 80 of the 93, excluding controls that do not fit their operating model (physical security controls for a fully remote company, for instance). The key is that every exclusion has a documented justification.
Clause requirements (4 through 10) are mandatory for every organisation seeking certification. They define how the ISMS works. Annex A controls are a reference set that you select from based on your risk assessment. You cannot exclude a clause requirement, but you can exclude an Annex A control with justification.
For a small tech company (10 to 50 staff) starting from scratch, a realistic timeline is 3 to 6 months of implementation before you are ready for a Stage 1 audit. Companies with existing security practices (access controls, encryption, incident response) can move faster because the gap between what they already do and what the standard requires is smaller.
Yes. The standard is available from ISO for about CHF 129 (roughly £115) [3], and ISO 27002 provides implementation guidance for every Annex A control [4]. Many founders and CTOs self-implement by reading the standard, running a gap analysis, and building the ISMS themselves. A consultant can speed things up, but the standard does not require one. Be aware that the consultant who helps you build your ISMS cannot be from the same certification body that audits you, due to impartiality rules under ISO/IEC 17021-1 [5].
The auditor raises a nonconformity. A minor nonconformity means you have a process but it is not fully effective. A major nonconformity means a requirement is not met at all, or the ISMS cannot achieve its intended outcomes. You get a defined period to submit corrective action evidence. Most Stage 2 audits result in a handful of minors, which is completely normal.
Sources
- 1.ISO/IEC. (2022). "ISO/IEC 27001:2022 Information security, cybersecurity and privacy protection - Information security management systems - Requirements". https://www.iso.org/standard/27001
- 2.ISO/IEC. (2022). "ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection - Information security controls". https://www.iso.org/standard/75652.html
- 3.ISO. (2022). "ISO/IEC 27001:2022 - Purchase page". https://www.iso.org/standard/27001
- 4.ISO/IEC. (2022). "ISO/IEC 27002:2022 - Purchase page". https://www.iso.org/standard/75652.html
- 5.ISO/IEC. (2015). "ISO/IEC 17021-1:2015 Conformity assessment - Requirements for bodies providing audit and certification of management systems". https://www.iso.org/standard/61651.html
- 6.International Accreditation Forum. (2023). "IAF MD 5:2023 Determination of Audit Time of Quality, Environmental, and Occupational Health & Safety Management Systems". https://iaf.nu/en/iaf-documents/
- 7.ISO. (2025). "The ISO Survey of Management System Standard Certifications 2024". https://www.iso.org/the-iso-survey.html
- 8.Department for Science, Innovation and Technology. (2026). "Cyber Security Breaches Survey 2025/2026". GOV.UK. https://www.gov.uk/government/statistics/cyber-security-breaches-survey-20252026
