OpenCyber AcademyLesson map
Lesson 16 published. Map, example, EX046.
flowchart TD
N0["Learning outcomes"]
N1["16.1 Programme as a system"]
N2["16.2 Traceability"]
N3["16.3 Life cycle"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX046"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["16.1 Programme as a system"]
N2["16.2 Traceability"]
N3["16.3 Life cycle"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX046"]
[Learning outcomes]
|
v
[16.1 Programme as a system]
|
v
[16.2 Traceability]
|
v
[16.3 Life cycle]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX046]
Learning outcomes
You will (1) treat the governance programme as a system with requirements and interfaces; (2) trace requirements to controls and tests; (3) manage the system's life cycle.
16.1 Programme as a system
Systems engineering treats complex efforts as systems with purposes, components, interfaces and life cycles. Nadia applies this view to Ardwell's governance programme. Its purpose is to keep risk within the board's appetite and demonstrate compliance. Its components include policies, the risk register, control owners, monitoring and audits. Interfaces connect it to finance, operations and regulators. Viewing governance as a system helps her ask engineering questions, such as what happens when one component fails or an interface changes. When the board changes its appetite, for example, the interface to monitoring must change too, or reports will measure against an old target.
16.2 Traceability
A core systems engineering tool is the traceability matrix. Nadia links each governance requirement, from law, contract or standard, to the controls that satisfy it and to the tests that show they work. Gaps appear as requirements with no control or controls with no test. She recognises this as the same coverage problem studied in compliance mapping. Traceability lets Ardwell answer an auditor's question about any requirement quickly and shows managers which controls exist only to satisfy obligations that may have lapsed. A requirement whose legal source has lapsed, for instance, would show in the matrix as a control kept only by habit.
16.3 Life cycle
Systems have life cycles: concept, development, operation, maintenance and retirement. Governance components do too. Policies are drafted, approved, used, reviewed and withdrawn. Controls are designed, implemented, tested and eventually replaced. Nadia notes that retirement is often neglected; old controls and policies remain on paper long after they stop working. NIST SP 800-37 Rev. 2 frames risk management as continuous across the life cycle, and she adopts its emphasis on monitoring as the step that keeps the system honest. An access review that still lists a retired billing system, for instance, is a control past its retirement point.
Worked example
Nadia models governance as a system, builds a requirement-to-control-to-test trace and plans life-cycle management including retirement.
Synthetic case. Ardwell's programme is synthetic; SP 800-37 Rev. 2 is real.
Errors and limits
System views can become bureaucratic. Traceability needs upkeep.
Exercises
- EX046 — Programme purpose. What is the purpose of Ardwell's governance programme as a system?
Show marking criteria
Rubric: 3 = keep risk within appetite and demonstrate compliance;; 2 = purpose;; 1 = vague;; 0 = none. - EX047 — Trace gaps. What gaps does a traceability matrix reveal?
Show marking criteria
Rubric: 3 = requirements without controls and controls without tests;; 2 = gaps;; 1 = vague;; 0 = none. - EX048 — Neglected stage. Which life-cycle stage is often neglected for controls and policies?
Show marking criteria
Rubric: 3 = retirement;; 2 = retirement, hedged with another stage;; 1 = design;; 0 = none.
Synthesis
Systems engineering brings traceability and life-cycle thinking to governance programmes.
Continue studying — chapter 16 of 50
← Chapter 15 (draft) · Course chapter index · Chapter 17 (draft) →