ISO/IEC 27001

Sooner or later a customer, a partner, or a regulator asks some version of: "prove you manage information security systematically." In much of the world — especially Europe and in regulated industries — the accepted answer is ISO/IEC 27001: an internationally recognized standard for running an Information Security Management System. The GRC analyst meets it three ways: helping the organization implement it, preparing for the certification audit, and answering customer questionnaires that assume it. This lesson teaches what the standard is and how its pieces fit, so you can work with it without ever having read the paid text.

Level 3 · Apply — do it unaided on an unfamiliar authorized target, and explain why it worked and what would have stopped it

Worked case authored and reviewed 2026-10-10 · no command line in this lesson

ISO/IEC 27001:2022 is a paid document sold by ISO. Everything in this lesson is taught from ISO's own free pages and the framework mappings, per the brief — never from the standard's text.

1. Where this shows up

Sooner or later a customer, a partner, or a regulator asks some version of: "prove you manage information security systematically." In much of the world — especially Europe and in regulated industries — the accepted answer is ISO/IEC 27001: an internationally recognized standard for running an Information Security Management System. The GRC analyst meets it three ways: helping the organization implement it, preparing for the certification audit, and answering customer questionnaires that assume it. This lesson teaches what the standard is and how its pieces fit, so you can work with it without ever having read the paid text.

2. Before you start

• You can write Current-vs-Target profiles (e-csf-20). ISO 27001's controls are one catalog you can map to those outcomes.
• You can assess risk (e-risk-assessment). Risk assessment is not a prerequisite for this lesson the way it is for others — it is the engine inside this standard. Every control decision here traces to a risk decision.
• No tools. The work products are a theme-level readiness checklist and a Statement of Applicability sketch. Bring the brief's rule: the standard is paid — one line, stated above, and we never discuss its price.

3. How it works

The ISMS concept. ISO/IEC 27001 does not tell you which firewall to buy. It specifies the requirements for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS) — a systematic way to manage the security of information the organization owns or handles, whatever form that information takes: digital, paper, or in people's heads. The standard is risk-based to its core: identify the risks to information, choose controls that treat them, and prove the controls keep working. An ISMS is a management system the way a quality system is — the subject happens to be information security.

The shape of the standard. Two parts, with different jobs:

• Clauses 4–10: the management system. These are the certifiable requirements — the part an auditor actually audits. In plain terms: understand your context (clause 4), get leadership accountable (5), plan around risk (6), resource and train (7), operate the system (8), check that it works (9), and fix and improve it (10). This is the Plan-Do-Check-Act loop wearing formal clothes. (Plan-Do-Check-Act: the continuous-improvement cycle — plan the change, do it, check the result, act on what you learned — here applied to security management.) If the organization does these seven things genuinely, it has an ISMS; if it only has the second part, it has a control list.
• Annex A: the control catalog. A reference set of 93 controls in four themes — organizational, people, physical, and technological — covering areas like organizational policies, access control, cryptography, physical security, incident management, and supplier relationships. Annex A is a menu, not a mandate: the organization selects controls based on its risk assessment. Implementing all 93 without a risk reason is as wrong as implementing twelve.

The risk assessment is the engine. The standard's logic runs: identify information security risks → decide how to treat each (modify, retain, avoid, share) → select Annex A controls (plus any of your own) that implement the treatments → write down why. Controls without a risk behind them are decoration; risks without a control or an explicit acceptance are gaps. This is why the lesson's prerequisite is the risk lesson, not a controls list.

The Statement of Applicability: the load-bearing artifact. The SoA is the document where the organization records, for each Annex A control, whether it applies and — critically — the justification either way, tied to the risk assessment. It is the single document an auditor, a customer, and your own future self all read first: it shows that control selection was a reasoning process, not a shopping trip. A good SoA justifies exclusions as carefully as inclusions ("control A.5.x excluded: no remote working in scope; risk accepted by CTO, 2026-09") — because an unjustified exclusion is indistinguishable from a gap nobody noticed. The auditor cannot tell "deliberate" from "forgotten" without the written reasoning.

