Information security management

STANDARD SUMMARY

The starting point

Give information security a clear scope, accountable owners and an evidence trail. ISO/IEC 27001 specifies the requirements for an information security management system, or ISMS, covering the confidentiality, integrity and availability of information.

This guide explains clauses 4–10 in plain language and offers practical ways to prepare evidence. It is an original implementation guide, not a substitute for the standard, a technical security assessment or a certification audit.

Who it is for. Organisations handling information whose loss, alteration or unavailability could affect customers, operations, contractual commitments or other interested parties.

What an ISMS should help you decide

An ISMS connects security decisions to the organisation’s activities, risks and responsibilities. The requirements in clauses 4–10 apply to the management system; Annex A supports the selection and checking of controls through risk treatment.

Our practical test is whether the organisation can explain what it is protecting, why that matters, who has authority to act and how it knows the arrangements work. A folder of policies can support that explanation, but it cannot supply the operational evidence by itself. Begin with a small number of important information flows and build a coherent account of their dependencies, risks and controls.

Clause 4 — define the context and scope

Clause 4 addresses the organisation’s context, relevant interested parties, the ISMS scope and the management system. The 2024 amendment adds the determination of climate relevance to the context review.

For implementation, describe the business service first. Then identify the information, people, systems, locations and external dependencies needed to deliver it. A scope written only as a company name gives little insight into the boundary. A scope that names one application but ignores the people administering it can also be misleading. Explain interfaces with excluded activities and how dependencies are managed.

A practical workshop can follow a customer record from collection through use, sharing, backup and disposal. Ask which contractual commitments or other applicable requirements attach to it. Record unresolved scope questions and obtain a decision from an accountable owner. Review the scope when services, locations, suppliers or acquisition plans change, rather than waiting for an annual calendar reminder.

Example: a software provider may place its hosted service and supporting development, operations and customer support within scope. Its evidence should then explain how shared identity services, remote workers and the cloud provider interact with that boundary. The example is illustrative; it does not prescribe the right scope for another organisation.

Clause 5 — make leadership and accountability visible

Clause 5 covers leadership commitment, information security policy and organisational responsibilities. Accountability needs to be clear enough for decisions to be made and followed through.

Our suggested evidence is a trail of actual decisions: accepting a residual risk, funding a control, prioritising a supplier issue or resolving a conflict between delivery speed and security. Identify who owns the risk and who operates the control; they may be different people. A security lead can coordinate the work without becoming the owner of every business decision.

Give the policy a usable purpose. It should help teams understand the organisation’s direction and the expectations that apply to their work. Explain how exceptions are requested, who may authorise them and when they expire. During an audit, leaders should be able to discuss significant risks and progress using their own operational knowledge. A signature on a policy is a starting point for evidence, not the entire leadership story.

Clause 6 — plan risk treatment and measurable objectives

Clause 6 addresses risks and opportunities, information security risk assessment and treatment, objectives and planning changes. Risk treatment includes a Statement of Applicability, commonly called the SoA.

Use a risk method that people can apply consistently. Define the scale, the decision thresholds and who can accept risk before producing a long register. A useful risk description connects an information asset or service, a possible event, a vulnerability or dependency, and the consequence. “Cyber risk” alone does not explain what action to take.

For each selected treatment, identify the owner, resources, intended result and evidence that will show completion. Distinguish installing a control from knowing it is effective. For example, introducing access reviews is an action; resolving inappropriate access found by those reviews is evidence that the process can change outcomes. Keep acceptance of remaining risk with the authorised risk owner.

Set objectives that can inform decisions. “Improve security” is difficult to evaluate. A more usable objective identifies a defined population, an outcome, a data source and a review date. The target must fit the organisation’s risk and resources; this guide does not prescribe a universal percentage or deadline. When a major change is planned, revisit the assumptions that supported the earlier risk decisions.

Clause 7 — provide resources and usable information

Clause 7 covers support for the ISMS, including resources, competence, awareness, communication and documented information.

For implementation, distinguish knowing about a policy from being able to perform a role. An administrator may need to demonstrate secure configuration and recovery tasks; a service desk colleague may need to handle an identity verification exception correctly. Training attendance is one source of evidence, while observed performance and targeted exercises can show whether the intended capability exists.

Keep documents close to the work they support. Give important records an owner, a version or other means of identifying the current instruction, appropriate access and a retention decision. Avoid placing sensitive evidence in a broadly shared audit folder simply because it is convenient. Prepare redacted or controlled access where the auditor can still verify the relevant fact.

Communication should also have an operating rhythm. Decide what teams need to know when a policy changes, an incident occurs or a supplier introduces a significant change. Capture the message and the audience where that record helps demonstrate the process. Do not create a record merely because a template contains an empty box.

Clause 8 — operate and revisit the controls

Clause 8 concerns operational planning and control, performing information security risk assessments and implementing the risk treatment process.

Our practical approach is to select several end-to-end examples and inspect whether the planned process occurred. Follow a new joiner through approval, access provision and review. Follow a supplier from evaluation to contract, onboarding and monitoring. Follow a significant system change from request to testing, approval and subsequent observation. Select examples with exceptions as well as examples that went smoothly.

Operational evidence needs dates and context. A screenshot of a configuration can show a state at one moment, but may not establish who approved it, whether it covers the whole population or how the setting is monitored. Pair it with the surrounding decision and review records when those are relevant.

Treat changes in services and dependencies as prompts to reassess risk. An earlier assessment may have assumed a particular hosting model, data location or support arrangement. When that assumption changes, the old conclusion may no longer be persuasive. Record what changed, who reviewed it and which controls or acceptance decisions followed.

