_1762866128417-DS2_OO1j.png)
What ISO 27001 requires
ISO/IEC 27001 is the international standard for information security management systems (ISMS). It requires an organisation to know its information assets, systematically assess risks to confidentiality, integrity and availability, and implement appropriate controls. A certificate shows customers, partners and authorities that information security is not left to chance.
The current edition, ISO/IEC 27001:2022, consists of clauses 4 to 10 following the Harmonized Structure and Annex A with 93 controls in four themes: organisational (37), people (8), physical (14) and technological (34). The transition period for certificates under the 2013 edition ended on 31 October 2025. A 2024 amendment also requires considering climate change as a possible issue in the organisation's context.
Working through the clauses
| Clause | Requirement | Typical evidence |
|---|---|---|
| 4 | Context, interested parties, ISMS scope | Context analysis, documented scope |
| 5 | Leadership, information security policy, roles | Approved policy, role descriptions |
| 6.1.2 | Information security risk assessment | Risk assessment method and results |
| 6.1.3 | Risk treatment and statement of applicability | Risk treatment plan, SoA |
| 6.2 | Information security objectives | Objectives with planning |
| 7 | Resources, competence, awareness, communication, documentation | Training records, controlled documents |
| 8 | Operation, performing risk assessment and treatment | Updated risk assessments, implementation evidence |
| 9 | Monitoring, internal audit, management review | KPIs, audit reports, minutes |
| 10 | Nonconformity, corrective action, improvement | CAPA records |
Risk assessment and statement of applicability
Risk assessment is at the heart of every ISMS. You define a method, identify risks to your information assets, assess likelihood and impact and decide how to treat each risk: avoid, reduce, transfer or accept.
Risk treatment leads to the statement of applicability (SoA). It lists all 93 Annex A controls, justifies whether each is applied and describes its implementation status. The SoA is one of the most important documents in the certification audit.
- 1
Define the method
Set criteria for likelihood, impact and risk acceptance.
- 2
Capture assets and risks
Gather information assets, threats and vulnerabilities and name risk owners.
- 3
Assess and prioritise
Assess risks using the defined method and compare them with the acceptance criteria.
- 4
Treat
Select controls, compare them with Annex A and record them in the risk treatment plan.
- 5
Create and approve the SoA
Document applicability and implementation status of each control; risk owners approve the residual risks.
How docxpert supports your ISMS
Mandatory documents at a glance
Besides the documents explicitly required by clauses 4 to 10, auditors expect evidence for the Annex A controls you declared applicable in the SoA. A detailed list with explanations is in the guide ISO 27001 mandatory documents.
- ISMS scope (4.3) and information security policy (5.2)
- Risk assessment and treatment process (6.1.2, 6.1.3)
- Statement of applicability (6.1.3 d) and risk treatment plan (6.1.3 e)
- Information security objectives (6.2) and evidence of competence (7.2)
- Results of risk assessment and treatment (8.2, 8.3)
- Monitoring results, audit programme and results, management review (9.1–9.3)
- Nonconformities and corrective actions (10.2)
Typical project path to certification
- 1
Scope and project team
Decide which sites, systems and processes belong to the ISMS; involve management, IT and business areas.
- 2
Gap analysis
Check existing policies and evidence against the clauses and Annex A.
- 3
Risk assessment and SoA
Assess risks, select controls, create the SoA.
- 4
Implement controls
Approve policies, implement technical controls, train employees.
- 5
Operate and check
Collect KPIs, carry out internal audits and the management review, then the two-stage certification audit.
Use the ISO 27001 readiness checklist to check before the audit whether the foundations are in place.
Practical tips
- Choose the scope deliberately: a scope that is too narrow will not convince customers; one that is too broad delays the project.
- Keep the risk method simple: a traceable three- or five-level scale beats a complex model nobody applies consistently.
- Write readable policies: short, role-based rules are followed more than long manuals.
- Include suppliers: cloud services and service providers belong in risk assessment and controls (A.5.19–A.5.23).
- Practise incidents: a tabletop exercise reveals gaps before a real incident does.
Frequently asked questions
How long does ISO 27001 certification take?
Six to twelve months is realistic for mid-sized companies – depending on scope and how many controls are already in place. Templates speed up documentation considerably; implementing technical controls takes its own time.
Do all 93 Annex A controls have to be implemented?
No. You must consider all controls and justify in the statement of applicability why each is or is not applied. Which ones are necessary follows from your risk assessment.
Is ISO 27001 the same as SOC 2?
No. SOC 2 is an attestation report common in the US based on the AICPA trust services criteria. ISO 27001 is an international certification of a management system. The content overlaps substantially, so many companies use one as a basis for the other.
Is ISO 27001 enough for NIS2?
ISO 27001 covers a large part of the NIS2 risk management measures. NIS2 adds obligations such as reporting deadlines, registration and personal accountability of management bodies that you should check separately.
Can docxpert be combined with ISO 27701?
Yes. Templates such as risk assessment, information assets and security incidents are also mapped to ISO 27701 and contain privacy sections that appear when you select ISO 27701 as applicable.
Where is data stored in docxpert?
Details on processing and storage locations are in our privacy policy. For your own supplier evaluation under A.5.19 we provide further information on request.
How do I keep the statement of applicability consistent with risk treatment and evidence?
Do not treat the statement of applicability as an isolated control checklist. For each control, make clear whether it applies, why that decision was made and its implementation status. Link the rationale to the risks the control addresses and to the policies, technical settings or records that evidence implementation. If a control is excluded, document the factual reason and check that it remains valid. Changes to risks, suppliers, systems or scope may alter earlier decisions, so assign an owner and a review trigger. A consistent mapping makes internal reviews and audits easier without automatically claiming that a control is effective; the organisation must assess its actual implementation.