Start from the business process and the ways it fails, not from the control catalog. A catalog tells you which controls exist. It cannot tell you where, in your supplier payment process or customer onboarding flow, a control has to sit to make a difference.
The frameworks say as much. NIST SP 800-53 describes its controls as flexible and customizable, to be implemented as part of an organization-wide risk management process. ISO/IEC 27001 asks organizations to decide the controls they need through risk treatment and then check them against Annex A, rather than adopting Annex A as a checklist. Internal control practice in finance, shaped by the COSO framework, has long worked at process level, with control activities sitting inside a structure of risk assessment and monitoring.
The method below suits any process that handles money, regulated data, critical service delivery or privileged access.
1. Choose the process
Start where failure creates real loss: paying a supplier, changing a supplier’s bank details, onboarding a customer, granting privileged access, releasing software to production, exporting customer data, changing payroll. Pick one. A pilot teaches more than a program plan.
2. Map how it really runs
Walk the process with the person who runs it. Capture the steps, the actors, the systems, the data, the handoffs, the approvals, and the workarounds that exist because the official process is slow. Where the documented procedure and the real one differ, control the real one. Note where decisions are made. That is where a control has the most leverage.
3. Find where it can fail
At each step, ask what would have to go wrong for this process to cause harm. Sort the answers into a few failure types: an unauthorized action, an incorrect action, exposure of data, loss of availability, and no evidence of what happened. Rank by consequence. Drop failures that cannot cause material harm. Controls on them add friction without reducing risk.
4. Place a control at each significant failure point
Prefer controls the workflow enforces over controls that depend on someone remembering. A finance system that holds the first payment after a bank-detail change until a second person approves is stronger than a policy telling staff to be careful.
The table is a constructed example for a supplier bank-detail change. Your controls will differ. The shape is what matters: each control answers a specific failure, has a type, and leaves evidence as a by-product of the work.
| Step | What can go wrong | Control | Type | Evidence |
|---|---|---|---|---|
| Request to change supplier bank details | A fraudster impersonates the supplier | Verify the request by calling a number already on file, never one given in the request | Preventive, manual | Call record in the ticket |
| Change entered in the finance system | Details altered without authority | A second person approves; the system blocks self-approval | Preventive, automated | Approval entry in the system log |
| First payment after the change | Money goes to the new account before the change is checked | System holds the first payment until verification is confirmed | Preventive, automated | Hold and release record |
| Weekly review | Unauthorized changes go unnoticed | Review every bank-detail change against its supporting ticket | Detective, manual | Signed review with exceptions listed |
5. Map requirements onto controls, not the other way around
Once the controls exist, link each one to the obligations it supports: regulations, contract clauses, framework requirements, audit criteria. One control often serves several. Keep the mapping as a column on the control record. When a new requirement arrives, check whether an existing control already meets it before designing another. That keeps the control set small and avoids the usual pattern of one control per regulation, each with its own owner and its own evidence request.
6. Give each control a business owner and a test
Security can design the control, but the person who runs the process has to own it. For each control, define:
-
the owner and a named backup
-
how often it operates
-
what evidence it produces and where that evidence lives
-
how it will be tested
-
what happens when it cannot operate
Build evidence into the workflow: an approval in the system, a ticket field, a log entry. Evidence gathered afterward for an auditor costs more to produce and is harder to trust.
7. Test it, then handle exceptions
Test two things separately. Design: if the control operates as described, does it stop the failure? Operation: did it operate, every time, in the period? Pilot on live transactions. Where people bypass a step, ask why. The answer is usually a design problem.
Define the exception path before go-live. Who may approve a bypass, for how long, with what compensating measure, and where is it recorded? Exceptions with no expiry become the real process.
8. Set review triggers
Review a control when the process changes, when a supporting system changes, after an incident, and when a requirement changes. Add a scheduled review for everything else. Retire controls that no longer address a real failure.
Where control design goes wrong
-
Designing per system, so the handoffs between systems go uncontrolled.
-
Stacking approvals until staff route around them.
-
Giving security ownership of controls the business runs.
-
Writing a policy and calling it a control.
-
Producing evidence only when the auditor asks.
-
Mapping to one framework and rebuilding for the next.
Use this note to turn requirements into operating controls: start with one process, place controls where it can fail, and make the evidence a by-product of the work.
Sources
How we label evidence
Facts carry a source. Analysis and recommendations are marked as ours. Examples that are hypothetical are labeled as hypothetical.
Part of the solutionSecure & ComplyTurn regulatory duties into controls that hold up.See how we work →Related service
Control Design & Implementation
Use this to turn requirements into operating controls.