If your risk register tells you what could go wrong, your controls register tells you what is stopping it. It is the inventory of every safeguard your organization depends on, and, crucially, the record of whether each one is actually working. This guide explains what a controls register is, the fields it should contain, how it connects to the risk register, and how to keep it accurate through control testing.
What You'll Learn
By the end of this article you'll understand what a controls register is, the fields every entry should carry, the difference between preventive, detective and corrective controls, how the register links to your risk register, and how control testing keeps it honest.
What Is a Controls Register?
A controls register (also called a control library or control inventory) is a structured record of all the controls an organization relies on to manage its risks. Each entry describes a single control: what it does, who owns it, how often it operates, and how well it is working.
A control is any measure that reduces the likelihood or impact of a risk: a policy, an approval step, an automated system check, a reconciliation, a piece of monitoring. The controls register brings all of these into one place so the organization can see its defenses as a whole rather than as scattered, undocumented habits.
The register exists for three reasons: visibility (knowing what controls you have), accountability (knowing who owns each one), and assurance (knowing whether each one actually works). Of these, the third is the one most organizations get wrong. They can list their controls but cannot evidence that those controls are effective.
Core Fields of a Controls Register
While the exact columns vary, a mature controls register carries the following fields for each control:
| Field | Purpose | Example |
|---|---|---|
| Control ID | Unique identifier for tracking and linking | CTRL-014 |
| Control Name | Short, descriptive title | Multi-Factor Authentication |
| Description | What the control does and how it operates | MFA required for all admin and remote-access accounts |
| Control Type | Preventive, detective, or corrective | Preventive |
| Control Owner | Person accountable for the control operating | Head of IT Security |
| Frequency | How often the control operates | Continuous |
| Manual or Automated | Whether a person or system runs it | Automated |
| Linked Risks | The risks this control mitigates | R-2026-018, R-2026-031 |
| Effectiveness Rating | Latest assessment of how well it works | Effective |
| Last Tested | When the control was last verified | 2026-01-15 |
| Test Frequency | How often the control should be tested | Quarterly |
The fields that separate a useful register from a static list are linked risks, effectiveness rating, and last tested. Linked risks connect the control to the things it protects; effectiveness and last-tested turn the register from a claim into evidence.
Want the full framework with worked examples?
Control Types: Preventive, Detective, Corrective
Classifying each control by type helps you see whether your defenses are balanced. Most frameworks use three primary types. For a fuller treatment, see our guide on the types of risk controls.
| Type | What It Does | Example |
|---|---|---|
| Preventive | Stops a risk event from happening in the first place | Segregation of duties; access controls; approval limits |
| Detective | Identifies that a risk event has occurred so it can be addressed | Reconciliations; exception reports; intrusion monitoring |
| Corrective | Limits damage and restores normal operations after an event | Backup restoration; incident response plan; insurance claim |
A healthy control environment leans toward prevention but never relies on it alone. Preventive controls fail, so you need detective controls to catch what slips through and corrective controls to recover. If your register is almost all detective controls, you are catching problems after the fact; if it is almost all preventive, you have no way of knowing when prevention fails.
Pro Tip
Run a quick balance check on your register: group controls by type and by linked risk. A critical risk defended only by a single preventive control is fragile. Aim for layered defenses, such as a preventive control backed by a detective one.
How It Relates to the Risk Register
The controls register and the risk register are two sides of the same coin. The risk register lists risks and references the controls that mitigate them; the controls register lists controls and references the risks they protect. Together they form a many-to-many relationship: one control can mitigate several risks, and one risk is usually managed by several controls.
This linkage is what makes residual risk meaningful. A risk's residual score reflects the assumption that its controls are working. If a control later tests as ineffective, every risk linked to it should be re-examined, because its residual score may need to rise. Without the register-to-register link, you can't trace that impact, and your residual scores drift away from reality.
The two registers are joined by treatment. As described in our guide on risk treatment plans, a treatment action that completes should produce or strengthen a control, and that control belongs in the controls register. For the mechanics of wiring these together, see how to link risks, controls, and actions.
CTRL-014: Multi-Factor Authentication
Description: MFA enforced on all administrator and remote-access accounts via the identity provider.
Type: Preventive · Automated · Frequency: Continuous
Owner: Thabo M., Head of IT Security
Linked Risks: R-2026-018 (Phishing-led credential compromise), R-2026-031 (Unauthorized system access)
Last Tested: 2026-01-15, sampled 25 privileged accounts, all enforced
Effectiveness Rating: Effective
Test Frequency: Quarterly · Next Test: 2026-04-15
Control Testing
A control you have never tested is a control you are merely hoping works. Control testing is the process of gathering evidence that a control is both designed correctly and operating as intended. It usually answers two questions:
- Design effectiveness: If this control operates as described, would it actually mitigate the risk? A poorly designed control can run flawlessly and still fail to address the threat.
- Operating effectiveness: Is the control actually being performed, consistently, by the people or systems responsible? A well-designed control that nobody runs is worthless.
Testing methods range from light to rigorous: inquiry (asking the owner), observation (watching it happen), inspection (reviewing evidence such as logs or sign-offs), and re-performance (independently redoing the control to confirm the result). Inquiry alone is the weakest form of assurance; inspection and re-performance are the strongest. For a full method on rating results, see control effectiveness and how to assess it.
Important
Don't confuse "the control exists" with "the control works." An entry in your register that says a reconciliation happens monthly proves nothing unless you can produce the signed reconciliations. Test frequency and last-tested dates should be visible fields, because a control overdue for testing is effectively unassured.
Keeping the Register Current
Controls registers decay faster than risk registers because controls change quietly: a system is upgraded, a process is automated, an owner leaves, a manual check is dropped to save time. None of these changes announce themselves, so the register slowly drifts from reality unless it is actively maintained.
Keep it current with a few disciplines:
- Tie updates to change: When a process, system, or organizational structure changes, review the affected controls as part of that change.
- Refresh ownership on role changes: A control owned by someone who has left is an orphaned control. Reassign ownership whenever people move.
- Enforce test cadence: Surface controls that are overdue for testing so they don't quietly become unassured.
- Retire dead controls: When a control is decommissioned, mark it retired rather than deleting it, since you may need the history for audit.
- Reconcile against the risk register: Periodically check that every significant risk has at least one effective linked control, and that every control still maps to a live risk.
A register that is reviewed only at audit time tells auditors more about your weaknesses than your strengths. The goal is a living inventory that the first, second, and third lines of defense can all rely on.
Common Mistakes to Avoid
1. Listing Controls Without Testing Them
A register full of "Effective" ratings with no test dates behind them is a register of assumptions. Effectiveness ratings must be backed by recent testing evidence.
2. No Link to Risks
A control that isn't linked to any risk has no reason to exist, and a risk with no linked control is unmanaged. Maintain the many-to-many link in both directions.
3. Orphaned Ownership
Controls owned by departed staff don't get performed or tested. Reassign ownership whenever roles change, not just at annual review.
4. Confusing Type and Strength
Preventive doesn't mean "stronger." A weak preventive control can be less effective than a robust detective one. Rate effectiveness independently of type.
5. Treating It as Static
Controls change constantly and silently. A register that isn't updated as systems and processes change becomes fiction within a year.
Summary
- A controls register is the inventory of every safeguard your organization relies on to manage risk
- Core fields include control ID, description, type, owner, frequency, linked risks, effectiveness, and last-tested date
- Controls are classified as preventive, detective, or corrective, and you should aim for layered, balanced defenses
- The controls register and risk register form a many-to-many relationship that makes residual risk meaningful
- Control testing through inquiry, observation, inspection, and re-performance turns claims of effectiveness into evidence
- Registers decay silently, so keep them current by tying updates to change and enforcing test cadence
Frequently Asked Questions
What is the difference between a controls register and a risk register?
A risk register lists the things that could go wrong and how serious they are. A controls register lists the safeguards that reduce those risks and records whether each one works. They are linked: risks reference their controls, and controls reference the risks they mitigate.
What are the three types of controls?
Preventive controls stop an event from happening (such as access restrictions), detective controls identify that an event has occurred (such as reconciliations or monitoring), and corrective controls limit damage and restore operations afterward (such as backups or incident response). See types of risk controls for more detail.
How often should controls be tested?
Test frequency should reflect how critical the control is and how often it operates. Controls protecting critical risks may be tested quarterly; controls over lower risks can be tested annually. Each control should carry a test frequency and a last-tested date so overdue testing is visible.
Can one control mitigate more than one risk?
Yes. The relationship is many-to-many: one control often mitigates several risks, and one risk is usually managed by several controls. A strong access-management control, for example, can reduce both unauthorized-access and data-breach risks. Your register should capture every linked risk for each control.
How does control testing relate to residual risk?
A risk's residual score assumes its controls are working. If a control tests as ineffective, the residual risk on every linked risk should be reconsidered and may need to rise. Control testing is therefore what keeps residual scores honest rather than aspirational.
Do I need separate software for a controls register?
A spreadsheet works when you are starting out, but the controls register's value comes from its links to risks and its testing history, both of which are hard to maintain by hand. Dedicated GRC software keeps the risk-to-control links live, tracks test results over time, and flags controls overdue for testing automatically.
Save this guide for later
Download the PDF version to read offline or share with your team.
