Control activities are the specific policies and procedures an organization puts in place to reduce the risks that could keep it from meeting its objectives, especially the accuracy of its financial reporting. The term comes from the Committee of Sponsoring Organizations of the Treadway Commission (COSO), whose Internal Control—Integrated Framework, first issued in 1992 and updated in 2013, is the standard reference used by auditors and regulators.1Committee of Sponsoring Organizations of the Treadway Commission (COSO). Guidance on Internal Control For publicly traded companies, Section 404 of the Sarbanes-Oxley Act of 2002 turned these controls into a legal requirement: management must evaluate and report on the effectiveness of internal controls over financial reporting each year, and an independent auditor must attest to that assessment.2U.S. Securities and Exchange Commission. SEC Proposes Additional Disclosures, Prohibitions to Implement Sarbanes-Oxley Act
In practice, a control activity is any concrete action tied to a specific risk. A supervisor’s signature on a purchase order is a control activity. So is a system rule that rejects a letter typed into a dollar field, a monthly bank reconciliation, a locked storage cage, and a rule that the person cutting checks isn’t the same person approving invoices. The categories below organize those actions so you can see what each type is designed to do.
Where Control Activities Fit in the COSO Framework
COSO identifies five components of internal control: the control environment, risk assessment, control activities, information and communication, and monitoring. Control activities sit in the middle for a reason. An organization first sets the tone at the top, then identifies what could go wrong, and only then designs the specific actions to keep those risks in check.
The 2013 update grouped control activities under three principles. Principle 10 calls for selecting activities that reduce identified risks to acceptable levels, so each control ties back to a risk the organization already flagged. Principle 11 addresses technology, requiring general IT controls that support all business applications. Principle 12 focuses on deployment through written policies and procedures that carry them out.1Committee of Sponsoring Organizations of the Treadway Commission (COSO). Guidance on Internal Control The working rule: every control activity should trace back to a specific risk and be documented well enough that someone new could step in and run it.
Preventive, Detective, and Corrective Controls
The most common way to sort control activities is by when they act on a problem: before it happens, after it happens, or once it has been found.
Preventive Controls
Preventive controls stop errors and unauthorized actions before they happen. A purchase order that requires a supervisor’s electronic approval before the system will process payment is preventive. So is a dropdown menu that limits an employee to approved vendor codes rather than free-text entry. Front-end barriers are cheaper than cleaning up problems after the fact, which is why most control systems are built around prevention first.
Detective Controls
No preventive control catches everything. Detective controls find the errors and irregularities that slipped past the first line. Monthly bank reconciliations, exception reports that flag transactions outside normal ranges, and surprise inventory counts all fit here. Detective controls also reveal whether preventive controls are weakening: if the same type of error keeps turning up on exception reports, the preventive side needs redesigning.
Corrective Controls
Corrective controls close the loop. Once a detective control identifies a problem, a corrective control is the response that fixes it and prevents recurrence. Adjusting journal entries to correct a posting error, retraining staff after a process breakdown, and updating a policy that proved inadequate are all corrective actions. Organizations that treat correction as a distinct step tend to improve; those that stop at detection tend to find the same problems repeating quarter after quarter.
Physical and Manual Controls
Physical Safeguards
Physical controls protect tangible assets by restricting who can touch them. Locked storage for inventory, safes for petty cash, badge readers on server rooms, and surveillance cameras in warehouses are standard examples. Badge readers and camera footage also create an audit trail, useful when something goes missing and you need to trace access.
Approvals, Authorizations, and Reconciliations
Manual controls that rely on human judgment fill gaps automation can’t cover. A supervisor reviewing and signing a purchase order before payment confirms the expense is legitimate, falls within the budget, and goes to an approved vendor. The person approving should not be the same person who initiated the request.
Bank reconciliations are among the most important manual detective controls. The process compares the general ledger to bank statements, identifies discrepancies, and investigates every unmatched item. Effective reconciliations happen monthly, and the person performing them should not have the ability to initiate payments or make deposits. A supervisor then reviews and signs the completed reconciliation. Without a dated signature, auditors have no way to confirm anyone checked the work.
Information Processing Controls
IT General Controls
General IT controls secure the technology environment that every application depends on. Password complexity requirements, multi-factor authentication, role-based access permissions, and regular system backups belong here. These controls aren’t tied to any single program; they protect the infrastructure underneath all of them.
Change management is a general IT control that gets less attention than it deserves. Every change to production software, whether a patch, a configuration update, or new code, should follow a documented process: request, risk assessment, testing in a separate environment, approval, and a rollback plan. Mixing test and production environments or skipping formal approval for small changes is where problems creep in. Damaging control failures often trace back to an undocumented change nobody reviewed.
Application Controls
Application controls are built into specific software programs to prevent processing errors at the transaction level. Edit checks reject invalid entries automatically, such as blocking a letter from being entered into a dollar-amount field or flagging a purchase order where the quantity exceeds an approved limit. Batch totals compare the sum of a group of transactions against a predetermined control total, catching missing or duplicated entries before they reach the general ledger. Automated checks run consistently every time. They don’t get tired, they don’t skip steps on a busy Friday afternoon, and they log every rejection.
Third-Party System Considerations
When an organization outsources processes to a cloud provider or service bureau, the control environment doesn’t end at the vendor’s door. A payroll processor or cloud accounting platform handles data that flows directly into financial statements, and an error or breach at the vendor can become the organization’s misstatement. SOC 1 Type 2 reports, developed by the American Institute of Certified Public Accountants, let organizations evaluate a service provider’s controls over a monitoring period. If a vendor can’t produce a current SOC 1 report, that’s a gap worth flagging, because auditors will ask about it.
Segregation of Duties
Segregation of duties splits a transaction’s lifecycle across different people so no single individual can authorize a payment, record it in the ledger, and hold the resulting asset. That three-way split between authorization, recordkeeping, and custody is the foundation. An employee who approves a vendor invoice should not also cut the check or reconcile the bank account. When these roles overlap, one person could pay a fictitious vendor and hide the fraud in the books. Distributing the responsibilities means any misconduct would require collusion, which is both harder to execute and more likely to be discovered.
Compensating Controls for Smaller Organizations
Full segregation of duties requires enough staff to split every process three ways, which small organizations and lean departments rarely have. Compensating controls fill the gap. The most common approach is a more detailed management review: if one person handles both recording and custody, a supervisor performs a thorough, documented review of the reconciliation each month. Some small teams swap reconciliation duties with another department so no one reconciles their own transactions. These workarounds don’t eliminate the risk as cleanly as true segregation, but they reduce it to a level most auditors will accept, provided the compensating control is actually performed and documented consistently.
Documentation Makes the Control Real
A control that isn’t documented is, for audit purposes, a control that didn’t happen. Every control activity needs a record showing who performed it, when, and what they found. A supervisor’s signed and dated bank reconciliation is evidence of review. An electronic approval stamp in a purchase order workflow is evidence of authorization. Auditors look for original records rather than copies, because originals are considered more reliable evidence of what actually occurred.3Public Company Accounting Oversight Board. AS 1105 – Audit Evidence
When auditors test controls, they combine inspecting records for evidence of authorization with observing the control being performed in real time.3Public Company Accounting Oversight Board. AS 1105 – Audit Evidence If your organization relies on internally generated reports as evidence, auditors will want to verify the accuracy and completeness of those reports or test the controls over the system that produced them. Organizations sometimes stumble here: the control works in practice, but nobody can prove it ran because the output wasn’t kept. Building documentation into the control itself, rather than treating it as a separate administrative step, is the simplest way to avoid that problem.