ISO/IEC 27001

What is ISO/IEC 27001?

ISO/IEC 27001 sets the requirements for an information security management system (ISMS): the policies, roles, processes, risk decisions and controls an organisation uses to protect the confidentiality, integrity and availability of information. It is a management-system standard. It does not prescribe a fixed technical configuration. Instead, it requires the organisation to understand its context, assess its information security risks, choose controls to treat them, run those controls, and check and improve how well the system works.

The current edition is ISO/IEC 27001:2022. In 2024 a short amendment added climate change considerations to the context clauses. Organisations certified to the older 2013 edition had a transition period to move to the 2022 edition, and that period has now ended.

Purpose and objectives

The standard gives an organisation a repeatable way to:

• decide, based on risk, what information security protection it needs;
• make leadership accountable for security, rather than leaving it with the IT team;
• show customers, regulators and partners that security is managed systematically, not ad hoc;
• keep improving as threats, technology and the business change.

Because the requirements are generic, the same standard fits a five-person software start-up and a global bank. What differs is the scope, the risks and the chosen controls.

Who does it apply to?

ISO/IEC 27001 is voluntary. No law requires it in general, but it is often expected in practice:

• Technology and SaaS providers use certification to answer customer security questionnaires and procurement requirements.
• Outsourcing, data-centre and managed-service providers use it to show clients how their environment is governed.
• Public-sector and regulated buyers sometimes name it in tenders or recognise it in supplier assurance.
• Any organisation can adopt it internally without seeking certification, as a structure for its security programme.

Scope and applicability

The ISMS scope (clause 4.3) is one of the most important decisions. It sets which parts of the organisation, which locations, which services and which information are covered. A certificate only says something about what is inside the scope, so readers of a certificate should always check the scope statement.

When defining scope, organisations look at internal and external issues, the requirements of interested parties (customers, regulators, staff, suppliers), and interfaces and dependencies on activities performed by others, such as cloud providers. Scoping too narrowly can make the certificate less useful to customers. Scoping too widely can make the first certification much harder.

How is the standard structured?

The 2022 edition follows the harmonised structure shared by ISO management-system standards. This makes it easier to integrate with ISO 9001, ISO 22301 or ISO/IEC 42001.

Annex A lists 93 reference controls. They are grouped into four themes: organisational, people, physical and technological. The 2022 edition reorganised the earlier list and introduced controls covering areas such as threat intelligence, information security for the use of cloud services, ICT readiness for business continuity, configuration management, data masking, data leakage prevention, monitoring activities, web filtering and secure coding. Detailed implementation guidance for each control is in the companion standard ISO/IEC 27002.

Core requirements in practice

Risk assessment and treatment

The organisation must define and apply a risk assessment process that produces consistent, comparable results. Then it decides how to treat each risk: modify it with controls, accept it, avoid it or share it. Risk owners must approve the treatment plan and accept the residual risk.

The Statement of Applicability (SoA)

The SoA lists the controls the organisation needs, whether each Annex A control is included or excluded, the justification, and whether the control is implemented. Auditors read it closely because it ties risk decisions to controls.

Objectives, competence and awareness

Security objectives must be measurable where practicable, monitored and communicated. People doing security-relevant work must be competent, and the organisation must keep evidence of that competence. Staff must know the policy and their own contribution.

Internal audit and management review

The organisation audits its own ISMS at planned intervals, and top management reviews whether the system is suitable, adequate and effective. These two clauses are where many first-time implementations struggle: they must work as real processes, not as paperwork completed just before the certification audit.

Implementation lifecycle

A typical journey looks like this. The order and duration depend on size and maturity.

1. Secure sponsorship. Agree why the organisation is doing this, who owns it, and what budget and time are available.
2. Define context and scope. Map services, locations, information assets, interested parties and dependencies.
3. Establish the risk method. Agree criteria for likelihood, impact and risk acceptance.
4. Assess and treat risks. Produce the risk register, treatment plan and Statement of Applicability.
5. Implement controls and processes. Write policies people can actually follow, and put technical and procedural controls in place.
6. Operate and measure. Run the ISMS long enough to produce real records: access reviews, incident logs, supplier reviews, training records.
7. Internal audit and management review. Test the system and act on what you find.
8. Certification audit (optional). Stage 1 reviews readiness and documentation. Stage 2 assesses whether the ISMS is implemented and effective.
9. Maintain. Surveillance audits, recertification, and continual improvement as the business changes.

Evidence and documentation

The standard calls records and documents documented information. Auditors usually expect to see, among other things:

• the ISMS scope and the information security policy;
• the risk assessment and risk treatment processes and their results;
• the Statement of Applicability;
• information security objectives and evidence of monitoring them;
• evidence of competence and awareness;
• results of monitoring and measurement, internal audits and management reviews;
• records of nonconformities and the corrective actions taken.

Good evidence is produced by the work itself, such as ticket histories, system-generated logs, signed approvals and review minutes. It should not be assembled retrospectively. Auditors sample evidence across the audit period, so consistency matters more than volume.

Governance and accountability

Clause 5 places responsibility on top management. They must make sure the policy and objectives fit the organisation’s strategy, provide resources, and promote continual improvement. In practice, mature programmes have a named ISMS owner, a cross-functional security steering forum, defined risk owners in the business, and regular reporting to senior leadership or the board.

Common misconceptions and pitfalls

• “Certification means we are secure.” A certificate shows that a management system meeting the standard was operating within the scope at the time of audit. It does not guarantee that no incident will happen.
• “Annex A is a checklist.” Implementing controls without a risk basis produces cost without clear benefit, and a weak Statement of Applicability.
• “The ISO standard tells us exactly what to configure.” It does not. Technical baselines come from your risk decisions, vendor guidance and frameworks such as the CIS Controls.
• Scope that customers can’t use. A certificate covering only a head-office function will not satisfy a customer asking about your production cloud service.
• Policy-only implementations. Documents with no operating records fail stage 2 audits.

Relationship with other frameworks