An organisation may own advanced security tools while former employees still have active accounts or sensitive files sit in locations nobody manages. An information security management system addresses this gap between technology and everyday work. ISO/IEC 27001:2022 specifies requirements for establishing, operating and improving a system to manage information risks, whether information is digital, on paper or shared between people. It connects responsibilities, decisions and evidence; it does not promise that incidents will never occur.
Start with the information the business needs
Ask which information your services depend on, who owns it, where it is held and who uses or shares it. Examples include customer files, contracts, designs, employee data and operational records. Information differs in sensitivity and importance. Understand the impact of disclosure, inappropriate change or loss of access before choosing protection.
Protection concerns confidentiality: access for authorised people; integrity: safeguarding accuracy and completeness against inappropriate change; and availability: access when needed. Sending a file to the wrong person affects confidentiality, unauthorised changes affect integrity, and losing access to a necessary record affects availability. One incident may affect several aspects.
Set clear boundaries and real responsibilities
Define the services, locations, people and systems covered, then explain their relationships with activities outside the scope. If a service depends on a cloud provider or shared HR team, that dependency does not disappear because the party is outside the scope. Clarify responsibilities, interfaces, supplier requirements and evidence needed to assess whether the dependency is appropriately managed.
Leadership directs the system and provides resources, while process and information owners participate in risk assessment and treatment decisions. IT delivers an important part, but cannot alone determine every business impact or accept every risk. Identify who approves access, monitors suppliers, directs incident response and accepts residual risks under defined authority.
Assess risk consistently
Describe risk as an understandable scenario: an unauthorised person could access customer files because obsolete permissions remain active, exposing sensitive information. Connect the scenario to affected information, weaknesses and existing controls. Apply agreed likelihood, impact and acceptance criteria, and record owners, evidence and assumptions. A coloured score is of little use if the team cannot explain it.
Use a qualitative or quantitative method appropriate to the organisation. Do not assume one particular matrix or multiplication of scores is the only approach the standard requires. The method should support consistent, useful decisions. Reassess after material service, supplier or technology changes, significant incidents or new evidence affecting likelihood or impact.
Select treatment and document applicability
Choose suitable treatment after assessment: reduce risk through controls, avoid the activity, share risk through an appropriate arrangement or accept it under defined criteria and authority. Outsourcing or buying insurance does not erase organisational responsibilities or every consequence. Set out actions, owners, resources, deadlines and verification, and obtain risk owners’ approval of the treatment plan and acceptance of residual risk.
Determine necessary controls and compare them with Annex A to check that none has been overlooked. Do not automatically implement every Annex A control or exclude one simply because it is expensive. Controls outside the annex may also be needed. The SoA must identify necessary controls, reasons for inclusion, whether they are implemented, and reasons for excluding any Annex A control. Keep it consistent with the risk assessment and treatment plan.
Distinguish control selection from excluding management-system requirements. Clauses 4 to 10 are not an optional menu when claiming conformity. ISO/IEC 27002:2022 provides control guidance; it does not replace ISO/IEC 27001 requirements or the organisation’s risk assessment.
Make controls demonstrable in everyday work
Treatment may involve access management, awareness, backups, change control, suppliers and incident response, as appropriate. Define who operates each control, when, how exceptions are handled and what evidence is retained. An access policy is insufficient without approved requests, actual reviews and removal of permissions when roles change or employment ends.
Test effectiveness as well as existence. A completed backup job does not prove that information can be restored: test restoration through a safe, authorised plan. Attendance at training does not prove understanding: use questions or work-related scenarios. Protect test records and other evidence because they may contain sensitive details that should not be circulated unnecessarily.
Practical example: removing access when employees leave
This hypothetical example illustrates an approach, not a mandatory deadline set by the standard. An organisation discovers that departure notifications reach IT late and that some cloud services are missing from the access-removal list. Deleting one account is insufficient. Identify accounts associated with the service, define the approved removal time and notification route, and address urgent cases.
HR, the business owner and IT agree an approved notification workflow. The organisation establishes verification that access is removed at the required time. IT performs the action, and an authorised person checks the result and records evidence. Exceptions require specific approval and an expiry date rather than becoming permanent unreviewed arrangements.
An initial sample shows that all access was removed on time in 8 of 10 cases: 80%. The team investigates the 2 late cases, their causes and consequences, rather than using a high percentage to excuse unauthorised access. After correction, it tests subsequent cases and checks the completeness of the system inventory. This measure addresses timeliness in the sample; it does not alone prove that unknown accounts or earlier disclosures are absent.
Review and improve the system
Use objective internal audits to examine implementation and evidence. Bring risks, controls, incidents, objectives and resource needs to management review. Address nonconformities and their causes, then verify corrective-action effectiveness. Plan–Do–Check–Act (PDCA) helps connect planning, operation and review instead of reserving attention for external audit season.
As checked on 6 October 2026, ISO lists the 2022 edition and ISO/IEC 27001:2022/Amd 1:2024 on climate action changes. Consider the amendment when reviewing context and interested-party requirements, and assess relevance to the system’s intended outcomes. Power interruptions or impacts on information-processing locations may warrant consideration depending on circumstances; do not assume identical relevance for every organisation.
What does certification demonstrate?
Certification concerns the management system within the stated scope. It is not a guarantee against compromise or a security certificate for every product or branch. Check the edition, scope, status and validity, and the certification body’s accreditation and scope when seeking accredited certification. A cloud provider’s certificate does not mean your organisation is itself certified.
Is the system solely IT’s responsibility? No. Leadership, information owners, HR, procurement and operations participate as appropriate to the scope.
Is a supplier certificate or one penetration test enough? No. These may contribute evidence, but their scope and limitations must be understood and the organisation’s responsibilities managed.
Can we benefit without certification? Yes. The system can improve risk management, subject to applicable contractual and regulatory obligations.
Related reading
Read What is ISO? for the distinction between standards, implementation and certification. The NIST Cybersecurity Framework can be a complementary reference, but does not replace conformity requirements. This article illustrates an implementation approach; use the licensed standard and applicable amendment for detailed comparison.
