Skip to main content
Regulatory Council
Promotional banner for the pentest readiness checklist
Category: Internal Controls & Audit

Process-Level Controls

Also known as: Transaction-Level Controls, Activity-Level Controls
Simply put

Process-level controls are the specific checks and procedures built into an organization's day-to-day operations, such as reviewing individual transactions or approving discrete steps in a workflow. They operate closer to the ground than broad, organization-wide controls, focusing on particular functions or activities. Their purpose is typically to help keep operations and conditions running consistently and to catch or prevent errors within a given process.

Formal definition

Process-level controls are controls designed to operate at the transaction or process level, typically involving the assessment of discrete functions or individual transactions within a specific business process. In the context of internal control frameworks, they are often distinguished from entity-level controls (which operate pervasively across the organization) and are frequently classified by function as preventive, detective, or corrective. Within internal control over financial reporting, they are commonly relied upon to help maintain operations or conditions at a consistent level; note, however, that no control eliminates risk or guarantees an outcome, and specific control objectives and design vary by process, framework edition, and organizational context. The precise taxonomy separating entity-level, process-level, and summary-level controls should be verified against the applicable primary framework or auditing guidance.

Why it matters

Process-level controls are where an organization's control intentions meet the reality of daily operations. Broad, entity-level controls set the tone and establish pervasive expectations, but it is at the transaction and process level that individual errors are typically caught or prevented, through checks such as reviewing a transaction, approving a discrete workflow step, or reconciling records. Without effective controls operating at this level, gaps in a specific function or activity can persist unnoticed even where high-level governance appears sound.

For internal control over financial reporting and similar objectives, process-level controls are commonly relied upon to help keep operations or conditions running at a consistent level. This makes them a frequent focus of internal audit testing and external audit evaluation, since assurance often depends on demonstrating that specific, documented controls operate as designed within a given process. It is important to note, however, that no control eliminates risk or guarantees an outcome; process-level controls reduce the likelihood or impact of errors within their scope but cannot by themselves ensure a process is free of misstatement or failure.

Understanding the distinction between process-level, entity-level, and summary-level controls also matters for how organizations design and rationalize their control environment. Over-reliance on one layer, or misclassifying a pervasive control as a discrete one, can lead to either redundant testing or unaddressed exposures. The precise taxonomy and the specific control objectives should be verified against the applicable framework edition and auditing guidance, as these vary by process, organization, and context.

Who it's relevant to

Internal Auditors
Internal auditors frequently test process-level controls to assess whether discrete functions and individual transactions are being handled as designed. Distinguishing these from entity-level controls helps auditors scope testing appropriately and avoid conflating pervasive controls with controls that operate within a single process.
Compliance and Controls Professionals
Those responsible for designing and maintaining an organization's control environment rely on process-level controls to help keep specific operations or conditions consistent and to catch or prevent errors within particular workflows. They also manage how these controls are classified, preventive, detective, or corrective, and how they relate to broader control layers.
Finance and Financial Reporting Teams
Within internal control over financial reporting, process-level controls are commonly relied upon at the transaction level, such as reviews and approvals over discrete accounting activities. Finance teams should note that specific control objectives vary by process and framework edition and should be confirmed against applicable guidance.
External Auditors
External auditors evaluate both entity-level and process-level controls as part of an audit of internal control. The identification and evaluation of controls at each layer informs the nature and extent of testing, with the precise taxonomy verified against applicable auditing standards and guidance.

Inside Process-Level Controls

Definition and Positioning
Process-level controls are control activities embedded within specific business or operational processes (such as procurement, order-to-cash, or payroll) that operate to modify risk at the transaction or activity level. They typically sit below entity-level controls in the control hierarchy and address risks arising from the execution of particular processes.
Control Objectives
Each process-level control is generally tied to a defined objective for the process, commonly framed around accuracy, completeness, validity, authorization, timeliness, and safeguarding of assets. These objectives help establish what the control is intended to achieve within its process context.
Preventive and Detective Controls
Process-level controls often include both preventive controls, which aim to stop errors or irregularities before they occur (such as segregation of duties or authorization limits), and detective controls, which are designed to identify issues after they arise (such as reconciliations or exception reporting). Many processes rely on a combination of both.
Manual and Automated Controls
Controls at the process level may be performed manually by individuals, executed automatically by information systems, or configured as IT-dependent manual controls that rely on system-generated information. The nature of the control affects how it is designed, tested, and relied upon.
Control Owners and Accountability
Process-level controls are typically assigned to identified owners responsible for their operation and effectiveness. Clear accountability is often a governance consideration, connecting the control to the individuals or roles that direct the underlying process.
Relationship to Risk
A process-level control is a measure intended to modify risk rather than a risk itself. It commonly acts on inherent risk within a process to help bring residual risk within an organization's stated appetite or tolerance, though no control can be assumed to eliminate risk entirely.

