Skip to main content

Legal

Tax & Accounting

Trade & Supply

Risk & Fraud

News & Media

Books

Developers

Internal Control

Understand controls and evaluate design

After you complete all of the Risk Assessment forms, select
Next
 to move to the Internal Control section, beginning with Understand Controls and Evaluate Design.
Understand Controls and Evaluate Design includes each component of Internal Control as identified by COSO, and provides a description of each control objective to indicate how the applicable control principle has been achieved:
  • Control Environment
  • Risk Assessment
  • Information and Communication
  • Monitoring
  • Activity-level and Other Entity-level Controls
Select
View Optional Entity-Level Control Form
 to view a list of specific control activities related to the control principle. You can use this feature to further document your understanding of controls and to indicate controls that you plan to test. In general, you should focus on key controls. When necessary, you can document your comments.
When you expand
Control Activities
 under
Understand Controls and Evaluate Design
, you'll need to mark
Significant Transaction Class
 and select
View Optional Activities Form
, which is similar to the
Entity Level Control Form
. The next section describes the column heading questions in both forms.

Column Heading Questions

In both the Entity-Level Control Form and the Control Activities Form, the column headings contain questions for each control principle/objective and control activity. The following sections describe each heading.

Evaluate Objective

Indicate whether you want to evaluate the control objective. A control objective states the purpose of a control in relation to risks of material misstatements in the financial statements. By considering control objectives and how they relate to risks, you may find it easier to identify relevant controls. Furthermore, you may find it easier to evaluate whether existing controls, if operating effectively, would fully achieve the objective or if deficiencies exist either in design or through non-existent controls.
Generally, focus on control objectives related to the assertions you identified as potentially being higher risk. In other words, focus on those that relate to the risks that caused you to identify the transaction class as significant. Then, identify the key controls for those objectives.
This question appears only on the
Control Activities Form
 for Process Level Controls and General Computer Controls.

Addresses Significant Risk

Indicate whether the control addresses an identified fraud or other significant risk.
This question only appears on the
Control Activities Form
 for Process Level Controls.

Key Control

You aren't required to understand all controls and control activities that might exist in an entity. Rather, focus on key controls (those that are most important in achieving the control objectives you intend to evaluate). When determining which controls are key, consider factors such as:
  • The nature of the risks being addressed
  • The characteristics of related account balances or transaction classes
  • Whether the control is preventive (prevents misstatements) or detective (detects misstatements)
  • Whether the control works in combination with or relies on the operation of other controls
  • Whether the control is manual or automated
Certain controls that typically are key are selected by default; however, you should evaluate them based on your individual client situations, considering the risks that caused you to identify the transaction class as significant.

Implemented

Indicate whether the control has been implemented. Note that not all controls listed must be implemented to achieve the control objective, but typically, those that you have identified as key controls should be appropriately designed and implemented. Generally, you can determine implementation using procedures such as observation or inspection in combination with inquiries. Note that inquiry alone isn't sufficient to evaluate the design of a control and determine if it has been implemented.
Select
Yes
,
No
, or
N/A
 from the dropdown in the
Implemented?
 column.

Control Type

For each implemented control that you intend to evaluate, indicate whether the control is preventative (prevents misstatements) or detective (detects misstatements).
Select
Preventive
 or
Detective
 from the dropdown in the
Control Type
 column.

IT Dependent

If you selected
Yes
 for the control from the
Control has been Implemented
 dropdown, the
IT Dependent
 checkbox is enabled. Mark the checkbox if the control is dependent upon information technology (IT). Examples of IT dependent controls include automated system controls that prevent access to data by unauthorized users, manual reviews or reconciliation based on computer-generated reports or spreadsheets, and so forth. For IT dependent controls, you'll need to indicate whether it's automated and identify the underlying software application.

Automated

If you marked the
IT Dependent
 checkbox, the
Automated
 checkbox is enabled. Indicate whether the control requires user intervention (manual control) or is performed by the system without user intervention (automated control). Manual controls in an automated system may use information produced by the system or may be limited to monitoring the automated controls and handling exceptions. Automated controls include processes such as edit and validation routines embedded in computer programs.
