ISO 27001: the ISMS and structure¶
What the certificate actually says¶
Scaldimet's customer asked for ISO 27001, and it is easy to misread what that demand means. ISO 27001 does not certify that an organisation is secure, or that it has bought the right products. It certifies that the organisation runs an Information Security Management System (ISMS): a managed, repeating process for deciding what to protect, choosing controls based on risk, operating them, checking they work, and improving them. The certificate is a statement about your system for managing security, not a guarantee about your security. Understanding that distinction is the difference between chasing a certificate and building something that lasts.
The ISMS is a management system, like any other¶
If your organisation already runs a quality management system (Scaldimet holds ISO 9001 at Alpha), the shape will be familiar, because ISO management-system standards share a structure. The requirements live in a set of clauses, and they describe a continual-improvement loop rather than a one-off project:
| Clause area | What it requires | Scaldimet |
|---|---|---|
| Context | Understand the organisation, its issues, and interested parties | The OEM customer, the two national regulators, the two sites |
| Leadership | Top management commits, sets policy, assigns roles | The mandate, policy and committee from Module 2 |
| Planning | Assess risks, set objectives, plan treatment | Where ISO meets Module 4: a risk assessment drives control choice |
| Support | Resources, competence, awareness, documentation | Budget, training, the document architecture from Lesson 2.3 |
| Operation | Actually run the risk assessment and the controls | Operating the socle (Chapter 3.5) |
| Performance evaluation | Monitor, measure, audit internally, review | Metrics (Lesson 2.5) and internal audit (Lesson 3.6) |
| Improvement | Fix nonconformities, improve continually | The loop closes and repeats |
Notice how much of this Scaldimet already built in Module 2. ISO 27001 does not ask for a separate universe; it formalises the governance you already put in place and adds a disciplined risk-and-control loop on top. That is why governance came first.
Why it is risk-driven by design¶
The single most important thing to understand about ISO 27001 is that it is risk-driven, not checklist-driven. You do not implement a fixed list of controls. You run a risk assessment, decide how to treat each risk, and select the controls that treatment requires. The document that records this is the Statement of Applicability (SoA): a list of the reference controls (Annex A, covered in the next Lesson), marking each as included or excluded, with the justification for the decision.
This is the central principle of the whole Module in practice: every control in the ISMS should have a clear rationale, normally linked to risk treatment, applicable requirements or other justified business needs. The SoA is the written trail from control to the risk it addresses. In practice you do not derive that set from a blank sheet. You adopt the risk-calibrated baseline (CyFun Important), and the SoA records why each control is included, usually the baseline itself, plus any Scaldimet-specific reason, and above all justifies any you exclude. A risk you cannot point to a control for is untreated, and that gap is where this Module hands over to Module 4: the tailored, scenario-based risk work feeds the choices recorded in the SoA.
A teaching simplification
This course separates baseline selection (this Module) from bespoke risk analysis (Module 4) to teach them clearly, one at a time. In a real ISMS the two are not sequential: risk assessment and control selection interact continuously, each informing the other as the system runs and improves.
Scaldimet's ISMS, in outline
- Scope: both sites, IT and OT, including the customer design data and the production systems. (Scoping ISO too narrowly to "head-office IT" would repeat the mandate mistake of Lesson 2.1 and, worse, hand the customer a certificate that excludes the systems they care about.)
- Leadership: satisfied by the Module 2 mandate, policy and security committee.
- Planning: the risk assessment that selects controls, which Module 4 will supply.
- The loop: operate, measure, internally audit, review, improve, and repeat.
Application: what the certificate proves, and the scope¶
On paper, two short tasks.
-
A judgement call. A competitor of Scaldimet buys excellent security tools, writes strong policies and circulates them, but never assesses its risks, never checks whether its controls work, and never reviews or improves anything. It applies for ISO 27001 certification. Would it pass? Decide yes or no, and write one sentence saying why.
-
Scope. Write Scaldimet's ISMS scope statement in two sentences: what is in, what is out, and why. Watch the trap from Lesson 2.1: a scope of "head-office IT" would hand the customer a certificate that excludes the very systems they care about.
Model answer (open after you've drafted yours)
A strong answer to (1): no. ISO 27001 does not certify tools or policies; it certifies a management system, the loop of assessing risk, choosing controls, checking they work, and improving them. A company with products but no risk assessment, no evaluation and no improvement has no ISMS to certify, however good its equipment. That is the whole point of this Lesson: the certificate is about the system for managing security, not the security itself.
For (2), a workable scope: "The ISMS covers both Scaldimet sites, including IT and operational technology, the customer design data and the production systems. It excludes any system that holds none of the assets the customer or the regulators care about, and says so explicitly." The one clause Scaldimet cannot yet satisfy is Planning (the risk assessment); that is the gap Module 4 fills, and the point where compliance hands over to risk analysis.
Key takeaway
ISO 27001 certifies an ISMS, a managed loop for running security, not a state of being secure. Its clauses (context, leadership, planning, support, operation, performance evaluation, improvement) describe continual improvement, and much of it is the Module 2 governance work formalised. Above all it is risk-driven: controls are selected because a risk assessment requires them, and the Statement of Applicability is the written trail from risk to control. That trail is what connects the controls back to risk, and the planning clause is where compliance hands over to the risk work of Module 4.
Next: Lesson 3.3.B · Annex A controls and the certification journey →