ISO/IEC 27001:2022 is a standard for an Information Security Management System: a set of coordinated policies, processes, responsibilities and records through which an organisation manages information risk. It is not a technical checklist, and it is not satisfied by buying security products. What an auditor examines is whether a management system exists, whether it is being used and whether it is improving.
1. Understand the driver before you scope anything
Almost every implementation begins with a commercial trigger: a customer requirement, a tender, an investor question, a regulator or a board decision. That driver matters, because it usually defines what the certificate needs to cover. A certificate whose scope excludes the service your customer actually buys will not satisfy them.
Write down what the certificate must demonstrate, to whom, and by when. Everything that follows is easier once that is explicit.
2. Context, interested parties and scope
The standard asks you to establish the organisation’s context — internal and external issues relevant to information security — and to identify interested parties and their requirements. In practice this means customers, regulators, employees, shareholders, suppliers and sometimes insurers.
The ISMS scope statement then defines the boundaries: which services, locations, business units, systems and people are covered. Narrow scope is easier to implement but can be commercially useless. Broad scope is credible but takes longer. Choose deliberately, and be able to justify the boundary.
3. Gap analysis
A gap analysis compares what already exists against the requirements of clauses 4 to 10 and the Annex A controls you are likely to need. Most organisations discover that they already do a great deal — access control, backups, joiners and leavers, supplier checks — but do not document decisions, assign ownership or retain evidence.
The output should be a prioritised action plan, not a compliance spreadsheet. It needs owners, sequencing and realistic effort estimates.
4. Risk assessment and treatment
Risk is the engine of the standard. You need a documented methodology that produces consistent, repeatable results, and an assessment carried out with the people who understand the work rather than by a consultant in isolation.
Typically this produces:
- An inventory of information assets or processes within scope
- Identified risks with owners and an agreed scoring approach
- A risk treatment plan showing what will be done, by whom and when
- A Statement of Applicability recording which Annex A controls apply, why, and their implementation status
Risk acceptance decisions must be made by people with the authority to make them. This is a common audit finding.
5. Building the management system
Documentation should be proportionate. A small organisation does not need the policy set of a bank. What it does need is a coherent framework: an information security policy approved by top management, supporting policies and procedures that reflect actual practice, defined roles and responsibilities, and records that show the system operating.
Resist the temptation to import a large template library. Auditors interview staff, and a policy nobody recognises is worse than a shorter one that people follow.
6. Making controls operate
Selected controls have to be implemented and evidenced. Some are technical and sit with IT or a managed provider; many are organisational — screening, awareness, supplier agreements, incident handling, change control. Agree early who produces the evidence and where it is stored, because retrospective evidence gathering is the single biggest cause of delay.
7. Internal audit and management review
Before an external auditor sees the system, you must audit it yourself and hold a management review. These are mandatory requirements, and they are also the most useful rehearsal available. Internal audit tests whether the system works as described; management review confirms that leadership has considered performance, risks, nonconformities, objectives and opportunities for improvement.
Findings at this stage are good news. Nonconformities identified and closed internally are far cheaper than those raised by a certification body.
8. Certification: Stage 1 and Stage 2
Certification is carried out by an independent, accredited certification body. Stage 1 is largely a readiness and documentation review — scope, policy, risk assessment, Statement of Applicability, internal audit and management review. Stage 2 assesses whether the ISMS is implemented and effective, through interviews and evidence sampling across the scope.
Findings are normal. Minor nonconformities are usually addressed through a corrective action plan. The certification decision belongs to the certification body alone; no consultancy can grant or guarantee it.
9. What happens next
Certification runs on a three-year cycle with surveillance audits in between. The system has to keep operating — risks reviewed, policies maintained, actions tracked, audits performed. Our guide on maintaining ISO 27001 certification covers what that looks like in practice.
Where projects lose time
- Scope decided too quickly, then reopened after the gap analysis
- Risk assessment carried out without the people who own the risks
- Documentation written in isolation and never adopted
- Evidence not retained as work happens
- Senior management engaged too late to make the required decisions
- Certification body engaged late, so audit dates dictate the plan
None of these are technical problems. They are project and ownership problems, which is why implementation benefits from someone who has run the process before.