Chapter 36 — Security governance, risk and compliance: performance and scale

Lesson map

Lesson 36 published. Map, example, EX106.

flowchart TD
  N0["Learning outcomes"]
  N1["36.1 Workload"]
  N2["36.2 Bottlenecks"]
  N3["36.3 Automation and sampling"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX106"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["36.1 Workload"]
  N2["36.2 Bottlenecks"]
  N3["36.3 Automation and sampling"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX106"]

[Learning outcomes]
    |
    v
[36.1 Workload]
    |
    v
[36.2 Bottlenecks]
    |
    v
[36.3 Automation and sampling]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX106]

Learning outcomes

You will (1) estimate the workload of a GRC programme; (2) find bottlenecks as it scales; (3) reduce effort through automation and sampling.

36.1 Workload

Nadia estimates the yearly workload of Ardwell's programme: eighty controls with tests at various frequencies, quarterly access reviews across ten systems, monthly recording sampling and annual audits. She counts hours per activity using owners' estimates and finds the total close to two full-time staff, spread thinly across many people. She learns that GRC programmes often fail not from bad design but from underestimated effort, which leads to skipped tests and stale evidence. Spread over many people, two full-time equivalents can disappear into other duties, which is how tests get skipped.

36.2 Bottlenecks

As Ardwell plans to add a second control centre and more vendors, Nadia models growth. Access reviews and evidence collection scale with systems and vendors, but the security analyst who checks evidence is a single person. At current growth, her queue would double within a year. Nadia identifies her as the bottleneck and recommends spreading review across trained control owners, with the analyst sampling their work. Finding the narrowest point lets Ardwell invest where it matters most. Training control owners to check their own evidence keeps the analyst's role as a sampler rather than the only checker.

36.3 Automation and sampling

Nadia lists tasks that could be automated: collecting patch levels, exporting account lists and checking configuration baselines. Automation reduces effort and improves consistency, though scripts need their own testing and ownership. For tasks requiring judgement, such as reviewing recordings, sampling reduces effort while keeping assurance. She learns that scale in governance comes from designing evidence to flow from systems automatically, reserving human attention for decisions, exceptions and the things automation cannot judge. Automated patch level collection, for example, removes a manual task while making monthly evidence consistent.

Worked example

Nadia estimates about two full-time staff of effort, finds the evidence analyst as the bottleneck and proposes automation and sampling.

Synthetic case. Workload estimates are synthetic.

Errors and limits

Hour estimates are rough. Automation can fail silently.

Exercises

• EX106 — Total effort. Roughly how much effort does the programme require?
  Show marking criteria

  Rubric: 3 = about two full-time staff;; 2 = two FTE;; 1 = vague;; 0 = none.
• EX107 — Bottleneck person. Who is the bottleneck as Ardwell grows?
  Show marking criteria

  Rubric: 3 = the single security analyst checking evidence;; 2 = analyst;; 1 = vague;; 0 = none.
• EX108 — Human focus. Where should human attention go once evidence is automated?
  Show marking criteria

  Rubric: 3 = decisions, exceptions and judgement tasks;; 2 = judgement;; 1 = vague;; 0 = none.

Synthesis

Scalable governance automates evidence and reserves human attention for judgement.

Continue studying — chapter 36 of 50

← Chapter 35 (draft) · Course chapter index · Chapter 37 (draft) →