Audit Conclusions | Cisa Exam Cram 2

After reviewing documentation, performing testing, and completing interviews and observations, the auditor is ready to form conclusions. This process involves identifying information that is material to the audit scope and issues that represent substantial control weaknesses. Per ISACA Guideline 50, materiality in an IT audit is determined in a qualitative manner as it relates to controls around the information system. A control is deemed material if its absence prevents control objectives from being met; the auditor determines materiality for an information system or operation that processes financial transactions by assessing the value of the assets controlled by the system or the volume of transactions processed through the system. As a part of the report conclusions, the auditor must draft a management letter; any material misstatements in the financial statements should be reported to management immediately. Management then evaluates responses to the findings, states corrective actions to be taken, and determines the timing for implementing these anticipated corrective actions.

Per ISACA Guidelines 70, the audit opinion should include the following:

Name of the organization
Title, signature, and data
Statement of audit objectives and whether these were met
Scope of the audit
Any scope limitations
Intended audience
Standards used to perform the audit
Detailed explanation of findings
Conclusion, including reservations or qualifications
Suggestions for corrective action or improvement
Significant subsequent events

Obtaining Evidence

In the normal course of an audit, the auditor should obtain specific documentation relating to the audit area. This information should be sufficient, reliable, relevant, and useful to achieve the audit objectives; it can include earlier audits, business plans, financial information, policies and procedures, results of test procedures, interviews, and observations. Gathering background information pertinent to the new audit is the first task an IS auditor should complete when performing an audit in an unfamiliar area. The information obtained is collectively known as evidence. The audit methodology and audit plan state the process and specific objectives of the audit. Sometimes there might be insufficient evidence or evidence that was gathered outside the scope of the audit and that, therefore, would not have relevance in the audit report.

Earlier audit reports are considered of lesser value to an IS auditor attempting to gain an understanding of an organization's IT process than evidence directly collected.

In the event of insufficient evidence, the auditor might not be able to meet the objectives of the audit. In other words, the evidence gathered would be insufficient to determine whether the controls were at the appropriate level. Although all the evidence obtained will help the auditor reach the audit conclusion, not all evidence has the same level of reliability. The reliability of evidence is based on the following criteria:

Independence of the provider of the evidence Evidence gained from outside the organization being audited is generally more reliable than evidence gained internally, as long as that evidence is gained from a reliable source. As a general rule, outside entities do not have a vested interest in the outcome of the audit.

As an example, a confirmation letter received from an outside source is usually considered more reliable than evidence provided by the client being audited.
Qualification of the individual providing the information/evidence Regardless of whether the individual providing the evidence is inside or outside the organization, the qualification of the individual determines the reliability of the evidence. This is also true of the auditor: If the auditor does not have a thorough grasp of the area being audited or the results of testing in that area, he or she might not collect the evidence required or might misunderstand the results of the test.
Objectivity of the evidence A variety of types of evidence is collected, and the objectivity of the evidence makes it more reliable. If tests are performed against account balances or a specific security control, this is more objective than interviews with personnel on account balances or the effectiveness or relevance of the security control.
Timing of evidence Some evidence might not be available because of internal procedures properly eliminating evidence or fairly high rates of change regarding the evidence. The timing of evidence collection might not coincide with the audit plan and timeline.

During the audit, evidence should be collected from a variety of sources to meet the audit objectives. Regardless of the type of evidence collected, the auditor should stay focused on the objectives, not the nature of the evidence. Some of the evidence-gathering techniques include review of IS organization structures, to look for proper segregation of duties, and review of IS policies, procedures, and standards. These policies and standards can include IS development documents, test plans and reports, program change logs and histories, user and operations manuals, security policies, and QA reports. In addition, the auditor should interview the appropriate personnel and observe processes and employee performance. The combination of this information should provide a clear view of the function being audited at a variety of levels and ensure that there is correlation and consistency among the actual operations, controls, and written policy/procedures.

The purpose and scope of the audit determines the extent to which data will be collected during an IS audit.

Organization's Use of System Platforms, IT Infrastructure, and Applications

For the auditor to understand the IT organization, he or she must gather information at various levels within the IT organization. A strong understanding of the organizational structure, policies, procedures, and standards enables the auditor to meet the outlined objectives.

The auditor should review the organizational structure to ensure segregation of duties and to identify personnel authority and responsibility. Firsthand evidence such as observation and interviews usually provides the best evidence of the segregation of duties in an IS department.

Further review of individual job descriptions provides specific levels of authority and tasks that specific individual should perform. A review of the policies provides a high-level overview of the guidance provided to all personnel within the functional area, as well as any controls that are applied. IS auditors are most likely to perform compliance tests of internal controls if, after their initial evaluation of the controls, they conclude that control risks are within the acceptable limits. The procedures and standards are a further definition of policies and one of the ways to ensure consistent application of policies within the IT organization. Figure 1.2 shows the top-down integration of strategic plans, policies, and procedures.

Figure 1.2. Policy diagram.

