Chapter 29 — Capstone build | Technologist Security governance, risk and compliance

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 29 — Capstone build

Lesson map

Lesson 29 published. Map, example, EX085.

flowchart TD
  N0["Learning outcomes"]
  N1["29.1 The tool"]
  N2["29.2 Testing"]
  N3["29.3 Documentation"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX085"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["29.1 The tool"]
  N2["29.2 Testing"]
  N3["29.3 Documentation"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX085"]

[Learning outcomes]
    |
    v
[29.1 The tool]
    |
    v
[29.2 Testing]
    |
    v
[29.3 Documentation]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX085]

Learning outcomes

You will (1) build a capstone GRC tool for Riverton; (2) test it with users; (3) document it for maintenance.

29.1 The tool

For her capstone, Priya builds a small governance dashboard using Python's standard library that reads the risk register, control test results, indicator values and evidence log, and produces a weekly HTML summary for the operations manager. It highlights overdue actions, stale evidence, threshold breaches and failed controls, each with its owner. She keeps the design simple so Riverton's IT coordinator can maintain it. Using only the standard library means the IT coordinator needs no extra packages to keep it running.

29.2 Testing

Priya tests the tool with sample data containing known problems, checking that each is reported correctly. She then asks the operations manager and two clinic managers to use the summary for two weeks. They find it useful but ask for a clinic filter. One manager notices that a resolved action still appears because the source file was not updated, which leads Priya to add the last-updated date for each source to the summary. The last-updated date lets a reader judge whether an item is truly open or simply based on stale data.

29.3 Documentation

Priya documents the tool: purpose, inputs, outputs, how to run it, how to add a new check, known limitations and who maintains it. She stores the code in Riverton's repository with a change log. She learns that a capstone tool succeeds only if it remains useful after the student leaves, which depends on simplicity, documentation and a named maintainer. The section on adding a new check matters most, because Riverton's needs will change after she leaves. A change log in the repository shows what changed between versions and why.

Worked example

Priya builds a weekly governance summary, tests it with known problems and users, adds a clinic filter and source dates and documents maintenance.

Synthetic case. The tool and data are synthetic.

Errors and limits

Dashboards can be ignored. Source data quality limits value.

Exercises

EX085 — Highlights. What does the weekly summary highlight? Rubric: 3 = overdue actions, stale evidence, threshold breaches, failed controls;; 2 = four;; 1 = vague;; 0 = none.
EX086 — Source dates. Why did Priya add last-updated dates for each source? Rubric: 3 = a resolved action appeared because a source was stale;; 2 = freshness;; 1 = vague;; 0 = none.
EX087 — Lasting value. What does lasting value depend on? Rubric: 3 = simplicity, documentation and a named maintainer;; 2 = maintainability;; 1 = vague;; 0 = none.

Synthesis

A capstone tool must be tested with users and documented for others to maintain.

Continue studying — chapter 29 of 30

← Chapter 28 (draft) · Course chapter index · Chapter 30 (draft) →