Control library

Internal Audit → Control Library

A control is a thing your organisation does to manage a risk: access is revoked within 24 hours of termination, vendor bank details are verified against a bank letter, a purchase order is matched to a goods receipt before payment. Your audit function tests the same controls again and again, cycle after cycle.

Before this page existed, each control was free text typed onto a work program step. The same control tested in 2026 and again in 2027 was two unrelated pieces of writing, so a question every Chief Audit Executive is asked — when did we last test this, and what did we find? — had no answer inside the product.

The control library gives a control an identity that outlives one engagement.

What is in the library

Column	What it is
Ref	Your own numbering, such as AC-04. This is the control's identity.
Control	What the organisation does. One sentence, in the present tense.
Regulator clause	The citation it satisfies, such as ECC-2-2-1 or SAMA-3.3.
Tested	How many work program steps have cited this control.

A clause is not a control

Several different controls usually cite the same regulator clause. ECC-2-2-1 covers access management, and an audit function may hold four separate controls under it: revocation on termination, owner approval before provisioning, automatic disabling of inactive accounts, and time-bound vendor access.

Those are four controls, not one. The library keeps them separate, and nothing in the product will ever merge two controls because they share a clause.

Using a control on a work program

On an engagement's Fieldwork tab, adding a step offers Control from the library above the control description. Pick one and the step cites it; leave it on Not from the library if you are testing something the library does not cover yet.

Picking a control fills in the control description and the regulator clause for you, the first time. Both stay editable: how a control reads in the context of one audit is legitimately not the library wording, and that local phrasing belongs to the step.

An existing step shows which control it cites when you expand it, with Link a control or Change beside it. A step citing nothing says not linked rather than showing a blank, because a step with no control never reaches that control's history.

Citing a library control is what makes the Tested count move, and what builds the test history below.

The link travels. Save an engagement's program to the Program Library and the control links go with it, so applying that program to next year's engagement arrives already linked — which is the point at which the history starts paying.

A control's test history

Select a control's reference, name or test count to open it. The page lists every time that control has been tested, grouped by cycle, newest first — the engagement, the step, the conclusion the auditor wrote, the verdict, who approved it, and any findings raised from it.

This is the answer to the question a Chief Audit Executive is asked in the room: when did we last test this, and what did we find?

Repeat exceptions

At the top of the page is one sentence summarising the whole history. It is worth reading carefully, because the wording is deliberate:

It says	It means
Never tested	No work program step cites this control yet.
Tested n times, not concluded	Testing has happened, but no working paper has been approved, so there is no result on record.
Tested n times, no exceptions	Every approved test passed.
Tested n times, one exception in year	It failed once.
Tested n times, repeat exceptions	It failed more than once, in non-consecutive cycles.
Tested n times, exceptions in consecutive cycles	It failed, was remediated, and failed again the next cycle.

The last one is the line worth carrying into an audit committee pack. A control that fails once and is fixed is ordinary. A control that fails in consecutive cycles is a remediation that did not hold, and that is a different conversation.

Only approved work counts

A verdict recorded on a working paper nobody has signed off is a draft opinion, not a result. The history shows it, marked Not yet approved, but it is excluded from the repeat judgement entirely.

This matters: describing a control as a repeat finding in front of a board, on the strength of an exception no reviewer has agreed to, is exactly the kind of overstatement the platform is built to avoid.

Adding a control

Select Add control. A reference and a control statement are required; everything else is optional. Write the control as a statement of what the organisation does, not as a test — "access is revoked within 24 hours" rather than "check that access is revoked".

Retiring, and why you cannot just delete

A control that is no longer relevant is retired, not deleted. Retiring it removes it from the list and stops it being cited by new work, while every step that already tested it keeps resolving and its history survives.

The library asks why. That reason goes onto the audit trail, where a quality assessor reviewing the function will read it.

A control that has never been tested can be deleted outright: there is no history to protect. Once a single step cites it, deletion is refused and the page offers retirement instead.

A retired control can be returned to the library. It comes back as the same control, carrying the same history — not as a new one, which would split its record in two.

Two things are deliberately immovable once a control has been tested:

• Its reference cannot be renumbered. Working papers cite it; a reference that changes stops matching the audit trail.
• It cannot be deleted. Retire it and add the replacement.

Building the library from work you already have

If you have been running engagements before this page existed, the controls are already written down — on the steps of every work program. A backfill script proposes a library from them:

npx tsx scripts/backfill-audit-controls.ts propose --out proposed.csv

It writes a spreadsheet of proposed controls for a person to read. Nothing is created until you review that file and run the second pass. Where it is unsure whether two steps describe the same control, it leaves them separate: two controls wrongly merged would invent a shared test history that never happened, and that is worse than two entries a person can merge later.

Who can do what

Action	Who
View the library	Anyone with audit access
Add, edit, retire, delete	Audit manager and above
Cite a control on a step	Any auditor on the engagement team

The library is function-level configuration, like risk factors and regulatory regimes — it belongs to the audit function, not to one engagement.