The use of manual controls is often more effective when judgment and discretion are needed. For example, manual controls are generally more appropriate in the following ways:
  • For large, unusual, or nonrecurring transactions.
  • When monitoring the effectiveness of automated controls.
  • In changing circumstances where a control response may be needed outside of the scope of an automated control.
  • When misstatements are difficult to anticipate, define, or predict.
However, manual controls may be subject to override, misinterpretation, error, or bypass. As a result, automated controls may be more suitable in the following situations:
  • Recurring or high-volume transactions.
  • Situations where errors can be anticipated, predicted, prevented, or detected by control parameters subject to automation.
  • Control activities whose nature allows the use of properly designed automated control processes.

Software Application

When evaluating the effectiveness of IT dependent controls, it's important to also consider the design of general computer controls around the software applications upon which the IT dependent controls rely. Evaluating the effectiveness of IT general controls is required if performing a public company audit of internal control. For example, to assess whether a control such as management’s review of sales by product is effective, you must also consider whether the general controls around the computer application that produces the sales by product report are effective and result in a reliable report.
For each IT dependent control that you intend to evaluate (for example, each IT dependent key control), indicate the computer software application upon which the control depends. This value is carried forward to the general computer controls section, where you can evaluate general computer controls over the software application.
  1. Select
    Select here
     in the
    Software Application
     column for the control you are describing.
  2. Enter the name of the application in the entry field and select
    Add Application
    .
  3. Mark the checkbox to mark it as significant, if applicable.
  4. Select
    Apply
    .

Effectively Designed

For those control principles/objectives that you intend to evaluate, conclude whether the control system is effectively designed to achieve the control objective.
Evaluation of design effectiveness considers whether an implemented control, individually or in combination with other implemented controls, is capable of effectively preventing or detecting and correcting errors that could result in material misstatements. That is, it considers the effectiveness of implemented controls in achieving the objective. If controls related to an objective are improperly designed, a control deficiency may exist that needs to be communicated to management and those charged with governance.

Test

If you selected
Yes
 for
Control has been Implemented
, the
Test
 column is activated. Mark the checkbox if you plan to test the control.

Financial Statement Audit

It's necessary to test controls only if you determine the following:
  • Doing so allows you to assess control risk for an assertion at less than high and therefore reduce the nature or extent of substantive procedures, resulting in a more effective, efficient audit.
  • Substantive procedures alone are not effective.
If you plan to test and rely on information technology (IT) dependent controls, you also should test general computer controls around the software applications upon which the IT dependent controls depend.
Test only key controls that you have determined are suitably designed and have been implemented to prevent or detect material misstatements in specific assertions. SAS No. 110 recognizes that control test results may be relied upon for three years, subject to certain conditions, so that tests of controls can be rotated using a 3-year cycle. However, controls that have changed since they were last tested or controls that mitigate fraud risks or other significant risks should be retested each year. Controls that have not changed should be retested at least every 3rd year. In addition, if a number of controls are being rotationally tested, some controls should be tested each year.

Public Company Audit of Internal Control

For all Understand Controls and Evaluate Design forms, when performing a public company audit of internal control to form a conclusion about the effectiveness of the company’s internal control, you must perform sufficient tests of controls to address the assessed risk of misstatement to each relevant assertion of each significant account and disclosure.
Applying a top-down approach, focus first on entity-level controls. Evaluate entity-level controls that are important to your conclusion about whether the company has effective internal control (including the financial close and reporting process; see Significant Transaction Classes). Then test other controls that are important to your conclusion about whether the company’s controls sufficiently address the assessed risk of misstatement to each relevant assertion of each significant account and disclosure. Some entity-level controls might operate at a level of precision that, without the need for other controls, sufficiently addresses the risk of misstatement to a relevant assertion. If a control sufficiently addresses the risk, you do not need to test other controls related to that risk.
Only test the operating effectiveness of controls that are effectively designed. A control that has a design flaw can't be an effective control, no matter how well it functions; there's no point in testing operating effectiveness.

Complete the Form

For all Understand Controls and Evaluate Design forms, as you complete the form, consider whether any risks that could result in material misstatement of the financial statements exist. If so, select
Add Risk
 to enter the risk.
A question at the end of each form prompts you to conclude whether the applicable COSO topic is properly designed and implemented (or effectively designed for public companies).
For a financial statement audit, the Control Deficiency Evaluation Form and Aggregation Worksheet can be used to evaluate whether control deficiencies are significant deficiencies or material weaknesses.
For a public company audit of internal control, you can use the Control Deficiency Evaluation Form and Aggregation Worksheet to summarize, accumulate, and evaluate deficiencies to determine whether they (alone or in combination) represent a material weakness or significant deficiency; and to form an overall conclusion on the effectiveness of internal control.
Select the
Yes
 or
No
 option next to the question. Document your comments, if applicable.

Sources of Information

For all Understand Controls and Evaluate Design forms, in the Sources of Information section of each of the COSO topics, describe your sources and procedures for gaining your understanding of the flow of information. Make sure your description satisfies auditing standards regarding documentation (see SAS No. 103 or PCAOB Auditing Std. No. 3).

Significant Transaction Classes

Significant Transactions Classes
 is a subtopic of
Control Activities
. This form lets you select the transaction classes for which you want to obtain an understanding of internal control and determine whether controls are properly designed and implemented (or effectively designed for public companies).
Significant Transactions Classes
 is a subtopic of
Control Activities
 in the Navigation pane. It is the form that follows the
Understand Controls and Evaluate Design
 COSO components (Control Environment, Risk Assessment, Information and Communication, and Monitoring).
This form lets you select the transaction classes for which you want to obtain an understanding of internal control and determine whether controls are properly designed and implemented (or effectively designed for public companies). Note that the Financial Close and Reporting and General Computer Controls processes are included with significant transaction classes.
To identify significant transaction classes:
  1. In the Significant Transaction Classes window, select
    +
     next to an audit area to view its transaction classes.
  2. Mark the checkbox next to each transaction class that's considered significant to the financial statements.

Add Transaction Class

If you want to use a transaction class that is not listed, select
Add Transaction Class
 Add.
In the
Add New Transaction Class
 window, enter the name of the new transaction class and mark the checkboxes for the applicable audit areas.
You can also select to base the new transaction class on an existing transaction class by making a selection from the dropdown.
If you base the new transaction class on an existing transaction class, objectives and their relationships to controls and test procedures are copied to the new transaction class.

Edit or Delete Transaction Class

Once the new transaction class is added, you can edit or delete it by selecting
Edit
 edit or
Delete
 delete
Only transaction classes that you have created with the
Add Transaction Class
 feature can be deleted. However, you can edit any transaction class, letting you add or omit audit areas to which the transaction class is assigned.

Apply a Risk-Based Approach

When selecting significant transaction classes, focus on those that present a reasonable possibility of material misstatement to the financial statements or disclosures. Evaluate qualitative and quantitative factors such as the following:
  • Accounting and reporting complexities associated with the account or disclosure.
  • Susceptibility to misstatement due to errors or fraud.
  • Existence of related party transactions in the account.
  • Volume of activity.
  • Size and composition of the account.
  • Nature of the account or disclosure.
  • Exposure to losses in the account.
  • Possibility of significant contingent liabilities arising from the activities reflected in the account or disclosure.
  • Changes from the prior period in account or disclosure characteristics.

Control Activities - Financial Close and Reporting

In the
Financial Close and Reporting
 subtopic under
Activity-level and Other Entity-level Controls
, you can describe the flow of information for each transaction class/process for each location.
In each location form, expand the
Describe Flow of Information
 section, then expand any of the transactions. Under the transactions, select
View Control Activities Form
 to view a list of specific control activities related to the transaction class/process.
The Control Activities Form can be used to further document your understanding of controls and to indicate controls that you plan to test.
A question following the transaction class/process input fields prompts you to conclude whether the controls are properly designed and implemented (or effectively designed for public companies). Select
Yes
 or
No
. If necessary, select the textbox to enter a comment.

This article applies to:

  • Product: Guided Assurance

Related content