Chapter 24 — Security governance, risk and compliance: controls

Chapter 24 — Security governance, risk and compliance: controls

Lesson map

Lesson 24 published. Map, example, EX070.

flowchart TD
  N0["Learning outcomes"]
  N1["24.1 Selecting controls"]
  N2["24.2 Statement of applicability"]
  N3["24.3 Owners"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX070"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["24.1 Selecting controls"]
  N2["24.2 Statement of applicability"]
  N3["24.3 Owners"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX070"]

[Learning outcomes]
    |
    v
[24.1 Selecting controls]
    |
    v
[24.2 Statement of applicability]
    |
    v
[24.3 Owners]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX070]

Learning outcomes

You will (1) select controls for Elmfield's top risks; (2) write a statement of applicability; (3) assign control owners.

24.1 Selecting controls

For each top risk, Sofia selects controls from ISO/IEC 27002:2022. For misdirected data: secure sharing links, recipient checks and training. For lost laptops: encryption and remote wipe. For ransomware: offline backups, multi-factor authentication and limited administrator rights. For contractor misuse: named accounts and access reviews. She learns that selecting from a recognised catalogue makes choices easier to explain and helps ensure nothing obvious is missed. Mapping each control back to a named risk also lets her show auditors why each one was chosen.

24.2 Statement of applicability

ISO/IEC 27001:2022 requires a statement of applicability listing reference controls, whether each is included and why. Sofia drafts one for Elmfield. Most controls are included. Some are excluded with reasons: secure development controls are excluded because Elmfield builds no software, though supplier controls cover its housing system. She learns that exclusions must be justified by scope and risk, not by convenience, and that the statement becomes a key document for auditors. Excluding secure development is justified because Elmfield builds no software, not because the controls would be inconvenient.

24.3 Owners

Each control needs an owner who ensures it operates. Sofia assigns owners: IT lead for backups and encryption, managers for access reviews, data protection lead for sharing rules and the finance manager for supplier contracts. She writes a one-line description of each control's operation. She learns that owners must have both authority and time; assigning everything to the IT lead would overload one person and leave controls unperformed when that person is absent. Splitting ownership across the IT lead, managers, the data protection lead and the finance manager spreads the load across roles with the right knowledge.

Worked example

Sofia selects controls for four risks, drafts a statement of applicability with justified exclusions and spreads ownership.

Synthetic case. Elmfield's controls are synthetic; ISO/IEC 27001:2022 and 27002:2022 are real.

Errors and limits

Catalogue controls need tailoring. Owners change roles.

Exercises

• EX070 — Laptop controls. Which controls address lost laptops? Rubric: 3 = encryption and remote wipe;; 2 = two;; 1 = vague;; 0 = none.
• EX071 — Justified exclusion. Why are secure development controls excluded? Rubric: 3 = Elmfield builds no software;; 2 = no development;; 1 = vague;; 0 = none.
• EX072 — Owner spread. Why not assign all controls to the IT lead? Rubric: 3 = it would overload one person;; 2 = overload;; 1 = vague;; 0 = none.

Synthesis

Catalogue-based selection, a justified statement of applicability and spread ownership make controls real.

Continue studying — chapter 24 of 40

← Chapter 23 (draft) · Course chapter index · Chapter 25 (draft) →