Chapter 21 — Security governance, risk and compliance: requirements
Lesson map
Lesson 21 published. Map, example, EX061.
flowchart TD
N0["Learning outcomes"]
N1["21.1 From obligations to requirements"]
N2["21.2 Testable requirements"]
N3["21.3 Prioritising"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX061"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["21.1 From obligations to requirements"]
N2["21.2 Testable requirements"]
N3["21.3 Prioritising"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX061"]
[Learning outcomes]
|
v
[21.1 From obligations to requirements]
|
v
[21.2 Testable requirements]
|
v
[21.3 Prioritising]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX061]
Learning outcomes
You will (1) derive programme requirements from obligations and appetite; (2) write requirements that can be tested; (3) prioritise them.
21.1 From obligations to requirements
Obligations are often broad. Nadia turns them into specific requirements for Ardwell's programme. For example, a contractual obligation to protect card data becomes requirements to keep a current inventory of cardholder data systems, to restrict access to them by business need and to review that access regularly. The board's appetite statement that no single incident should interrupt supply for more than four hours becomes a recovery requirement for control-system backups and spare equipment. The four-hour limit then becomes the yardstick against which recovery tests in later chapters are judged.
21.2 Testable requirements
Nadia learns to write requirements so they can be tested. A vague requirement such as access should be appropriate cannot be checked. A testable version says that access to cardholder data systems is reviewed every quarter and that excess access found is removed within ten working days. Each testable requirement names an owner, a frequency, a measurable condition and evidence. She rewrites twelve of Ardwell's requirements this way and finds that three had no clear owner at all. The three requirements without owners join the register as gaps to be assigned before any test can run.
21.3 Prioritising
Not every requirement is equally urgent. Nadia ranks them by the consequence of failure and by whether they are mandatory. Requirements tied to safety of the electricity supply and to contractual card obligations rank highest. Requirements that support voluntary certification rank next. Improvements for efficiency come last. She presents the ranking to the information security manager with reasons, so that limited staff time goes first to the requirements whose failure would harm customers or breach obligations. Ranking with reasons also lets the security manager challenge the order if a voluntary item has become contractual.
Worked example
Nadia derives requirements from obligations and appetite, rewrites twelve as testable statements and ranks them by consequence.
Synthetic case. Requirements are synthetic.
Errors and limits
Testable wording can miss intent. Priorities shift with incidents.
Exercises
- EX061 — Appetite to requirement. Which requirement followed from the four-hour appetite statement? Rubric: 3 = a recovery requirement for control-system backups and spares;; 2 = recovery;; 1 = vague;; 0 = none.
- EX062 — Testable parts. What does each testable requirement name? Rubric: 3 = owner, frequency, measurable condition and evidence;; 2 = four parts;; 1 = vague;; 0 = none.
- EX063 — Top priority. Which requirements ranked highest? Rubric: 3 = safety of supply and contractual card obligations;; 2 = safety;; 1 = efficiency;; 0 = none.
Synthesis
Specific, testable and prioritised requirements turn obligations into an executable programme.
Continue studying — chapter 21 of 50
← Chapter 20 (draft) · Course chapter index · Chapter 22 (draft) →