Chapter 27 — Security governance, risk and compliance: control design
Lesson map
Lesson 27 published. Map, example, EX079.
flowchart TD
N0["Learning outcomes"]
N1["27.1 Control objectives"]
N2["27.2 Using a catalogue"]
N3["27.3 Documenting for testing"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX079"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["27.1 Control objectives"]
N2["27.2 Using a catalogue"]
N3["27.3 Documenting for testing"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX079"]
[Learning outcomes]
|
v
[27.1 Control objectives]
|
v
[27.2 Using a catalogue]
|
v
[27.3 Documenting for testing]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX079]
Learning outcomes
You will (1) design controls with clear objectives and attributes; (2) select controls from a reference catalogue; (3) document controls so they can be tested.
27.1 Control objectives
Nadia learns that a well-designed control starts with an objective: what risk it reduces and how. For vendor access, the objective is that only approved, identified vendors reach control systems, only for approved tasks, with a record of what they did. From the objective she derives attributes: type, frequency, owner, automation level and the evidence produced. Without a clear objective, controls drift into rituals that are performed but no longer linked to the risk they were meant to reduce. The vendor access objective, for instance, makes clear that session recording exists to show what vendors did, not only who connected.
27.2 Using a catalogue
Rather than inventing controls, Nadia consults ISO/IEC 27002:2022 and NIST SP 800-53 Rev. 5. The catalogues offer tested ideas: account management, remote access, session audit and supplier relationship controls. She selects and tailors them to Ardwell, recording which catalogue controls are applied, adapted or excluded, and why. This record resembles the statement of applicability that ISO/IEC 27001:2022 requires, and it lets auditors see that the selection followed from risk rather than habit or convenience. Excluding a catalogue control, for instance, needs a reason tied to Ardwell's risks, such as a control written for a type of system Ardwell does not operate.
27.3 Documenting for testing
Each control description answers who does what, when, using what, and what evidence results. For the monthly recording review, the description names the security analyst, the ten percent sample, the criteria for concern and the report filed in the ticketing system. Nadia checks that an independent tester could verify the control from the description alone. Prof. Brenner notes that ambiguous control descriptions are a common audit problem, because testers and owners then disagree about what the control was supposed to do. The named ten percent sample, for example, gives a tester a fixed number to check rather than a vague instruction to review recordings.
Worked example
Nadia states a control objective, selects and tailors catalogue controls with recorded reasons and writes testable control descriptions.
Synthetic case. Control designs are synthetic; ISO/IEC 27002:2022, 27001:2022 and SP 800-53 Rev. 5 are real.
Errors and limits
Catalogues are generic. Descriptions can describe intent rather than practice.
Exercises
- EX079 — Objective role. Why should every control start with an objective? Rubric: 3 = so it stays linked to the risk it reduces;; 2 = objective;; 1 = vague;; 0 = none.
- EX080 — Selection record. Which ISO/IEC 27001:2022 document does the selection record resemble? Rubric: 3 = the statement of applicability;; 2 = SoA;; 1 = vague;; 0 = none.
- EX081 — Description test. How does Nadia check a control description? Rubric: 3 = an independent tester could verify it from the description alone;; 2 = testability;; 1 = vague;; 0 = none.
Synthesis
Objectives, catalogues and testable descriptions produce controls that can be operated and verified.
Continue studying — chapter 27 of 50
← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →