Key concepts you will need to understand:
✓ ISACA IS Auditing Standards and Guidelines and Code of Professional Ethics
✓ IS auditing practices and techniques
✓ Techniques to gather information and preserve evidence
✓ Control objectives and controls related to IS
✓ Types of risk: IS, business, and audit risk
✓ How to determine an organization’s use of system platforms, IT infrastructure and applications
✓ Risk-analysis methods, principles, and criteria
✓ Audit planning and management techniques
✓ How to communicate the audit results
✓ Personnel-management techniques
Techniques you will need to master:
✓ Develop and implement a risk-based IS audit strategy and objectives, in compliance with generally accepted standards, to ensure that the organization’s information technology and business processes are adequately controlled, monitored, and assessed, and are aligned with the organization’s business objectives
✓ Plan specific audits to ensure that the IS audit strategy and objectives are achieved
✓ Obtain sufficient, reliable, relevant, and useful evidence to achieve the audit objectives
✓ Analyze information gathered to identify reportable conditions and reach conclusions
✓ Review the work performed to provide reasonable assurance that objectives have been achieved
✓ Communicate audit results to key stakeholders
✓ Facilitate the implementation of risk-management and control practices within the organization
To understand the material required for the exam, you must first understand what an auditor is and is not. An IS auditor is responsible for assessing the strength and effectiveness of controls that are designed to protect information systems, and to ensure that audit engagements are planned, designed, and reviewed based on the assessed level of risk that irregular and illegal acts might occur. These acts could be material to the subject matter of the IS auditor’s report. The IS auditor is not qualified to determine whether an irregular, illegal, or erroneous act has occurred, but has the responsibility to report suspected acts to the appropriate parties. Determining whether information systems safeguard assets and maintaining data integrity are the primary objectives of an IS audit function.
To ensure the audit is comprehensive, you will use guidelines to assist you in applying IS Auditing Standards. These standards define the mandatory requirements for IS auditing and reporting, as well as provide a minimum level of performance for auditors. The Information Systems Auditing Association (ISACA) provides the auditing community with guidance in the form of auditing guidelines, standards, and polices specific to information systems (IS) auditing. One of the goals of the ISACA is to advance globally applicable standards to meet its vision. The development and dissemination of the IS Auditing Standards is a cornerstone of the ISACA professional contribution to the audit community. The ISACA framework for the IS Auditing Standards provides multiple levels of guidance for conducting IT audits.
There are 8 categories and 12 overall IS auditing standards. IS Auditing Standards are brief mandatory requirements for certification holders’ reports on the audit and its findings. IS Auditing Guidelines and Procedures give detailed guidance on how to follow those standards. The IS Auditing Guidelines provide a framework an IS auditor normally follows, with the understanding that in some situations the auditor will not follow that guidance. In this case, it is the IS auditor’s responsibility to justify the way in which the work is done. The Procedures examples show the steps performed by an IS auditor and are more informative than IS Auditing Guidelines. Table 1.1. provides ISACA’s definition of standards, guidelines, and procedures.
Table 1.1. IS Auditing Procedures
The examples are constructed to follow the IS Auditing Standards and the IS Auditing Guidelines, and provide information on following the IS Auditing Standards. To some extent, they also establish best practices for procedures to be followed.
The eight standards categories are the first three digits in a document number. IS Auditing Standards begin with 0; Standards for IS Control Professionals begin with 5. The standards numbers are the second three numbers in the document. The third set of three digits in a document number is the number of the guideline. Procedures are listed separately and numbered consecutively by issue date.
For example, document 060.020.040 is a guideline. It provides guidance in the sixth standard category, Performance of Audit Work. The guidance applies to the second standard in that category, Evidence. It is the fourth guideline listed under Evidence. Procedures are numbered consecutively as they are issued, beginning with 1.
It is suggested that during the annual audit program, as well as during individual reviews throughout the year, the IS auditor should review the standards to ensure compliance with them. The IS auditor can refer to the ISACA standards in the report, stating that the review was conducted in compliance with the laws of the country, applicable audit regulations, and ISACA standards. Table 1.2 is the ISACA framework for the IS auditor. This framework is broken down into multiple levels of guidance.
Table 1.2. ISACA Auditing Standards
As an auditor, you will have access to a variety of information, including intellectual property, internal controls, legal contracts, internal procedures, and both business and IT strategies. ISACA has set forth a Code of Professional Ethics to guide the professional and personal conduct of members of the association and its certification holders.
Members and ISACA certification holders shall...
Support the implementation of and encourage compliance with appropriate standards, procedures, and controls for information systems.
Perform their duties with objectivity, due diligence, and professional care, in accordance with professional standards and best practices.
Serve in the interest of stakeholders in a lawful and honest manner, while maintaining high standards of conduct and character, and not engage in acts discreditable to the profession.
Maintain the privacy and confidentiality of information obtained in the course of their duties unless disclosure is required by legal authority. Such information shall not be used for personal benefit or released to inappropriate parties.
Maintain competency in their respective fields and agree to undertake only those activities that they can reasonably expect to complete with professional competence.
Inform appropriate parties of the results of work performed, revealing all significant facts known to them.
Support the professional education of stakeholders in enhancing their understanding of information systems security and control.
Failure to comply with this Code of Professional Ethics can result in an investigation into a member’s or certification holder’s conduct and, ultimately, in disciplinary measures.
As an auditor, it is important that you pay particular attention to maintaining the privacy and confidentiality of information obtained in the course of your duties and informing the appropriate parties of the results of work performed, revealing all significant facts known to you.
Although management is ultimately responsible for preventing and detecting irregular or illegal acts, you must plan the IT audit engagement based on the assessed level of risk that these acts might occur and design audit procedures that can identify these acts. The auditor then should create a report of the findings of the audit revealing all significant facts known to him or her.
As previously stated, auditors are not qualified to determine whether an irregular, illegal, or erroneous act has occurred. If during the course of the audit the auditor suspects that these acts have occurred, the auditor must report this to one or more of the following parties:
The IS auditors’ immediate supervisor and possibly the corporate governance bodies, such as the board of directors or audit committee
Appropriate personnel within the organization, such as a manager who is at least one level above those who are suspected to have engaged in such acts
Corporate governance bodies, if top management is suspected
Legal counsel of other appropriate external experts
As we know, privacy is an issue at the forefront in today’s society. A majority of organizations have developed privacy polices that outline how they collect, store, protect, and use private information, along with controls designed to protect private information. As an auditor, you will assess the strength and effectiveness of controls designed to protect personally identifiable information in organizations. This will help ensure that management develops, implements, and operates sound internal controls aimed at protecting the private information that it collects and stores during the normal course of business.
So far, we have provided you with auditors’ responsibilities, the ISACA code of ethics, and definitions for guidelines, standards, and procedures for IS auditing. At this point, you might be asking yourself, “What am I getting myself into?” and “What is IS auditing really?”
Whether you are a financial auditor, are a network or security systems engineer, or are new to IS auditing, rest assured that we will guide you through the auditing process and assist you in understanding how the IS audit process and its components fit together. We start at the top by providing you with IS audit planning and management techniques.
As you read through the remainder of this chapter and the following chapters, keep in mind that we start from the auditor’s perspective in planning the IS audit and add the components as we go along. Be sure to use all the resources available to you to completely understand the topic before moving forward. You have the CBT and the questions at the end of each chapter to keep you focused and on track. To help solidify the process and components in your mind as you read, apply the things you are learning to your own organization; try to envision the planning, documentation, and people you would communicate with (at both the management and operational levels); imagine what type of information you could expect to receive/review; and consider how you would communicate your results at all levels in the organization.
Keep in mind that the work you perform can directly assist in the successful assessment and mitigation of risk and overall security of the organization you are auditing. If performed successfully, it will be a factor in ensuring the success of the organization, management, employees, and continued service to customers. Good luck and have fun!
The organization’s management is responsible for preventing and detecting illegal or irregular acts. Although the IS auditor is not qualified to determine whether an irregular, illegal, or erroneous act has occurred, auditors are responsible for assessing the level of risk that irregular and illegal acts might occur. This is accomplished by designing audit procedures that consider the assessed risk level for irregular and illegal acts. The IS auditor then should review the results of audit procedures for indications of such acts. If the IS auditor suspects that these acts have occurred, the auditor must report the finding immediately to the immediate supervisor and possibly corporate governance bodies, such as the board of directors or audit committee. In addition, the IS auditor is responsible for ensuring that management develop, implement, and operate sound internal controls aimed at the protection of private information. The IS auditor should assess the strength and effectiveness of controls designed to protect personally identifiable information within the organization.
Other resources available through ISACA are the COBIT resources. COBIT is intended for use by business and IT management as well as IS auditors. Therefore, its use ensures business objectives and the communication of best practices and recommendations are based on a commonly understood and well-respected standard reference. These resources can be used as a source of best-practice guidance. Each of the following is organized by an IT management process, as defined in the COBIT Framework. The COBIT framework provides good practices for the management of IT processes in a manageable and logical structure, meeting the multiple needs of enterprise management by bridging the gaps between business risks, technical issues, control needs, and performance measurement requirements. Auditors will review IS for formal risk-management strategies for systems development and implementation projects, as well as acquisition, development, change management, and implementation of IT applications.
COBIT management guidelines are composed of maturity models, critical success factors, key goal indicators, and key performance indicators.
COBIT control objectives provide the critical insight needed to delineate a clear policy and good practice for IT controls and incorporate 318 specific, detailed control objectives throughout the 34 high-level control objectives.
The COBIT framework provides 11 processes in the management and deployment of IT systems:
Develop a strategic plan
Articulate the information architecture
Find an optimal fit between the IT and the organization’s strategy
Design the IT function to match the organization’s needs
Maximize the return of the IT investment
Communicate IT policies to the user community
Manage the IT workforce
Comply with external regulations, laws, and contracts
Conduct IT risk assessments
Maintain a high-quality systems-development process
The control self-assessment (CSA) is a formal, documented, collaborative process in which management or work teams are directly involved in judging and monitoring the effectiveness of controls. The CSA does not replace an audit, but its main objective is to enhance audit responsibility. A primary benefit derived from an organization that employs control self-assessment (CSA) techniques is that it can identify high-risk areas that might need a detailed review later.
The CSA is generally accompanied by workshops in which the IS auditor leads and guides the clients in assessing their environment. This enables auditors to serve as assessment facilitators and shifts some of the control-monitoring responsibilities to the functional areas.
One of the significant challenges facing auditors today is what to audit. The tighter integration of information systems and business processes, and the continued complexity of these systems, combined with limited resources and the ever-increasing pace of business, make auditing everything an impossible task. One of the techniques that management and auditors can use to allocate limited audit resources is a risk-based audit approach. The risk-based audit approach helps ensure that appropriate levels of protection are applied to information assets.
Many types of risk are associated with business and auditing. These risks are identified during the planning stage of the audit and are used as the foundation for control review. Risk assessment is the process of reviewing the threats and vulnerabilities, their effects on the assets being audited, and the projected loss frequency and severity. The organization can then use the risk assessment to determine how to remediate risk to the lowest possible level. Keep in mind that risk can never be reduced to zero and that there are a finite amount of resources to mitigate risk. Risk mitigation consists of reducing risk to a tolerable level by implementing controls that reduce the risk; the remaining risk is called residual risk. Residual risk can be mitigated by transference to a third party. A variety of risks are associated with business and the process of auditing:
Business risk—. The risk that a business will not achieve its stated business goals or objectives. Business risk can be affected by both internal and external factors.
Security risk—. The risk that unauthorized access to data will adversely affect the integrity of that data. Poor data integrity can lead to poor decision making and contribute to business risk.
Continuity risk—. This is the risk associated with systems availability and its capability to utilize backups to recover.
Audit risk—. The risk that the information of financial reports might contain material errors or that the IS auditor might not detect an error that has occurred. This term is also used to describe the level of risk an auditor is prepared to accept during an audit engagement. A material error is an error that should be considered significant to any party concerned with the item in question.
Inherent risk—. The risk that a material error could occur, assuming that there are no related internal controls to prevent or detect the error. Inherent risk is the susceptibility of an area or process to an error that could be material. An example is when an authorized program has exits (trap doors) because they provide flexibility for inserting code to modify or add functionality.
Control risk—. The risk that a material error exists that would not be prevented or detected on a timely basis by the system of internal controls.
Detection risk—. Detection risk results when an IS auditor uses an inadequate test procedure and concludes that material errors do not exist, when, in fact, they do.
An auditor should create and follow a specific predefined set of processes to set control objectives, gather evidence, review the evidence, and produce a findings conclusion and recommendations. The following steps help define your responsibilities as an auditor:
Plan the IT audit engagement based on an assessed level of risk that irregular and illegal acts might occur, and that such acts could be material to the subject matter of the IS auditor’s report.
Design audit procedures that consider the assessed risk level for irregular and illegal acts.
Review the results of the audit procedures for indications of irregular and illegal acts.
Assume that acts are not isolated.
Determine how the act slipped though the internal control system.
Broaden audit procedures to consider the possibility of more acts of this nature.
Conduct additional audit procedures.
Evaluate the results of the expanded audit procedures.
Consult with legal counsel and possibly corporate governance bodies to estimate the potential impact of the irregular and illegal acts, taken as a whole, on the subject matter of the engagement, audit report, and organization.
Report all facts and circumstances of the irregular and illegal acts (whether suspected or confirmed) if the acts have a material effect on the subject matter of the engagement or organization.
Distribute the report to the appropriate internal parties, such as managers who are at least one level above those who are suspected or confirmed to have committed the acts, or corporate governance.
IT governance provides structure to functions and processes within the IT organization. Because of the critical dependency of business on its information systems, the governance structure must ensure that the IT organizational strategy is aligned with the business strategy. The implementation of the IT strategy will help ensure that IT processes contain the necessary controls to reduce risk to the organization and its business objectives. IT resources should be used responsibly, and IT risks should be managed appropriately.
The organization should have an IT steering committee to ensure that the IS department’s strategy directly aligns with the organization’s corporate mission and objectives and efficient use of IT resources. The IT steering committee is a formal organization usually composed of senior managers representing the business areas, with duties outlined in a charter. The charter outlines what authority and responsibilities are assigned to the committee and is a strong indicator that senior management supports the steering committee. One of the functions of the IT steering committee is to keep detailed minutes of the meeting, to document both procedural functions of the committee and its decisions. The committee is responsible for ensuring that the organization’s leadership (board of directors and senior management) is informed in a timely manner via the minutes and additional reporting, if required.
Although the committee is responsible for reviewing issues such as new and ongoing projects, major equipment acquisitions, and the review and approval of budgets, it does not usually get involved in the day-to-day operations of the IS department. The IT steering committee uses project plans, work breakdown structures, and policy/procedures to review the alignment of the IT department with the organizational mission. Generally, the IT steering committees will meet one to two times per month in a formal meeting at which the head of the IT department and project managers present their progress on major projects, propose new projects and policies, or refine procedures.
The lack of a formal chartered IT steering committee could be an indication that the IT department is not correctly aligned with the organization’s strategy. In the absence of an IT steering committee, the auditor might find that projects do not support the mission of the organization; that they are not on time or on budget, usually because of the lack of external controls; and that policies are outdated or not communicated or followed consistently throughout the organization. The auditor might also find situations in which an IT steering committee is present, but, because of the lack of a formal charter or direction from senior managers of the organization, members are unclear about their duties or level of authority. The IT steering committee meetings should focus on alignment and should refrain from becoming involved in the operational details of the IS department. In both of these situations, the IT steering committee is not ensuring the efficient use of data-processing resources, examining costs associated with projects, or setting priorities for the IT department.
Organizations should have processes for the development and review of strategic plans. Strategic plans ensure that the organization meets its goals and objectives, and, if properly reviewed, reflect the current direction of the organization and associated business units, including the IS department. The strategic-planning process should involve senior management, to ensure that the plan addresses the established goals and objectives, and a review process that enables the organization to update or change the strategic plan in the event of goal or objective changes. Strategic plans should incorporate both long-term (three to five years) and short-term (one to two years) strategic objectives of the organization, and are the responsibility of senior management. When auditing the IS strategic-planning process and implementation, the auditor should review overall goals and business plans but should not focus on procedures. Reviewing management’s long-term strategic plans helps the IS auditor gain an understanding of an organization’s goals and objectives.
The IS policies, procedures, standards, and guidelines are all implemented to support the overall strategic plan. Policies and procedures reflect the actual operational implementation of the strategic plan and should have a formal process for creation, communication, and review. Although most organizations have policies in place, they are often “shelf ware,” meaning that they are created once, generally communicated to new employees, and then put on the shelf. The danger with this implementation is that there is the lack of ongoing review of policies and procedures to ensure that they align with the strategic plan. This leads to instances in which employees are not aware of policies and procedures as they apply to the day-to-day work. A review of the strategic plan, policies, procedures, and observations will identify whether there is correct alignment within the organization. Additional review of and questions of who has ownership of the strategic planning and policy creation/implementation and how often plans are reviewed or updated will indicate the presence or absence of a formal process.
IT departments should have a clearly defined structure that outlines authority and responsibility, and defines the hierarchal structure. This structure is usually defined in an organization chart, which helps the IS auditor determine whether there is proper segregation of functions. In addition, each employee should have a job description that provides a detailed outline of job function and the tasks associated with that function. Per ISACA, segregation of duties avoids the possibility that a single person could be responsible for diverse and critical functions in such a way that those errors or misappropriations could occur and not be detected in a timely manner and in the normal course of business processes.
The structure of the IT department and its responsibilities could change slightly based on the goals of the organization, but Figure 1.1 shows ISACA’s outline of an organizational structure and descriptions of the functions.
To maintain proper control of IT projects, including the acquisition, design, implementation, and maintenance of the IT infrastructure, the IT department should implement the following disciplines:
Personnel management—. This is done in accordance with organizational policies and procedures for hiring, promotion, retention, and termination of employees and personnel. Proper implementation ensures that employees are qualified to perform their jobs and are promoted and retained to consistently improve the quality of the IT operations.
IT project management—. All new and existing projects should include project plans that outline the resources required for the project, milestones, return on investment, and regular milestone reviews. The combination of the IT steering committee reviews and independent audits ensures that projects stay on time and on budget and that they meet the strategic objectives of the organization.
IT change management—. Change management is a formal documented process for introducing technology changes into the environment. Proper change control ensures that changes are documented, approved, and implemented with minimum disruption to the production environment and provide maximum benefits to the organization.
Financial management—. The process of budget development includes forecasting, monitoring, and analyzing financial information as it applies to resources. This management process ensures the adequate allocation of funds, proper distribution of funds within the different IT functions (operations, security, and so on), and any gaps that exist between IT investments and the benefits provided by those investments.
We discuss these disciplines in further detail throughout the book, but it is important to note that they might fall within a single group or be used across operational groups to efficiently manage IT resources.
The department is headed by an information technology manager/director, or in larger organizations, by a chief information officer. The head of the IT department is responsible for the overall operation of the IT department, including budget authority, hiring, training and retaining of qualified people, and alignment of IT as a service organization, to ensure that the organization can meet strategic objectives and operational goals.
The security department is enabled through senior management’s understanding of risk and application of the resources to mitigate risk. The security department’s functions are guided through policies and procedures, and should remain separate from IT functions. The security administrator should report directly to the head of the security department or, in some cases, to the board of directors. This person is responsible for ensuring that users are complying with security policy and that the policy is adequate to prevent unauthorized access to company assets (including intellectual property, data, programs, and systems).
Quality-assurance personnel usually perform two functions. First they ensure that all personnel are following quality processes. As an example the QA personnel ensure that the IT department adheres to standards and procedures for IP addressing conventions. Second, quality-control personnel are responsible for testing and review, to verify that software is free of defects and meets user expectations. All functional and operational testing is performed as part of the SDLC and must be complete before systems go into production.
The applications function is divided into two categories: Systems programmers are responsible for maintaining operating systems and systems software. Application programmers are responsible for developing new systems and maintaining applications that are in production.
In keeping with proper segregation of duties, managers must ensure that application programmers use a code library (test-only) while creating and updating code, and that they do not have access to production programs. The test-only programs should be reviewed and put into production by a separate group. Systems programmers should have access to entire systems, and management should use compensating controls such as access and change logs to monitor and ensure that they have access to only the system libraries for which they are responsible. The use of a compensating control reduces the risk associated with a control that is not adequate. Another example of compensating controls is a risk associated with unauthorized viewing of sensitive data. Although access controls are in place, there is a possibility that unauthorized users might still review sensitive data. To compensate for limitations of access controls, additional controls can be added:
Extensive risk analysis on the systems containing sensitive data
Increased supervisory review of access logs and application-level audit reports
Systems analysts are involved during the initial phase of the systems-development life cycle and ensure that the needs of users are incorporated into the system or application requirements and high-level design documents.
The database administrator (DBA) is responsible for defining data structures and for maintaining those structures in the organization’s database systems. The DBA acts as a data custodian by ensuring that database design, structure, relationships, and maintenance support the needs of the organization and its users, and for maintaining the quality and security of data. The DBA generally has access to all of the organization’s data, both test and production. Although it is not practical to prohibit access to the data, management should implement compensating controls to monitor DBA activities. These controls can include using access logs, logging structural changes to data-bases, and applying detective controls over the use of database tools.
Technical support personnel fall into three categories. The first and most common are the help desk technicians. The help desk is responsible for assisting end users with problems or issues with desktops or workstations, and personnel frequently participate in configuring and deploying new equipment, operating systems, and applications. Network administrators are responsible for the network infrastructure, which includes routers, switches, and firewalls. They are also responsible for the performance of the network, as well as redundancy, proper network segmentation, and backups of critical systems. In smaller organizations, network administrators might be responsible for security administration of the systems, including firewall configuration, access control, and authorization activities. Systems administrators are responsible for maintaining the systems that provide services to the organization. These can include file/print sharing, email, and virus prevention and detection. The administrator can add or remove users (set up user accounts), grant access to resources, install system-wide software, and allocate storage.
The operations group is responsible for computer operations and usually includes computer operators, librarians, and data entry operators. A majority of the organization’s information, or input/output, is maintained by the operations group and can include data input, report generation, data output via magnetic media, and operations activities scheduling.
Segregation of duties is an important means by which fraudulent or malicious acts can be discouraged or prevented.
A common example of improper segregation of duties is allowing a single person within operations or the help desk to have the responsibility of ordering hardware/software, receiving and managing asset or inventory control. This type of structure could allow a single person to order and receive IT equipment without adding it to the asset-control system and, therefore, creates the opportunity for theft of equipment. In small organizations in which proper segregation of duties is not possible, the IT department must set up compensating controls. In this instance, the IT department could institute a daily/weekly review of all orders by a manager, to ensure that equipment is being added to the asset-control system.
The structure of the organization must consider segregation of incompatible duties, keeping in mind that segregation between operations and programming, as an example, might not be possible in smaller environments. The use of compensating controls, such as audit trails, might be acceptable to mitigate the risk that exists because of improper segregation of duties. IT functions such as systems development, computer operations, and security should be segregated.
An auditor can perform a variety of audit types. Our primary topic is IT auditing, but it is important to understand the procedures associated with each type of audit:
Financial audit—. A financial audit often involves detailed, substantive testing. This kind of audit relates to information integrity and reliability; its purpose is to assess the correctness of the organization’s financial statements.
Operation audit—. An operation audit is designed to evaluate the internal control structure in a given process or area. IS audits of application controls or logical security systems are examples of operation audits.
Integrated audit—. An integrated audit combines the testing of controls and substantive testing for the completeness, validity, and integrity of the information. An SAS 94 audit is an example of an integrated audit.
Administrative audit—. This audit assesses issues related to the efficiency of operation productivity within an organization.
Information systems audit—. This process collects and evaluates evidence to determine whether information systems and related resources adequately safeguard assets, maintain data and system integrity, provide relevant and reliable information, achieve organizational goals effectively, consume resources efficiently, and have in effect internal controls that provide reasonable assurance that business, operation, and control objectives will be met.
Compliance audit—. Compliance auditing involves an integrated series of activities focused on investigating and confirming whether products or services comply with internal policy or external guidelines or laws. Sarbanes-Oxley and the Health Insurance Portability Act are examples of external laws that require compliance.
The IS auditor should follow an IT audit life cycle in the planning, assessment, and execution of the audit. The audit life cycle should include the following steps:
Plan
Assess risk
Prepare and plan an audit program
Conduct a preliminary review of the audit area/subject
Evaluate the audit area/subject
Gather evidence
Conduct compliance testing
Conduct substantive testing
Form conclusions
Deliver audit opinion (communicate results)
Follow up
In preparation for the audit, the auditor should either use an existing audit methodology or create one. The audit methodology is a set of documented audit procedures to ensure that the auditor achieves the planned audit objectives. Establishment of the audit methodology encompasses all phases of the audit and creates a repeatable, consistent approach to audits in the organization. The methodology should be documented and approved by the audit management and should be communicated to the audit staff.
Table 1.3 lists the phases of a typical audit
Table 1.3. Phases of an Audit
Using the audit methodology, the auditing department can create boundaries for the audit, ensure consistent processes, and identify specific steps to be performed during the audit. The combined effect is that the auditing function has a trail of what entities were audited, who was interviewed, what material was collected, and how controls were verified. This ensures that the audit report is complete without exceeding the audit boundaries, and provides confidence that the procedures that were followed met the objectives of the audit.
A risk-based audit approach helps management effectively utilize limited auditing resources by identifying areas of high risk in the organization. This method helps prioritize audits, and information gathered from risk analysis facilitates more effective corporate governance by ensuring that audit activities are directed to high business risk areas, maximizing the effectiveness of audit activities.
In a risk-based approach to auditing, the IS auditor gains an understanding of the client’s environment and information systems, and determines which areas are high-risk, or material. These areas then become the focus of the audit. The alternative to the risk-based approach is for the auditing department to evaluate the organization’s entire environment and operating system. This is often referred to as the “old model” of auditing. In planning an audit, the most critical step is to identify the areas of high risk. The IS auditor should use the following risk-based approach to creating an audit plan:
Gather information and plan.
Knowledge of business and industry
Audit results from earlier years
Recent financial information
Regulatory statutes
Inherent risk assessments
Determine internal controls and obtain an understanding of how they function.
Control environment
Control procedures
Detection risk assessment
Control risk assessment
Equate total risk
Perform compliance tests.
Perform substantive tests.
During an information systems audit, the IS auditor should review the internal control environment of information systems and the use of these systems. The IS audits usually evaluate processing controls, system input/output backup and recovery plans, and security. Four main types of audits are used in reviewing information systems:
Attestation—. The auditor provides assurance on something for which the client is responsible. This type of audit is considered a compliance audit and can ensure internal or external compliance.
Finding and recommendation—. This is a consulting or advisory engagement in which the auditor performs a less structured type of engagement, such as a systems-implementation engagement.
SAS 94—. This type of audit is referred to as an integrated audit. Typically, this is part of a regular financial audit, in which the auditor must evaluate controls around a client’s information system and the entries that are processed through that system.
The objective of a true attestation audit is to render an opinion on whether the reader of the statement or report can be reasonably sure that the information contained in the report is correct. An attestation audit can include reports on descriptions of systems of internal controls and compliance with statutory, contractual, or regulatory requirements.
Types of attestation audits include the following:
Data analytic reviews
Commission agreement reviews
WebTrust engagements
Systrust engagements
Financial projections
Compliance reviews
An example of attestation standards is the WebTrust audit standards introduced by the American Institute of Certified Public Accountants (AICPA) and the Canadian Institute of Chartered Accountants (CICA). The AICPA/CICA WebTrust provides a set of standards for reviewing e-commerce websites to ensure security, online privacy, availability, confidentiality, and process integrity. Auditors examine both the company and the e-commerce website with regard to business practices, transaction integrity, and information protection. If the site passes inspection per the AICPA statements on standards for attestation engagements, the auditor should create an independent accounts report for submission to the AICPA. The AICPA then issues a WebTrust seal to the website. This seal represents a third-party, AICPA, attestation that the website meets the AICPA/CICA standards.
Other types of attestation audits include compliance audits. In these audits, the auditor verifies that the organization’s business practices have sufficient controls to meet contractual or regulatory standards. Regulatory standards might include HIPAA, Sarbanes-Oxley, GLBA, or others.
These types of auditing engagements require that the auditor clearly understand the business functions, have a high degree of technical proficiency, and be able to conduct security and integrity tests to verify that the systems meet the standards.
Findings and recommendations do not produce an opinion; they provide a summary of the work performed in connection with the engagement. These consulting or advisory types of engagements can include review of the following:
System implementations
Enterprise resource planning
System security reviews
Database application reviews
Internal audit services
The IS auditor defines the audit objectives and, through the examination of sufficient, competent, and relevant information, testing, and other evaluations, develops the audit report. The IS auditor must understand the business functions, clearly define the audit objectives, and have the technical proficiency to conduct the required review and testing.
The Statement on Auditing Standards (SAS) 70, “Service Organizations,” is a recognized auditing standard developed by AICPA. The SAS 70 audit or service auditor’s examination is widely recognized and indicates that an organization has been through an in-depth audit of its control activities, including controls over IT and related processes. The opinions offered in an SAS 70 report can be created only by a Certified Public Accountant (CPA). Two types of SAS 70 audits exist, appropriately named Type I and Type II. In a Type I report, the IS auditor expresses an opinion on whether the organization’s description of its controls is aligned with the controls that are actually in place and whether the controls achieve the specified control objectives. In a Type II report, the IS auditor expresses an opinion on the items in Type I and whether the controls that were tested were operating effectively to provide reasonable assurance that the control objectives were achieved.
The SAS 70 report is an independent third-party review of the organization’s controls and states that the controls meet the control objectives. This report helps the organization build trust with customers and third-party partners. The specialization of IT services and outsourcing of some or part of those services means an increased reliance on partners; a service organization might have to entertain audit requests from partners or customers as a condition of providing services. The SAS 70 audit ensures that the service organization will not have to perform multiple audits at the request of potential partners and customers, and that all potential partners and customers will have access to the same information about the organization’s business practices and controls.
The Statement on Auditing Standards (SAS) 94, “The Effect of Information Technology on the Auditor’s Consideration of Internal Control in a Financial Statement Audit,” amends SAS 55 and provides guidance to auditors on the impact of IT on internal controls. The SAS 94 audit complies with the SAS 55 requirement to obtain an understanding of the five internal control components: the control environment, risk assessment, control activities, information and communication monitoring, and how IT impacts the overall audit strategy. For this reason, the SAS 94 is considered an integrated audit. In other words, the IS auditor must ensure that the information provided by IT systems is accurate and complete, and also must understand what procedures (whether manual or automated) were used in preparing the financial statements. The SAS 94 standard acknowledges that IT systems and their associated controls can be so significant that the quality of the audit evidence depends on those controls and that the IT process for managing and creating financial statements has a major influence on the audit.
The IS auditor should examine IT system controls and determine whether the controls prevent unauthorized access to menus, programs, and data:
Destruction or improper changes
Unauthorized, nonexistent, or inaccurate transactions
Errors or fraud
The IS auditor needs a high degree of technical proficiency to integrate an SAS 94 audit. During the audit planning, the IS auditor should identify the types of misstatements that could occur and should consider the factors that affect the risk of material misstatement. In addition, the auditor should identify controls that are likely to prevent or detect material misstatement in specific assertions and should test those controls. In addition, the auditor must understand both the business practices and the manual and automated processes used in creating the financial statements.
Attribute sampling deals with the rate of occurrence or frequency of items that have a certain attribute. The attribute either is there or is not. The policy/procedure either exists or does not. Attribute sampling is the primary sampling method used for compliance testing.
When the IS auditor uses attribute sampling, the results are expressed as a sample frequency or error rate. An example of expressing an error rate is review system logs in which one event, such as a daily backup, is not logged 1 day in 100. This would represent a 1% sample error rate. There may be 1,000 logs to review, so the IS auditor must choose a sample (100 logs) of the total population (1,000 logs); the error rate of the sample population is most likely to be the same error rate for the entire population because the sample population should be representative of the entire population.
Variable sampling deals with variations in some unit of measure. As an example, system logs should have time stamps for the start and end of backups on a given day. Those times might vary, depending on the type of backup or the amount of data backed up.
When the IS auditor uses variable sampling, a random sample can produce results that can be expressed as a percentage. Going back to the example of the backups when using variable sampling, the auditor would choose a sample (100 logs) of the total population (1,000 logs), sampling only the same type of backups (daily), and would sample the start and end times of the backup. The results of the random sample might show that on 10 out of the 100 days reviewed, the backups took 50% less time. This percentage of the sample population is most likely to be the same percentage of the entire population.
As the IS auditor gathers samples from the environment, it is important to ensure that the sample population is representative of the total population. The sampling confidence coefficient is a percentage expression of the probability that the characteristics of the sample are considered a true representation of the population. If the organization has stronger controls, there will be less reliance on sampling, which will allow for a smaller accepted sample size (confidence coefficient). If the strength of controls is not known, the auditor must choose a larger sample size to provide a greater confidence coefficient. The confidence coefficient is expressed in percentages; a 95% confidence coefficient is considered a high degree of confidence. If incorrect assumptions are made about a population that the sample is selected from, this introduces sampling risk. Sampling risk is calculated using this formula:
Sampling risk = 1 – Confidence coefficient
So what have we learned from these particular samples? In the case of error sampling, there are days when the backups either are not logged or do not run for some reason, introducing risk into the environment by either not being able to recover from a data error (backup not running) or not being able to ensure that the backups are actually running (not logging). When reviewing the results of variable sampling, we find that daily backups that should require approximately the same amounts of time for backup do not. Assuming that there have not been significant changes in the amount of data being backed up, the results of variable sampling might indicate errors in the backup program. The cause of these errors could include the exclusion of data that should be backed up or start and end times not logged correctly 10% of the time.
Substantive testing substantiates the integrity of actual processing, sometimes called transaction integrity. This type of testing provides an appropriate assurance of detecting the possibility of material errors. Neither attribute nor variable sampling is a perfect fit for substantive testing because attribute sampling measures frequencies/percentages, not value, and variable sampling measures averages. The IS auditor can use one or both sampling methods combined with observation and interviews as a part of substantive testing.
Compliance testing tests controls in the environment, to ensure that they are being applied in a manner that complies with the organization’s policies and procedures. Using the examples discussed in sampling, the auditor tests to see that backups are backing up all data and logging in accordance with backup policies and business continuity planning. The IT auditor used both types of testing (attribute and variable) to meet the compliance testing objective.
A distinction that can be made between compliance testing and substantive testing is that compliance testing tests controls, whereas substantive testing tests details.
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
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.
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.
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.
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.
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.
The combination of organizational structure, policies and procedures, and best practices that are implemented to reduce risk is called internal controls. Internal controls are used by the organization to provide a reasonable assurance that the business objectives will be met and risk will be prevented, detected, or corrected. Preventative control objectives detect problems before they arise, monitor both operations and inputs, and prevent errors, omissions, or malicious acts from occurring. Using an access-control system (think user/password combination) is an example of a preventative control. Detective controls are used to detect and report the occurrence of an error, omission, or malicious act. Using audit trails is an example of a detective control. Corrective controls minimize the impact of threat, identify the cause of a problem, and modify the system to minimize future occurrences of the problem. Using a rollback facility in a database environment is an example of a corrective control. When evaluating the collective effect of preventative, detective, or corrective controls within a process, an IS auditor should be aware of the point at which controls are exercised as data flows through the system.
Internal controls operate at all levels of the organization and should be continuously monitored to ensure their effectiveness. The auditor should be primarily concerned with the overall strength of the control or combination of controls to ensure that it meets its stated objective. Control procedures can be manual or automated and generally fall into three categories:
Internal accounting controls—. Primarily used in accounting operations. They apply to safeguarding the assets and reliability of financial data and records.
Operational controls—. Used in day-to-day operations to ensure that the operation is meeting business objectives.
Administrative controls—. Used to ensure compliance with management policy.
As an example, access controls are implemented to ensure confidentiality, integrity, and availability of information systems and their associated data. Confidentiality is the assurance that the information will not be disclosed to unauthorized individuals, programs, or processes. Integrity ensures that the data is not altered in an unauthorized way. Availability ensures timely access to information by authorized users, programs, or processes. Table 1.4 identifies specific controls, how they are implemented, and their classification (preventative, detective, corrective).
Table 1.4. Controls
Area | Transaction Type | Control Objective | Control Activity | Audit Procedure | Class | Method |
|---|---|---|---|---|---|---|
Information systems operations | Safeguard IT systems | Network access is restricted to authorized users and restricts unauthorized activity | Examine access policy. Users must fill out a system authorization form and be granted access by IS management. | Gather and review samples of the system operations form. Compare the form to identify users who have current access and current employees of the organization. | Preventative | Manual |
IS management verifies users with access to a department listing provided by department managers, to ensure that access is appropriate and accurate. | Review previously completed access verification audit results, and determine that appropriate IS management approval was obtained and that exceptions were properly resolved. | Detective | Manual | |||
Audit logging is enabled for both successful and unsuccessful access, and access to the logs is restricted to IS management. | Compare access logs against a list of current employees and users, and determine whether there are patterns of unsuccessful access (password guessing) or successful access during inappropriate hours or from unauthorized systems or networks. | Corrective |
Internal control objectives define the desired purpose or desired outcome associated with the implementation of the control. Table 1.5 outlines control objectives, their associated activities, and the audit procedures.
Table 1.5. Example of a Control Matrix
The first step in aligning IT with an organization’s corporate goals is having and working on an appropriate level of planning. The IT department should have long-range (three- to five-year) and short-range (one-year) plans. These plans should provide specific solutions that ensure the growth and profitability of the organization, as well as identify both internal and external opportunities and controls that meet the organizational objectives.
Establishing a sound IT management methodology through sound project management and IT organizational policies ensures that organizational goals are fulfilled and business risks are reduced. IT managers must define roles and articulate the value of the IT function. The roles and responsibilities must have clearly defined job descriptions and authority levels, and must incorporate proper segregation of duties.
A high-level steering committee should be formed to ensure that the IS department closely supports the corporate mission and objectives:
The committee should include various senior managers representing all organizational business areas.
Duties and responsibilities should be defined in a formal charter.
The committee should not become involved in routine operations.
The committee should monitor major projects and the status of IS project plans and budgets; establish priorities; approve policies, standards, and procedures; and monitor overall IS performance.
The committee should act as a liaison between the IS department and user departments.
Formal minutes of the IS steering committee meetings should be maintained to document the committee’s activities and decisions, and to inform the board of directors of IS activities.
IS structures reflect the requirements of the organization. Figure 1.3 outlines a common structure to provide you with a definition of roles, responsibilities, and job types.
An important step before developing the audit conclusions is to evaluate the evidence gathered for strengths and weaknesses. The auditor must make judgments based primarily on experience. This review process is critical to the outcome of the findings and recommendations. ISACA’s standard for IS auditing 030.020, Professional Care guides the auditor while performing the audit, along with the determination of strengths and weaknesses of the evidence.
The IS auditor might need a high degree of specialized technical proficiency and might need to provide consulting or advisory services with regard to the findings and recommendations. Auditors do not produce an opinion; they simply provide a summary of the work performed in connection with the engagement. The IS auditor might provide the following services:
Systems implementation reviews
Enterprise resource-planning implementations
Security reviews (Enterprise, SAP, Oracle, Peoplesoft)
Database application reviews
IT infrastructure and improvements needed for engagements
Project-management reviews
IT internal audit services
The auditor can use the control matrix to assess the proper level of controls. The control matrix is created during the planning stages of the audit and encompasses known errors and known controls to detect errors. During the audit and review, the auditor will find both strong and weak controls, which should all be considered when evaluating the overall structure. A weak control in one area might be compensated for by a stronger control in another area.
In today’s complex IT environment, it is common to find overlapping or compensating controls. IT managers and technical resources frequently employ defense-in-depth strategies, which are based on layered sets of controls that often compensate for each other. It is important for the auditor to recognize the relationship and overall effect of compensating controls before reporting a weakness.
Part of the review pertains to the materiality of the evidence. The question of materiality is based on the auditor’s judgment but should be also based on the determination of what information would be pertinent to the different levels of management that the audit findings and recommendations will be communicated to.
As an example, an access-control weakness on a standalone computer at a remote site will be material to management at that site but might not be material to management at headquarters.
The IS auditor is ultimately responsible to senior management and to the audit committee of the board of directors. Before communicating the results to senior management, the IS auditor should discuss the findings with the management staff of the audited entity to gain agreement on the findings and to develop a course of corrective action.
Because audit reports are the final work product of the audit process, it is imperative that the IS auditor be concerned with the following:
Providing a balanced objective report based on the evidence that is material to the audit
Ensuring that the facts presented in the report are correct
Ensuring that recommendations are feasible and cost-effective
Describing negative issues in conjunction with positive, constructive comments
Focusing on improving processes and controls while reporting on controls already in place
Ensuring independence in the reporting process
The structure and content of the report will vary by organization but will usually have the following parts:
Introduction to the report
Statement of audit objectives
Statement of scope
Period of audit coverage
Statement on the nature and extent of the audit
Statement of procedures examined during the audit
Auditor’s conclusion and opinion
Adequacy of controls and procedures examined during the audit
Auditor’s reservations or qualifications
Statement of whether the controls were adequate or inadequate
Support for the conclusion and overall evidence
Detailed audit findings
Evidence included or not included in the report, based on materiality
A restatement of the guidance provided by upper management
Limitations to the auditor
Any limitations of evidence, access, and so on
Statement of the IS audit guidelines followed
The report might vary, depending on the audience to which it is presented and management guidance with regard to the report. The IS auditor might present findings and recommendations to the auditee, senior management, and the board of directors; in each case, the audit would contain not only a different focus, but possibly subsets of information gathered during the audit.
The audit report should provide specific recommendations to management. As a result of the findings and recommendations, management should create an action plan to implement corrective actions. Keep in mind that resource constraints might prevent management from implementing all the audit recommendations; however, the auditor should obtain a commitment with expected dates for corrective action.
An exit interview should be conducted at the conclusion of the audit. This provides the auditor with an opportunity to discuss the scope and the findings and recommendations of the audit. The exit interview also assures the auditor that the facts presented in the report are correct and that the recommendations are realistic (cost-effective), and establishes the implementation dates for corrective action.
Risk can be defined as the possibility of something adverse happening. Risk management is the process of assessing risk, taking steps to reduce risk to an acceptable level (mitigation), and maintaining that acceptable level of risk. Earlier, this chapter defined the different types of risks, such as business risk and continuity risk. As a part of ongoing IT procedures, a formal risk-management process must be incorporated into the planning, acquisition, development, testing, and deployment of information systems. Organizations can choose to transfer, reject, reduce, or accept risks.
An example of transferring risk occurs when a company or individual purchases insurance. The company might purchase insurance on assets so that, in the event of theft, damage, or destruction, the asset can be replaced or repaired. The insurance might cover most of the asset, or the business might opt to pay a lower annual fee, thereby increasing the deductible on claims. The deductible on the claim would be the organization’s residual risk.
An effective risk-management program should enable the organization to realize its business objectives by doing the following:
Better securing IT systems that store, process, or transmit organizational information
Enabling management to make well-informed risk-management decisions to justify expenditures that are part of the IT budget
Risk management encompasses three processes: risk assessment, risk mitigation, and risk transference.
The risk-assessment process includes identifying information resources or assets that are vulnerable and might need protection. Assets are resources, processes, products, or computer infrastructures that an organization has determined must be protected. Identifying these assets includes prioritizing and might involve mission criticality/sensitivity or asset value. Examples of assets include the following:
Hardware/software
Information/data
Services
Organization documents
Personnel
Intellectual capital
Inventory
Cash
Physical assets (buildings, equipment, and so on)
The next step in the process is defining the threats associated with the asset(s) and the probability of the exercise of vulnerabilities. A vulnerability is a weakness in internal controls that could be exploited by a threat to gain unauthorized access to information or disrupt systems. Threats are defined as a potential danger (hazard) to information systems; the hazard is something that increases the likelihood of loss. Threats can generally be classified as natural, environmental, or manmade; they have the potential to cause such harm to the asset as destruction, disclosure, modification, or disruption. Some common classes of threats can include these:
Natural threats (fire, flood, earthquake, tornado)
Environmental threats (power, smoke, explosion)
Human threats (internal or external)
(Intentional) Hacker, criminal, terrorist, ex-employee
(Accidental) Errors, accidents, misuse
The result of a threat exercising a vulnerability is called an impact; this can result in a loss to the organization’s resources. The impact might be quantitative (direct loss of money, opportunity, disruption) or qualitative (breach of legislation, damage to reputation, endangerment of staff, breach of confidence) and represents either a direct or an indirect loss to the organization.
After the resources, threats, vulnerabilities, and priorities have been established, the organization must determine whether the risk is acceptable; if not, the auditor should identify and evaluate the existing controls. This evaluation determines which controls, if any, should be implemented to further reduce risk or minimize the residual risk. These controls can be actions, devices, procedures, or techniques, and can be measured based on design strength or the likelihood of effectiveness. When evaluating the strength of controls, the IS auditor should consider whether the controls are preventative or detective, manual or programmed, and formal or informal (ad-hoc).
After the organization has applied controls to the resource through transfer or reduction, the remaining risk is called residual risk. The organization’s management can use the presence of residual risk to identify areas that need additional control or less stringent controls (more cost-effective). The organization’s acceptance of residual risk takes into account the organizational policy, risk-management plan and measurement, and the cost-effectiveness of implementing controls.
The objective of risk management is to mitigate risk to an acceptable level. Risk is mitigated, or reduced, by implementing cost-effective controls. IT managers, the steering committee, and auditors should implement a risk-management process with the goal of protecting the organization and its capability to perform its business functions, not just the organization’s IT assets.
Senior management must support risk analysis in the organization for it to be successful. Risk analysis is the process of identifying risk in the organization, quantifying the impact of potential threats, and providing cost/benefit justification for the implementation of controls. The organization must establish the purpose of the risk-management program, which might vary by organization but should include specific objectives such as reducing the cost of insurance in the organization or ensuring that background-screening processes are cost-effective. Clearly defining the purpose of the program enables senior managers to evaluate the results of risk management and determine its effectiveness. Generally, the executive director working with the board of directors defines the purpose for the risk-management program. As with all programs in the organization, the risk-management program must have a person or team charged with developing and implementing the program. The risk-management committee and associated team will be utilized at all levels within the organization and will need the help of the operations staff and board members to identify areas of risk and develop suitable mitigation strategies.
Risk analysis can use either a quantitative approach, which attempts to assign real numbers to the cost of threats and the amount of damage, or a qualitative approach, which uses a ranking method to analyze the seriousness of the threat against the sensitivity of the asset.
As an example of a risk-management process, let’s take a look at the identification of a critical asset, threats, and vulnerabilities, and the review of implementing controls.
The organization has servers located at one of its satellite offices in San Diego, California. The servers are critical to the organization’s business objectives. Although redundant servers and data are available via a redundant facility, the organization wants to ensure that it can resume business operations in San Diego as quickly as possible. The organization has performed a vulnerability assessment of the servers in San Diego. The facility has not been hit by an earthquake, but it wants to identify the likelihood that it will and to identify specific controls to mitigate this risk. As a result of the vulnerability assessment, the organization discovered that a relatively small earthquake (leaving the facility intact) could cause disruption to the servers if the racks topple or are disconnected from the network. For this scenario, we review our summary of the risk equation:
Risk = Threat × Vulnerability × Cost of asset
Threat = Earthquake (5 in the last 15 years large enough to damage the facility or at least move or topple office equipment)
Vulnerability = Annualized rate of occurrence. 15 years ÷ 5 earthquakes = .33 expected earthquakes per year.
Cost of asset = Total hardware (rack + servers) = $35,000 + outage cost per day ($3,000) × 3 days (time to bring up secondary servers) = $9,000 + 35,000 = $42,000
The organization could put in place quite a few controls to mitigate the risk.
It could develop a hot site that contains up-to-date information from the servers in San Diego, at the cost of $125,000 annually. It could implement earthquake-proof controls (earthquake rack-mounting equipment), for a one-time cost of $5,000. The organization could move the servers from San Diego to another satellite office, headquarters, or hosting facility, for a one-time cost of $10,000 and an annual cost of $15,000.
All three solutions would mitigate the risk associated with earthquakes at the San Diego facility, but we will use our equation to identify which is cost-effective:
Threat = (15 ÷ 5) = Vulnerability = .33 × Cost of asset = 42,000 = 13,860
The equation states that the cost of the control should not exceed $13,860 annually, so we can compare this against the cost associated with the hot site ($125,000), the earthquake rack ($12,000), and the server move ($15,000), and readily identify that the earthquake rack-mounting is the most cost-effective control for this threat. Keep in mind that this scenario identifies only one threat and the cost of the control to mitigate that threat. In actuality, the total of all controls for all threats would be compared against the cost of the asset to determine cost-effectiveness.
Risk management is the process that allows IT managers to balance the operational and economic costs of protective measures and achieve gains in mission objectives by protecting the IT systems and data that support their organization’s objectives.
To ensure that the information systems strategy aligns with the organization’s goals, senior IT managers need to effectively communicate with senior management and the business functional areas. In this chapter, we have discussed some of the tools available to IT management and their role in enabling communications throughout the organization. The IT steering committee assists in providing clear guidance to the IT department, to ensure that acquisition and integration activities align with the organizational strategy. In addition, the senior managers of the IT steering committee receive regular status updates on projects in progress, the cost of projects, and issues that impact the critical path of those projects. The change-control board serves as another vehicle of communication to the organization. The change-control board reviews and documents changes at all levels of the IT infrastructure and regularly reviews milestones. In addition, the individual project manager maintains project schedules defining milestones and resources that are being utilized.
IT senior management should use this information to provide both status- and decision-based information for both formal and informal reporting to the organization. IT managers use real-time and historical reporting to show continuous improvement and provide ad-hoc information required by functional business areas to facilitate decision making. The better IT management understands the organization, particularly the individual business functions, the better it can provide timely and effective solutions.
The increased reliance on and integration of IT in business requires IT and senior management to make quicker decisions regarding IT infrastructure. The internal competition among the business functions for IT resources presents challenging and sometimes conflicting priorities. A strong line of communication will help the organization reduce conflict and ensure the efficient use of IT resources.
The term information systems is usually interpreted as the hardware/software and processes that provide data and services. An information system also includes the personnel who implement and maintain information systems. The organization should have organizational policies and procedures for hiring, termination, promotion, and retention. The existence of and adherence to these policies and procedures reduces overall risk for the organization and improves the quality of the staff. An organization that effectively communicates and enforces procedures ensures that the staff is as effective and efficient as possible; in turn, this improves the overall effectiveness and efficiency of information systems.
In addition to internal policies and procedures, organizations must develop policies that ensure compliance with external laws and regulations. Some internal policies might include the following:
Employee handbooks
Company visions and ethics statements
Security policies
Descriptions of employee benefits
Vacation and holiday policies
Rules on overtime
Performance evaluation timelines and procedures
Emergency procedures
When disciplinary actions are taken
To protect itself, the organization should implement controls (hiring practices) to ensure that prospective employees have the skill sets and background necessary to perform the duties outlined in the job description. Some of these controls might include education verification, past job performance, and local and federal criminal checks. Upon hiring, the organization might implement confidentiality agreements or noncompete agreements, or bond employees to protect against losses due to theft, neglect, or errors.
As part of employees’ introduction into the organization, they should be aware of promotion policies, training, required time reporting, and vacation procedures. In addition, the organization should schedule regular formal communication of company policies and procedures. This communication might take the form of required presentations, periodic reviews of all policies by the employees, or formal training.
Written policies relating to vacation and termination are important in reducing business risk. If employees are required to take regular vacations, it allows others to take over duties in their absence and reduces opportunity for that person to commit improper or illegal acts. It might also be possible to discover fraudulent activity, assuming that there is no collusion between employees. A termination policy ensures that, upon employee separation, the assets of the organization are protected. All keys and access badges must be turned in, and login and password information must be suspended or removed. Termination policies should include procedures for both voluntary and involuntary terminations. Involuntary or immediate terminations are an emotional time for the organizational management as well as the employee, and delineating specific procedures ensures that the employee is properly escorted from the premises, that the employee turns in all material owned by the organization, and that staff and security personnel receive notification regarding the employee’s status.
Employees who know specifically what is required from them tend to be happier employees and, therefore, perform better than employees who are unaware of the organization’s policies and procedures. As an IS auditor, you must look for the existence of personnel policies, the frequency of communication, and a formal process for change. While observing and questioning employees, you can determine whether the policies are communicated and observed by employees as they are performing within their functional areas.