“Management reviews the report.” It is the most common control description in the world, it appears in risk and control matrices at companies of every size, and it cannot be tested. It does not say which manager, which report, how often, what the reviewer is looking for, what they do when they find it, or what evidence the review leaves behind. A tester handed that description has to interview someone to learn what the control actually is before testing can begin, and a second tester a year later will interview someone else and test a different control under the same name. The description is the control’s specification; when the specification is vague, the control is vague, the test is vague, and the conclusion is worth nothing.
This guide sets out the five-part formula for a control description that can be tested by someone who has never met the process owner: who performs it, what they do, when, how, and what evidence it leaves. It explains why the formula matters for every downstream use of the description, from the risk and control matrix to SOX testing to the external auditor’s reliance, rewrites ten typical poor descriptions into testable ones with a note on what changed, gives the five-question test that tells you a description is ready, and shows how the formula bends for automated and IT-dependent controls. It feeds the risk and control matrix template and the free RCM Workbench, where every control you enter deserves a description written this way.
In this guide
- What a control description is for, and how vague ones fail
- The five parts, and the two attributes that make them precise
- The sentence pattern and how long a description should be
- Ten before-and-after rewrites
- Manual, automated, and IT-dependent controls: how the formula bends
- The five-question testability check
- Worked example: MidState’s route cash controls, described properly
- How the description drives SOX scoping, testing, and reliance
- A drafting process for a whole matrix
- Common mistakes
What a control description is for, and how vague ones fail
A control description is read by more people than any other sentence in a control framework. The process owner reads it to know what they are accountable for. The internal auditor reads it to design a test. The SOX team reads it to decide whether it is a key control and how many items to sample. The external auditor reads it to decide whether to rely on management’s testing. The new hire reads it to learn the job. A regulator reads it in a walkthrough and forms a view of the whole control environment from how precisely the company can describe what it does. Each of those readers needs the same thing from the sentence: enough specificity to know exactly what would constitute the control operating and what would constitute it failing.
| How vague descriptions fail | Example | What goes wrong downstream |
|---|---|---|
| No performer | “The report is reviewed.” | The tester cannot check who did it; segregation of duties cannot be assessed; nobody is accountable when it lapses |
| No frequency | “Reconciliations are performed.” | The population cannot be defined, so the sample size cannot be set; the sample size guide starts from frequency |
| No precision | “Variances are investigated.” | The tester cannot tell whether a $40 variance left uninvestigated is an exception; the control cannot be evaluated for whether it would catch a material error |
| No evidence | “The manager checks the entries.” | Nothing to inspect; the test collapses to inquiry, which is never sufficient on its own |
| Describes the objective, not the activity | “Access is restricted to authorized personnel.” | That is the outcome the control is supposed to produce; the control itself, the approval and the periodic review, is unnamed and untested |
| Describes the policy, not the control | “Purchases above $10,000 require two approvals.” | A policy states a rule; the control is what enforces it: a workflow configuration, a signature, a system block |
| Bundles several controls | “Vendor changes are requested, approved, entered, and verified.” | Four controls with four performers; a single test cannot cover them and a single exception cannot be attributed |
| Names the system, not the check | “The ERP prevents duplicate payments.” | Which configuration, on which fields, and who can change it; without those the automated control cannot be tested or its general controls scoped |
The cost of these failures is not abstract. The same imprecision that leaves a tester guessing leaves the operator guessing, which is why vaguely described controls fail operating effectiveness tests at higher rates: the person performing the control is doing what they think it is rather than what the framework needs it to be. The what is a control guide covers the underlying definition; this guide is about writing it down.
The five parts, and the two attributes that make them precise
| Part | The question it answers | Example fragment | If it is missing |
|---|---|---|---|
| Who | Which role performs the control, and which role must not | “The accounts payable manager”, not “management”; “independent of the preparer” | Accountability and segregation cannot be assessed; the test cannot verify the performer |
| What | The action taken, as a verb that can be observed | “compares”, “approves”, “reconciles”, “rejects”, “investigates”; not “ensures”, “monitors”, “oversees” | The activity is undefined; “monitors” can mean anything from a glance to a re-performance |
| When | The frequency or trigger | “each business day by 10 a.m.”; “before the entry posts”; “within five business days of the termination date” | The population is undefined; timeliness cannot be tested |
| How | The mechanism, including the source of the information used | “using the aged payables report generated from the ERP”; “by comparing the settlement sheet to the handheld export” | The tester cannot re-perform; the report’s reliability is never tested; see the IPE guide |
| Evidence | What the control leaves behind that proves it operated | “initials and date on the report”; “the approval record in the workflow”; “the ticket closed with the investigation notes” | The control can only be tested by inquiry, which is never sufficient alone |
| Precision (attribute) | The threshold at which the performer acts | “any variance above $50 or 2 percent of the deposit, whichever is lower” | The control’s ability to catch a material error cannot be judged; every review control needs it |
| Exception handling (attribute) | What happens when the check finds something | “investigates and documents the resolution before the deposit is approved; unresolved items are escalated to the controller the same day” | A control that finds errors and does nothing about them is a detective control with no correction |
The two attributes are what separate a description that can be tested from one that can be relied on. A review control without a precision statement cannot be evaluated against the risk it addresses, because nobody can say whether the reviewer would notice the error that matters, which is the whole subject of the management review controls guide. And a control without exception handling describes only half the control: detection without correction. Where a control has a compensating partner, name it in the matrix rather than in the description, so that each description stays a single control.
The sentence pattern and how long a description should be
The pattern is one sentence for the control and, where needed, one for the exception handling: [Who] [what, as an observable verb] [the object] [when], [how, including the information source], [precision], and [evidence]. Two sentences, forty to eighty words, is the normal length; a description under twenty words is almost always missing a part, and one over a hundred is usually two controls. Written to the pattern, the accounts payable review reads: “The accounts payable manager reviews the weekly aged payables report generated from the ERP each Monday, investigates every invoice aged over 60 days and every vendor with an open balance above $25,000, and evidences the review by initialing and dating the report and logging each follow-up item in the AP issue tracker. Items unresolved after ten business days are escalated to the controller.” Every reader listed above can now do their job from that sentence alone.
Three drafting rules keep descriptions honest. Verbs must be observable: compares, approves, signs, rejects, reconciles, counts, investigates. The words “ensures”, “monitors”, “oversees”, “is responsible for”, and “appropriately” are banned, because each hides the actual activity. Nouns must be specific: the report has a name and a source system, the threshold has a number, the frequency has a unit. And the description must describe what happens, not what should happen; if the process owner says “we’re supposed to do it weekly but it’s really monthly”, the description says monthly and the gap between policy and practice becomes a finding rather than a fiction in the matrix.
Ten before-and-after rewrites
Each “before” below is a description taken from the kind of matrix that arrives in an auditor’s inbox; each “after” is the same control written to the formula, with the change that mattered most in the last column. The rewrites are deliberately drawn from different processes so that the pattern, rather than the process, is what you take away.
| # | Before | After | What changed |
|---|---|---|---|
| 1 | Management reviews the report. | The accounts payable manager reviews the weekly aged payables report generated from the ERP each Monday, investigates every invoice aged over 60 days and every vendor with an open balance above $25,000, and evidences the review by initialing and dating the report and logging follow-ups in the AP issue tracker. | Named performer, named report and source, weekly frequency, two precision thresholds, and evidence in two places |
| 2 | Bank reconciliations are performed. | The staff accountant prepares a reconciliation of each of the nine operating bank accounts to the general ledger within five business days of month end using the bank statement downloaded from the bank portal; the assistant controller, who has no cash handling or posting access, reviews it, investigates reconciling items older than 30 days or above $5,000, and signs and dates the reconciliation in the close binder. | Preparer and independent reviewer, population of nine accounts, deadline, information source, precision, evidence |
| 3 | Access is restricted to authorized users. | New ERP user accounts are created by the IT security administrator only on receipt of an access request form approved by the employee’s department head and by the application owner for the requested role; the approved form is attached to the ticket, and the account is provisioned with the roles on the form and no others. | The objective became the activity: two approvals, a form, a ticket, and a “no others” precision statement |
| 4 | Journal entries are approved. | Manual journal entries above $10,000 are routed by the ERP workflow to the accounting manager, who reviews the supporting documentation attached in the workflow for business rationale and account coding before approving; entries cannot post without approval, the workflow records approver and timestamp, and a delegate approver is assigned during the manager’s absences so that no entry auto-releases. | Threshold, routing mechanism, what the reviewer examines, system enforcement, evidence, and the delegate rule that closes the auto-release gap |
| 5 | Physical inventory counts are performed periodically. | Warehouse staff count the full stock of each depot annually and the top 200 SKUs by value quarterly, using blind count sheets printed without system quantities after receiving and shipping are frozen; the depot manager investigates variances above 2 percent of a SKU’s book quantity or $1,000 before adjustments post, and the signed count sheets and variance log are retained in the depot file. | Two frequencies with defined scope, blind counts, the freeze, precision, and evidence |
| 6 | The system does not allow duplicate invoices. | The ERP rejects any invoice entry where the vendor number and invoice number match an existing record, based on the duplicate-check parameter in the AP module configuration; the rejection is logged in the AP error log, and changes to the parameter are restricted to the IT application team under the change management process. | Automated control named by its configuration, its log, and the general control that protects it |
| 7 | Vendor changes are reviewed. | Each business day, the AP supervisor, who cannot create or edit vendor records, reviews the ERP vendor master change report for the previous day, agrees every bank account change to the vendor’s signed change request received through the vendor portal, calls the vendor at the phone number on the existing master record for any bank account change, and initials the report; unmatched changes are reversed the same day. | Segregation stated, daily frequency, the source report, the callback mechanism, evidence, and the correction |
| 8 | Segregation of duties is maintained. | The ERP role design prevents any single user from holding both vendor master maintenance and invoice entry, or invoice entry and payment release; the IT security administrator runs the conflicting-roles report quarterly, the controller reviews and approves any documented exception with a compensating control, and the report and approvals are retained. | A design property became two controls: the preventive role configuration and the detective quarterly review, each with performer and evidence |
| 9 | Payroll is reviewed before processing. | Before each biweekly payroll is released, the payroll manager compares the payroll register to the prior period’s register using the variance report from the payroll system, investigates any employee whose gross pay changed by more than 10 percent or $1,000, any new employee, and any terminated employee still paid, and documents the review by signing the variance report; the HR director, independent of payroll entry, approves the release in the system. | Comparison mechanism, three specific attributes of what is investigated, precision, evidence, and a second independent approver |
| 10 | Compliance monitors adherence to policy. | The compliance testing team selects 25 new customer accounts each month from the core system’s new-account report, tests each against the customer identification checklist, records results in the compliance testing log, reports exceptions to the branch operations manager within five business days, and includes the exception rate in the quarterly compliance report to the risk committee. | A monitoring function described as a control: sample, source, criteria, log, reporting, and cadence |
Look at what the rewrites did not do. They did not add adjectives; “appropriately”, “timely”, and “adequately” appear nowhere in the after column. They did not lengthen the description with policy background. And they did not describe the risk, which belongs in the matrix’s risk column rather than the control description; the description says what happens, and the matrix’s structure links it to why. The preventive, detective, corrective guide covers the classification that sits alongside the description, and the segregation of duties guide covers why rewrite eight needed to become two controls.
Manual, automated, and IT-dependent controls: how the formula bends
The five parts apply to every control, but the answers change shape with the control’s nature, and a description that treats an automated control like a manual one, or the reverse, misleads the tester about what to test.
| Control type | Who | How and when | Evidence | What the tester will need from the description |
|---|---|---|---|---|
| Manual | A named role, with the segregation stated | The action and its frequency in human terms | Signatures, initials, logs, tickets | Population and frequency for sampling; the performer’s independence; the evidence to inspect |
| Automated | The system, named, with the configuration parameter or rule identified | The condition the system evaluates and what it does when the condition is met (rejects, blocks, routes, flags), on every transaction | The configuration itself, the system log of rejections, and the change records | The configuration to inspect, one transaction to re-perform, and the general controls over changes and access; see the ITGC vs. application controls guide |
| IT-dependent manual | A named role reviewing system output | The report by name and source system, the parameters it is run with, and the review criteria | Evidence of the review plus the report as run | The report’s completeness and accuracy must be tested as well as the review; the description must name the report precisely enough to test it |
| Entity-level | The board, a committee, or an executive | Meetings, approvals, and policies, with cadence | Minutes, approved documents, attestations | Entity-level controls are assessed rather than sampled; the description must state the cadence and the document that results |
The IT-dependent manual control is where descriptions fail most often and most expensively. “The controller reviews the variance report” hides two controls: the human review and the report’s reliability, and a tester who inspects the controller’s initials without testing that the report contained every variance has tested nothing. The description must name the report, its source, and the parameters, so that the information produced by the entity can be tested alongside the review. For automated controls the description must name the configuration, because the test is the configuration, and it must point to the change and access controls that protect it, because a configuration anyone can change is not a control.
The five-question testability check
Before a description goes into a matrix, hand it to someone who has never seen the process and ask the five questions below. If any answer is “I’d have to ask”, the description is not finished. The check takes two minutes per control and saves the hours a tester would otherwise spend rediscovering the control in the field; the design vs. operating effectiveness guide explains why a description that fails the check produces a test that cannot distinguish the two.
| Question | What a passing description tells the reader | Typical failure |
|---|---|---|
| 1. What is the population? | The set of instances the control operates over and how often: nine accounts monthly, every manual journal above $10,000, every termination | “Reconciliations are performed” gives no population; the tester cannot size a sample |
| 2. How would I select a sample? | The trigger or frequency implies the list: the month-end reconciliations, the workflow’s approval log, the HR termination report | No source for the list; the tester takes whatever management provides |
| 3. What evidence would I ask for? | Named artifacts: the initialed report, the workflow record, the signed count sheet, the ticket | “Reviews” with no artifact; the tester falls back on inquiry |
| 4. What would an exception look like? | A missing signature, a variance above the threshold left uninvestigated, an entry approved by the preparer, a report run with the wrong parameters | No precision or performer stated, so nothing can be called an exception |
| 5. Would this control catch the error that matters? | The precision threshold sits below the size of misstatement or loss the risk column describes | Threshold missing or set above materiality; the control operates perfectly and catches nothing relevant |
Worked example: MidState’s route cash controls, described properly
MidState Beverage’s route cash process, the example that runs through the internal controls guide, had a control matrix before the FY27-01 audit that read exactly like the “before” column above: “settlements are reconciled daily”, “variances are approved”, “deposits are verified”. The audit found that the reconciliation was not independent at nine of twelve depots and that 1,412 variance overrides had been approved by the person whose variance it was. Neither problem was visible in the matrix, because the descriptions never said who. The rewrites below are what the matrix says now, and the difference is that each one names the segregation the old version silently assumed.
| Control | Before | After | What the audit found that the old description hid |
|---|---|---|---|
| Daily settlement reconciliation | Settlements are reconciled daily. | Each business day, the depot clerk, who does not handle route cash, counts the cash and checks turned in against the handheld settlement export for every route and prepares the settlement reconciliation; the depot manager, who neither drives nor counts, reviews it, investigates any variance above $25, and signs and dates it; the signed reconciliation and export are scanned to the depot folder by 10 a.m. the following day. | At nine depots the reviewer was the preparer or had handled the cash; the old description could not have been tested for independence because it named no one |
| Variance override approval | Variances are approved. | Any settlement variance above $50 requires approval in the ERP by a depot manager other than the user who recorded the settlement; the ERP records the approver and prevents self-approval by role configuration; the controller reviews the monthly override report for approver and frequency by depot. | 1,412 overrides were self-approved because the ERP role design allowed it; the rewritten description names the system rule that now prevents it and the monthly review that detects it |
| Deposit verification | Deposits are verified. | The depot clerk prepares the deposit listing in the ERP from the settlement records, not by re-keying, and the depot manager agrees the listing to the bank deposit receipt the same day and initials both; the controller’s monthly bank reconciliation agrees deposits per bank to the ERP listing for all twelve depots, including the two acquired depots’ accounts. | Seven depots re-keyed the listing into spreadsheets, breaking the trail; the controller’s reconciliation excluded the acquired depots; both facts are now in the description as requirements |
| Customer statements | Statements are sent monthly. | Accounts receivable generates and sends monthly statements to every active customer flagged as cash-paying in the customer master on the third business day; the AR supervisor reconciles the statement run count to the count of active cash-paying customers and investigates any difference before the run is released. | 1,130 customers were flagged to receive no statement; the reconciliation of the run to the master is the new control that catches it |
How the description drives SOX scoping, testing, and reliance
In a SOX program the description decides more than the test. The key-control decision rests on whether the control, as described, would prevent or detect a material misstatement in the assertion it is mapped to, and a description without precision cannot support that judgment, which is why so many matrices carry controls marked “key” on faith. The sample size rests on the frequency stated: a daily control is tested with 25 to 40 items, a monthly one with two to four, an annual one with one, and a description that says “periodically” gives the SOX team no basis for any of them. The external auditor’s decision to rely on management’s testing rests partly on whether the descriptions are specific enough that management’s tester and the external auditor’s tester would test the same thing; a matrix of vague descriptions is a matrix the external auditor will re-perform in full, at the company’s expense. The SOX scoping guide covers the key-control decision and the deficiency evaluation guide what happens when a control described as precise turns out not to be.
The same logic applies outside SOX. An internal audit function deciding whether to rely on a second-line function’s monitoring, under the coordination and reliance standard, needs the monitoring described as a control: what is sampled, from where, against what criteria, with what evidence. Regulators in examinations ask process owners to describe their controls and judge the control environment by the answers; a bank whose managers can state who, what, when, how, and evidence without looking anything up presents very differently from one whose managers say “we review it”. And a process owner who has written the description in this form has, usually for the first time, decided exactly what the control is, which is why the drafting exercise often improves the control before anyone tests it.
A drafting process for a whole matrix
Rewriting one description is a two-minute job; rewriting a matrix of two hundred is a project, and it goes better in a fixed order. Start by listing every control and marking the ones that fail the five-question check, which in most inherited matrices is the majority. Take the key controls first, because they carry the reliance and the testing hours. For each, sit with the actual performer, not the process owner’s manager, and watch the control once; write the description from what you saw, then read it back and let them correct it. Add precision and exception handling as explicit questions: what number makes you act, and what do you do when it does. Split anything that turns out to be two controls, and merge anything that turns out to be one control described twice under two names. Run the five questions on the finished set with someone who did not write them. Then load the result into the RCM Workbench or your matrix and treat the descriptions as the specification for the next test cycle, so that any tester who finds the control operating differently from its description raises the difference rather than quietly testing what they found. The work program guide shows how the finished descriptions turn into test steps almost mechanically, which is the surest sign they were written properly.
Common mistakes
| Mistake | Example | Fix |
|---|---|---|
| Describing the objective | “Revenue is recorded in the correct period.” | Name the activity that produces it: the cut-off review, who performs it, on what report, at what threshold |
| Describing the policy | “All contracts over $100,000 require legal review.” | Name the enforcement: the workflow that blocks signature without legal’s approval record, or the quarterly review of signed contracts against legal’s log |
| Hiding the performer in “management” | “Management approves new vendors.” | The role, and the role it must be independent of |
| Unobservable verbs | “The controller monitors cash balances.” | Compares, investigates, approves: what would someone watching actually see |
| No precision on a review control | “The CFO reviews the monthly financial statements.” | State what the CFO compares against and the variance that triggers investigation; without it the review cannot be evaluated |
| Bundling | “Invoices are received, matched, approved, and paid.” | One description per control; four here |
| Describing the ideal, not the practice | Weekly in the matrix, monthly in reality | Describe what happens; raise the gap as a finding |
| Report without a source | “reviews the exception report” | Name the system, the report, and the parameters, so the report can be tested |
| Automated control without its configuration | “The system prevents duplicate payments.” | Name the parameter, the log, and the change control over it |
| Adjectives instead of numbers | “timely”, “appropriately”, “significant” | Five business days, by the department head, above $5,000 |
A control description written to the formula is longer than the one it replaces, and that is the point. The extra forty words are the specification that every downstream reader needs and that every vague description forces them to reconstruct. Write who, what, when, how, and evidence, add the precision and the exception handling, run the five questions, and the matrix stops being a list of good intentions and becomes something a tester can test, a regulator can read, and a process owner can be held to.
Related guides
- Risk and control matrix template
- RCM Workbench (free tool)
- What is a control
- Internal controls: what they are and who tests them
- Management review controls
- Testing information produced by the entity
- Segregation of duties
- ITGC vs. application controls
- Test of design vs. operating effectiveness
- Preventive, detective, and corrective controls
- Audit sample sizes
- SOX 404 explained
- The COSO 17 principles
- Start here
Leave a Reply