Chapter 18 — Security governance, risk and compliance: controls

Lesson map

Lesson 18 published. Map, example, EX052.

flowchart TD
  N0["Learning outcomes"]
  N1["18.1 Documenting controls"]
  N2["18.2 Mapping to obligations"]
  N3["18.3 Statement of applicability"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX052"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["18.1 Documenting controls"]
  N2["18.2 Mapping to obligations"]
  N3["18.3 Statement of applicability"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX052"]

[Learning outcomes]
    |
    v
[18.1 Documenting controls]
    |
    v
[18.2 Mapping to obligations]
    |
    v
[18.3 Statement of applicability]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX052]

Learning outcomes

You will (1) document controls with owners and frequencies; (2) map controls to obligations; (3) prepare a simple statement of applicability.

18.1 Documenting controls

Priya documents Riverton's key controls in a control register: name, objective, owner, frequency, how it operates and the evidence produced. For example, the monthly backup test is owned by the IT lead, restores five sample files from the image archive and produces a dated test record. She learns that clear documentation lets anyone test a control and lets owners know exactly what is expected, which reduces disagreement during audits. Five sample files from the image archive give a concrete, repeatable test that any technician can perform.

18.2 Mapping to obligations

Priya maps each control to the obligations it supports. Encryption supports data protection law. Card terminal segmentation supports PCI DSS v4.0. Access reviews support both data protection and contractual commitments to the practice system provider. Mapping shows which obligations rely on which controls, so a failed control can be assessed for its compliance impact. She learns that one control often supports several obligations, which raises its importance. Access reviews, supporting both law and the provider contract, therefore rank among Riverton's most important controls.

18.3 Statement of applicability

Riverton is considering ISO/IEC 27001:2022 certification in two years. Priya prepares a draft statement of applicability listing reference controls from ISO/IEC 27002:2022 and whether each applies, with reasons. Controls for secure software development are marked not applicable because Riverton does not develop software, though supplier controls cover its providers. She learns that preparing the statement early clarifies scope and highlights gaps long before an audit. Marking supplier controls as applicable instead makes clear how Riverton covers its practice system provider.

Worked example

Priya builds a control register, maps controls to obligations and drafts a statement of applicability with justified exclusions.

Synthetic case. Controls are synthetic; ISO/IEC 27001:2022, 27002:2022 and PCI DSS v4.0 are real.

Errors and limits

Registers age. Mappings can overstate coverage.

Exercises

• EX052 — Backup control. How does the monthly backup test operate?
  Show marking criteria

  Rubric: 3 = IT lead restores five sample files and records the result;; 2 = restore test;; 1 = vague;; 0 = none.
• EX053 — Multi-obligation. Why does a control supporting several obligations matter more?
  Show marking criteria

  Rubric: 3 = its failure affects several obligations;; 2 = importance;; 1 = vague;; 0 = none.
• EX054 — Not applicable. Why are secure development controls not applicable?
  Show marking criteria

  Rubric: 3 = Riverton develops no software;; 2 = no development;; 1 = vague;; 0 = none.

Synthesis

Documented controls mapped to obligations show what each control is for and what its failure means.

Continue studying — chapter 18 of 30

← Chapter 17 (draft) · Course chapter index · Chapter 19 (draft) →