How I create controls that work: a simple method for governance and projects

1. When I realized the problem wasn't the control, but how it was done

In one of my first projects related to banking compliance, I remember opening a controls catalog and thinking: “this looks more like a spreadsheet made to satisfy an audit than to actually help someone”.

It was a huge document, full of acronyms, statuses updated out of obligation, and lines that no one could explain in day-to-day work.
Over time, I realized that the value of a controls catalog lies in being alive, practical, and connected to the business. It should help people make better decisions, not just exist as a compliance showcase.

When I started working more closely with operational areas, I understood that building a useful catalog is less about technique and more about dialogue. In the end, every control needs to answer a simple question: how does this reduce real risk within the process?

2. The scenario: between risk and operations

In a bank, every control exists to protect a critical process, whether it's client onboarding, transaction monitoring, or AML alert management.

Once, during a first-line controls review, the operations team called me to understand why the data quality control seemed so disconnected from reality.
In the spreadsheet, the control read: “check the integrity of master data every monthly cycle”. But no one knew what that meant in practice.

We sat down together and translated it into something operationally meaningful:
“compare the source of funds field from KYC against the registration in the Sigma system and flag discrepancies above 5%”.

The change was immediate.

The same control, which used to be just text, became a decision-making tool. The area was able to measure, correct, and show results.
The following week, other teams started asking for the same kind of clarity. That's when I realized the secret isn't in listing controls, but in making them applicable.

3. What makes a controls catalog truly useful

After building and reviewing dozens of them, I learned a few principles that always guide me:

1. Each control needs to address a specific risk.
   If the risk is “clients with inconsistent documentation,” then the control should target exactly that, with clear evidence.
2. The control owner needs to understand the why.
   The best control is one the analyst feels is a natural part of their work. That's why I always describe impact, frequency, and who is responsible.
3. Evidence has to be simple to collect.
   If a control depends on ten screenshots and three emails, it dies. Automating evidence, even just the basics, is what keeps the catalog alive.
4. The catalog should connect to the risk journey.
   In structured programs, each control links to a pillar (Screening, Monitoring, Data Quality, etc.) and to the type of second-line testing.
   This way, the catalog talks to the rest of governance, instead of living in isolation.
5. Updating is a process, not an event.
   A controls catalog isn't reviewed once a year. It evolves with the product, the system, and customer behavior.

In the end, a good catalog is almost like a living map of governance: it shows where the safeguards are, what's working, and where there are gaps for risk to slip through.

Today, when someone asks me for help building a controls catalog, I usually answer:
let's start by understanding the problem you want to avoid.
Only after that does it make sense to open Excel or the tool.