OpenCyber Academy
Engineering · Chapter 27 · English
Course code: OCA-118Chapter 27: OCA-118-C027

Chapter 27 — Data governance: control design

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

Lesson map

Lesson 27 published. Map, example, EX079.

flowchart TD
  N0["Learning outcomes"]
  N1["27.1 Control types"]
  N2["27.2 Control catalogue"]
  N3["27.3 Evidence"]
  N4["27.4 Control testing"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX079"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["27.1 Control types"]
  N2["27.2 Control catalogue"]
  N3["27.3 Evidence"]
  N4["27.4 Control testing"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX079"]
[Learning outcomes]
    |
    v
[27.1 Control types]
    |
    v
[27.2 Control catalogue]
    |
    v
[27.3 Evidence]
    |
    v
[27.4 Control testing]
    |
    v
[Worked example] --> [Exercise EX079]

Learning outcomes

You will (1) design preventive, detective and corrective controls for data; (2) set control ownership; (3) define control evidence.

27.1 Control types

Kofi designs controls for the leakage chain in three types. Preventive controls stop bad data entering: schema constraints and input validation in the field application. Detective controls find problems: daily quality rules, flat-line detectors and reconciliation. Corrective controls fix problems: documented procedures for re-requesting files, correcting readings with approval and restating figures. He explains that relying only on detection leaves owners constantly cleaning up, while prevention reduces the volume of problems at their source. Each type has a named owner in the catalogue.

27.2 Control catalogue

Each control in the catalogue has an identifier, purpose, type, owner, frequency, evidence produced and linked requirement. For example, control DQ-04 checks district completeness daily, is owned by billing, produces a results table and supports the completeness requirement. The catalogue contains thirty-one controls. He maps them to the risks from chapter 23 and finds that two medium risks have no control, so he designs additional controls for them before implementation begins. The catalogue is stored in the repository and versioned, so every change to a control is traceable.

27.3 Evidence

For each control, Kofi defines what evidence shows it operated: stored rule results with timestamps, alert logs, approval records for corrections. He explains that auditors will ask not only whether controls exist, but whether they ran and whether issues were followed up. Evidence that is generated automatically and stored centrally is more reliable than evidence assembled manually before audits, which tends to be incomplete and arrives too late to reveal problems. Kofi configures each control to write its evidence to a shared store with retention of seven years.

27.4 Control testing

Kofi plans control testing. Each quarter, a steward tests a sample of controls by introducing synthetic errors into a test environment and confirming that controls detect them and alerts reach owners. Controls that fail testing are fixed and retested. Prof. Varga notes that untested controls provide comfort rather than assurance, and that deliberately injecting errors is one of the few ways to confirm that detective controls work before a real failure relies on them. Test results are reported to the governance board each quarter.

Worked example

Kofi designs preventive, detective and corrective controls, builds a thirty-one-control catalogue, fills two gaps, defines automatic evidence and plans quarterly error-injection tests.

Synthetic case. Controls are synthetic.

Errors and limits

Controls without evidence cannot be shown to work.

Exercises

Worked answers

EX079. A documented procedure for correcting readings with approval.

EX080. Thirty-one.

EX081. By injecting synthetic errors in a test environment.