You are on page 1of 37

Auditing Standard # 5 and IT Controls

Overview of Key Concepts with an Application to IT Controls in Performing an Audit of Internal Control Over Financial Reporting

To gain an understanding of the concepts in the new Auditing Standard #5 (AS 5) and their relation to IT controls in performing an audit of internal control over financial reporting.

Overview of the New Auditing Standard #5

The new standard supersedes Auditing Standard #2 (AS 2). Passed in June/July by the PCAOB and SEC. This standard establishes requirements and provides direction that applies when an auditor is engaged to perform an audit of management's assessment of the effectiveness of internal control over financial reporting ("the audit of internal control over financial reporting") that is integrated with an audit of the financial statements.

Overview of the New Auditing Standard #5

The auditor should use the same suitable, recognized control framework to perform his or her audit of internal control over financial reporting as management uses for its annual evaluation of the effectiveness of the company's internal control over financial reporting.

Eliminates the requirement to provide an opinion on managements assessment.

Overview of the New Auditing Standard #5

Areas of Notable Change Between AS 2 and AS 5 include the following items:

Risk Assessment
Top-Down Approach

Removal of Prescriptive Requirements

Focusing the Audit Elimination of Certain Procedures Scalability

Role of Risk Assessment in Scaling the Audit

Risk assessment underlies the entire audit process described by AS 5, including the determination of: Significant accounts and disclosures Relevant assertions The selection of controls to test The determination of the evidence necessary for a given control.

The complexity of the organization, business unit, or process, will play an important role in the auditor's risk assessment and the determination of the necessary procedures.

Role of Risk Assessment in Scaling the Audit

A direct relationship exists between the degree of risk that a material weakness could exist in a particular area of the company's internal control over financial reporting and the amount of audit attention that should be devoted to that area.

The auditor should focus more of his or her attention on the areas of highest risk.
It is not necessary to test controls that, even if deficient, would not present a reasonable possibility of material misstatement to the financial statements.

The COSO Model

COSO stands for the Committee of Sponsoring Organizations. It is an organization whose mission is to improve financial reporting with a focus on ethics, effective internal controls, and solid corporate governance. The organizations that make up COSO are the American Institute of Certified Public Accountants (AICPA), the Institute of Internal Auditors (IIA), Financial Executives International (FEI), Institute of Management Accountants (IMA), and the American Accounting Association (AAA). In 1992, the COSO committee published their initial Internal Control Integrated Framework

Beginning in 2001, The COSO committee engaged PricewaterhouseCoopers (PwC) to develop the Enterprise Risk Management (ERM) framework using the 1992 model as the basis for their work.

The COSO Model

The COSO model for assessing Internal Control has Risk Assessment as one of the 5 Pillars of COSO.
Operations Financial Reporting Compliance Control Environment Risk Assessment Control Activities Information & Communication Monitoring

The COSO Model

The model helps to integrate 3 distinct components Processes, Entity Levels, and Controls

Processes are the high level functions most often performed in any organization: Operations Financial Reporting Compliance Entity Levels are the strata most often found within organizations: Entity/Corporate Level Division Business Unit Subsidiary

The COSO Model

The Controls relate to the following:
1. Control Environment: The control environment sets
the tone for the organization. It is the foundation of all other components of internal control, providing discipline and structure. Control environment factors include the integrity, ethical values and competence of the entitys people, management philosophy and operating style, the way management assigns authority and responsibility, and the attention and direction provided by the board of directors.

2. Risk Assessment: Risk assessment is the identification

and analysis of risks to the achievement of established business objectives and should form a basis to determine how the risks should be managed. As economic, industry, regulatory, and operating conditions change, mechanisms are required to identify and deal with the special risks associated with change.

The COSO Model

The Controls relate to the following:
3. Control Activities: Control activities are the policies and
procedures established to ensure management directives are carried out, and ensuring that necessary actions are taken to address risks to achievement of the entitys business objectives. Control activities occur throughout the organization and include a range of activities such as approvals, authorizations, verifications, reconciliations, reviews of operating performance, security of assets and segregation of duties. identified, captured and communicated timely and in a manner enabling people to fulfill their responsibilities. Reports containing operational, financial and compliance related information should support effective business management, control, and informed business decisionmaking. Effective communication should occur internally, flowing across organization, and externally, with parties such as customers, suppliers, regulators and shareholders.

4. Information and Communication: Information must be

The COSO Model

