Designing Controls With an Owner, a Trigger and an Artefact

This lesson builds on the previous one by diving deep into control design, which is the skill that separates competent compliance teams from those that write controls that look good on paper but fail in practice.

A well-designed control has three attributes: it is owned by a named person, it is triggered by a specific event, and it produces evidence (an artefact) that it executed. Too many controls fail because they miss one of these three. A control with no owner is a control that no one does. A control with a fuzzy trigger executes unpredictably. A control that produces no artefact cannot be verified.

Start with the owner. This is a named person in line 1 or line 2, not a title or department. “The compliance team will review data quality” is not an assignment; “Jane Smith, Senior Compliance Officer, will review data quality” is. Assigning a named owner is uncomfortable because it creates accountability, but that discomfort is exactly why it works. Jane knows that her name is on the control and that compliance will ask for evidence of her review.

Triggers define when the control must execute. Triggers can be event-based (when a new model is trained, when a data breach is discovered, when a new supplier is onboarded) or time-based (quarterly, annually, before each deployment). Event-based triggers are ideal because they link the control to a specific change that increases risk. Time-based triggers work for ongoing monitoring (Does the model still perform well? Has anyone reported fairness concerns?).

Write triggers specifically. “When risk changes” is too vague. “When a high-risk system is modified to process data for a new population” or “When a model’s accuracy on the monthly holdout test drops below 85 percent” are clear triggers that tell an owner exactly when to act.

Artefacts are the evidence that a control executed. If the control is “bias testing before deployment”, the artefact is the bias test report with results and a sign-off. If the control is “human review of high-risk decisions”, the artefact is a sample of decision logs showing that a human reviewed and approved before the system acted. Artefacts should be stored where compliance can find them: a shared drive, a database, a system log.

Some controls produce artefacts that are easy to fabricate or audit-trail. A signature on a form saying “I have reviewed the model” is an artefact, but you cannot tell from it whether the review was superficial. A bias test report with numerical results is harder to fake and gives compliance the information needed to assess the review’s quality.

Design controls with line 1 execution in mind. If a control requires expertise that line 1 does not have, either provide that expertise or design a simpler control. A control that says “Run a statistical fairness test before deployment” will fail if line 1 does not know how to run it. A control that says “Complete a fairness checklist with the risk assessment team” is more likely to execute because it involves someone with the expertise.

Build controls in layers that reflect operational reality. A preliminary control might be a self-assessment by the system owner: “Does this system process data on protected groups?” If the answer is yes, a secondary control triggers: “Complete a fairness testing plan.” Only if the plan is approved does a tertiary control trigger: “Execute the testing and provide results.” This layered approach allocates testing effort where it matters most.

Automation can strengthen controls by reducing execution burden. If fairness testing happens today through manual spreadsheet work, it is often skipped. If you build automated testing into your model validation pipeline, testing happens every time a model is trained. Automation also creates logs that are hard to falsify.

Control design requires iteration. The first version of your controls will include some that are too burdensome for line 1 to follow and others that produce so little evidence that compliance cannot verify them. Run a pilot with a subset of systems. Ask line 1 what barriers they face. Adjust the controls and try again. After several cycles, you will have controls that actually work.

Control documentation should include not just what the control is, but why it exists. What regulatory obligation does this control address? What harm is it meant to prevent? This context helps line 1 understand the control’s importance and helps auditors understand its design rationale. When a control owner questions why they must follow a procedure, understanding the regulatory context or risk it addresses often clarifies the importance.