Techniques to Gather Information and Preserve Evidence

A clear understanding of the organizational structure, functions, and strategy is important in gathering information. The auditor uses a variety of techniques to gather and correlate information, and the auditor is responsible for assessing both the quantity (sufficient) and the quality (competent) of the evidence gathered. Competent evidence is both valid and relevant to the audit objectives. Audit judgment is used to determine when the sufficiency is accomplished. The auditor should be aware of the different types of evidence gathered and the rules of evidence because both the audit findings and the conclusions are supported by this evidence.

The auditor should review information pertaining to the organizational structure, to ensure adequate segregation of duties. This is a key control in the IS environment. The auditor should understand both general and specific controls, to be able to evaluate the overall effectiveness of these controls. The organizational structure and job descriptions provide specific information on the daily roles and responsibilities for the IS organization.

Organizations invest heavily in developing, acquiring, and maintaining critical systems that support critical functions. Extreme care should be exercised in managing IT applications in order to minimize risk and maximize return on investment. Software business risk is the likelihood that the new system will not meet the applications user's business needs, requirements, or expectations, and is often caused by a lack of discipline in managing the software-development process. Lack of discipline from poor management can result in scope creep, introducing the risk of the project exceeding the time and cost estimates originally provided for the project. The auditor should review policies and procedures to ensure that the objectives of the strategic plan are being met. The auditor should review standards and look for a minimum level of information systems documentation. The systems development life cycle (SDLC) defines how the organization acquires, develops, changes, and implements IT infrastructure and applications. This documentation addresses how the IS organization functions and can include the following:

Phase 1: Feasibility study The feasibility study enables management to identify and quantify the cost savings of a new system, and estimate the payback schedule for costs incurred in implementing the system.
Phase 2: Requirements definition The requirements definition maps the major requirements to the solution. It involves management and end users to make sure the new system will support the business needs. Users specify automated and nonautomated resource needs and how they want to have them addressed in the new system. A requirements definition should ensure that the requirements are complete, consistent, unambiguous, verifiable, modifiable, testable, and traceable. A review of the requirements definition allows the auditor to determine whether adequate security requirements have been defined for the new system.
Phase 3: System design The requirements gathered in Phase 2 assist in establishing a baseline of system and subsystem specifications that describe the parts of the system, how they interact, and how the system will be implemented using the chosen hardware, software, and network facilities. The design phase is normally involved in the translation of the user requirements in IT terms; this will be the foundation needed for the development of the system.
Phase 4: Development In the system-development phase, the programming and testing take place. The testing verifies and validates what has been developed. The responsibilities primarily rest with the programmers and system analysts who are building the system.
The programmers should use program-coding standards, which are essential to simply and clearly read and understand code without requiring specification review. Programmers should design the code with more cohesion (dedication to a single function) and less coupling (interaction with other functions), resulting in less troubleshooting and software maintenance. Online programming facilities increase programming productivity, lower development cost, reduce response time, and expand programming resources available, but they can increase risk of inappropriate access and version control. This risk can lead to reduced integrity of programming and processing, and valid changes can be overwritten by invalid changes.
Different types and levels of testing exist for new applications. Bottom-up testing tests programs or modules while progressing toward testing the entire system. Bottom-up testing allows for a modular approach to testing and can be started before the entire system is complete; it detects errors in critical modules early. Top-down testing tests major functions or processes early in the development, and detects interface errors sooner.
Testing at different levels and with separate testing elements ensures that the system meets the performance requirements (performance testing), that it can be recovered (recovery testing), and that it meets the security requirements (security testing). Basic testing elements include these:
- Whitebox testing Logical paths through the software are tested using test cases that exercise specific sets of conditions and loops.
- Blackbox testing This testing examines an aspect of the system with regard to the internal logical structure of the software.
- Function/validation testing This tests the functionality of the system against the detailed requirements.
- Regression testing A portion of the test scenarios is rerun, to ensure that changes or corrections have not introduced new errors.
- Parallel testing Test data is fed into both the new and old systems, and the results are compared.
Phase 5: Implementation Implementation is the final phase in the system development lifecycle. This phase puts the new system into operation. It includes final user acceptance testing and can include certification and accreditation processes. The tasks in this phase measure to ensure that the system meets the intended objectives and establishes appropriate levels of internal control.

The auditor should look for evidence of a structured approach to applications management with defined life-cycle phases and progression points. Advantages to the auditor of such an approach include the following:

The IS auditor's influence is increased when there are formal procedures and guidelines identifying each phase in the application life cycle and the extent of auditor involvement.
The IS auditor can review all relevant areas and phases of the systems-development project and can report independently to management on the adherence to planned objectives and company procedures.

If controls are lacking as a result of the organizational structure or of the software methods used, or if the processes are disorderly (informal), the IS auditor must advise the project management team and senior management of the deficiencies. It might also be necessary to notify those involved in the development and acquisition activities of appropriate controls or processes.

IS auditors involved actively in the design and implementation of the application system risk having their independence impaired.