The Controls relate to the following:
5. Monitoring: Internal controls need to be monitored
using a process that assesses the quality of their performance over time. Ongoing monitoring must occur in the course of operations through regular management and supervisory activities, and other actions taken by personnel in performing their duties. The scope and frequency of any separate independent evaluations will depend on a risk assessment and the effectiveness of ongoing monitoring procedures. Internal control gaps should be reported upstream, with serious matters reported to senior management and the board of directors.

Why Include IT Controls?

IT is an integral part of compliance because there is usually a significant dependency on IT within most organizations:

High degree of automation in processing day-to-day transactions. IT data elements are primary source of information used in decision-making. IT availability and integrity are critical to financial statement closing and reporting processes. Risk of unwarranted reliance by management on IT systems and controls.

Description of IT Controls
Types of IT Controls:

General Computer Controls General Computer Controls are the high level controls that typically impact all of the individual applications and data in the technology environment. These controls include Application Development, Change Control, Information Security, and Data Center Operations. These controls need to be documented, and potentially tested, each year. If there is a solid General Controls environment, it is easier to place more reliance on the Application Level controls.

2. Application Level Controls These are specific controls for the applications in use at the client. An example, is a systematic check to insure that duplicate invoices are not being paid by the AP system. The documentation and testing of these controls is based upon discussions with the audit engagement team. You may or may not address application controls each year.

General Computer Controls

Application Development
A System Development Life Cycle (SDLC) exists within organization and is used to guide the development and acquisition processes within the company. Project requests and requests for changes are documented and approved by stakeholders. Project requests and requests for changes have evidence of requirements definition, retained and approved. Project requests and requests for changes have evidence of testing, retained and approved.

General Computer Controls

Change Control

A standard policy/procedure process and/or document exists that details the organizations methods for applying application, infrastructure, and system software changes. A standard change request record/form (electronic or paper) is used to document and track changes and approvals. All change requests are approved by the appropriate requesting management, as well as other impacted management (as defined by policies and procedures). Emergency changes are tested and approved by authorized management after implementation and follow outlined policies and procedures.

General Computer Controls

Information Security

User administration procedures should be in place to address the requirements for granting, changing, and timely removing access to systems and applications, including remote access capabilities (i.e. the access request process and necessary manager approval). Unique user accounts are set up to provide user accountability for use of system resources. All exceptions should be documented and approved.

Minimum password standards are applied to restrict access (i.e. required password, minimum password length, password change standards, password composition standards, timeout, unsuccessful access attempts).
Access to the production environment (OS and application programs) is restricted by appropriate facilities (i.e. RACF, Native OS ACLs) and supports segregation of duties (i.e. programmers do not have access to modify code in production libraries, non-administration personal do not have access to root, administrator or RACF SPECIAL attribute).

General Computer Controls

Information Security (continued)

Access to databases is authorized based on job responsibility (i.e. DBA has Oracle administration access) and access to manipulate database files through the OS is restricted by the appropriate facilities (i.e. RACF or native OS ACL). Access to sensitive facilities (access to master passwords, powerful utilities (including scheduling packages), and system manager facilities) is granted based on job responsibility. Audit logs (e.g. SU log) are in place to document user access to sensitive or powerful sensitive facilities and reviewed where appropriate. Firewall architecture is in place to protect access to internal systems from unauthorized external parties via untrusted networks (i.e. the internet). Intrusion Detection Systems are in place and are monitored periodically.

General Computer Controls

Data Center Operations

Management has defined and implemented a problem management process/system to ensure that operational events that are not part of standard operation (i.e. incidents, problems, and errors (e.g., processing abends)) are recorded, analyzed, escalated and resolved in a timely manner. System processing jobs and batch feeds are documented in the IT Operations Manual or other equivalent documentation. Daily operations checklists are used to assist in monitoring systems processing. Critical programs and data are identified by management. Backups of these critical programs and data are scheduled and performed. There is an off-site storage process and backups are removed.

A Disaster Recovery process is in place for all data centers.

Physical security and environmental control (i.e., raised floor, A/C, fire control system, water sensors, UPS) controls are in place for all data centers.

Application Level Controls

Application Controls Include:
Input Controls Edit Checks Input File Validation Edit/Error Reports Processing Controls Balancing Controls Program Calculations Processing Statistics Output Controls Processing Reports Output Files Interfaces to Other Systems Security Controls Application Level Security Controls

The IT Control Umbrella

General Controls
Application Development

Change Control
Information Security Data Center Operations

Application Controls
Input Controls
- Edit Checks - Input File Validation - Edit/Error Reports

Processing Controls
- Balancing Controls - Program Calculations - Processing Statistics

Output Controls
- Processing Reports - Output Files - Interfaces to Other Systems

Security Controls
- Application Level Security Controls