Clause 9 — evaluate performance and challenge assumptions

Clause 9 addresses monitoring and evaluation, internal audit and management review. These activities should provide a basis for understanding whether the ISMS is working.

Choose measures that answer a management question. An inventory completion rate may be useful if the organisation understands the missing items and their significance. A count of completed tickets tells less unless it is connected to timeliness, risk or recurring failure. Define the source and calculation so that a change in the number can be explained.

Plan internal audits around the scope, important processes, risks and previous results. Use competent auditors with sufficient objectivity, and make the audit criteria explicit. A consultant can carry out an internal audit on the organisation’s behalf, but the engagement remains an internal audit; it does not become certification. Findings should connect the criterion, the observed evidence and the gap.

Management review should turn information into decisions. Record the issues considered, decisions made, resources agreed, owners and follow-up. An agenda copied into minutes without discussion does not explain the organisation’s judgement. Revisit significant open actions, especially those repeatedly deferred, and identify what must change for them to be resolved.

Clause 10 — correct problems and improve the system

Clause 10 covers continual improvement and the response to nonconformity, including corrective action. Improvement should address the functioning of the management system as well as individual controls.

When something fails, separate immediate correction from action on the cause. Removing an account that should have been disabled corrects the observed access problem. Understanding why the leaving process missed it, changing the relevant handover and testing later leavers addresses recurrence. This example is a suggested reasoning pattern, not a prescribed investigation method.

A useful corrective action record identifies the affected requirement, evidence, extent of the problem, containment where needed, cause analysis, action, owner and target date. Decide in advance what would demonstrate effectiveness and when it can reasonably be checked. A completed task is not always an effective solution.

Look for learning across processes. An access issue may reveal a wider weakness in ownership, communication or change management. Consider whether similar failures could exist elsewhere and document the basis for that decision. Use the result to improve the system instead of treating each finding as an isolated item to remove from a dashboard.

Annex A — select controls with a defensible rationale

The 2022 Annex A has 93 reference controls: 37 organisational, 8 people, 14 physical and 34 technological. ISO/IEC 27002 provides related control guidance. These counts describe the reference set; they are not a score or an instruction to implement every control identically.

The organisation determines necessary controls through risk treatment and checks its selection against Annex A. The SoA records necessary controls, inclusion reasons, implementation status and reasons for excluding Annex A controls. Additional controls may be necessary. The SoA need not reproduce the standard’s wording or become a public inventory of sensitive safeguards.

For practical use, connect each relevant entry to an owner and a way of locating evidence. Where a supplier performs part of the control, explain your own responsibilities and how you obtain assurance about the supplier’s contribution. An exclusion should explain the reasoning within the actual scope, rather than repeat “not applicable” without context. Revisit the SoA when risks, services or control arrangements change.

Build evidence that someone else can follow

Our recommended evidence index uses a reference, description, owner, relevant period, access route and connection to the process being tested. This helps an auditor locate a record without encouraging indiscriminate copying of sensitive material.

Select evidence across time and circumstances. A single successful backup does not, by itself, demonstrate a reliable recovery process. Consider whether tests cover the important services, whether results met the intended objectives and whether failures were resolved. Similarly, a supplier certificate may support a due diligence decision but does not answer every question about your particular service, contract or configuration.

Explain limitations openly. If a process is newly implemented, identify the available operating history and what remains to be observed. If a sample is small, state the population and the selection method. Useful assurance grows from evidence that can be checked, including its boundaries; it does not require pretending that every uncertainty has disappeared.

Prepare for an independent certification decision

Agree the scope and edition with a certification body whose accreditation covers the relevant activity. Use the initial audit stages to demonstrate the implemented system and address findings through the body’s process. The certification decision belongs to the certification body.

Our preparation sequence is to resolve scope uncertainties, test the risk method and SoA, gather operating evidence, complete an internal audit and management review, and check corrective actions. Maintain the system after certification. A certificate represents a defined scope and status; it does not mean that every product is secure, every supplier is approved or a future incident is impossible.

IMPLEMENTATION ADVICE

Evidence to prepare

• A current scope with physical, organisational and technological boundaries and interfaces.
• Context and interested-party reviews, including a reasoned climate relevance determination.
• A consistent risk method, current assessments, treatment decisions and risk-owner approvals.
• A Statement of Applicability that connects necessary controls, implementation status and exclusion reasons.
• Operating evidence for selected access, supplier, change, incident and recovery processes as applicable.
• Competence and awareness evidence proportionate to the responsibilities of each role.
• Measures, internal audit results and management review decisions that lead to action.
• Corrective actions with cause analysis and later checks of effectiveness.

Common pitfalls

• Treating 93 Annex A controls as a universal checklist detached from the scope and risk assessment.
• Confusing a vulnerability scan, penetration test or policy pack with a complete ISMS.
• Claiming a supplier’s certification automatically covers your organisation or configuration.
• Stating that a certificate guarantees security, legal compliance or absence of future incidents.
• Using a 2013 certificate without verifying current certification status after the transition deadline.
• Closing corrective actions when the document changes, before checking the result in practice.

FICTIONAL WORKED EXAMPLE

Fictional example: checking access after a person leaves

A fictional software provider reviews whether its leaving process reaches a separately managed support platform. This educational scenario is not an actual security incident.

One account record does not prove organisation-wide security. This example authorises no testing, access or change to a live system.

Related guidance and practical next steps