An Information Security Management System (ISMS) is the set of policies, processes, roles, and records an organization uses to manage information security in a repeatable, auditable way. ISO/IEC 27001:2022 is the standard that defines what such a system must contain, and certification means an outside auditor has confirmed it does. This course takes an organization that already has some of those pieces and turns them into one coherent system, from scope through risk, controls, internal audit, and certification readiness.
It matters because every later decision hangs on the boundary you draw first. Scope sets which risks you assess, which controls you justify, and what the certificate will say to customers. In this lesson you will build a defensible context and scope, starting with what auditors actually examine.
Certification audits test the management-system requirements in clauses 4 to 10. None of them can be excluded when you claim conformity. Each clause produces outcomes, and most of those outcomes leave behind documented information an auditor can open.
Scope comes from clause 4, policy and leadership from clause 5, risk work from clause 6, operation from clause 8, and audits and management review from clauses 9 and 10. The Statement of Applicability (SoA) is the document that justifies each Annex A control. Because scope is the first artifact an auditor reads at Stage 1, it shapes everything that follows. Here is how the clauses map to the evidence you will need to produce:
Clause 4.3 tells you to draw the boundary after considering three inputs. Two of them come from earlier in clause 4. Clause 4.1 asks for the internal and external issues that affect your ability to achieve ISMS outcomes, such as a cloud migration, a regulatory change, or staff turnover. Clause 4.2 asks who the interested parties are and which of their requirements you will address.
Different parties want different things, and they want different proof. A customer may demand a certificate covering the service they buy. A regulator cares about legal obligations such as data protection law. Internal teams care about workable processes. Write each requirement down and note which ones the ISMS will address, since the scope must visibly respond to them. Let’s compare what three of these groups expect:
Law ignores scope A narrow certificate never narrows regulatory duties. Legal obligations attach to the organization, whatever the ISMS covers.
A boundary can follow sites, services, products, legal entities, or information types, or a mix. What matters is that it is clear, defensible, and traceable to your context and interested-party inputs. The scope statement itself stays short. It names the legal entity, the services covered, the locations, and any significant exclusions.
You exclude organizational territory, never requirements. Clauses 4 to 10 apply in full inside the fence. You also cannot exclude what your in-scope work depends on, like the laptops developers use or the network the office runs on. A narrow scope cuts audit effort but can leave a certificate customers reject, while a broad one multiplies evidence and cost. Try moving the boundary yourself and watch the trade-offs: