COSO – Control Activities has been saved
COSO – Control Activities
Today we will continue with the COSO framework and we will be looking at Control Activities which is the third of the five (5) integrated components of COSO. Under this component, we will be looking at three (3) principles of the seventeen (17) COSO principles that relates to control activities.
Control Activities: Control activities are the actions established through policies and procedures that help ensure that management’s directives to mitigate risks to the achievement of objectives are carried out. Control activities are performed at all levels of the entity, at various stages within business processes, and over the technology environment. They may be preventive or detective in nature and may encompass a range of manual and automated activities such as authorizations and approvals, verifications, reconciliations, and business performance reviews. Segregation of duties is typically built into the selection and development of control activities. Where segregation of duties is not practical, management selects and develops alternative control activities.
For the Control Activities component,
1. The organization selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels.
2. The organization selects and develops general control activities over technology to support the achievement of objectives.
3. The organization deploys control activities through policies that establish what is expected and in procedures that put policies into action.
The Framework recommends certain approaches to the application of these principles. It should however be noted that these approaches are not exhaustive, therefore the entity can also take steps to achieve these principles where there are no relevant approaches recommended by the Framework.
Principle 9 - The organization selects and develops control activities that contribute to the mitigation of risks to the achievement of objectives to acceptable levels:
Once the Risk Assessment component is implemented and the risks which threaten the achievement of the entity’s objectives are identified and assessed, the onus is on the management and board of the entity to establish control activities that would eliminate these risks or reduce their occurrences to the barest minimum or at least an acceptable level. Matrices can be drawn up to indicate the risks that the organization is exposed to as well as the controls that can be put in place to limit them. Also, authorization limits can be set to reduce the entity’s exposure to the possibilities of one man’s fraudulent activities. Duties can be duly segregated to prevent one man seeing through all stages of a transaction. These can, at least, limit the occurrences of fraudulent practices even if it does not totally eradicate them.
An entity can employ several approaches to meet this principle such as Using Matrices, Workshops, or an Inventory of Control Activities to Map Identified Risks to Control Activities, Implementing or Monitoring Control Activities when Outsourcing to a Third Party, Considering the Types of Control Activities, Considering Alternative Control Activities to the Segregation of Duties, Identifying Incompatible Functions.
Principle 10 - The organization selects and develops general control activities over technology to support the achievement of objectives:
Since the advent of technology, a lot of business processes have become computerized and automated. However, even though technology works to a very high level of accuracy, its outputs are based on the inputs fed into it. As a result, there are risks of producing inaccurate outputs through errors and misstatement in the input. There is therefore just as much need to place controls around the electronic business process as there is over the manual/people operated processes. For that reason, duties can also be segregated amongst different personnel, so one person does not handle too many processes. One person could be made to input transactions while another person would have the duty of authorizing the transaction. This provides a level risk mitigation and confidence in reports but this is only subject to avoidance of collusion among these personnel.
The Framework provides entity’s willing to apply it with the following approaches to achieving this principle. They include Using Risk and Control Matrices to Document Technology Dependencies, Evaluating End-User Computing, Implementing or Monitoring Control Activities when Outsourcing IT Functions to a Third Party, Configuring the IT Infrastructure to Support Restricted Access and Segregation of Duties, Configuring IT to Support the Complete, Accurate, and Valid Processing of Transactions and Data, Administering Security and Access, Applying a System Development Life Cycle over Packaged Software, Applying a System Development Life Cycle over Software Developed In-House.
Principle 11 - The organization deploys control activities through policies that establish what is expected and procedures that put policies into action:
The prior principles on Risk Assessment component state that the organization should select and develop control activities, including control activities over technology, that contribute to the mitigation of risks to the achievement of objectives to acceptable levels. This principle however elaborates that even though the previous principles are important, their objectives would not be fulfilled except they are properly documented and implemented as policies. These policies, after being developed, can be cascaded throughout the organization by leaders in various positions and parts of the entity. The policies, apart from being assessed on a regular basis, should also be reviewed when there is a specific need for such.
Approaches to applying this principle include Developing and Documenting Policies and Procedures, Deploying Control Activities through Business Unit or Functional Leaders, Conducting Regular and Ad Hoc Assessments of Control Activities. Although these approaches are recommended by the Framework, they should not be seen as an exhaustive list. An entity may take steps of its own, especially when not addressed by the Framework.