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 Presented by: Michael Pinna December 14, 2007
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.
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 management’s assessment.
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.
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.
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 entity’s 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.
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 entity’s 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.
4. Information and Communication: Information must be 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 decision-making. Effective communication should occur internally, flowing across organization, and externally, with parties such as customers, suppliers, regulators and shareholders.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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 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.