Chapter 2 — Security governance, risk and compliance: advanced seminar
Lesson map
Lesson 02 published. Map, example, EX008.
flowchart TD
N0["Learning outcomes"]
N1["2.1 Framework landscape"]
N2["2.2 Coverage analysis"]
N3["Lab — Requirement, control and evidence coverage"]
N4["2.3 Critique of mapping"]
N5["2.4 Seminar discussion"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX008"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["2.1 Framework landscape"]
N2["2.2 Coverage analysis"]
N3["Lab — Requirement, control and evidence coverage"]
N4["2.3 Critique of mapping"]
N5["2.4 Seminar discussion"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX008"]
[Learning outcomes]
|
v
[2.1 Framework landscape]
|
v
[2.2 Coverage analysis]
|
v
[Lab — Requirement, control and evidence coverage]
|
v
[2.3 Critique of mapping]
|
v
[2.4 Seminar discussion]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX008]
Learning outcomes
You will (1) compare major governance and control frameworks; (2) analyse requirement-to-control-to-evidence coverage; (3) present a critical seminar argument.
2.1 Framework landscape
In the seminar, Lucas compares frameworks. ISO/IEC 27001:2022 specifies requirements for an information security management system and lists reference controls in Annex A drawn from ISO/IEC 27002:2022. NIST CSF 2.0 organises outcomes under six functions, including the new Govern function. COBIT 2019 addresses governance of enterprise information and technology, separating governance from management. NIST SP 800-53 Rev. 5 offers a detailed control catalogue. He notes that these frameworks overlap heavily but differ in purpose, granularity and whether they can be certified. He keeps a table of these differences for later chapters.
2.2 Coverage analysis
Compliance often asks whether every requirement has a control and evidence that the control works. Lucas builds a small synthetic example for Tessaly: ten policy requirements, eight controls and a record of whether each control has current evidence. The lab finds eight requirements mapped to at least one control but only six with evidence; two requirements are unmapped and two are mapped to controls with no evidence. Coverage is therefore 80% on paper but only 60% in demonstrable terms, a gap auditors are likely to find.
Lab — Requirement, control and evidence coverage
"""Requirement-to-control-to-evidence coverage on synthetic data (stdlib only)."""
reqs = {"R1": ["C1"], "R2": ["C2", "C3"], "R3": [], "R4": ["C4"], "R5": ["C5"],
"R6": ["C6"], "R7": ["C2"], "R8": [], "R9": ["C7"], "R10": ["C8"]}
evidence = {"C1": True, "C2": True, "C3": False, "C4": True, "C5": False,
"C6": True, "C7": True, "C8": False}
mapped = [r for r, c in reqs.items() if c]
evidenced = [r for r in mapped if any(evidence[c] for c in reqs[r])]
print(f"requirements {len(reqs)}; mapped {len(mapped)}; evidenced {len(evidenced)}")
print("unmapped:", ", ".join(r for r, c in reqs.items() if not c))
print("mapped but no evidence:", ", ".join(r for r in mapped if r not in evidenced))
print(f"coverage mapped {len(mapped)/len(reqs):.0%}; evidenced {len(evidenced)/len(reqs):.0%}")
Run with python3 lab_map.py. Verified output:
requirements 10; mapped 8; evidenced 6
unmapped: R3, R8
mapped but no evidence: R5, R10
coverage mapped 80%; evidenced 60%
2.3 Critique of mapping
Lucas argues in his seminar paper that mapping can create an illusion of assurance. A requirement mapped to a control looks covered, but the control may be badly designed, poorly operated or evidenced by a document no one checks. Spears and Barki (2010) found that involving business users in security risk management improved alignment with business processes, which suggests coverage depends on people as well as tables. He recommends that mappings record evidence quality and date, not just a link, so that gaps stay visible.
2.4 Seminar discussion
Classmates challenge him. One argues that mapping is still valuable because it reveals unmapped requirements, such as R3 and R8 in the lab, which would otherwise be forgotten. Another notes that evidence checks cost time, so organisations sample instead of checking everything. Lucas accepts both points and refines his claim: mapping is a necessary first step, but assurance requires tested evidence, and the depth of testing should follow risk. This refinement links his seminar to his thesis question about access reviews.
Worked example
Lucas compares four frameworks, finds 80% mapped but 60% evidenced coverage and argues that assurance needs tested evidence.
Synthetic case. The coverage data are synthetic; the frameworks are real.
Errors and limits
Coverage percentages hide control quality. Frameworks change editions.
Exercises
- EX008 — Certifiable standard. Which of the frameworks discussed specifies certifiable ISMS requirements? Rubric: 3 = ISO/IEC 27001:2022;; 2 = 27001;; 1 = CSF;; 0 = none.
- EX009 — COBIT separation. What does COBIT 2019 separate? Rubric: 3 = governance from management;; 2 = governance;; 1 = vague;; 0 = none.
- EX010 — Mapped count. How many requirements did the lab find mapped? Rubric: 3 = eight of ten;; 2 = 8;; 1 = 10;; 0 = none.
- EX011 — Evidenced coverage. What share of requirements had evidence? Rubric: 3 = 60%;; 2 = six;; 1 = 80%;; 0 = none.
- EX012 — Unmapped items. Which requirements were unmapped? Rubric: 3 = R3 and R8;; 2 = two;; 1 = vague;; 0 = none.
- EX013 — Illusion of assurance. Why can mapping create an illusion of assurance? Rubric: 3 = mapped controls may be badly designed, operated or evidenced;; 2 = quality hidden;; 1 = vague;; 0 = none.
- EX014 — Refined claim. How did Lucas refine his claim after discussion? Rubric: 3 = mapping is necessary, assurance needs risk-based tested evidence;; 2 = refined;; 1 = vague;; 0 = none.
Synthesis
Frameworks overlap; demonstrable coverage requires evidence, not just mappings.
Continue studying — chapter 02 of 08
← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →