Policies, procedures and the control framework

A risk assessment says what can go wrong; the control framework says what the firm does about it, who does it, and how anyone can tell that it was done. Supervisors and auditors judge a program by this chain: a policy that matches the risk, procedures staff actually follow, controls that work, and evidence that they were tested. This lesson shows how to build each link and connect them.

The policy hierarchy

Documents work best in layers, each more detailed and more frequently changed than the one above.

A multi-country firm usually writes one group policy set to the strictest common standard and adds short country addenda for local differences, such as a lower Travel Rule threshold or a local reporting format. The addenda point back to the group policy instead of rewriting it. The method for identifying those local differences is in the lesson How national regimes implement the standard.

Every document carries an owner, a version number, an approval date and the date of the next review. A policy past its review date is one of the easiest findings an examiner can write.

Writing procedures that work

Most weak procedures fail in one of three ways: they copy the law instead of describing tasks, they describe an ideal process the systems do not support, or they never say what evidence to keep. A good procedure step answers six questions:

1. Trigger: what starts the step (an alert, a new customer, a list update).
2. Actor: which role performs it, and who reviews it.
3. Action: what is checked, in which system, against which criteria.
4. Timing: the deadline, such as "within 24 hours of the list update".
5. Decision and escalation: the possible outcomes and where each goes.
6. Evidence: what record is saved, where, and in what form.

Test a draft by walking through it with the people who will use it, on the real system. If a step cannot be performed as written, change the procedure or the system before go-live, not after the first audit.

Preventive and detective controls

A control is an action or system feature that reduces the likelihood or impact of a risk. Preventive controls stop an event before it happens; detective controls find it afterward so that it can be corrected and reported. A sound framework mixes both, because no preventive control is perfect.

Controls also differ by how they run: automated controls work consistently once configured but fail silently if the configuration is wrong; manual controls adapt to context but vary with the person. A key control is one whose failure alone would leave a material risk uncovered; key controls get tested first and most often. A third family, corrective controls, limits the damage once something is found: freezing funds, restricting or exiting the customer, filing a report, and fixing the root cause.

Mapping risks to controls

The risk and control matrix (RCM) links each risk in the enterprise-wide risk assessment (see the lesson The risk-based approach) to the controls that mitigate it.

Review the matrix for three kinds of gap: risks with no control or only detective controls, orphan controls that map to no risk and may be wasted effort, and single key controls carrying a high-risk area alone. The RCM is also how control ratings feed back into the residual risk scores of the risk assessment.

Exceptions and overrides

Every framework needs a controlled way to depart from it, or staff will find an uncontrolled one. A sound exception process:

• names who may approve each type of exception, and never lets the person who benefits approve it;
• sets an expiry date and a compensating control, such as lower limits while a document is outstanding;
• records every exception in a register with its reason, approver and expiry;
• requires two people and a reason code to override an automated control, such as releasing a withdrawal that screening blocked.

Report the exception rate and its trend to the compliance officer. Many exceptions against the same rule mean either the rule is wrong and should be changed, or the business is working around it, which is a culture problem (see the lesson Training, culture and independent testing).

Testing controls

Testing asks two questions. Design effectiveness: if the control works as described, does it address the risk? Operating effectiveness: did it actually work, consistently, over the period? Test methods range from inquiry (weakest) through observation and inspection of records to reperformance, where the tester repeats the control and compares results.

For manual controls, samples scale with frequency. Common audit practice, not a formal standard, uses about 1 sample for an annual control, 2 for quarterly, 2–5 for monthly, 5–15 for weekly, 20–40 for daily and 25–60 for controls performed many times a day. An automated control can be tested once, provided the controls over changes to its configuration (who can change a screening threshold, and how changes are approved) are also tested.

Data lets a tester check the whole population instead of a sample:

-- Test of control TR-01: VASP withdrawals in Q2 2026 broadcast
-- without an outgoing Travel Rule message sent at or before broadcast
SELECT w.withdrawal_id, w.customer_id, w.amount_usd,
       w.broadcast_at, m.sent_at
FROM withdrawals w
LEFT JOIN travel_rule_messages m
       ON m.withdrawal_id = w.withdrawal_id
      AND m.direction = 'OUT'
WHERE w.destination_type = 'VASP'
  AND w.broadcast_at >= DATE '2026-04-01'
  AND w.broadcast_at <  DATE '2026-07-01'
  AND (m.sent_at IS NULL OR m.sent_at > w.broadcast_at);

The LEFT JOIN keeps withdrawals that have no message at all, and the last condition returns those plus any whose message was sent only after the transfer left. Every row is an exception to investigate; zero rows across the full quarter is strong evidence of operating effectiveness. The DATE literal syntax is standard SQL, but some engines expect a function or a plain string instead.

Rate each result on a simple scale, such as effective, needs improvement or ineffective, and record the evidence behind the rating. A key control rated ineffective raises an issue with an owner and a deadline, and the residual risk it supported is reassessed until the fix is proven.

The compliance monitoring plan

Second-line testing follows a compliance monitoring plan: a risk-based annual schedule of reviews, approved by the compliance officer and reported to the board. It is distinct from internal audit's independent plan (see the lesson Training, culture and independent testing), though the two should be coordinated to avoid gaps and duplication.

Each review produces rated findings that enter the firm's issue log. ISO 37301:2021, the international standard for compliance management systems, offers a widely used structure for the whole cycle: identify obligations, assess risk, set controls, monitor, and improve.

Exam focus: the levels of the policy hierarchy, who approves each and how often each is reviewed; group policy with country addenda; the six questions a procedure step must answer; preventive versus detective and automated versus manual controls, with crypto examples, and key controls; building a risk and control matrix and spotting gaps and orphan controls; design versus operating effectiveness, test methods, sample sizes and testing automated controls with change controls; full-population testing with data; the purpose of the compliance monitoring plan and how it differs from internal audit.