Key Internal Control Concepts

Design Effectiveness

Are standard IT controls in place at the client location and do they appear to be in operation? Are the controls performed by persons possessing the necessary authority and competence to perform the control effectively? Procedures performed include a mix of inquiry of personnel, observation of the companys operations, and inspection of relevant documentation.

Key Internal Control Concepts

Design Effectiveness

Walkthroughs that include the preceding page procedures are sufficient to evaluate the design effectiveness. A smaller, less complex company might achieve its control objectives in a different manner from a larger, more complex organization (i.e., less segregation of duties) and my implement alternative controls to achieve its control objectives. In such circumstances, the auditor should evaluate whether those alternative controls are effective.

Key Internal Control Concepts

Operating Effectiveness

Are standard IT controls as documented performing as expected throughout the audit period? The amount of testing evidence is directly related to the level of risk assessed for that control. The greater the level of risk the greater the level of evidence needed to evaluate the operating effectiveness of the control.

Key Internal Control Concepts

Operating Effectiveness

The IT environment has a direct impact on the level of assessed risk since many financial and operational controls are affected by IT controls. Procedures performed include a mix of inquiry of personnel, observation of the companys operations, inspection of relevant documentation, and the re-performance of a control.

Key Internal Control Concepts

More Persuasive Re-Performance

Reliability of Evidence

Inspection of Relevant Documentation


Less Persuasive


Inquiry alone is not sufficient to conclude on the operating effectiveness of a control.

Key Internal Control Concepts

Operating Effectiveness

Testing controls over a greater period of time provides more evidence of the effectiveness of controls than testing over a shorter period of time. Testing performed closer to the date of management's assessment provides more evidence than testing performed earlier in the year. The auditor should balance performing the tests of controls closer to the as-of date with the need to test controls over a sufficient period of time to obtain sufficient evidence of operating effectiveness.

Key Internal Control Concepts

Operating Effectiveness If a new control is implemented in the testing period, and sufficient time exists to test the new control, then the auditor may elect not to test the old/superseded control. The more extensively a control is tested, the greater the evidence obtained from that test. When the auditor reports on the effectiveness of controls as of a specific date and obtains evidence about the operating effectiveness of controls at an interim date, the auditor should determine what additional evidence concerning the operation of the controls for the remaining period is necessary.

Evaluating Control Deficiencies

The auditor must evaluate the severity of each control deficiency that comes to his or her attention to determine whether the deficiencies, individually or in combination, are material weaknesses as of the date of management's assessment.

In planning and performing the audit, however, the auditor is not required to search for deficiencies that, individually or in combination, are less severe than a material weakness.
The severity of a deficiency is based on the reasonable possibility concept vs. the magnitude of the potential misstatement.

Evaluating Control Deficiencies

A new definition is presented for a material weakness (MW) to align with SEC guidance.

Revises the definition of a significant deficiency (SD) to align with the definition the SEC has proposed. AS 5 encourages the use of auditor judgment in evaluating MWs and SDs. The goal is to move away from prescribed MWs and SDs based on the standard.

Benchmarking of Automated Controls

Entirely automated application controls are generally not subject to breakdowns due to human failure. This feature allows the auditor to use a "benchmarking" strategy. If general controls are effective and continue to be tested, and if the auditor verifies that the automated application control has not changed since the auditor established a baseline (i.e., last tested the application control), the auditor may conclude that the automated application control continues to be effective without repeating the prior year's specific tests of the operation of the automated application control.

Benchmarking of Automated Controls

The nature and extent of the evidence that the auditor should obtain to verify that the control has not changed may vary depending on the circumstances, including depending on the strength of the company's program change controls.

Certain automated controls may be dependent on other automated controls in order to function properly. Therefore, the auditor may need to evaluate the entire process and not just an isolated control.

Benchmarking of Automated Controls

To determine whether to use a benchmarking strategy, the auditor should assess the following risk factors:

The extent to which the application control can be matched to a defined program/module within an application. The extent to which the application is stable (i.e., there are few changes from period to period). The availability and reliability of information on the nature and timing of program changes. The program change process including the lockdown of the production libraries/directories.

As these factors indicate lower risk, the control being evaluated might be well-suited for benchmarking.

Benchmarking of Automated Controls

Benchmarking automated application controls can be especially effective for companies using purchased software when the possibility of program changes is remote (e.g., when the vendor does not allow access or modification to the source code).

After a period of time, the length of which depends upon the circumstances, the baseline of the operation of an automated application control should be reestablished.

Questions ?

Contact Information
Michael Pinna Director - IT Risk Services Weiser LLP (732) 475-2198