Control design
Turning policy into practice: what a control is, the preventive/detective/corrective families, and mapping controls to the risks and obligations they satisfy.
A charter states intent; controls are how intent becomes reality. A control is a specific, verifiable safeguard that reduces a risk or satisfies an obligation — the concrete mechanisms that make 'we ensure human oversight' true rather than aspirational. This lesson is where governance meets the engineering work of the whole track: the evals, guardrails, and audit logs the technical courses built are controls, and a governance leader's job is to specify which controls each system needs and confirm they exist.
The three control families
- Preventive — stop the bad thing from happening. The impact-assessment intake gate (unassessed systems can't ship), least-privilege tool design, code-side action validators, input redaction, data-governance gates before training. The strongest kind: they prevent rather than react.
- Detective — catch it when it happens. Monitoring and quality metrics (Vigil-style data observability, LLMOps sampled evals), audit logs, red-team suites in CI, bias testing, anomaly alerts. They don't prevent, but they shrink the time-to-discovery from 'a customer told us' to 'our monitor flagged it'.
- Corrective — limit the damage and recover. Rollback, kill switches, incident-response procedures, human override, remediation workflows. What you're glad exists when prevention and detection both missed.
A well-governed high-risk system has all three, in depth — the same defense-in-depth logic the security course taught, now framed as organizational controls. The HR tool needs preventive (human review before any rejection), detective (periodic bias audit), and corrective (a process to review and reverse wrongful rejections).
Mapping controls to risks and obligations
The discipline is traceability: every material risk and every regulatory obligation is covered by at least one named control, and every control traces back to what it satisfies. This bidirectional mapping is what lets you answer 'how do you ensure X?' with 'control Y, here's its evidence' — and lets you spot the risk with no control (an uncovered gap) or the control satisfying nothing (busywork). Proportionality applies: critical and legally high-risk systems get more, stronger, independently-verified controls; low-risk ones get light-touch self-attestation. Over-controlling a low-risk tool wastes effort you owe to the critical one.
Designed well vs. operating in fact
Auditors split control quality into two questions, and so should you. Design effectiveness — would this control address the risk if performed as described? Operating effectiveness — is it actually performed, consistently, by people who take it seriously? A control can pass the first and fail the second: Problem set 4's human reviewer who approves 100% of decisions in 2 seconds each is a well-designed oversight control that is not operating. The testing methods, in one line: inquiry (ask the operator), observation (watch it run), reperformance (do it yourself and compare), and sampling (pull N instances and check the evidence). Module 4's workshop bakes both questions into the matrix.
A control that depends on a human remembering to do something will eventually fail. Prefer controls built into the system and the pipeline: an eval gate that blocks a bad deploy, a validator that cannot be talked past, an intake gate enforced by tooling. This is why the technical track matters to governance — the engineers' automated guardrails are more reliable controls than any policy a person must remember to follow. Govern toward automation.