Common questions

Answers to the questions practitioners most commonly ask about Process-Level Controls.

Are process-level controls the same thing as entity-level controls?
No. The two operate at different layers and serve different purposes. Entity-level controls typically address organization-wide matters such as the control environment, governance structures, tone at the top, and enterprise policies, and they often influence the design and operation of controls throughout the organization. Process-level controls, by contrast, operate within specific business processes or transaction cycles and are designed to modify risk at that more granular level. In many internal control frameworks the two are seen as complementary rather than interchangeable, with entity-level controls setting conditions under which process-level controls are expected to function. Treating them as equivalent can lead to gaps in coverage.
Does having a process-level control in place mean the associated risk has been eliminated?
Not typically. A control is a measure that modifies risk, not one that removes it. Even a well-designed and consistently operating process-level control generally reduces the likelihood or impact of a risk event rather than eliminating it, leaving some residual risk. Factors such as control override, human error, collusion, and changes in the process environment mean that no single control should be assumed to guarantee an outcome. Frameworks commonly emphasize evaluating residual risk against risk appetite and tolerance rather than presuming a control brings risk to zero.
How do you decide which risks in a process warrant a process-level control?
Selection generally follows from a risk assessment of the process, in which risks are identified and evaluated against objectives before controls are designed. Many organizations prioritize controls where the inherent risk is more significant, where the process affects material financial reporting, regulatory obligations, or key operational objectives, and where residual risk would otherwise exceed the stated risk appetite or tolerance. The specific prioritization approach can vary by framework, sector, and organization size, so the criteria used should be documented and consistent with the organization's broader risk management methodology.
How can the operating effectiveness of a process-level control be tested?
Operating effectiveness is often assessed by examining whether the control functioned as designed over a period, which is distinct from design effectiveness (whether the control is capable of addressing the risk if operated as intended). Common techniques include inquiry, observation, inspection of evidence, and reperformance, frequently applied to a sample of transactions or instances. The appropriate sample size, frequency, and rigor typically depend on the nature and frequency of the control and on the level of assurance sought. Where controls are relied upon for external reporting or regulatory purposes, testing approaches may need to align with applicable standards, which vary by jurisdiction and context.
What is the difference between a preventive and a detective process-level control, and should both be used?
Preventive controls are designed to stop an error or undesirable event before it occurs, such as authorization requirements or system-enforced input validation, while detective controls are designed to identify an event after it has occurred, such as reconciliations or exception reviews. In many control designs the two are used together so that detective controls can catch matters that preventive controls do not stop. Whether to use both, and in what balance, generally depends on the risk being addressed, the cost of each control, and the residual risk the organization is prepared to accept.
How should process-level controls be documented and kept current?
Documentation commonly describes the control's objective, the risk it addresses, who performs it, its frequency, the evidence it produces, and whether it is manual or automated. Keeping documentation current typically involves periodic review, particularly when the underlying process, system, personnel, or regulatory requirements change, since a control that is no longer aligned with the process it governs may become ineffective. Many organizations tie control documentation to their broader risk and control inventory so that changes in one are reflected in the other. The level of formality expected can vary by sector, regulatory environment, and organization size.

Common misconceptions

Process-level controls guarantee that risks are eliminated or that compliance is assured.
Controls modify risk; they do not eliminate it. Even well-designed and consistently operating process-level controls typically reduce likelihood or impact to a residual level rather than removing exposure entirely, and control operation may still be subject to error, override, or circumvention.
Process-level controls are interchangeable with entity-level controls.
Entity-level controls operate broadly across the organization (for example, governance structures, tone at the top, or organization-wide policies), whereas process-level controls operate within specific processes at the transaction or activity level. The two are complementary and generally distinct in scope, and deficiencies at one level are not necessarily compensated for at the other.
A control and the risk it addresses are the same thing.
A risk is a potential event and its effect on objectives, while a process-level control is a measure that modifies that risk. Conflating the two can lead to gaps where a described 'control' is actually a restatement of the risk rather than an action that treats it.

Best practices

Map each process-level control to a specific, articulated risk and control objective so that its purpose within the process is clear and its effectiveness can be evaluated.
Distinguish preventive from detective controls and consider whether the combination provides appropriate coverage for the process's key risks rather than relying on a single control type.
Assign a named owner to each control and document whether it is manual, automated, or IT-dependent, since this affects how the control is operated, monitored, and tested.
Assess residual risk after considering control operation, and confirm it aligns with the organization's stated risk appetite or tolerance rather than assuming the control removes exposure.
Periodically test both the design and operating effectiveness of process-level controls, recognizing that a well-designed control may still fail if not consistently performed.
Coordinate process-level controls with entity-level controls so that reliance is placed appropriately and gaps between the two levels are identified and addressed.
Promotional banner highlighting failures found in PCI audits and how to spot the gaps