What is a Key Control?

What is a Key Control?

A key control is a control that management relies on, alone or with a few others, to prevent or detect a material misstatement, so that its failure would leave the risk unaddressed.

The phrase does not appear in the SEC or PCAOB rules. It grew out of the top-down, risk-based approach in the SEC's 2007 guidance on management's report on ICFR, which says management can focus on the controls that are needed to adequately address the risk of a material misstatement and does not require management to identify every control in a process. PCAOB AS 2201 takes the same position for the auditor, who tests the controls that are important to the conclusion about whether the company's controls sufficiently address the assessed risk for each relevant assertion. Practitioners call those controls key; everything else is secondary or non-key.

Why it matters

• It bounds the SOX program. Testing effort, evidence collection and deficiency evaluation all attach to key controls, so the selection sets the annual workload.
• It forces a risk conversation. A control is key only in relation to a stated risk and assertion, which makes the risk-control matrix the real scoping document.
• It is where auditors push back. Too few key controls leaves risks uncovered; too many wastes effort and blurs which control the company actually relies on.

How a key control is selected

Start from the financial reporting risks: for each significant account and disclosure, identify what could go wrong for each relevant assertion (existence, completeness, accuracy, valuation, rights, presentation). For each risk, identify the control or controls that, operating together, reduce it to an acceptable level. Those are the key controls. A risk may have one key control, or a preventive control plus a detective review. The test for a candidate is simple: if this control failed and nothing else changed, would the risk be unaddressed?

Key versus non-key controls

Non-key controls still matter to the business, but they are redundant to a key control, operate at too low a precision to address a material risk, or support efficiency rather than financial reporting. They are documented but not tested for SOX, although a change in them may prompt a review of the key control they sit beside. The precision of a key control (the threshold at which a reviewer investigates) must be documented, because that is what supports the reliance.

Documenting key controls

• Risk and assertion the control addresses.
• Control owner, frequency and whether it is manual, automated or IT-dependent.
• Preventive or detective, and precision or threshold.
• Evidence produced when it operates.
• Dependencies: the reports, systems and IT general controls it relies on.

Related terms

• Risk control matrix (RCM)
• SOX scoping
• SOX control testing
• Control testing
• Internal controls
• Control library

In SmartSuite

SmartSuite SOX Management keeps the risk-control matrix as linked records, so a key flag on a control shows the risk and assertion it covers, the tests scheduled against it and any deficiency raised, and a control with no linked risk stands out immediately.

Frequently asked questions

Is the term key control defined by the SEC or PCAOB?

No. Both regulators describe selecting controls that adequately address the risk of material misstatement, and the auditor testing the controls important to that conclusion, but neither uses the label. Key control is the practitioner term for the controls chosen under that approach, and companies define it in their own SOX methodology.

How many key controls should a process have?

Enough to cover every identified risk and assertion, and no more. A typical mid-size company runs a few hundred key controls across its SOX scope. The number matters less than the mapping: each key control should trace to at least one risk, and each risk to at least one key control, with the precision documented.

Can an automated control be a key control?

Yes, and it is often the preferred choice because it operates consistently. The reliance then depends on the IT general controls over the application, so an automated key control brings the access, change and operations controls of that system into scope and its ITGC conclusion into the deficiency evaluation.