Certification: voluntary, and what it means. An organization may implement the standard purely for its own benefit, or it may seek certification: an independent certification body audits the ISMS against Clauses 4–10 and issues a certificate scoped to the assessed ISMS. Certification bodies are commonly accredited by a national accreditation body, which is the competence check on the checkers. Two honesties: certification attests that the management system meets the standard — it is not a penetration test and not a guarantee against breach; and "certified to ISO/IEC 27001:2022" names the full reference, because editions matter.

How it relates to the CSF. The CSF states outcomes; ISO 27001 provides a management system plus a control catalog that can satisfy them. NIST's Informative References map the two explicitly — the same control selection can serve both masters, which is why organizations rarely implement either in isolation.

4. Walkthrough

No CLI by design — the walkthrough is the worked case, authored and self-reviewed 2026-10-10. The fictional company is Meridian Analytics (180-person SaaS analytics firm, continued from e-csf-20). Every fact about Meridian is invented and labeled. The standard's text was not consulted; all structure below comes from ISO's free pages (Help Centre ISMS overview, the standard's public page) and the CSF mapping.

Step 1 — Frame the ISMS scope. Meridian's ISMS scope: the SaaS production platform, corporate IT, and the people who operate both. Explicitly out of scope: the office cleaning contractor's systems (no information access). Scope owner: CTO. This scoping decision is recorded first because everything — risk assessment, SoA, certificate — inherits it.

Step 2 — Theme-level readiness checklist. For each of the four Annex A themes, assess readiness against Meridian's (fictional, labeled) evidence. Two to three control areas per theme, worked:

Organizational theme — policies exist but are unsigned drafts (evidence: wiki, "draft" watermark, 2026-02); supplier security reviews happen ad hoc before big contracts (evidence: two email threads); incident response roles are named in the IR plan (evidence: plan v1.2). Readiness: partial — the policy set needs approval and publication.

People theme — onboarding includes a security briefing (evidence: onboarding checklist, signed); no periodic refresher; privileged-user screening at hire only. Readiness: partial — joiner process works, mover/leaver and refresher are gaps.

Physical theme — office badge access with visitor log (evidence: badge system export); server room behind a second locked door; no tailgating challenge culture. Readiness: adequate for the risk — Meridian's information lives in the cloud, so physical controls are proportionally light, and the SoA will say so.

Technological theme — SSO+MFA enforced (evidence: IdP policy); encryption at rest on production datastores (evidence: cloud console screenshots); logging central but unalerted (evidence: SIEM config — the same DE.CM gap from the CSF profile). Readiness: strong on identity and data protection, weak on detection.

Step 3 — Draft the Statement of Applicability (sketch). Five rows worked in full, showing the justification discipline; the reader extends the pattern:

| Control area (theme) | Applies? | Justification (risk-tied) |

|---|---|---|

| Information security policies (organizational) | Yes | Risk: inconsistent handling of customer data across teams. Treatment: publish and approve the policy set; review annually. Evidence: approved PDFs in the policy repo. |

| Supplier relationships (organizational) | Yes | Risk: analytics pipeline depends on two sub-processors with data access. Treatment: security review before contract + annual re-review. Evidence: review records. |

| Remote working (organizational) | No | Justification: Meridian has no remote-working arrangement outside the managed-device VPN; the risk the control addresses does not exist in scope. Accepted by CTO, 2026-09. |

| Disciplinary process (people) | Yes | Risk: insider misuse without consequence framework. Treatment: HR-owned process linked to the acceptable-use policy. |

| Physical entry controls (physical) | Partial | Justification: proportional — production information assets are cloud-hosted; office controls cover the residual (visitor access to workstations). Documented as a scoped application, not an exclusion. |

Step 4 — Map to the CSF profile. Each "Yes" row above traces to a CSF Subcategory outcome from the e-csf-20 profile (e.g., access-control rows → PR.AA; policy rows → GV.PO). The mapping is recorded in a third column of the working SoA — one selection of controls, two frameworks satisfied.

Step 5 — Self-review. Checklist, all true before this ships: every SoA row has a risk behind it or a written exclusion; no row says "applies" without naming the treatment; the physical theme's lightness is argued from where the information actually lives, not from laziness; the words "certified" appear nowhere (Meridian is implementing, not certified); nothing in this document quotes the standard's text.

5. On your own

Extend Meridian's SoA sketch to five more control areas of your choice — at least one exclusion with a written justification and one "partial" with a scoped rationale. Success test: a skeptical auditor reading only your SoA can reconstruct why each decision was made, and cannot find a control that applies "because best practice."

6. Where it goes wrong

• The certificate as the goal. Organizations that implement for the audit, not the risk, get both wrong: the ISMS withers the day after the certificate arrives, and the next incident reveals the gap. Certification is evidence of a system, not a substitute for one.
• Annex A as a mandatory checklist. Implementing all 93 controls without risk reasons is the most expensive way to misunderstand the standard. The auditor will ask why each control is there; "because it's in Annex A" is not an answer the standard accepts.
• Copy-paste SoA. A Statement of Applicability that could belong to any company belongs to no company. If your exclusions don't mention your actual scope, they aren't justifications.
• Scope games. Drawing the ISMS scope around the tidy parts and excluding the messy production system. Auditors and customers both read the scope statement first, for exactly this reason — the tell is the scope statement itself: the production platform excluded while the office Wi-Fi is included.
• 27001 vs 27002 confusion. 27001 states the requirements (the auditable part); 27002 gives guidance on implementing the controls. Citing 27002 as the requirement is a category error the lesson corrects once, here.

7. Read the source

1. ISO's own standard page for ISO/IEC 27001:2022 (iso.org) — read the "What is" and FAQ sections: the ISMS concept, the voluntary-certification model, the accredited-body structure. The standard itself is paid — this page is the free, authoritative shape of it.
2. ISO Help Centre: ISO/IEC 27001 — Information Security Management Systems — read: the four Annex A themes, the 93-control catalog described at theme level, the risk-based implementation narrative. This is the page this lesson's structure follows.
3. NIST's CSF pages on Informative References (via nist.gov/cyberframework) — skim to see how ISO 27001 controls map to CSF outcomes; this is the practical reason organizations run both frameworks off one control selection.

8. Check yourself

1. Meridian excludes the remote-working control area because it has no remote working. A year later it hires ten remote engineers. What breaks, in the ISMS logic, if nobody revisits the SoA — and which clause's requirement ("continually improve") is the mechanism that should have caught it?
2. An auditor asks why Meridian's physical controls are light. Give the answer the SoA gives — and explain why "our data is in the cloud" alone would not be an acceptable justification.
3. A vendor tells you they are "ISO 27001 certified, so all 93 Annex A controls are implemented." Name two things wrong with that sentence.
4. Your SoA says a control "applies" but the treatment column is blank. What question will the auditor ask, and what does the blank reveal about the risk assessment?
5. Meridian wants one control selection to satisfy both the CSF Target Profile and the ISO 27001 SoA. Sketch the argument for why this is legitimate — and the one thing you must not do when maintaining the two documents.

9. Prove it

The artifacts: (1) a theme-level readiness checklist for a fictional organization (four themes, evidence per row, labeled fictional); (2) a Statement of Applicability sketch — at least ten rows, each with applies/does-not-apply and a risk-tied justification, including at least one honest exclusion and one scoped partial. Publish both as documents a stranger can audit.

After this lesson you can honestly claim: you can draft a risk-based control selection and defend it in a Statement of Applicability. You cannot yet claim: implementation experience against the real standard's text, audit experience, or any certification — those come from doing the work for real.

10. Leads to

• e-soc2 — the attestation engagement that tests whether controls like these actually operate.
• e-security-audits — audit method: what an auditor does with your SoA.
• e-cyber-law — the contractual commitments (customer DPAs, SLAs) that drive which controls matter.
• GRC analyst path: this lesson is the control-selection method the path's "one control mapped to exact evidence" checkpoint assumes.