A key control is a control you rely on to address a specific risk: the one, or one of the few, whose failure would allow a significant error, loss or misstatement to go undetected. Non-key controls still exist and still help, but the conclusion about whether the risk is controlled does not depend on them, so they are not the focus of testing. The practical test is simple: for each risk, if you could test only one control, which would you choose? That control is key. Most control programs designate far too many controls as key, which spreads testing thin across controls that do not carry the risk. A structured rationalization, built on a coverage matrix that shows which controls uniquely address which risks, usually cuts the key control count substantially while improving the quality of the testing that remains.
This guide explains what makes a control key under auditing standards and in practice, how the idea applies outside SOX, six criteria for designating key controls, the over-keying problem and its opposite, a six-step rationalization method with a coverage matrix, how to document each decision, what happens to non-key controls, and a worked example in which a newly listed company went from 412 key controls to 168. It builds on step 5 of the site’s SOX scoping guide, which sets out the rules that keep the key control count honest.
In this guide
- What makes a control key
- Key controls outside SOX
- Six criteria for designating a key control
- The over-keying problem
- Under-keying: the opposite failure
- Signs your key control set needs rationalizing
- A rationalization method in six steps
- The coverage matrix
- Typical key controls by process
- How the external auditor’s view differs
- Key controls in an internal audit engagement
- Documenting the key control decision
- What happens to non-key controls
- Worked example: from 412 key controls to 168
- Keeping the key control set current
- Questions about key and non-key controls
- Related guides
What makes a control key
The phrase “key control” does not appear as a defined term in most standards, but the idea is embedded in them. The PCAOB’s AS 2201 tells auditors to test the controls that are important to their conclusion about whether the company’s controls sufficiently address the assessed risk of misstatement to each relevant assertion. The SEC’s 2007 interpretive guidance for management takes the same top-down, risk-based approach: management’s evaluation should focus on the controls that adequately address the risk of material misstatement, rather than on every control that exists. Neither requires every control to be tested. Both require the controls that carry the conclusion to be tested well.
The site’s SOX scoping guide turns that into a working definition: a key control is one that, alone or with a small number of others, prevents or detects a material misstatement for a specific thing that could go wrong, and the selection is made by asking, for each risk, which control the company would rely on if it could test only one. Three consequences follow.
- Key is relative to a risk. A control is key for a particular risk and assertion, not in general. The same control can be key for one risk and irrelevant to another.
- Key is not the same as important. A control can matter a great deal operationally, such as a safety check or a customer-service standard, and still not be a key control for financial reporting.
- Key controls can be detective. A precise detective control, such as a reconciliation or a detailed review, often covers several preventive steps and is frequently the better key control.
Key controls outside SOX
The idea is not limited to financial reporting. Any internal audit engagement has to decide which controls to test, and the same logic applies: identify the risks, then identify the controls whose failure would leave each risk unaddressed.
| Setting | What “key” means there | Where it is documented |
|---|---|---|
| SOX and ICFR | Controls important to the conclusion on each relevant assertion | The SOX risk and control matrix |
| UK Provision 29 | “Material controls”: the controls whose failure would matter most across financial, operational, reporting and compliance objectives | The board’s list of material controls; the site’s Provision 29 guide works a list of 42 for a manufacturer |
| Internal audit engagements | The controls the engagement’s conclusion will rest on | The engagement risk and control matrix and work program |
| Operational risk and RCSA | Key controls for each key risk in the risk register, often tested by the first or second line | The RCSA and the control library; see the RCSA guide |
| Regulatory compliance | Controls that address specific regulatory obligations | The compliance obligations register |
In an internal audit engagement, designating key controls is what turns a long process walkthrough into a focused test plan. The engagement risk and control matrix should mark which controls will be tested and why, and the audit work program should test those controls properly rather than all controls lightly.
Six criteria for designating a key control
The questions below turn the definition into a decision. A control that meets the first two is a candidate; the others decide between candidates.
| Criterion | The question | Points toward key | Points toward non-key |
|---|---|---|---|
| 1. Risk addressed | Does it address a risk that matters, for a relevant assertion? | A significant risk or assertion, with a specific what-could-go-wrong | An operational or efficiency purpose, or a risk below the threshold that matters |
| 2. Consequence of failure | If it failed, would the error be caught by something else in time? | No other control would catch it | Another control would catch the same error at adequate precision |
| 3. Precision | Would it catch an error of the size that matters? | Operates at the transaction level or with a low threshold | Reviews totals or large variances |
| 4. Coverage | Does it cover the whole population and several risks at once? | A reconciliation or review that covers the account completely | A step that applies to part of the population |
| 5. Reliability | Is it likely to operate consistently? | Automated, with effective IT general controls; or a well-evidenced manual control | Dependent on one person’s memory; no evidence |
| 6. Testability | Does it leave evidence that can be tested? | Clear evidence of performance and of follow-up | Nothing to test but a person’s assurance |
The second criterion does most of the work in rationalization. A control whose failure would be caught by another control at adequate precision is not key for that risk, however well it operates. That is not an argument for removing it; it is an argument for not spending testing hours on it.
The over-keying problem
Most control programs start with too many key controls. The causes are predictable, and so are the costs.
| Cause | What it looks like |
|---|---|
| Documentation by inventory | Consultants or process owners list every control in the process, and all are marked key |
| Fear of missing something | “If in doubt, key it” becomes the policy |
| Operational controls included | Controls that exist for efficiency or customer service carry no financial reporting assertion but are marked key |
| Duplicates | The same review is recorded once for each risk it addresses, and counted as several controls |
| Preventive chains | Every preventive step in a process is keyed, even where a single detective control covers them all |
| No review since listing | The matrix built for the listing has never been revisited |
The costs are less obvious than the count. Testing hours spread across hundreds of controls mean each control is tested more superficially. Control owners grow tired of testing and treat it as paperwork. Reviewers cannot tell which failures matter. And the external auditor’s time is spent on the same inflated inventory. A program with 400 key controls, each tested lightly, usually gives less assurance than one with 160 key controls tested properly.
Under-keying: the opposite failure
Rationalization can go too far. The failures below are what an over-enthusiastic cut produces, and they are more dangerous than over-keying because they leave risks untested.
- Assertions with no key control. A coverage matrix that shows an assertion with no key control is a gap, not an efficiency.
- Reliance on imprecise controls. Replacing process-level controls with a review of totals that could not catch the errors that matter. The site’s guide to entity-level controls explains why most high-level reviews are not precise enough.
- Missing dependencies. A key control that relies on a system report brings the report’s completeness and accuracy into scope, and an automated key control brings the IT general controls over its system. Dropping those dependencies leaves the key control untested in substance. The guides to IPE testing and testing automated controls cover both.
- Fraud risks treated like error risks. Controls over management override and other fraud risks are key even when the monetary exposure looks small, because the risk is the intent, not the average amount.
Signs your key control set needs rationalizing
Most programs do not need a formal study to know whether they are over-keyed. The signs are visible in the matrix and the testing calendar.
- The key control count has only ever gone up since the program began.
- More than a handful of key controls have no stated what-could-go-wrong or assertion.
- The same review appears several times in the matrix under different processes.
- Testers routinely test controls whose failure, if found, nobody would report.
- Control owners describe testing as “the SOX paperwork” rather than as a check on their controls.
- The program cannot say which key control it relies on for a given assertion without searching.
- Most key controls are preventive steps, and few are reconciliations or detailed reviews.
- The external auditor tests a noticeably smaller set than management does, and the difference has never been discussed.
Two or three of these together usually mean a rationalization would pay for itself in the first year.
A rationalization method in six steps
The method below works for a SOX program, a Provision 29 list or an engagement matrix. It needs the risk and control matrix, the scoping memo and a few days of the program team’s time.
| Step | What to do | What it produces |
|---|---|---|
| 1. Anchor every control to a risk | Link each control to a specific what-could-go-wrong and a relevant assertion; controls that link to neither are operational | A list of controls with no financial reporting purpose, to be marked non-key |
| 2. Merge duplicates | Record each control once, with every risk it addresses listed against it | A single entry per control, and an honest count |
| 3. Build the coverage matrix | For each risk, list the controls that address it and whether each does so at adequate precision | A matrix showing which controls uniquely address a risk and which are redundant |
| 4. Choose the key control for each risk | Ask which control you would rely on if you could test only one; prefer precise detective controls that cover several risks | The key control for each risk, with the reason |
| 5. Test the coverage | Confirm every relevant assertion and every significant risk has at least one key control | Gaps to close by adding or redesigning controls |
| 6. Add the dependencies | For each key control, add the reports, systems and IT general controls it relies on | A complete key control set, ready to test |
Step 3 is where the savings appear. A coverage matrix often shows that three or four preventive controls address a risk that one detective control also addresses completely and precisely. Designating the detective control as key, and the preventive controls as non-key, is not a weakening of the program; it is an acknowledgment of where the assurance actually comes from.
The coverage matrix
The matrix below is a small extract for the accounts payable process. Each row is a risk; each column is a control; each cell says whether the control addresses the risk at adequate precision.
| Risk (what could go wrong) | C1 Three-way match | C2 Invoice approval by budget holder | C3 Vendor master change approval | C4 Monthly AP subledger to GL reconciliation | C5 Payment run review by treasury | Key control chosen |
|---|---|---|---|---|---|---|
| Invoices paid for goods not received | Yes | Partly | No | No | No | C1 |
| Invoices recorded at wrong amounts | Yes | Partly | No | Totals only | No | C1 |
| Payments to fictitious or altered vendors | No | No | Yes | No | Partly | C3 |
| Subledger does not agree to the ledger | No | No | No | Yes | No | C4 |
| Duplicate payments | Partly | No | No | No | Partly | Gap: add a duplicate payment check |
Reading across the rows shows the choices. The budget holder’s approval (C2) partly addresses two risks that the three-way match addresses fully, so it is non-key for those risks, although it may still matter for authorization. The treasury review of payment runs (C5) partly addresses two risks but not precisely enough to be relied on. And no control addresses duplicate payments fully, which is a gap the rationalization found rather than created. The site’s risk and control matrix template has the columns for this, and the accounts payable audit guide sets out the risks in full.
Typical key controls by process
The examples below are the controls most often designated key in each process. They are starting points, not a standard list: the right key control for a risk depends on the organization’s systems and on what else is in place.
| Process | Typical key controls | Why they tend to be key |
|---|---|---|
| Revenue and receivables | Automated pricing and invoicing from approved orders; review of credit memos above a threshold; monthly revenue cut-off review; reconciliation of the receivables subledger to the ledger | They address accuracy, cut-off and occurrence for the whole population, and the credit memo review addresses the main route for manipulation |
| Purchasing and payables | Three-way match with tolerances; approval of vendor master changes, including bank details; subledger to ledger reconciliation | The match covers most invoice risks at once; vendor master changes are the main fraud route |
| Payroll | Approval of starters, leavers and rate changes; payroll-to-payroll variance review at the employee level; payroll bank reconciliation | Changes are where errors and fraud enter; the variance review catches what the change controls miss |
| Inventory | Physical count procedures and reconciliation to the records; review of inventory adjustments; cost roll-up review | Existence and valuation depend on them |
| Fixed assets | Capital expenditure approval and capitalization review; depreciation calculation (often automated); impairment review | Capitalization and valuation judgments, and a large automated calculation |
| Treasury and cash | Bank reconciliations; payment release with dual authorization; review of investment valuations | Cash is where errors and theft surface first, and reconciliations cover every transaction |
| Financial close | Account reconciliations with review; manual journal approval; review of top-side and consolidation entries; flux review at an adequate precision | The close assembles every number; override risk concentrates in its journals |
| IT general controls | Change management over in-scope systems; user access provisioning and periodic review; privileged access monitoring | Every automated key control depends on them |
The site’s how-to-audit guides for procure-to-pay, order-to-cash, payroll and the financial close each set out the risks behind these controls in full.
How the external auditor’s view differs
Management and the external auditor each decide which controls matter for their own purposes. Management designates key controls for its assessment; the external auditor selects the controls it will test for its opinion, and may use management’s testing or internal audit’s work only to the extent its standards allow. AS 2201 permits the auditor to use the work of others, including internal auditors, based on their competence and objectivity and the risk associated with each control. The practical consequence is that the two sets usually overlap heavily but are not identical, and the differences should be discussed every year rather than discovered at year-end.
Three differences are common. The external auditor may test fewer controls than management, because it can combine control testing with substantive work. It may insist on testing a control management has made non-key, if it relies on that control for its own risk assessment. And it will almost always test the controls over management override and the period-end reporting process itself, whatever management’s matrix says. A rationalization done with the external auditor in the room, as in the example below, avoids surprises.
Key controls in an internal audit engagement
Outside SOX, the same thinking shapes every engagement’s test plan. An engagement matrix for a process audit typically lists every control the walkthrough found, and the team then decides which of them the conclusion will rest on. Those are the engagement’s key controls, and they are tested properly; the others are noted, and tested only if a key control fails and another might compensate.
The discipline matters most in engagements with a long list of candidate controls and a fixed budget. A route cash audit at a distributor with twelve depots, for example, might find twenty or more controls across settlement, custody, deposits and customer statements. The conclusion about whether cash is safe rests on a few of them: the independent reconciliation of each settlement, the approval of variance overrides, the check of deposit listings against the bank, and the statements that give customers a chance to spot a missing payment. Testing those well, at every depot, gives a sounder conclusion than testing twenty controls lightly at a few depots. The site’s guide to the audit work program shows how the key controls become the test steps.
Documenting the key control decision
Every key and non-key designation should carry a short rationale, so that the decision can be reviewed, challenged and repeated next year. The fields below fit in the risk and control matrix.
Control reference and description. Written to the standard in the control description guide.
Risks and assertions addressed. Every what-could-go-wrong the control covers.
Key or non-key. For each risk it addresses, not in general.
Rationale. One sentence: why this is the control relied on for this risk, or why another control is relied on instead.
Precision. The level of error it would catch, compared with the amount that matters.
Type. Automated, IT-dependent manual, or manual.
Dependencies. Reports, systems and IT general controls it relies on.
Last reviewed. The date the designation was last confirmed, and by whom.
The rationale field is the one that saves the most time later. When the external auditor, a new program lead or a regulator asks why a control is not key, the answer is already written.
What happens to non-key controls
Designating a control non-key does not mean removing it from the process, and it should not be read that way by the people who operate it. Non-key controls continue to operate, often provide operational value, and sometimes serve as the first line of defense that keeps the key control’s exception rate low.
| Question | Answer |
|---|---|
| Do non-key controls still operate? | Yes. The designation changes what is tested, not what is done |
| Are they ever tested? | Sometimes: on a rotation, when a key control fails and a non-key control might compensate, or in an operational audit with a different objective |
| Can they become key? | Yes, when a key control changes, fails or is removed. The coverage matrix makes that visible |
| Should control owners be told? | Yes, and told why. Owners who hear that their control has been “downgraded” without explanation sometimes stop performing it |
The last row is a practical point that programs miss. A rationalization announced as “we’ve cut 240 controls” can be heard by control owners as permission to stop doing them. It should be announced as a change in what is tested, with the controls still expected to operate.
Worked example: from 412 key controls to 168
The newly listed software company described in the site’s guide to entity-level controls had its control matrix written by consultants during its listing. The matrix covered nine processes and marked 412 controls as key. In the year before its first auditor attestation, internal audit and the SOX program lead ran the six-step rationalization over six weeks.
| Step | Change | Key controls remaining |
|---|---|---|
| Starting point | All controls marked key in the listing-year matrix | 412 |
| 1. Anchor to risks | 97 controls had no what-could-go-wrong or assertion: customer-service checks, efficiency steps, a security badge control, and similar | 315 |
| 2. Merge duplicates | 61 entries were the same control recorded under several risks or processes | 254 |
| 3 and 4. Coverage and choice | 58 preventive controls were fully covered by a precise detective control, such as a reconciliation or a detailed review, and were designated non-key | 196 |
| 4. Choice, continued | 35 controls addressed accounts or risks below the level that mattered | 161 |
| 5. Coverage test | 7 assertions had no key control, mostly around revenue disclosures and stock compensation; controls were designed and added | 168 |
The final set was 34 automated, 71 IT-dependent manual and 63 manual controls. Step 6 then added the dependencies: 42 system reports to be tested for completeness and accuracy, and the IT general controls over six systems. The external auditor reviewed the rationale for each designation, agreed with all but two, and asked for two controls that the merge step had combined to be kept as separate key controls, which is reflected in the final count.
The effect on testing was larger than the count suggests. The program’s estimate of annual testing effort fell from about 9,900 hours to about 4,500, even though each remaining control was now tested more thoroughly: larger samples where the frequency warranted them, precision evidence for every review control, and proper testing of the reports the controls relied on. The seven controls added in step 5 mattered most. Two of them, over the stock compensation disclosure, found errors in the first quarter they operated, which would otherwise have reached the first attested financial statements.
Keeping the key control set current
A rationalized key control set decays like any other document. Processes change, systems are replaced, businesses are acquired, and the control that was the obvious key control two years ago may no longer exist in the form the matrix describes. Four habits keep the set current.
| Habit | What it involves |
|---|---|
| Annual re-confirmation | Each year, before testing is planned, the program lead and control owners confirm every key designation and its rationale against the current process |
| Change triggers | Any system implementation, acquisition, reorganization or significant process change triggers a review of the key controls it touches, not at year-end but when the change is approved |
| Deficiency feedback | When a key control fails, the coverage matrix is checked for whether another control could have been relied on, and whether the design of the key control set needs to change |
| A change log | Additions, removals and re-designations are logged with dates and reasons, so that anyone reviewing the program can see how the set evolved |
The change log is what lets a program answer the question every external auditor and new program lead eventually asks: why is this control not key any more? Without it, the answer depends on someone’s memory. The site’s guide to control ownership covers the related problem of keeping each control’s owner current.
Questions about key and non-key controls
Who decides which controls are key?
Management, for its own assessment, usually through the SOX program office or the control owners with the finance leadership. Internal audit may advise, and the external auditor makes its own decision about which controls it will test for its opinion. The two lists usually overlap heavily but do not have to be identical.
How many key controls should a company have?
There is no right number, and benchmarking against peers is misleading, because the number depends on the business’s complexity, systems and risks. What matters is that every relevant assertion and significant risk has a key control and that no control is key without a risk it uniquely addresses. The FRC made the same point about Provision 29’s material controls: it saw companies identify around 30 to 50, and said they should not benchmark to peers.
Can a key control be non-key next year?
Yes. Key designations should be re-confirmed each year, and whenever processes, systems or risks change. A control that was key because another control was missing becomes non-key once the other control is in place.
Is a non-key control ever reported as a finding?
It can be, if it fails in a way that matters for another objective, such as an operational or compliance one. For the financial reporting conclusion, a non-key control’s failure matters only if the key control also fails, or if the non-key control was the one compensating for something.
Should entity-level controls be designated key?
Only those that are relied on for the conclusion. Most entity-level controls are indirect and are assessed as part of the control environment rather than designated key for a specific risk; the few that are precise enough to address a risk directly can be key.
What is a key control in internal audit?
In an internal audit engagement, a key control is one the engagement’s conclusion relies on: the control that, if it failed, would leave the risk being audited unaddressed. The team designates key controls when it builds the engagement’s risk and control matrix, tests them in depth, and treats other controls as context unless a key control fails.
Is a key control the same as a critical control?
The terms are often used interchangeably. Some organizations reserve “critical control” for a smaller set of controls that address the most severe risks, such as safety or catastrophic loss, and use “key control” for the broader set that testing focuses on. Whichever terms a function uses, it should define them once and apply them consistently.
Related guides
- SOX scoping — the top-down approach and the rules for selecting key controls.
- SOX 404 — the assessment the key control set supports.
- Entity-level controls — which controls above the process can be relied on.
- Compensating controls — when a non-key control is asked to cover a failed key control.
- Manual, automated and IT-dependent manual controls — the classification every key control needs.
- IPE testing — the reports key controls depend on.
- Testing automated controls — the IT general control dependency.
- The risk and control matrix template — where designations and rationales are recorded.
- How to write a control description — the standard for describing a key control.
- UK SOX and Provision 29 — material controls, the UK’s version of the idea.
- The RCSA process — key controls in operational risk.
- Control ownership — telling owners what the designation means.
- How to audit procure-to-pay — the payables risks behind the coverage matrix.
- The audit work program — turning key controls into test steps.
- Control Design Principles: What Makes a Control Work — what makes a control well designed, with the failure patterns and a design checklist
Leave a Reply