Control Register Template

The columns that matter

Registers fail by being either too thin to be useful or so wide that nobody maintains them. These columns are the working minimum.

• Control ID and short name — stable, referenced everywhere else.
• Source — the policy, standard, regulation, or framework objective it satisfies.
• Risk addressed — plain language, one sentence.
• Control type — preventive, detective, or corrective; manual, automated, or hybrid.
• Process and activity — where in the flow it actually applies.
• Owner and approver — named people, not teams.
• Test method and frequency — how you know it works and how often you check.
• Last tested, result, and evidence link.
• Status — effective, degraded, failed, or retired.

Conventions that keep it alive

A register only survives if the rules for filling it in are boring and consistent.

• One control, one row. If a row has 'and' in it twice, it is two controls.
• Never delete a retired control — mark it retired with a date and a reason.
• If a control cannot be tested, it is a policy statement; move it out of the register.
• Owners are individuals. A team cannot be called at 7am.

Linking the register to live data

The difference between a register that is read and one that is filed is whether the test column is automatic. Where a control maps to a governance rule over an event log, the last-tested date and result should be written by the platform, not by a person.

Manual tests still belong in the register — just mark them clearly so you can see what proportion of your control environment depends on someone remembering.

The review rhythm

Monthly: exceptions and failed tests only. Quarterly: ownership, thresholds, and anything degraded. Annually: full re-walk against the source policies, including retirement of controls that no longer address a live risk.