Control register
Updated
A control register is the master inventory of the controls an organization relies on — each recorded with attributes such as an owner, a description, how often it runs, the risk it addresses, and how it is tested. Also called a control matrix or risk-and-control matrix (RCM), it is the single source of truth a compliance program is built and audited against.
The register turns a scattered set of controls into something you can manage: it shows what controls exist, who is accountable, which risks and frameworks each control maps to, and what evidence proves it operated. Because one control often satisfies several frameworks at once, a well-kept register is also the backbone of crosswalking — testing evidence once and reusing it across SOX, SOC 2, and ISO 27001.
What a control register is
A control register (or control matrix) is a structured list of every control in scope for a compliance or risk program, with a consistent set of attributes captured for each one. It is the operational counterpart to a framework: where a framework such as COSO or ISO 27001 describes what should be controlled, the register records the specific controls an organization has actually implemented to meet it.
Its job is to make the control environment legible. Instead of controls living implicitly in people's heads, tickets, and scattered documents, the register states each one explicitly — so a new team member, an internal auditor, or an external assessor can see the full population of controls and reason about coverage and gaps.
What each entry contains
There is no single mandated schema, but mature registers converge on a common set of attributes. The goal is that each row is self-describing enough to test the control and evaluate any failure without hunting for context elsewhere.
- Control ID and description — a stable identifier and a plain statement of what the control does.
- Owner — the person or role accountable for the control operating.
- Type and frequency — preventive or detective, manual or automated, and how often it runs.
- Risk and assertion — the risk it mitigates and, for financial controls, the assertion it supports.
- Framework mapping — the SOX, SOC 2, ISO 27001, or other requirements the control satisfies.
- Test procedure and evidence — how effectiveness is checked and what artifact proves it operated.
How the register is used
During an audit or assessment, the register is the starting point: assessors pull controls from it, request the mapped evidence, and test whether each operated over the period. Because every control carries its risk and framework mapping, the register also answers coverage questions — which risks lack a control, and which controls satisfy more than one framework and can therefore be tested once and reused.
A register is only as useful as it is current. Controls change as systems and processes change, so entries drift out of date if the register is treated as a one-time deliverable rather than a living record. The common failure mode is a register that looks complete but references controls, owners, or evidence that no longer exist — which surfaces, expensively, during testing.
Frequently asked questions
What is the difference between a control register and a risk register?
A risk register catalogs the risks an organization faces; a control register catalogs the controls that mitigate them. They are linked — a good control register maps each control back to the risks it addresses — but they answer different questions. The risk register asks "what could go wrong?" and the control register asks "what do we do about it, and how do we prove it?"
Is a control register the same as a control matrix?
In practice, yes. "Control register," "control matrix," and "risk-and-control matrix (RCM)" are used interchangeably for the structured inventory of controls and their attributes. Some teams reserve "matrix" for a view that explicitly crosses controls against risks or framework requirements, but the underlying artifact is the same.
How does a control register support multiple frameworks at once?
By recording a framework mapping on each control, the register shows where one control satisfies several requirements — for example, an access-review control relevant to both SOX ITGC and SOC 2. That mapping lets a team test and evidence the control once and reuse the result across every framework it legitimately supports, rather than duplicating work per framework.
Published by ShipReady Metrics, an evidence-based technology and compliance intelligence platform. This guide is educational and vendor-neutral.