Ask five people in a company to name a control and you will get a policy, a system, a report, a department, and a person. “We have a travel policy.” “SAP won’t let you do that.” “Finance gets a monthly report.” “Compliance reviews it.” “Maria checks everything.” None of those is a control, and the gap between what people call a control and what actually stops or catches an error is where most audit findings live. A control is an action: something a specific person or system does, at a specific point, to a specific population, that prevents a specific bad thing from happening or detects it afterwards, and that leaves evidence it happened. The travel policy is the criterion the control enforces. SAP’s configuration is a control only if someone can say which setting blocks which transaction. The monthly report is a control only when someone reads it against a threshold and acts. Compliance’s review is a control when its scope, frequency, and follow-up are defined. Maria is a control risk.
This guide defines a control the way the frameworks and the Standards define it, then takes the definition apart and shows how to recognize, describe, classify, and test one. It gives the COSO and IIA definitions and what each word in them does, the seven attributes every control description needs with five weak-versus-strong rewrites, a classification table covering the six axes auditors use, a library of 40 controls across ten industries and processes with the risk each addresses and the evidence each leaves, a table of the things that get called controls but are not, a table showing how the same risk is controlled at a 40-person company and a 40,000-person one, the four questions an auditor asks to test a control, and the mistakes people make when writing controls into a risk and control matrix. It was rewritten in September 2026 to reflect the Global Internal Audit Standards and COSO’s 2013 framework as currently applied. It pairs with the site’s guides to the COSO 17 principles and to preventive, detective, and corrective controls, which go deeper on two of the sections below.
In this guide
- The definition, and what each word is doing
- The anatomy of a control: seven attributes and five rewrites
- Classifying controls: the six axes
- A library of 40 controls across industries and processes
- What is not a control
- The same risk controlled at three sizes of organization
- How an auditor tests a control: four questions
- Writing controls into a risk and control matrix
- Common mistakes in identifying and describing controls
The definition, and what each word is doing
Two definitions govern the profession’s use of the word, and they operate at different levels. COSO’s 2013 Internal Control – Integrated Framework defines internal control, the system, as a process, effected by an entity’s board of directors, management, and other personnel, designed to provide reasonable assurance regarding the achievement of objectives relating to operations, reporting, and compliance. The IIA’s Global Internal Audit Standards define a control, the unit, in their glossary as any action taken by management, the board, and other parties to manage risk and increase the likelihood that established objectives and goals will be achieved. Read together they say four things. A control is an action, not a document or a structure. It is taken by people or by systems people configured, so it has an owner. It exists to manage a risk to an objective, so a control without a named risk is unmoored. And the standard it is held to is reasonable assurance, not certainty, which is why controls are designed to a precision and a frequency and why a control that catches nine errors in ten can be well designed for one risk and inadequate for another.
COSO’s five components (control environment, risk assessment, control activities, information and communication, monitoring) and 17 principles describe the system; controls in the everyday sense are mostly control activities under Principles 10 to 12, which require the organization to select and develop control activities that mitigate risks to acceptable levels, to select and develop general controls over technology, and to deploy control activities through policies and procedures. That last principle is the source of the most useful test in this guide: a control exists when a policy (the rule) has been turned into a procedure (who does what, when) that people actually perform. The policy alone fails Principle 12 before anyone asks whether it works. The IIA’s definition adds the risk linkage, and the Standards’ requirement that engagements evaluate the design and operation of controls (Standard 13.2 and Domain V generally) means an internal auditor has to be able to say, for each control, which risk it manages and how well; the GIAS Domain V guide shows where that evaluation sits in an engagement.
The anatomy of a control: seven attributes and five rewrites
A control that cannot be described in a sentence with seven attributes cannot be tested, because the tester will not know what to look for. The attributes are the performer (a role, not a name), the action (a verb that could be observed: compares, approves, reconciles, blocks, recounts), the object (which transactions, records, or assets), the frequency or trigger (daily, per transaction, monthly, on exception), the criterion (against what: a policy limit, a source document, a prior balance, a threshold), the evidence (what the action leaves behind: a signature, a system log, a tick mark, a workflow status), and the follow-up (what happens when the control finds something). Descriptions that omit the criterion or the evidence are the ones that fail in testing, because “reviews the report” can be true of a glance and of a line-by-line check, and only the latter is a control. The table rewrites five descriptions of the kind found in most risk and control matrices.
| As written in the RCM | What is missing | Rewritten with the seven attributes |
|---|---|---|
| “Management reviews the monthly financials.” | Performer, object, criterion, evidence, follow-up | The controller (performer) compares (action) each P&L line for each entity (object) to budget and prior month (criterion) within five business days of close (frequency), investigates variances over $25,000 or 10 percent (criterion and precision), and documents explanations in the close checklist, signed and dated (evidence); unexplained variances are escalated to the CFO before the reporting package is released (follow-up) |
| “Invoices are approved before payment.” | Performer, criterion, evidence | The cost center manager named on the PO (performer) approves (action) each non-PO invoice over $1,000 (object) in the AP workflow against the delegation of authority limits (criterion) before the payment run (trigger); approval is recorded with user ID and timestamp in the workflow log (evidence); invoices without approval are held by AP and reported weekly to the AP manager (follow-up) |
| “The system prevents duplicate payments.” | Configuration, object, evidence, follow-up | The ERP duplicate-invoice check (performer: automated), configured to block entry of an invoice with the same vendor, invoice number, and amount as an existing record (criterion), for all invoices at entry (object and trigger); blocked attempts are logged in the exception report (evidence), which the AP supervisor reviews weekly and clears with a documented reason (follow-up) |
| “Depot cash is reconciled daily.” | Performer independence, criterion, evidence | The regional finance analyst (performer, independent of the depot) reconciles (action) each depot’s daily settlement total per the route module (object) to the bank deposit per the bank portal (criterion) each business day (frequency), records the reconciliation and any variance in the ERP workflow with approval (evidence), and refers variances over $100 to the depot manager and over $500 to the regional finance manager the same day (follow-up) |
| “Access is reviewed periodically.” | Performer, object, criterion, frequency, evidence, follow-up: everything but the verb | Each application owner (performer) reviews (action) the system-generated user access list for their application (object) against current HR roster and role definitions (criterion) quarterly (frequency), certifies the list in the access review tool (evidence), and removal requests for terminated or inappropriate access are raised within five business days and confirmed by IT (follow-up) |
Notice what the rewrite does to testability. For the first version of each control there is no test to design; for the second, the test writes itself: select 25 invoices over $1,000, check the workflow log for an approval by the named manager before the payment run, check the approver’s limit against the delegation of authority. The rewrite also exposes design problems immediately. The depot cash control, as originally described, was performed at MidState Beverage by the depot manager who had also approved the settlements, which the seven-attribute version makes visible in the word “independent”; the site’s segregation of duties guide covers that class of design failure. Functions that adopt a description standard find their RCMs shrink, because half the “controls” listed cannot be written this way and turn out to be policies, reports, or wishes.
Classifying controls: the six axes
Controls are classified along several axes at once, and each axis answers a different audit question. Timing tells you whether the control stops the error or finds it afterwards, which decides how much loss can occur before detection. Nature tells you how it is tested: an automated control is tested once for configuration plus the IT general controls that keep the configuration stable, while a manual control is sampled across the period. Level tells you what it protects: entity-level controls set the environment, process-level controls govern a flow, transaction-level controls act on individual items. Objective maps to COSO’s three categories. Significance (key or non-key) decides whether the control is relied on and therefore tested. Function is the everyday vocabulary of what the control does. The table sets out the six axes with the audit consequence of each.
| Axis | Categories | Example | Audit consequence |
|---|---|---|---|
| Timing | Preventive; detective; corrective | Approval limit blocks a payment (preventive); bank reconciliation finds an unauthorized payment (detective); recovery procedure recalls it and revises the limit (corrective) | Preventive controls limit exposure; detective controls limit duration; a process with only detective controls needs them to be frequent and precise, and the auditor should ask what loss occurs between error and detection |
| Nature | Manual; automated; IT-dependent manual (a person acting on a system report) | Supervisor signs a timesheet (manual); system enforces three-way match tolerance (automated); controller reviews a system-generated variance report (IT-dependent manual) | Automated controls are tested once plus ITGCs; manual controls are sampled by frequency; IT-dependent manual controls require the report to be tested as information produced by the entity before the review can be relied on |
| Level | Entity-level; process-level; transaction-level | Code of conduct and tone at the top (entity); month-end close checklist (process); PO approval (transaction) | Entity-level controls are evaluated for their pervasive effect and rarely sampled; transaction-level controls carry the detailed testing |
| Objective | Operations; reporting (financial and non-financial, internal and external); compliance | Route scheduling optimization (operations); revenue cutoff review (reporting); excise tax filing review (compliance) | Determines which stakeholders care and which criteria apply; SOX scoping covers only controls relevant to external financial reporting |
| Significance | Key; non-key (secondary, compensating) | Independent settlement reconciliation (key); depot manager’s informal daily glance at totals (non-key) | Key controls are the ones whose failure would leave the risk unmitigated; testing concentrates on them; non-key controls are documented for context and as candidates for compensating reliance |
| Function | Authorization; segregation of duties; reconciliation; verification and matching; physical safeguard; review and supervision; information processing (edit checks, validations); IT general controls | See the 40-control library below | The function is the vocabulary used in RCMs and work programs, and each function has a characteristic evidence type and test |
Two of the axes get misused. “Automated” is claimed for anything involving a computer, but a control is automated only where the system performs the comparison and takes the action without a person; a report a person must read is IT-dependent manual, and the distinction decides whether one test or twenty-five is needed, as the ITGC versus application controls guide explains. And “key” is applied to too many controls, usually because the process owner listed everything they do and nobody asked which controls, if removed, would leave a risk uncontrolled. The test for key status is subtraction: take the control away and ask whether the risk is still mitigated by something else. If it is, the control is non-key.
A library of 40 controls across industries and processes
The library below is meant to be lifted into risk and control matrices and adapted. Each row names the control in the seven-attribute style, compressed, the risk it addresses, its classification on the timing and nature axes, and the evidence an auditor would inspect. The rows are grouped by process and drawn from manufacturing, distribution, banking, healthcare, software, retail, nonprofit, and public sector settings; several are MidState Beverage’s controls after its FY27 route cash remediation.
| # | Control | Risk addressed | Type | Evidence |
|---|---|---|---|---|
| 1 | Procure-to-pay: ERP three-way match blocks invoice posting where quantity or price varies from PO and receipt beyond a 2 percent or $50 tolerance | Payment for goods not received or at unauthorized prices | Preventive, automated | Configuration screen; blocked-invoice log |
| 2 | Procure-to-pay: vendor master changes require a second-person approval in the workflow, with a callback to the vendor at a number on file for bank detail changes | Payment redirection fraud | Preventive, IT-dependent manual | Workflow approval log; callback note |
| 3 | Procure-to-pay: AP supervisor reviews the weekly duplicate-invoice exception report and clears each item with a reason | Duplicate payment | Detective, IT-dependent manual | Signed report with dispositions |
| 4 | Procure-to-pay: treasury releases payment runs only after a second approver compares the run total and count to the AP proposal | Unauthorized or altered payment file | Preventive, manual | Release approval record |
| 5 | Order-to-cash: credit limit check in the order system blocks orders that would exceed the customer’s approved limit | Credit loss | Preventive, automated | Configuration; blocked-order log |
| 6 | Order-to-cash: pricing overrides above 5 percent require sales director approval in the system before invoicing | Revenue leakage; unauthorized discounts | Preventive, IT-dependent manual | Override approval log |
| 7 | Order-to-cash: monthly statements are sent to every customer with a balance, and returned or disputed statements are logged and investigated by credit control | Lapping; unbilled sales; misapplied cash | Detective, manual | Statement run log; dispute register |
| 8 | Order-to-cash: revenue recognized on shipment is reconciled to shipping system records at month end by the revenue accountant | Cutoff error; fictitious revenue | Detective, IT-dependent manual | Reconciliation with sign-off |
| 9 | Cash: regional finance analyst reconciles each depot’s daily settlement to the bank deposit and approves in the ERP workflow (MidState, post-remediation) | Skimming; short deposits | Detective, IT-dependent manual | Workflow approval; variance log |
| 10 | Cash: settlement variance overrides above $25 per route-day require approval by a supervisor other than the settlement clerk, enforced by role in the route module (MidState) | Self-approved write-offs concealing theft | Preventive, automated with manual approval | Role configuration; approval log |
| 11 | Cash: two-person count of the depot safe at shift change, recorded on a numbered count sheet and compared to the system balance | Cash loss between settlement and deposit | Detective, manual | Count sheets; variance reports |
| 12 | Cash: bank reconciliations prepared by the staff accountant and reviewed by the assistant controller within five business days of month end, with reconciling items over 30 days escalated | Unrecorded transactions; concealed shortages | Detective, manual | Reconciliation with preparer and reviewer sign-off and dates |
| 13 | Payroll: HR-initiated new hires and terminations flow to payroll through the HRIS interface; payroll cannot create employee records directly | Ghost employees | Preventive, automated | Interface configuration; access roles |
| 14 | Payroll: payroll manager reviews the pre-transmission register for employees with changes over 10 percent from the prior period and for duplicate bank accounts | Unauthorized pay changes; diversion | Detective, IT-dependent manual | Reviewed register with annotations |
| 15 | Payroll: department heads approve timesheets in the time system before the payroll cutoff; unapproved time is not paid | Overpayment for hours not worked | Preventive, IT-dependent manual | Approval timestamps |
| 16 | Inventory: cycle counts of A-class items weekly by warehouse staff not responsible for the location, with variances over 2 percent investigated by the inventory controller before adjustment | Shrinkage; record inaccuracy | Detective, manual | Count sheets; adjustment approvals |
| 17 | Inventory: adjustments over $5,000 require plant controller approval in the ERP before posting | Concealment of shrinkage through adjustments | Preventive, IT-dependent manual | Approval log |
| 18 | Inventory: physical access to the warehouse is restricted by badge to warehouse staff, with the access list reviewed quarterly by the warehouse manager | Theft | Preventive, automated with manual review | Badge system access list; quarterly certification |
| 19 | Fixed assets: capitalization requests over the threshold are approved by the controller against the capitalization policy before posting | Misclassification of expenses as assets | Preventive, manual | Approved capitalization form |
| 20 | Fixed assets: annual physical verification of tagged assets against the register by facilities, with missing assets investigated before write-off approval | Existence; unrecorded disposals | Detective, manual | Verification listing; write-off approvals |
| 21 | Financial close: close checklist with owner, due date, and sign-off for each task, reviewed by the controller before the reporting package is released | Incomplete or late close; missed entries | Preventive and detective, manual | Completed checklist |
| 22 | Financial close: manual journal entries over $50,000 require preparer and independent approver in the ERP; the system blocks self-approval | Unauthorized or erroneous entries | Preventive, automated with manual approval | JE approval log; configuration |
| 23 | Financial close: controller reviews the entity P&L and balance sheet against budget and prior period, investigates variances over $25,000 or 10 percent, and documents explanations | Undetected misstatement | Detective, IT-dependent manual | Signed flux analysis |
| 24 | IT general controls: new user access requires manager approval in the ticketing system and provisioning by IT to the role approved, with the ticket retained | Inappropriate access | Preventive, manual | Tickets with approvals |
| 25 | IT general controls: terminated employees’ access is removed within one business day of the HR termination record, triggered by the HRIS feed and confirmed by IT | Access by former employees | Preventive, IT-dependent manual | Termination report matched to access removal log |
| 26 | IT general controls: quarterly user access review by application owners against HR roster and role definitions, certified in the access review tool | Accumulated inappropriate access | Detective, IT-dependent manual | Certifications; removal tickets |
| 27 | IT general controls: program changes require documented testing and approval by a person other than the developer before migration to production, enforced by the deployment tool | Unauthorized or untested changes | Preventive, automated with manual approval | Change records; deployment log |
| 28 | IT general controls: privileged access is limited to named administrators, with activity logged and reviewed monthly by the security team | Misuse of administrative rights | Detective, IT-dependent manual | Privileged access list; log review record |
| 29 | Cybersecurity: multi-factor authentication enforced for all remote and administrative access | Credential compromise | Preventive, automated | Identity provider configuration |
| 30 | Cybersecurity: critical patches deployed within 14 days of release, with the exceptions report reviewed by the CISO monthly | Exploitation of known vulnerabilities | Preventive and detective, IT-dependent manual | Patch compliance report; exception dispositions |
| 31 | Banking: transactions above the customer’s expected activity profile generate an alert that an AML analyst disposes within five business days, with SAR decisions approved by the BSA officer | Money laundering; regulatory breach | Detective, IT-dependent manual | Alert dispositions; SAR approval records |
| 32 | Banking: loan disbursements require verification that all approval conditions are satisfied, performed by loan operations independent of the originating officer | Disbursement of unapproved or non-compliant loans | Preventive, manual | Closing checklist with sign-off |
| 33 | Healthcare: charge capture reconciliation between the clinical scheduling system and billed encounters, daily, by the revenue cycle analyst, with unbilled encounters worked within 48 hours | Lost revenue; billing errors | Detective, IT-dependent manual | Reconciliation reports; work queue records |
| 34 | Healthcare: access to patient records is role-based, with break-the-glass access logged and reviewed by the privacy officer weekly | Privacy breach | Preventive and detective, automated with manual review | Role configuration; access review log |
| 35 | Software (SaaS): production deployments require passing automated test suites and peer review approval in the source control system | Defects and unauthorized code in production | Preventive, automated | Pipeline configuration; merge records |
| 36 | Software (SaaS): customer contract terms entered in the billing system are reviewed against the signed contract by revenue accounting before the first invoice | Revenue misstatement from setup errors | Detective, manual | Setup review checklist |
| 37 | Retail: store cash drawers are assigned to one cashier per shift and counted at shift end against the POS record by the shift supervisor | Cash shortages without accountability | Detective, manual | Drawer count records |
| 38 | Retail: refunds over $100 require manager override at the register, and refund activity by cashier is reviewed weekly against store averages | Refund fraud | Preventive and detective, automated with manual review | Override log; weekly report with annotations |
| 39 | Nonprofit: restricted donations are coded to the restricted fund at receipt by the development coordinator and reviewed monthly by the finance director against donor documentation | Misuse of restricted funds | Preventive and detective, manual | Coding review record |
| 40 | Public sector: procurement above the competitive threshold requires evidence of three quotes or a documented sole-source justification approved by the procurement officer before the PO is issued | Non-compliant procurement; favoritism | Preventive, manual | Quote comparison or justification on file |
Three patterns run through the library. Almost every strong control has an independence property built into the performer: the reconciler is not the preparer, the approver is not the requester, the counter is not the custodian. Almost every detective control has a threshold and a follow-up, because a review without a threshold is a glance and a variance without a follow-up is a number. And the automated controls all depend on IT general controls (rows 24 to 28) to keep their configuration what it was when it was tested, which is why an audit that relies on rows 1, 5, 13, or 22 has to test the ITGCs too. The site’s process guides, including accounts payable, payroll, and user access reviews, expand the relevant rows into full test programs.
What is not a control
Most of the entries that have to be removed from a risk and control matrix fall into a handful of categories, and each has a tell. The table lists them with the question that exposes each and what the real control behind it, if any, would be.
| Often listed as a control | Why it is not one | The exposing question | The control that may be behind it |
|---|---|---|---|
| A policy (“Travel expenses must comply with the T&E policy”) | The criterion, not the action; a rule nobody enforces controls nothing | Who checks compliance with it, when, and what happens when they find a breach? | Manager approval of each expense report against policy limits before reimbursement, with the audit of a sample by finance |
| A system (“We use SAP”) | Software is a platform for controls, not a control; most configurations are permissive by default | Which setting blocks which transaction, and who can change it? | Specific configured checks (tolerances, limits, required fields) plus the change control over them |
| A report (“Management receives a monthly aged debtors report”) | Information, not action; a report unread is a file | Who reads it, against what threshold, and what do they do? | Credit manager reviews balances over 90 days and initiates collection or provision, documented |
| A department (“Compliance monitors this”) | An organizational unit, not a procedure | What does compliance actually do, to which population, how often? | A defined monitoring program with scope, frequency, and reporting |
| A person (“Maria checks everything”) | A dependency on an individual’s diligence, undefined and unevidenced; a key-person risk, not a control | What does she check, against what, and what would show she did it? | The specific comparison she performs, with evidence, and a backup performer |
| A risk restated (“Controls are in place to prevent fraud”) | An assertion, not a description | Which controls, and which fraud? | Named preventive and detective controls mapped to specific fraud schemes |
| Segregation of duties stated in the abstract (“Duties are segregated”) | A design principle, real only where role assignments enforce it | Which roles are separated, and how is it enforced and monitored? | Role design in the system, conflict rules, and a periodic SoD review |
| Training (“Staff are trained on the policy”) | A contributor to the control environment, not a control over a transaction | What stops a trained person from making the error anyway? | The transaction-level control the training supports |
| A KPI (“Days sales outstanding is tracked”) | A measure of an outcome; useful for monitoring, not a control over the process producing it | Who acts when the KPI moves, and how? | The review with a threshold and defined action |
| Management oversight (“The CFO is closely involved”) | Tone, not procedure; unfalsifiable | What does the CFO review, sign, or approve, and when? | Specific approvals and reviews performed by the CFO with evidence |
| An external audit (“The auditors look at this annually”) | Assurance after the fact by a party outside the process; not management’s control | What does management do during the year? | Management’s own review and reconciliation controls |
| Insurance | Risk financing; it transfers the loss, it does not prevent or detect the event | What reduces the likelihood or catches the event? | The operational controls; insurance is recorded as a risk response, not a control |
The exposing question is always some form of “who does what, when, against what, and what shows it?” A process owner who cannot answer it for an item in their matrix has told you something important about their process, and the item should be recorded as a gap, not carried as a control. The management review controls guide deals with the largest single category of false controls, the review that is really a glance, in detail.
The same risk controlled at three sizes of organization
A control has to fit the organization that performs it, and the frameworks say so: COSO’s reasonable-assurance standard and its explicit statement that smaller entities achieve the principles differently mean that “the vendor master change requires two approvers” is a well-designed control at a 40,000-person bank and an impossible one at a 40-person distributor with one person in finance. The auditor’s job is to ask whether the risk is controlled, not whether the large-company control is present, and the table shows the same three risks controlled at three scales. Notice that the small-company versions lean on the owner’s involvement and on detective controls performed by someone outside the process, which is legitimate design, and that they carry a key-person dependency the auditor should name as a residual risk rather than a finding.
| Risk | 40-person company, one finance person | 600-person company, small finance team, one-person internal audit | 40,000-person company |
|---|---|---|---|
| Fraudulent or erroneous vendor payments | Owner approves every payment run against the invoice list and signs the bank release; bank account requires dual authorization (owner plus bookkeeper); owner reviews the bank statement monthly line by line | AP clerk enters, controller approves invoices over $2,500 in the workflow, CFO releases payment runs after comparing to the proposal; vendor master changes approved by the controller with callback; monthly vendor-payment analytics run by internal audit | Automated three-way match; workflow approvals by delegation of authority; segregated vendor master team with callbacks; payment release by treasury with dual approval; continuous duplicate and anomaly analytics; quarterly SoD review |
| Payroll to fictitious or overpaid employees | Owner approves the payroll register each period and knows every employee by name; outsourced payroll provider processes only from the owner-approved register | HR maintains employee records, payroll manager processes, controller reviews the pre-transmission register for changes over 10 percent and new hires against HR’s list; annual internal audit of a payroll sample | HRIS-to-payroll interface with no direct payroll record creation; automated variance flags; departmental time approval; quarterly headcount reconciliation; analytics on duplicate bank accounts and addresses |
| Unauthorized system access | Owner is the administrator of the accounting package; two users, both known; annual password reset; bank tokens held by the owner | IT manager provisions access on the controller’s emailed approval; termination checklist includes access removal; internal audit reviews the user list against HR annually | Ticketed access requests with manager approval; HRIS-driven automatic deprovisioning; quarterly certifications by application owners; privileged access management with session logging |
The 600-person column is where most of this site’s readers work, and it is the hardest to design for, because it is large enough that the owner can no longer see everything and small enough that full segregation is unaffordable. The design pattern that works there is a small number of high-precision detective controls performed by someone outside the process (the controller’s register review, the CFO’s payment release, internal audit’s analytics), which is what the site’s guide to setting up an internal audit function in a small company recommends the first audit plan concentrate on.
How an auditor tests a control: four questions
Every control test answers four questions in order, and the seven attributes above are what make them answerable. Does the control exist as described? The auditor walks it with the performer, on a real transaction, and confirms the performer, action, object, frequency, criterion, evidence, and follow-up are as the matrix says; where they are not, the matrix is wrong and the design evaluation proceeds on the control as actually performed. Is it designed to address the risk? The auditor asks whether the control, performed as prescribed by a person with the necessary authority and competence, would prevent or detect the error the risk describes, at the precision the risk requires; a reconciliation with a $500 tolerance does not address a risk of $100 thefts. Did it operate through the period? The auditor selects a sample sized to the control’s frequency and the residual risk (commonly 25, 40, or 60 items for a daily control) and inspects the evidence for each, re-performing where the evidence alone does not show the criterion was applied. And what does a deviation mean? A single deviation in a sample sized on the assumption of none means the control cannot be relied on for the period, and the auditor’s job becomes establishing whether the cause was isolated or systemic and what the exposure is. The test of design versus operating effectiveness guide covers the second and third questions in depth, and the sampling guide the arithmetic behind the third.
Writing controls into a risk and control matrix
The risk and control matrix is where the definition becomes operational, and its columns are the seven attributes plus the classification axes plus the test. A workable RCM row carries the process and sub-process, the risk (what could go wrong, stated as an event with a consequence), the control in the seven-attribute form, the control owner by role, the frequency, the type on the timing and nature axes, key or non-key, the evidence, the design conclusion from the walkthrough, the test procedure, the sample size and its basis, and the result. Functions that write controls into the matrix in the seven-attribute form find that the test procedure column nearly writes itself and that the design conclusion column exposes the false controls before any testing hours are spent. The site’s risk and control matrix template has the columns, the free RCM Workbench builds one from a process description, and the walkthrough guide covers how the design conclusion gets filled in at the performer’s desk.
Common mistakes in identifying and describing controls
| Failure | What it looks like | Why it matters | Fix |
|---|---|---|---|
| Listing policies as controls | “Expenses comply with policy” in the control column | Nothing to test; the risk is uncontrolled while the matrix says otherwise | Write the enforcement action, performer, and evidence; the policy is the criterion |
| No independence in the performer | The preparer reviews their own work; the depot manager approves their own settlements | The control cannot detect what its performer wants hidden | Name the independence property in the description; where it cannot be achieved, record a compensating control or a gap |
| Reviews without thresholds | “Manager reviews the report” | Untestable and, in practice, a glance | State the criterion and the threshold that triggers action |
| Evidence omitted | A control that leaves no trace when performed | Cannot be distinguished from a control that did not operate | Design the evidence into the control: sign-off, log, workflow status |
| “Automated” for anything with a computer | A report someone reads classified as automated and tested once | Under-testing; the human part of the control is never sampled | Classify IT-dependent manual controls correctly and test the report as IPE |
| Everything marked key | Forty key controls in a process with six risks | Testing effort spread thin; the controls that matter get the same 25 items as the ones that do not | Apply the subtraction test; typically one or two key controls per risk |
| Controls without a risk | A control listed because the process owner does it, mapped to nothing | Effort spent testing something whose failure would not matter | Every control maps to a stated risk or is removed |
| Risks without a control | A risk row with a blank control cell quietly filled with “management oversight” | A real gap disguised as a control | Record the gap; it is a finding, not a matrix formatting problem |
| Large-company controls imposed on small companies | A finding that a 40-person firm lacks a segregated vendor master team | Unactionable; loses the auditee’s trust | Ask whether the risk is controlled at this scale; credit owner-level and detective controls where evidenced |
| Copying the prior year’s matrix | Controls described as in FY24 for a process re-implemented in FY26 | Testing controls that no longer exist as described | Walk the process each cycle and update the descriptions before testing |
A control is an action, by a named role, at a defined point, to a defined population, against a defined criterion, leaving evidence, with a defined follow-up. Everything in this guide is an elaboration of that sentence, and everything that fails it (policies, systems, reports, departments, people, and good intentions) belongs somewhere else in the matrix or nowhere at all. The preventive, detective, and corrective controls guide extends the timing axis with a 50-example library of its own, and the COSO 17 principles guide shows where controls sit in the framework that defines them.
Related guides
- Preventive, detective, and corrective controls — the timing axis with 50 examples
- The COSO 17 principles — the framework the definition comes from
- Segregation of duties — the independence property inside most strong controls
- Management review controls — the review that is really a glance, and how to fix it
- ITGC vs. application controls — the nature axis and what it means for testing
- Test of design vs. operating effectiveness — the four questions in depth
- Risk and control matrix template — the columns the seven attributes fill
- RCM Workbench — the free tool for building a matrix
- Control deficiency evaluation — what to do when a control fails
- Audit walkthroughs — where the design conclusion is formed
- All Guides — the full index
Leave a Reply