CHAPTER 3
The Audit Process
This chapter discusses the following topics:
• Audit management
• ISACA auditing standards, procedures, and guidelines
• Audit and risk analysis
• Internal controls
• Performing an audit
The topics in this chapter represent 10 percent of the CISA examination.
The IS audit process is the procedural structure used by auditors to assess and evaluate the effectiveness of the IT organization and how well it supports the organization’s overall goals and objectives. The audit process is backed up by the framework that is the ISACA code of ethics, ISACA audit standards, guidelines, and audit procedures. This framework is used to ensure that auditors will take a consistent approach from one audit to the next throughout the entire industry. This will help to advance the entire audit profession and facilitate its gradual improvement over time.
Audit Management
An organization’s audit function should be managed so that an audit charter, strategy, and program can be established; audits performed; recommendations enacted; and auditor independence assured throughout. The audit function should align with the organization’s mission and goals, and work well alongside IT governance and operations.
The Audit Charter
As with any formal, managed function in the organization, the audit function should be defined and described in a charter document. The charter should clearly define roles and responsibilities that are consistent with ISACA audit standards and guidelines (including but not limited to ethics, integrity, and independence). The audit function should have sufficient authority that its recommendations will be respected and implemented, but not so much power that the audit tail will wag the IS dog.
The Audit Program
An audit program is the term used to describe the audit strategy and audit plans that include scope, objectives, resources, and procedures used to evaluate a set of controls and deliver an audit opinion. You could say that an audit program is the plan for conducting audits over a given period.
The term “program” in audit program is intended to evoke a similar “big picture” point of view as the term program manager does. A program manager is responsible for the performance of several related projects in an organization. Similarly, an audit program is the plan for conducting several audits in an organization.
Strategic Audit Planning
The purpose of audit planning is to determine the audit activities that need to take place in the future, including an estimate on the resources (budget and manpower) required to support those activities.
Factors that Affect an Audit
Like security planning, audit planning must take into account several factors:
Organization strategic goals and objectives The organization’s overall goals and objectives should flow down to individual departments and their support of these goals and objectives. These goals and objectives will translate into business processes, technology to support business processes, controls for both the business processes and technologies, and audits of those controls. This is depicted in Figure 3-1.
New organization initiatives Closely related to goals and objectives, organizations often embark on new initiatives, whether new products, new services, or new ways of delivering existing products and services.
Market conditions Changes in the product or service market may have an impact on auditing. For instance, in a product or services market where security is becoming more important, market competitors could decide to voluntarily undergo audits in order to show that their products or services are safer or better than the competition’s. Other market players may need to follow suit for competitive parity. Changes in the supply or demand of supply-chain goods or services can also affect auditing.
Changes in technology Enhancements in the technologies that support business processes may affect business or technical controls, which in turn may affect audit procedures for those controls.
Changes in regulatory requirements Changes in technologies, markets, or security-related events can result in new or changed regulations. Maintaining compliance may require changes to the audit program. In the 20-year period preceding the publication of this book, many new information security–related regulations have been passed or updated, including the Gramm-Leach-Bliley Act, the Sarbanes-Oxley Act, the Health Insurance Portability and Accountability Act, as well as U.S. federal and state laws on privacy.
Figure 3-1 Organization goals and objectives translate down into audit activities.
All of the changes listed here usually translate into new business processes or changes in existing business process. Often, this also involves changes to information systems and changes to the controls supporting systems and processes.
Changes in Audit Activities
These external factors may affect auditing in the following ways:
New internal audits Business and regulatory changes sometimes compel organizations to audit more systems or processes. For instance, after passage of the Sarbanes-Oxley Act of 2002, U.S. publicly traded companies had to begin conducting internal audits of those IT systems that support financial business processes.
New external audits New regulations or competitive pressures could introduce new external audits. For example, virtually all banks and many merchants had to begin undergoing external PCI audits when that standard was established.
Increase in audit scope The scope of existing internal or external audits could increase to include more processes or systems.
Impacts on business processes This could take the form of additional steps in processes or procedures, or additions/changes in recordkeeping or record retention.
Resource Planning
At least once per year, management needs to consider all of the internal and external factors that affect auditing to determine the resources required to support these activities. Primarily, resources will consist of budget for external audits and manpower for internal audits.
Additional external audits usually require additional man-hours to meet with external auditors; discuss scope; coordinate meetings with process owners and managers; discuss audits with process owners and managers; discuss audit findings with auditors, process owners, and managers; and organize remediation work.
Internal and external audits usually require information systems to track audit activities and store evidence. Taking on additional audit activities may require additional capacity on these systems.
Additional internal audits require all of the previously mentioned factors, plus time for performing the internal audits themselves. All of these details are discussed in this chapter, and in the rest of this book.
Audit and Technology
ISACA auditing standards require that the auditor retain technical competence. With the continuation of technology and business process innovation, auditors need to continue learning about new technologies, how they support business processes, and how they are controlled. Like many professions, IS auditing requires continuing education to stay current with changes in technology.
Some of the ways that an IS auditor can update their knowledge and skills include:
ISACA training and conferences As the developer of the CISA certification, ISACA offers many valuable training and conference events, including:
Computer Audit, Control, and Security Conference (CACS)
IT Governance, Risk, and Compliance Conference
Information Security and Risk Management Conference
ISACA Training Week
University courses This can include both for-credit and noncredit classes on new technologies. Some universities offer certificate programs on many new technologies; this can give an auditor a real boost of knowledge, skills, and confidence.
Voc-tech training Many organizations offer training in information technologies, including MIS Training Institute, SANS, Intense School, and ISACA.
Training webinars These events are usually focused on a single topic and last from one to three hours. ISACA and many other organizations offer training webinars, which are especially convenient since they require no travel and many are offered at no cost.
ISACA chapter training Many ISACA chapters offer regular training events so that local members can acquire new knowledge and skills where they live.
Other security association training Many other security-related trade associations offer training, including ISSA (International Systems Security Association), SANS Institute (Systems administrations, Audit, Network, Security), and CSI (Computer Security Institute). Training sessions are offered online, in classrooms, and at conferences.
Security conferences Several security-related conferences include lectures and training. These conferences include RSA, SANS, CSI, ISSA, and SecureWorld Expo. Many local ISACA and ISSA chapters organize local conferences that include training.
NOTE CISA certification holders are required to undergo at least 40 hours of training per year in order to maintain their certification. Chapter 1 contains more information on this requirement.
Audit Laws and Regulations
Laws and regulations are one of the primary reasons why organizations perform internal and external audits. Regulations on industries generally translate into additional effort on target companies’ parts to track their compliance. This tracking takes on the form of internal auditing, and new regulations sometimes also require external audits. And while other factors such as competitive pressures can compel an organization to begin or increase auditing activities, this section discusses laws and regulations that require auditing.
Almost every industry sector is subject to laws and regulations that affect organizations’ use of information systems. These laws are concerned primarily with one or more of the following characteristics and uses of information and information systems:
Security Some information in information systems is valuable and/or sensitive, such as financial and medical records. Many laws and regulations require such information to be protected so that it cannot be accessed by unauthorized parties and that information systems be free of defects, vulnerabilities, malware, and other threats.
Integrity Some regulations are focused on the integrity of information to ensure that it is correct and that the systems it resides on are free of vulnerabilities and defects that could make or allow improper changes.
Privacy Many information systems store information that is considered private. This includes financial records, medical records, and other information about people that they feel should be protected.
Automation Brings New Regulation |
Automating business processes with information systems is still a relatively new phenomenon. Modern businesses have been around for the past two or three centuries, but information systems have been playing a major role in business process automation for only about the past 15 years. Prior to that time, most information systems supported business processes but only in an ancillary way. Automation of entire business processes is still relatively young, and so many organizations have messed up in such colossal ways that legislators and regulators have responded with additional laws and regulations to make organizations more accountable for the security and integrity of their information systems. |
Computer Security and Privacy Regulations
This section contains several computer security and privacy laws in the United States, Canada, Europe, and elsewhere. The laws here fall into one or more of the following categories:
Computer trespass Some of these laws bring the concept of trespass forward into the realm of computers and networks, making it illegal to enter a computer or network unless there is explicit authorization.
Protection of sensitive information Many laws require that sensitive information be protected, and some include required public disclosures in the event of a breach of security.
Collection and use of information Several laws define the boundaries regarding the collection and acceptable use of information, particularly private information.
Law enforcement investigative powers Some laws clarify and expand the search and investigative powers of law enforcement.
The consequences of the failure to comply with these laws vary. Some laws have penalties written in as a part of the law; however, the absence of an explicit penalty doesn’t mean there aren’t any! Some of the results of failing to comply include:
Loss of reputation Failure to comply with some laws can make front-page news, with a resulting reduction in reputation and loss of business. For example, if an organization suffers a security breach and is forced to notify customers, word may spread quickly and be picked up by news media outlets, which will help spread the news further.
Loss of competitive advantage An organization that has a reputation for sloppy security may begin to see its business diminish and move to its competitors. A record of noncompliance may also result in a failure to win new business contracts.
Government sanctions Breaking many federal laws may result in sanctions from local, regional, or national governments, including losing the right to conduct business.
Lawsuits Civil lawsuits from competitors, customers, suppliers, and government agencies may be the result of breaking some laws. Plaintiffs may file lawsuits against an organization even if there were other consequences.
Fines Monetary consequences are frequently the result of breaking laws.
Prosecution Many laws have criminalized behavior such as computer trespass, stealing information, or filing falsified reports to government agencies.
Knowledge of these consequences provides an incentive to organizations to develop management strategies to comply with the laws that apply to their business activities. These strategies often result in the development of controls that define required activities and events, plus analysis and internal audit to determine if the controls are effectively keeping the organization in compliance with those laws. While organizations often initially resist undertaking these additional activities, they usually accept them as a requirement for doing business and seek ways of making them more cost-efficient in the long term.
Determining Compliance with Regulations An organization should take a systematic approach to determine the applicability of regulations as well as the steps required to attain compliance and remain in this state.
Determination of applicability often requires the assistance of legal counsel who is an expert on government regulations, as well as experts in the organization who are familiar with the organization’s practices.
Next, the language in the law or regulation needs to be analyzed and a list of compliant and noncompliant practices identified. These are then compared with the organization’s practices to determine which practices are compliant and which are not. Those practices that are not compliant need to be corrected; one or more accountable individuals need to be appointed to determine what is required to achieve and maintain compliance.
Another approach is to outline the required (or forbidden) practices specified in the law or regulation, and then “map” the organization’s relevant existing activities into the outline. Where gaps are found, processes or procedures will need to be developed to bring the organization into compliance.
Regulations Not Always Clear |
Sometimes, the effort to determine what’s needed to achieve compliance is substantial. For instance, when the Sarbanes-Oxley Act was signed into law, virtually no one knew exactly what companies had to do to achieve compliance. Guidance from the Public Company Accounting Oversight Board was not published for almost a year. It took another two years before audit firms and U.S. public companies were familiar and comfortable with the necessary approach to achieve compliance with the Act. |
U.S. Regulations Selected security and privacy laws and standards in the United States include:
Access Device Fraud, 1984
Computer Fraud and Abuse Act of 1984
Electronic Communications Act of 1986
Electronic Communications Privacy Act (ECPA) of 1986
Computer Security Act of 1987
Computer Matching and Privacy Protection Act of 1988
Communications Assistance for Law Enforcement Act (CALEA) of 1994
Economic and Protection of Proprietary Information Act of 1996
Health Insurance Portability and Accountability Act (HIPAA) of 1996
Children’s Online Privacy Protection Act (COPPA) of 1998
Identity Theft and Assumption Deterrence Act of 1998
Gramm-Leach-Bliley Act (GLBA) of 1999
Federal Energy Regulatory Commission (FERC)
Provide Appropriate Tools Required to Intercept and Obstruct Terrorism (PATRIOT) Act of 2001
Sarbanes-Oxley Act of 2002
Federal Information Security Management Act (FISMA) of 2002
Controlling the Assault of Non-Solicited Pornography and Marketing (CAN-SPAM) Act of 2003
California privacy law SB1386 of 2003
Identity Theft and Assumption Deterrence Act of 2003
Basel II, 2004
Payment Card Industry Data Security Standard (PCI-DSS), 2004
North American Electric Reliability Corporation (NERC), 1968/2006
Massachusetts security breach law, 2007
Canadian Regulations Selected security and privacy laws and standards in Canada include:
Interception of Communications, Section 184
Unauthorized Use of Computer, Section 342.1
Privacy Act, 1983
Personal Information Protection and Electronic Documents Act (PIPEDA)
European Regulations Selected security and privacy laws and standards from Europe include:
Convention for the Protection of Individuals with Regard to Automatic Processing of Personal Data, 1981, Council of Europe
Computer Misuse Act (CMA), 1990, UK
Directive on the Protection of Personal Data (95/46/EC), 2003, European Union
Data Protection Act (DPA) 1998, UK
Regulation of Investigatory Powers Act 2000, UK
Anti-Terrorism, Crime, and Security Act 2001, UK
Privacy and Electronic Communications Regulations 2003, UK
Fraud Act 2006, UK
Police and Justice Act 2006, UK
Other Regulations Selected security and privacy laws and standards from the rest of the world include:
Cybercrime Act, 2001, Australia
Information Technology Act, 2000, India
ISACA Auditing Standards
The Information Systems Audit and Control Association (ISACA) has published a code of ethics, a set of IS auditing standards, audit guidelines to help understand the standards, and procedures that can be used when auditing information systems. These are discussed in this section.
ISACA Code of Professional Ethics
Like many professional associations, ISACA has published a code of professional ethics. The purpose of the code is to define principles of professional behavior that are based on the support of standards, compliance with laws and standards, and the identification and defense of the truth.
Audit and IT professionals who earn the CISA certification are required to sign a statement that declares their support of the ISACA code of ethics. If someone who holds the CISA certification is found to be in violation of the code, he or she may be disciplined or lose his or her certification.
Members and ISACA Certification holders shall:
1. Support the implementation of, and encourage compliance with, appropriate standards, procedures and controls for information systems.
2. Perform their duties with due diligence and professional care, in accordance with professional standards and best practices.
3. 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.
4. 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.
5. Maintain competency in their respective fields and agree to undertake only those activities, which they can reasonably expect to complete with professional competence.
6. Inform appropriate parties of the results of work performed; revealing all significant facts known to them.
7. 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.
NOTE The CISA candidate is not expected to memorize the ISACA code of ethics, but is required to understand and be familiar with it.
ISACA Audit Standards
The ISACA audit standards framework defines minimum standards of performance related to security, audits, and the actions that result from audits. This section lists the standards and discusses each.
The full text of these standards is available at www.isaca.org/standards.
S1, Audit Charter
Audit activities in an organization should be formally defined in an audit charter. This should include statements of scope, responsibility, and authority for conducting audits. Senior management should support the audit charter through direct signature or by linking the audit charter to corporate policy.
S2, Independence
Behavior of the IS auditor should be independent of the auditee. The IS auditor should take care to avoid even the appearance of impropriety.
The IS auditor’s placement in the command and control structure of the organization should ensure that the IS auditor can act independently.
S3, Professional Ethics and Standards
The IS auditor should adhere to the ISACA Code of Professional Ethics as well as other applicable standards. The IS auditor should conduct himself with professionalism and due care.
S4, Professional Competence
The IS auditor should possess all of the necessary skills and knowledge that are related to the processes and technologies being audited. The auditor should receive periodic training and continuing education in the practices and technologies that are related to her work.
S5, Planning
The IS auditor should perform audit planning work to ensure that the scope and breadth of auditing is sufficient to meet the organization’s needs. She should develop and maintain documentation related to a risk-based audit process and audit procedures. The auditor should identify applicable laws and develop plans for any required audit activities to ensure compliance.
S6, Performance of Audit Work
IS auditors should be supervised to ensure that their work supports established audit objectives and meets applicable audit standards. IS auditors should obtain and retain appropriate evidence; auditors’ findings should reflect analysis and the evidence obtained. The process followed for each audit should be documented and made a part of the audit report.
S7, Reporting
The IS auditor should develop an audit report that documents the process followed, inquiries, observations, evidence, findings, conclusions, and recommendations from the audit. The audit report should follow an established format that includes a statement of scope, period of coverage, recipient organization, controls or standards that were audited, and any limitations or qualifications. The report should contain sufficient evidence to support the findings of the audit.
S8, Follow-up Activities
After the completion of an audit, the IS auditor should follow up at a later time to determine if management has taken steps to make any recommended changes or apply remedies to any audit findings.
S9, Irregularities and Illegal Acts
IS auditors should have a healthy but balanced skepticism with regard to irregularities and illegal acts: The auditor should recognize that irregularities and/or illegal acts could be ongoing in one or more of the processes that he is auditing. He should recognize that management may or may not be aware of any irregularities or illegal acts.
The IS auditor should obtain written attestations from management that state management’s responsibilities for the proper operation of controls. Management should disclose to the auditor any knowledge of irregularities or illegal acts.
If the IS auditor encounters material irregularities or illegal acts, he should document every conversation and retain all evidence of correspondence. The IS auditor should report any matter of material irregularities or illegal acts to management. If material findings or irregularities prevent the auditor from continuing the audit, the auditor should carefully weigh his options and consider withdrawing from the audit. The IS auditor should determine if he is required to report material findings to regulators or other outside authorities. If the auditor is unable to report material findings to management, he should consider withdrawing from the audit engagement.
S10, IT Governance
The IS auditor should determine if the IT organization supports the organization’s mission, goals, objectives, and strategies. This should include whether the organization had clear expectations of performance from the IT department.
The auditor should determine if the IT organization is compliant with all applicable policies, laws, regulations, and contractual obligations. She should use a risk-based approach when evaluating the IT organization.
The IS auditor should determine if the control environment used in the IT organization is effective and should identify risks that may adversely affect IT department operations.
S11, Use of Risk Assessment in Audit Planning
The IS auditor should use a risk-based approach when making decisions about which controls and activities should be audited and the level of effort expended in each audit. These decisions should be documented in detail to avoid any appearance of partiality.
A risk-based approach does not look only at security risks, but overall business risk. This will probably include operational risk and may include aspects of financial risk.
S12, Audit Materiality
The IS auditor should consider materiality when prioritizing audit activities and allocating audit resources. During audit planning, the auditor should consider whether ineffective controls or an absence of controls could result in a significant deficiency or material weakness.
In addition to auditing individual controls, the auditor should consider the effectiveness of groups of controls and determine if a failure across a group of controls would constitute a significant deficiency or material weakness. For example, if an organization has several controls regarding the management and control of third-party service organizations, failures in many of those controls could represent a significant deficiency or material weakness overall.
S13, Use the Work of Other Experts
An IS auditor should consider using the work of other auditors, when and where appropriate. Whether an auditor can use the work of other auditors depends on several factors, including:
The relevance of the other auditors’ work
The qualifications and independence of the other auditors
Whether the other auditors’ work is adequate (this will require an evaluation of at least some of the other auditors’ work)
Whether the IS auditor should develop additional test procedures to supplement the work of another auditor(s)
If an IS auditor uses another auditor’s work, his report should document which portion of the audit work was performed by the other auditor, as well as an evaluation of that work.
S14, Audit Evidence
The IS auditor should gather sufficient evidence to develop reasonable conclusions about the effectiveness of controls and procedures. The sufficiency and integrity of audit evidence should be evaluated, and this evaluation should be included in the audit report.
Audit evidence includes the procedures performed by the auditor during the audit, the results of those procedures, source documents and records, and corroborating information. Audit evidence also includes the audit report.
ISACA Audit Guidelines
ISACA audit guidelines contain information that helps the auditor understand how to apply ISACA audit standards. These guidelines are a series of articles that clarify the meaning of the audit standards. They cite specific ISACA IS audit standards and COBIT controls, and provide specific guidance on various audit activities. ISACA audit guidelines also provide insight into why each guideline was developed and published.
The full text of these guidelines is available at www.isaca.org/standards.
G1, Using the Work of Other Auditors
Written June 1998, updated March 2008. Clarifies Standard S13, Using the Work of Other Experts, and Standard S6, Performance of Audit Work.
Explores details regarding using the work of other auditors, including assessing their qualifications, independence, relevance, and the level of review required.
G2, Audit Evidence Requirement
Written December 1998, updated May 2008. Clarifies Standard S6, Performance of Audit Work, Standard S9, Irregularities and Illegal Acts, Standard S13, Using the Work of Other Experts, and Standard S14, Audit Evidence.
Provides additional details regarding types of evidence, how evidence can be represented, and selecting and gathering evidence.
G3, Use of Computer-Assisted Audit Techniques (CAATs)
Written December 1998, updated March 2008. Clarifies Standard S6, Performance of Audit Work, Standard S5, Planning, Standard S3, Professional Ethics and Standards, Standard S7, Reporting, and Standard S14, Audit Evidence.
Provides details on the use of CAATs, whose use is increasing. In some information systems, CAATs provide the majority of available evidence. This guideline provides direction on the reliability of CAAT-based evidence, automated and customized test scripts, software tracing and mapping, expert systems, and continuous monitoring.
G4, Outsourcing of IS Activities to Other Organizations
Written September 1999, updated May 2008. Clarifies Standard S1, Audit Charter, Standard S5, Planning, and Standard S6, Performance of Audit Work.
Includes additional granularity for auditing outsourced IS activities, including examination of legal contracts and SLAs and service management.
G5, Audit Charter
Written September 1999, updated February 2008. Clarifies Standard S1, Audit Charter.
Guidance provides additional weight on the need for an audit mandate and additional details on the contents of an audit charter, including purpose, responsibilities, authority, accountability, communication with auditees, and quality assurance. Also includes details on the contents of an engagement letter.
G6, Materiality Concepts for Auditing Information Systems
Written September 1999, updated May 2008. Clarifies Standard S5, Planning, Standard S10, IT Governance, Standard S12, Audit Materiality, and Standard S9, Irregularities and Illegal Acts.
While financial audits can easily focus on materiality, IS audits focus on other topics such as access controls and change management. This guidance includes information on how to determine materiality of audits of IS controls.
G7, Due Professional Care
Written September 1999, updated March 2008. Clarifies Standard S2, Independence, Standard S3, Professional Ethics and Standards, and Standard S4, Professional Competence.
This provides guidance to IS auditors for applying auditing standards and the ISACA Code of Professional Ethics on performance of duties with due diligence and professional care. This guidance helps the IS auditor better understand how to have good professional judgment in difficult situations.
G8, Audit Documentation
Written September 1999, updated March 2008. Clarifies Standard S5, Planning, Standard S6 Performance of Audit Work, Standard S7 Reporting, Standard S12, Audit Materiality, and Standard S13, Using the Work of Other Experts.
This guideline provides considerably more detail on the specific documentation needs for an IS audit. This includes providing additional information regarding the auditor’s assessment methods and retention of audit documents.
G9, Audit Considerations for Irregularities and Illegal Acts
Written March 2000, updated September 2008. Clarifies Standard S3, Professional Ethics and Standards, Standard S5, Planning, Standard S6, Performance of Audit Work, Standard S7, Reporting, and Standard S9, Irregularities and Illegal Acts.
This guideline adds more color to ISACA audit standards for situations that the IS auditor may encounter, including nonfraudulent irregularities, fraud, and illegal acts. The guideline defines additional responsibilities of management and IS auditors when dealing with irregularities and illegal acts.
The guideline also describes the steps in a risk assessment that includes the identification of risks that are related to irregularities and illegal acts. Next, the guideline details the actions that an IS auditor should follow when encountering illegal acts, including internal and external reporting where required by law.
G10, Audit Sampling
Written March 2000, updated August 2008. Clarifies Standard S6, Performance of Audit Work.
This provides guidance on objective, statistically sound sampling techniques, sample design and selection, and evaluation of the sample selection.
G11, Effect of Pervasive IS Controls
Written March 2000, updated August 2008. Clarifies Standard S6, Performance of Audit Work.
Pervasive controls are those general controls that focus on the management and monitoring of information systems. Examples of pervasive controls are:
IS strategy
Software development/acquisition life cycle
Access management
Security administration
Capacity management
Backup and recovery
This guideline helps the auditor understand the pervasive controls that should be a part of every organization’s control framework. The IS auditor needs to determine the set of pervasive controls in her organization—they can be derived from the four COBIT domains: Plan and Organize (PO), Acquire and Implement (AI), Deliver and Support (DS), and Monitor and Evaluate (ME). It is no accident that these match up to the Deming Cycle process of Plan, Do, Check, Act.
G12, Organizational Relationship and Independence
Written September 2000, updated August 2008. Clarifies Standard S2, Independence, and Standard S3, Professional Ethics and Standards.
This guideline expands on the concept and practice of auditor independence so that the auditor can better understand how to apply audit standards and perform audits objectively and independently.
G13, Use of Risk Assessment in Audit Planning
Written September 2000, updated August 2008. Clarifies Standard S5, Planning, and Standard S6, Performance of Audit Work.
This guideline provides direction for the IS auditor to properly determine the risk associated with each control and related activity in the IS organization. Such guidance has been available for financial auditors, but was not readily available to IS auditors until publication of this guideline.
Rather than rely solely on judgment, IS auditors need to use a systematic and consistent approach to establishing the level of risk. The chosen approach should be used as a key input in audit planning.
G14, Application Systems Review
Written November 2001, updated December 2008. Clarifies Standard S6, Performance of Audit Work.
This guideline provides additional information for IS auditors who are performing an application systems review. The purpose of such a review is to identify application risks and evaluate an application’s controls to determine how effectively the application supports the organization’s overall controls and objectives.
G15, Planning
Written March 2002. Clarifies Standard S5, Planning.
This guideline assists the IS auditor in the development of a plan for an audit project by providing additional information found in ISACA audit standard S5. An audit plan needs to take several matters into consideration, including overall business requirements, the objectives of the audit, and knowledge about the organization’s processes and information systems. Levels of materiality should be established and a risk assessment performed, if necessary.
G16, Effect of Third Parties on an Organization’s IT Controls
Written March 2002, updated March 2009. Clarifies Standard S5, Planning, and Standard S6, Performance of Audit Work.
Third-party organizations can become a key component in one or more controls. In situations where an organization outsources key business applications, the third party’s controls for practical purposes supplement the organization’s own controls.
The IS auditor needs to understand how a third-party organization supports the organization’s business objectives. This may require a review of contracts, service level agreements, and other business documents that describe the services that the third-party organization provides.
The auditor will need to review the third party’s controls through reviews of independent audits of another third-party organization. The IS auditor also needs to understand the effects and the risks associated with the use of the third party, and be able to identify countermeasures or compensating controls that will minimize risk.
G17, Effect of Nonaudit Role on the IS Auditor’s Independence
Written July 2002, updated June 2009. Clarifies Standard S2, Independence, and Standard S3, Professional Ethics and Standards.
In many organizations, IS auditors are involved in many nonaudit activities, including security strategy development, implementation of information technologies, software design, development and integration, process development, and implementing security controls. These activities provide additional knowledge and experience, which help the IS auditor better understand how security and technology support the organization. However, some of these activities may adversely affect the IS auditor’s independence and objectivity.
G18, IT Governance
Written July 2002. Clarifies Standard S6, Performance of Audit Work.
Organizations have created a critical dependency upon information technology to conduct business transactions. The role of IT systems is critical to an organization’s goals and objectives. This trend has made IT governance all the more critical to an organization’s success. IS auditors need to have a clear understanding of the role of IT governance when planning and carrying out an audit.
G19, Irregularities and Illegal Acts
This guideline was replaced in September 2008 by Guideline G9, Audit Considerations for Irregularities and Illegal Acts.
G20, Reporting
Written January 2003. Clarifies Standard S7, Reporting.
This guideline describes how an IS auditor should comply with ISACA auditing standards on the development of audit findings, audit opinion, and audit report.
G21, Enterprise Resource Planning (ERP) Systems Review
Written August 2003.
This guideline provides additional information for the IS auditor who is performing a review or audit of enterprise resource planning (ERP) applications and systems. The guideline describes ERP systems and business process reengineering (BPR), and provides considerable detail of audit procedures.
G22, Business-to-Consumer (B2C) E-commerce Review
Written August 2003, updated December 2008. Clarifies Standard S6, Performance of Audit Work.
This guideline provides additional information for the IS auditor who may be performing a review or audit of a business-to-consumer e-commerce application or system. The guideline defines and describes e-commerce systems and describes several areas that should be the focus of an audit. The guideline includes a detailed audit plan and areas of possible risk.
G23, System Development Life Cycle (SDLC) Review
Written August 2003. Clarifies Standard S6, Performance of Audit Work.
This guideline provides IS auditors with additional information regarding audits of the process of defining, acquiring, and implementing applications. This process is commonly known as the systems development life cycle (SDLC).
G24, Internet Banking
Written August 2003. Clarifies Standard S2, Independence, Standard S4, Professional Competence, Standard S5, Planning, and Standard S6, Performance of Audit Work.
This guideline provides IS auditors with detailed information regarding the review and audit of Internet banking applications. The guideline describes Internet banking and includes detailed audit procedures.
G25, Review of Virtual Private Networks
Written July 2004. Clarifies S6, Performance of Audit Work.
This guideline describes virtual private network (VPN) technology and architecture, and provides detailed audit procedures. The guideline includes a description of VPN-related risks.
G26, Business Process Reengineering (BPR) Project Reviews
Written July 2004. Clarifies S6, Performance of Audit Work.
This guideline describes the process of business process reengineering (BPR) and the potentially profound effect it can have on organizational effectiveness. The guideline describes operational risks associated with BPR and includes audit guidelines for BPR projects and their impact on business processes, information systems, and corporate structures.
G27, Mobile Computing
Written September 2004. Clarifies Standard S1, Audit Charter, Standard S4, Professional Competence, Standard S5, Planning, and Standard S6, Performance of Audit Work.
This guideline describes the phenomenon of mobile computing in business operations, the technologies that support mobile computing, the risks associated with mobile computing, and guidance on applying audit standards on mobile computing infrastructures.
G28, Computer Forensics
Written September 2004. Clarifies Standard S3, Professional Ethics and Standards, Standard S4, Professional Competence, Standard S5, Planning, and Standard S6, Performance of Audit Work.
Because of their expertise in security and controls, IS auditors are subject to being asked to assist with investigations of irregularities, fraud, and criminal acts. This guideline defines forensics terms and includes forensics procedures that should be followed in such proceedings.
G29, Post-implementation Review
Written January 2005. Clarifies Standard S6, Performance of Audit Work, and Standard S8, Follow-up Activities.
This guideline includes recommended practices for carrying out a post-implementation review of a new or updated information system. The purpose of a post-implementation review is to measure the effectiveness of the new system.
G30, Competence
Written June 2005. Clarifies Standard S4, Professional Competence.
This guideline provides additional details on the need for an IS auditor to attain and maintain knowledge and skills that are relevant to IS auditing and information technologies in use.
G31, Privacy
Written June 2005. Clarifies Standard S1, Audit Charter, Standard S5, Planning, and Standard S6, Performance of Audit Work.
This guideline provides additional information about privacy so that the IS auditor can properly consider privacy requirements, concerns, and laws during IS audits. The guideline includes details on the approach for personal data protection.
G32, Business Continuity Plan (BCP) Review from IT Perspective
Written September 2005. Clarifies Standard S6, Performance of Audit Work.
This guideline provides recommended practices for the review of business continuity plans and testing of BCP controls. It includes a description of business continuity planning, disaster recovery planning (DRP), and business impact analysis (BIA).
G33, General Considerations on the Use of the Internet
Written March 2006. Clarifies Standard S4, Professional Competence, Standard S5, Planning, and Standard S6, Performance of Audit Work.
This guideline provides detailed information for the IS auditor regarding the use of the Internet in support of business information systems. It includes a description of risks and audit procedures for evaluating controls that include the use of Internet-based resources.
G34, Responsibility, Authority, and Accountability
Written March 2006. Clarifies Standard S1, Audit Charter.
This guideline updates the responsibility, authority, and accountability of IS auditors in light of the advancements in technology and the pervasive use of information technology in support of critical business processes in the time since Standard S1 was originally written.
G35, Follow-up Activities
Written March 2006. Clarifies Standard S8, Follow-up Activities.
This guideline provides additional direction to IS auditors with regard to follow-up activities after an IS audit.
G36, Biometric Controls
Written February 2007. Clarifies Standard S6, Performance of Audit Work, and Standard S10, IT Governance.
This guideline provides additional information about biometric technology, including guidance on reviewing and auditing such technology.
G37, Configuration Management
Written November 2007. Clarifies Standard S6, Performance of Audit Work.
This guideline provides information about auditing configuration management tools and processes, and whether they are effective at making an organization’s IT environment more efficient and stable.
G38, Access Controls
Written February 2008. Clarifies Standard S1, Audit Charter, and Standard S3, Professional Ethics and Standards.
This guideline provides additional guidance on the audit of access controls and how they protect an organization’s assets from disclosure and abuse.
G39, IT Organization
Written May 2008. Clarifies Standard S10, IT Governance.
This guideline provides additional information to the IS auditor regarding the audit and review of IT governance. It describes the common themes that exist among most IT organizations, as well as the typical differences between them. This information can assist an IS auditor by describing the common attributes of IT organizations.
G40, Review of Security Management Practices
Written December 2008. Clarifies Standard S1, Audit Charter, and Standard S3, Professional Ethics and Standards.
This guideline provides additional guidance to IS auditors who are reviewing and auditing an organization’s security management practices. Information is a key asset in many organizations, and the protection of that information is vital to the organization’s survival. Security management provides the framework for that protection.
ISACA Audit Procedures
ISACA audit procedures contain information that helps the auditor understand how to audit different types of technologies and processes. While auditors are not required to follow these procedures, they provide insight into how technologies and processes can be audited effectively.
The full text of these procedures is available at www.isaca.org/standards.
P1, Risk Assessment
Written July 2002.
This procedure defines the IS audit risk assessment as a methodology used to optimize the allocation of IS audit resources through an understanding of the organization’s IS environment and the risks associated with each aspect or component in the environment. In other words, it is a method for identifying where the highest risks are so that IS auditors can concentrate their audit activities on those areas.
The procedure describes a detailed scoring-based methodology that can be used to objectively identify areas of highest risk. It includes several example risk assessments to illustrate the methodology in action. The examples include listings of risk factors, weighting, and scoring to arrive at a total risk ranking for components in the environment.
P2, Digital Signature and Key Management
Written July 2002.
This procedure describes the evaluation of a certificate authority (CA) business function. It defines key terms and includes detailed checklists on the key characteristics of a CA that must be examined in an audit. The procedure considers business attributes, technology and its management, and whether the CA has had any prior audits. The areas examined are organizational management, certification and accreditation, technology architecture, and operations management. Each area includes a checklist of procedures to be completed by the auditor.
P3, Intrusion Detection Systems (IDS) Review Procedure
Written August 2003.
This procedure describes the function of an intrusion detection system, its purpose, and benefits. Both host-based and network-based IDS systems are described in detail. The procedure includes a detailed list of attributes to examine during an audit.
P4, Viruses and Other Malicious Code
Written August 2003.
This is a detailed procedure for assessing an organization’s antivirus and anti-mal-ware business and technical controls. Also included is a procedure for end users to follow if they suspect a malware infection on their workstation.
P5, Control Risk Self-Assessment
Written August 2003.
This is a detailed control risk self-assessment (CRSA) procedure. This is a process that is used to identify risks and mitigate them through the implementation of controls. While a CRSA is not a substitute for an external audit, it does help the organization focus inward, identify risk areas, and develop solutions to reduce risk. This helps an organization take responsibility for identifying and mitigating areas of risk.
P6, Firewalls
Written August 2003.
This procedure includes a detailed description of the types of firewalls, how they function, and how they are configured. Also covered are detailed descriptions of network address translation (NAT), virtual private networks (VPNs), and network architecture that is related to firewalls. The procedure also includes detailed steps to audit a firewall, including its configuration and its operation.
P7, Irregularities and Illegal Acts
Written November 2003.
This audit procedure helps the IS auditor assess the likelihood that irregularities could occur in business processes. Irregularities could include errors, illegal acts, and fraud. This procedure contains a detailed list of analytical procedures and computer-assisted audit procedures that can detect irregularities. It contains examples of irregularities and procedures for reporting irregularities, or conditions that could permit them.
P8, Security Assessment—Penetration Testing and Vulnerability Analysis
Written September 2004.
This procedure document contains detailed information for IS auditors and other security professionals who are responsible for performing penetration tests and vulnerability analyses. The procedure includes detailed discussions and checklists for external penetration testing, internal penetration testing, tests of physical access controls, social engineering, wireless network assessments, war dialing, manual and automated scans of web-based applications, and vulnerability assessments. The procedure also contains guidance on report preparation.
P9, Evaluation of Management Controls over Encryption Methodologies
Written January 2005.
This procedure contains a thorough description of encryption technology, including discussions of symmetric key cryptography, public key cryptography, and one-way hashing. The procedure includes risk assessment on the use of encryption, a discussion on the common uses and applications of encryption, laws and regulations on the use of encryption, and a detailed audit procedure.
P10, Business Application Change Control
Written October 2006.
This procedure describes and details the purpose and phases of the systems development life cycle (SDLC) and includes detailed procedures for auditing change control procedures.
P11, Electronic Funds Transfer
Written May 2007.
This procedure describes the electronic funds transfer (EFT) system in detail and includes an EFT risk assessment and detailed audit procedures.
Relationship Between Standards, Guidelines, and Procedures |
The ISACA audit standards, guidelines, and procedures have all been written to assist IS auditors with audit- and risk-related activities. They are related to each other in this way: |
|
|
|
Risk Analysis
In the context of an audit, risk analysis is the activity that is used to determine the areas that warrant additional examination and analysis.
In the absence of a risk analysis, an IS auditor is likely to follow his or her “gut instinct” and apply additional scrutiny in areas where they feel risks are higher. Or, an IS auditor might give all areas of an audit equal weighting, putting equal resources into low-risk areas and high-risk areas. Either way, the result is that an IS auditor’s focus is not necessarily on the areas where risks really are higher.
Auditors’ Risk Analysis and the Corporate Risk Management Program
A risk analysis that is carried out by IS auditors is distinct and separate from risk analysis that is performed as part of the IS risk management program. Often, these are carried out by different personnel and for somewhat differing reasons. A comparison of IS auditor and IS management risk analysis is shown in Table 3-1.
In Table 3-1, I am not attempting to show a polarity of focus and results, but instead a tendency for focus based on the differing missions and objectives for IS audit and IS management.
Evaluating Business Processes
The first phase of a risk analysis is an evaluation of business processes. The purpose of evaluating business processes is to determine the purpose and importance of business activities. While a risk analysis may focus on technology, remember that technology exists to support business processes, not the other way around.
Table 3-1 Comparison of IS Audit and IS Management Risk Analysis
When a risk analysis starts with a focus on business processes, it is possible to consider the entire process and not just the technology that supports it. When examining business processes, it is important to obtain all available business process documentation, including:
Charter or mission statement Often, an organization will develop and publish a high-level document that describes the process in its most basic terms. This usually includes the reason that the process exists and how it contributes to the organization’s overall goals and objectives.
Process architecture A complex process may have several procedures, flows of information (whether in electronic form or otherwise), internal and external parties that perform functions, assets that support the process, and the locations and nature of records. In a strictly IT-centric perspective, this would be a data flow diagram or an entity-relationship diagram, but starting with either of those would be too narrow a focus. Instead, it is necessary to look at the entire process, with the widest view of its functions and connections with other processes and parties.
Procedures Looking closer at the process will reveal individual procedures—documents that describe the individual steps taken to perform activities that are part of the overall process. Procedure documents usually describe who (if not by name, then by title or department) performs what functions with what tools or systems. Procedures will cite business records that might be faxes, reports, databases, phone records, application transactions, and so on.
Records Business records contain the events that take place within a business process. Records will take many forms, including faxes, computer reports, electronic worksheets, database transactions, receipts, canceled checks, and e-mail messages.
Information system support When processes are supported by information systems, it is necessary to examine all available documents that describe information systems that support business processes. Examples of documentation are architecture diagrams, requirements documents (which were used to build, acquire, or configure the system), computer-run procedures, network diagrams, database schemas, and so on.
Once the IS auditor has obtained business documents and records, she can begin to identify and understand any risk areas that may exist in the process.
Identifying Business Risks
The process of identifying business risks is partly analytical and partly based on the auditor’s experience and judgment. An auditor will usually consider both within the single activity of risk identification.
An auditor will usually perform a threat analysis to identify and catalog risks. A threat analysis is an activity whereby the auditor considers a large body of possible threats and selects those that have some reasonable possibility of occurrence, however small. In a threat analysis, the auditor will consider each threat and document a number of facts about each, including:
Probability of occurrence This may be expressed in qualitative (high, medium, low) or quantitative (percentage or number of times per year, for example) terms. The probability should be as realistic as possible, recognizing the fact that actuarial data on business risk is difficult to obtain and more difficult to interpret. Here, an auditor’s judgment is required to establish a reasonable probability.
Impact This is a short description of the results if the threat is actually realized. This is usually a short description, from a few words to a couple of sentences.
Loss This is usually a quantified and estimated loss should the threat actually occur. This figure might be a loss of revenue per day (or week or month) or the replacement cost for an asset, for example.
Possible mitigating controls This is a list of one or more countermeasures that can reduce the probability or the impact of a threat, or both.
Countermeasure cost and effort The cost and effort to implement each countermeasure should be identified, either with a high-medium-low qualitative figure or a quantitative estimate.
Updated probability of occurrence With each mitigating control, a new probability of occurrence should be cited. A different probability, one for each mitigating control, should be specified.
Updated impact With each mitigating control, a new impact of occurrence should be described. For certain threats and countermeasures, the impact may be the same, but for some threats, it may be different. For example, for a threat of fire, a mitigating control may be an inert gas fire suppression system. The new impact (probably just downtime and cleanup) will be much different from the original impact (probably water damage from a sprinkler system).
The auditor will put all of this information into a chart (or electronic spreadsheet) to permit further analysis and the establishment of conclusions—primarily, which threats are the most likely to occur and which ones have the greatest potential impact on the organization.
NOTE The risk analysis method described here is no different from the risk analysis that takes place during the business impact assessment phase in a disaster recovery project, covered in Chapter 7.
NOTE The establishment of a list of threats, along with their probability of occurrence and impact, depends heavily on the experience of the IS auditor and the resources available to him.
Risk Mitigation
The actual mitigation of risks identified in the risk assessment is the implementation of one or more of the countermeasures found in the risk assessment. In simple terms, mitigation could be as easy as a small adjustment in a process or procedure, or a major project to introduce new controls in the form of system upgrades, new components, or new procedures.
When the IS auditor is conducting a risk analysis prior to an audit, risk mitigation may take the form of additional audit scrutiny on certain activities during the audit. An area that the auditor identified as high risk could end up performing well, while other lower-risk areas could actually be the cause of control failures.
Additional audit scrutiny could take several forms, including:
More time spent in inquiry and observation
More personnel interviews
Higher sampling rates
Additional tests
Reperformance of some control activities to confirm accuracy or completeness
Corroboration interviews
Countermeasures Assessment
Depending upon the severity of the risk, mitigation could also take the form of additional (or improved) controls, even prior to (or despite the results of) the audit itself. The new or changed control may be major or minor, and the time and effort required to implement it could range from almost trivial to a major project.
The cost and effort required to implement a new control (or whatever the countermeasure is that is designed to reduce the probability or impact of a threat) should be determined before it is implemented. It probably does not make sense to spend $10,000 to protect an asset worth $100.
NOTE The effort required to implement a control countermeasure should be commensurate with the level of risk reduction expected from the countermeasure. A quantified risk analysis may be needed if the cost and effort seem high, especially when compared to the value of the asset being protected.
Monitoring
After countermeasures are implemented, the IS auditor will need to reassess the controls through additional testing. If the control includes any self-monitoring or measuring, the IS auditor should examine those records to see if there is any visible effect of the countermeasures.
The auditor may need to reperform audit activities to determine the effectiveness of countermeasures. For example, additional samples selected after the countermeasure is implemented can be examined and the rate of exceptions compared to periods prior to the countermeasure’s implementation.
Internal Controls
The policies, procedures, mechanisms, systems, and other measures designed to reduce risk are known as internal controls. An organization develops controls to ensure that its business objectives will be met, risks will be reduced, and errors will be prevented or corrected.
Controls are used in two primary ways in an organization: They are created to achieve desired events, and they are created to avoid unwanted events.
Control Classification
Several types, classes, and categories of controls are discussed in this section. Figure 3-2 depicts this control classification.
Types of Controls
The three types of controls are physical, technical, and administrative.
Physical These types of controls exist in the tangible, physical world. Examples of physical controls are video surveillance, bollards, and fences.
Technical These controls are implemented in the form of information systems and are usually intangible. Examples of technical controls include encryption, computer access controls, and audit logs.
Administrative These controls are the policies and procedures that require or forbid certain activities. An example administrative control is a policy that forbids personal use of information systems.
Figure 3-2 Control classification shows types, classes, and categories of controls
Classes of Controls
There are six classes of controls.
Preventive This type of control is used to prevent an unwanted event. Examples of preventive controls are computer login screens (which prevent unauthorized persons from accessing information), keycard systems (which prevent unauthorized persons from entering a building or workspace), and encryption (which prevent persons lacking an encryption key from reading encrypted data).
Detective This type of control is used to record both wanted and unwanted events. A detective control cannot enforce an activity (whether it is desired or undesired), but instead it can only make sure that it is known that the event occurred. Examples of detective controls include video surveillance and audit logs.
Deterrent This type of control exists in order to convince someone that they should not perform some unwanted activity. Examples of deterrent controls include guard dogs, warning signs, and visible video surveillance cameras and monitors.
NOTE Auditors and security professionals usually prefer preventive controls over detective controls because they actually block unwanted events and prefer detective controls to deterrent controls because detective controls record events while deterrent controls do not. However, there are often circumstances where cost, resource, or technical limitations force an organization to accept a detective control when it would prefer a preventive one. For example, there is no practical way to build a control that would prevent criminals from entering a bank, but a detective control (security cameras) would record anything they did.
Corrective This type of control occurs after some unwanted event has occurred. An example corrective control is the act of improving a process when it was found to be defective.
Compensating This type of control is enacted because some other direct control cannot be used. For example, a video surveillance system can be a compensating control when it is implemented to compensate for the lack of a stronger detective control, such as a keycard access system.
Recovery This type of control is used to restore the state of a system or asset to its pre-incident state. An example recovery control is the use of a tool to remove a virus from a computer.
NOTE Many controls can be classified in more than one class. For example, a video surveillance camera can be thought of as both a detective control (because it is part of a system that records events) and a deterrent control (because its visibility is designed to discourage persons from committing unwanted acts). Also, an audit log can be thought of as both a detective and a compensating control—detective because it records events and compensating because it may compensate for a lack of a stronger, preventive control, such as a user IDs and password access control.
Categories of Controls
There are two categories of controls.
Automatic This type of control performs its function with little or no human judgment or decision making. Examples of automatic controls include a login page on an application that cannot be circumvented and a security door that automatically locks after someone walks through the doorway.
Manual This type of control requires a human to operate it. A manual control may be subject to a higher rate of errors than an automatic control. An example of a manual control is a monthly review of computer users.
NOTE IS auditors and security professionals often prefer automatic controls to manual ones, as they are typically less prone to error. However, there are often circumstances where an organization must settle for a manual control because of cost or other factor.
Internal Control Objectives
Internal control objectives are statements of desired states or outcomes from business operations. Example control objectives include:
Protection of IT assets
Accuracy of transactions
Confidentiality and privacy
Availability of IT systems
Controlled changes to IT systems
Compliance with corporate policies
Control objectives are the foundation for controls. For each control objective, there will be one or more controls that exist to ensure the realization of the control objective. For example, the “Availability of IT Systems” control objective will be met with several controls. including:
IT systems will be continuously monitored, and any interruptions in availability will result in alerts sent to appropriate personnel
IT systems will have resource-measuring capabilities.
IT management will review capacity reports monthly and adjust resources accordingly.
IT systems will have anti-malware controls that are monitored by appropriate staff.
Together, these four (or more) controls contribute to the overall control objective on IT system availability. Similarly, the other control objectives will have one or more controls that will ensure their realization.
NOTE CISA candidates are not required to memorize COBIT or other frameworks, but familiarity with them will help the CISA candidate to better understand how they contribute to effective IT governance and control.
IS Control Objectives
IS control objectives resemble ordinary control objectives but are set in the context of information systems. Examples of IS control objectives include:
Protection of information from unauthorized personnel
Protection of information from unauthorized modification
Integrity of operating systems
Controlled and managed changes to information systems
Controlled and managed development of application software
The COBIT Controls Framework |
To ensure that IT is aligned with business objectives, the COBIT (Control Objectives for Information and related Technology) controls framework of four domains and 34 processes is an industry-wide standard. The four domains are Plan and Organize, Acquire and Implement, Deliver and Support, and Monitor and Evaluate. |
COBIT contains more than 200 detailed control objectives to support these domains and processes. |
Established in 1996 by ISACA and the IT Governance Institute, COBIT is the result of industry-wide consensus by managers, auditors, and IT users. Today, COBIT is accepted as a best-practices IT process and control framework. |
An organization will probably have several additional IS control objectives on other basic topics such as malware, availability, and resource management.
Like ordinary control objectives, IS control objectives will be supported by one or more controls.
General Computing Controls
An IS organization supporting many applications and services will generally have some controls that are specific to each individual application. However, IS will also have a set of controls that apply across all applications and services. These are usually called its general computing controls, or GCCs.
An organization’s GCCs are general in nature and are often implemented in different ways on different information systems, based upon their individual capabilities and limitations. Examples of GCCs include:
Applications require unique user IDs and strong passwords.
Passwords are encrypted while stored and transmitted, and are not displayed.
Highly sensitive information, such as bank account numbers, is encrypted when stored and transmitted.
All administrative actions are logged, and logs are protected from tampering.
Readers who are familiar with information systems technology will quickly realize that these GCCs will be implemented differently across different types of information systems. Specific capabilities and limitations, for example, will result in somewhat different capabilities for password complexity and data encryption. Unless an organization is using really old information systems, the four GCCs shown here can probably be implemented everywhere in the IS environment. How they are implemented is the subject of the next section.
IS Controls
The GCCs discussed in the previous section are implemented across a variety of information technologies. Each general computing control is mapped to a specific IS control on each system type, where it is implemented. In other words, IS controls describe the implementation details for GCCs.
For example, a GCC for password management can be implemented through several IS controls—one for each type of technology platform in use in the organization: one for Windows servers, one for Linux servers, and one for each application that performs its own access management. Those specific IS controls would describe implementation details that reflect the capabilities and limitations of each respective platform.
Performing an Audit
An audit is a systematic and repeatable process whereby a competent and independent professional evaluates one or more controls, interviews personnel, obtains and analyzes evidence, and develops a written opinion on the effectiveness of the controls.
An IS audit, then, is an audit of information systems and the processes that support them. An IS auditor interviews personnel, gathers and analyzes evidence, and delivers a written opinion on the effectiveness of controls implemented in information systems.
An auditor cannot just begin an audit. Formal planning is required that includes:
Purpose The IS auditor and the auditee must establish a reason why an audit is to be performed. The purpose for a particular audit could be to determine the level of compliance to a particular law, regulation, standard, or contract. Another reason could be to determine whether specific control deficiencies identified in past audits have been remediated. Still another reason is to determine the level of compliance to a new law or standard that the organization may be subject to in the future.
Scope The auditor and the auditee must also establish the scope of the audit. Often, the audit’s purpose will make the scope evident, but not always. Scope may be multidimensional: It could be a given period, meaning records spanning a start date and end date may comprise the body of evidence, geography (systems in a particular region or locale), technology (systems using a specific operating system, database, application, or other aspect), business process (systems that support specific processes such as accounting, order entry, or customer support), or segment of the organization.
Risk analysis To know which areas require the greatest amount of attention, the IS auditor needs to be familiar with the levels of risk associated with the domain being audited. Two different perspectives of risk may be needed: First, the IS auditor needs to know the relative levels of risk among the different aspects of the domain being audited so that audit resources can be allocated accordingly. For example, if the audit is on an ERP system and the auditor knows that the accounts receivable function has been problematic in the past, the IS auditor will probably want to devote more resources and time on the accounts receivable function than on others. Second, the IS auditor needs to know about the absolute level of risk across the entire domain being audited. For example, if this is an audit to determine compliance to new legislation, the overall risk could be very high if the consequences of noncompliance are high. Both aspects of risk enable the IS auditor to plan accordingly.
Audit procedures The purpose and scope of the audit may help to define the procedures that will be required to perform the audit. For a compliance audit, for example, there may be specific rules on sample sizes and sampling techniques, or it may require the auditors with specific qualifications to perform the audit. A compliance audit may also specify criteria for determining if a particular finding constitutes a deficiency or not. There may also be rules for materiality.
Resources The IS auditor must determine what resources are needed and available for the audit. In an external audit, the auditee (which is a client organization) may have a maximum budget figure available. For an external or internal audit, the IS auditor needs to determine the number of man-hours that will be required in the audit and the various skills required. Other resources that may be needed include specialized tools to gather or analyze information obtained from information systems—for example, an analysis program to process the roles and permissions in a database management system in order to identify high-risk areas. To a great degree, the purpose and scope of the audit will determine which resources are required to complete it.
Schedule The IS auditor needs to develop an audit schedule that will give enough time for interviews, data collection and analysis, and report generation. However, the schedule could also come in the form of a constraint, meaning the audit must be complete by a certain date. If the IS auditor is given a deadline, he will need to see how the audit activities can be made to fit within that period. If the date is too aggressive, the IS auditor will need to discuss the matter with the auditee to make required adjustments in scope, resources, or schedule.
Appendix A is devoted to a pragmatic approach to conducting audits.
Audit Objectives
The term audit objectives refers to the specific goals for an audit. Generally, the objective of an audit is to determine if controls exist and are effective in some specific aspect of business operations in an organization.
Depending on the subject and nature of the audit, the auditor may examine the controls and related evidence herself, or the auditor may instead focus on the business content that is processed by the controls. In other words, if the focus of an audit is an organization’s accounting system, the auditor may focus on financial transactions in the system to see how they affect financial bookkeeping. Or, the auditor could focus on the IS processes that support the operation of the financial accounting system. Formal audit objectives should make such a distinction so that the auditor has a sound understanding of the objectives.
Types of Audits
The scope, purpose, and objectives of an audit will determine the type of audit that will be performed. IS auditors need to understand each type of audit, including the procedures that are used for each.
Operational audit This type of audit is an examination of IS controls, security controls, or business controls to determine control existence and effectiveness. The focus of an operational audit is usually the operation of one or more controls, and it could concentrate on the IS management of a business process or on the business process itself. The scope of an operational audit is shaped to meet audit objectives.
Financial audit This type of audit is an examination of the organization’s accounting system, including accounting department processes and procedures. The objective of a financial audit is to determine if business controls are sufficient to ensure the integrity of financial statements.
Integrated audit This type of audit combines an operational audit and a financial audit in order for the auditor to gain a complete understanding of the entire environment’s integrity. Such an audit will closely examine accounting department processes, procedures, and records, as well as the IS applications that support the accounting department. Virtually every organization uses a computerized accounting system for management of its financial records; the computerized accounting system and all of the supporting infrastructure (database management system, operating system, networks, workstations, and so on) will be examined to see if the IS department has the entire environment under adequate control.
IS audit This type of audit is a detailed examination of most or all of an IS department’s operations. An IS audit looks at IT governance to determine if IS is aligned with overall organization goals and objectives. The audit also looks closely at all of the major IS processes, including service delivery, change and configuration management, security management, systems development life cycle, business relationship and supplier management, and incident and problem management. This audit will determine if each control objective and control is effective and operating properly.
Administrative audit This type of audit is an examination of operational efficiency within some segment of the organization.
Compliance audit This type of audit is performed to determine the level and degree of compliance to a law, regulation, standard, or internal control. If a particular law or standard requires an external audit, the compliance audit may have to be performed by approved or licensed external auditors; for example, a U.S. public company financial audit must be performed by a public accounting firm, and a PCI audit must be performed by a licensed QSA (qualified security assessor). If, however, the law or standard does not explicitly require audits, the organization may still wish to perform one-time or regular audits to determine the level of compliance to the law or standard. This type of audit may be performed by internal or external auditors, and typically is performed so that management has a better understanding of the level of compliance risk.
Forensic audit This type of audit is usually performed by an IS auditor or a forensic specialist in support of an anticipated or active legal proceeding. In order to withstand cross-examination and to avoid having evidence being ruled inadmissible, strict procedures must be followed in a forensic audit, including the preservation of evidence and a chain of custody of evidence.
Service provider audit Because many organizations outsource critical activities to third parties, often these third-party service organizations will undergo one or more external audits in order to increase customer confidence in the integrity of the third-party organization’s services. In the United States, a Statement of Accounting Standards No. 70 (abbreviated SAS70) audit can be performed on a service provider’s operations, and the audit report transmitted to customers of the service provider. The SAS70 standard was developed by the American Institute of Certified Public Accountants (AICPA) for the purpose of auditing third-party service organizations that perform financial services on behalf of their customers.
Pre-audit While not technically an audit, a pre-audit is an examination of business processes, IS systems, and business records in anticipation of an upcoming external audit. Usually, an organization will undergo a pre-audit in order to get a better idea of its compliance to a law, regulation, or standard prior to an actual compliance audit. An organization can use the results of a pre-audit to implement corrective measures, thereby improving the outcome of the real audit.
Compliance vs. Substantive Testing
It is important for IS auditors to understand the distinction between compliance testing and substantive testing. These two types of testing are defined here.
Compliance testing This type of testing is used to determine if control procedures have been properly designed and implemented, and that they are operating properly. For example, an IS auditor might examine business processes, such as the systems development life cycle, change management, or configuration management, to determine if information systems environments are properly managed.
Substantive testing This type of testing is used to determine the accuracy and integrity of transactions that flow through processes and information systems. For instance, an IS auditor may create test transactions and trace them through the environment, examining them at each stage until their completion.
IS audits sometimes involve both compliance testing and substantive testing. The audit objectives that are established will determine if compliance testing, substantive testing, or both will be required.
Audit Methodology
An audit methodology is the set of audit procedures that are used to accomplish a set of audit objectives. An organization that regularly performs audits should develop formal methodologies so that those audits are performed consistently, even when carried out by different personnel.
The phases of a typical audit methodology are described in the remainder of this section.
Audit Subject
Determine the business process, information system, or other domain to be audited.
Audit Objective
Identify the purpose of the audit. For example, this may be an audit that is required by a law, regulation, standard, or business contract. Or this may be an audit to determine compliance with internal control objectives to measure control effectiveness.
Type of Audit
Identify the type of audit that is to be performed. This may be an operational audit, financial audit, integrated audit, administrative audit, compliance audit, forensic audit, or a security provider audit.
Audit Scope
The business process, department, or application that is the subject of the audit needs to be identified. Usually, a span of time needs to be identified as well so that activities or transactions during that period can be examined.
Pre-Audit Planning
Here, the auditor needs to obtain information about the audit that will enable her to establish the audit plan. Information needed includes:
Location(s) that need to be visited
A list of the applications to be examined
The technologies supporting each application
Policies, standards, and diagrams that describe the environment
This and other information will enable the IS auditor to determine the skills required to examine and evaluate processes and information systems. The IS auditor will be able to establish an audit schedule and will have a good idea of the types of evidence that are needed. The IS audit may be able to make advance requests for certain other types of evidence even before the on-site phase of the audit begins.
Audit Statement of Work
For an external audit, the IS auditor may need to develop a statement of work or engagement letter that describes the audit purpose, scope, duration, and costs. The auditor may require a written approval from the client before audit work can officially begin.
Establish Audit Procedures
Using information obtained regarding audit objectives and scope, the IS auditor can now develop procedures for this audit. For each objective and control to be tested, the IS auditor can specify:
A list of people to interview
Inquiries to make during each interview
Documentation (policies, procedures, and other documents) to request during each interview
Audit tools to use
Sampling rates and methodologies
How and where evidence will be archived
How evidence will be evaluated
Communication Plan
The IS auditor will develop a communication plan in order to keep the IS auditor’s management, as well as the auditee’s management, informed throughout the audit project. The communication plan may contain one or more of the following:
A list of evidence requested, usually in the form of a PBC (provided by client) list, which is typically a worksheet that lists specific documents or records and the names of personnel who can provide them (or who provided them in a prior audit).
Regular written status reports that include activities performed since the last status report, upcoming activities, and any significant findings that may require immediate attention.
Regular status meetings where audit progress, issues, and other matters may be discussed in person or via conference call.
Contact information for both IS auditor and auditee so that both parties can contact each other quickly if needed.
Report Preparation
The IS auditor needs to develop a plan that describes how the audit report will be prepared. This will include the format and the content of the report, as well as the manner in which findings will be established and documented.
The IS auditor will need to make sure that the audit report complies with all applicable audit standards, including ISACA IS audit standards.
If the audit report requires internal review, the IS auditor will need to identify the parties that will perform the review, and make sure that they will be available at the time when the IS auditor expects to complete the final draft of the audit report.
Wrap-up
The IS auditor needs to perform a number of tasks at the conclusion of the audit, including the following:
Deliver the report to the auditee.
Schedule a closing meeting so that the results of the audit can be discussed with the auditee and so that the IS auditor can collect feedback.
For external audits, send an invoice to the auditee.
Collect and archive all work papers.
Update PBC documents if the IS auditor anticipates that the audit will be performed again in the future.
Collect feedback from the auditee and convey to any audit staff as needed.
Post-audit Follow-up
After a given period (which could range from days to months), the IS auditor should contact the auditee to determine what progress the auditee has made on the remediation of any audit findings. There are several good reasons for doing this:
It establishes a tone of concern for the auditee organization and an interest that the auditee is taking the audit process seriously.
It helps to establish a dialogue whereby the auditor can help auditee management work through any needed process or technology changes as a result of the audit.
It helps the auditor better understand management’s commitment to the audit process and to continuous improvement.
For an external auditor, it improves goodwill and the prospect for repeat business.
NOTE An audit methodology is a process. Like any process, it should be documented end-to-end and process documents reviewed from time to time.
Audit Evidence
Evidence is the information collected by the auditor during the course of the audit project. The contents and reliability of the evidence obtained is used by the IS auditor to reach conclusions on the effectiveness of controls and control objectives. The IS auditor needs to understand how to evaluate various types of evidence and how (and if) it can be used to support audit findings.
The auditor will collect many kinds of evidence during an audit, including:
Observations
Written notes
Correspondence
Internal process and procedure documentation
Business records
When the IS auditor examines evidence, he needs to consider several characteristics about the evidence, which will contribute to its weight and reliability. These characteristics include the following:
Independence of the evidence provider The IS auditor needs to determine the independence of the party providing evidence. She will place more weight on evidence provided by an independent party than upon evidence provided by the party being audited. For instance, phone and banking records obtained directly from those respective organizations will be given more credence than an organization’s own records (unless original statements are also provided).
Qualifications of the evidence provider The IS auditor needs to take into account the qualifications of the person providing evidence. This is particularly true when evidence is in the form of highly technical information, such as source code or database extracts. The quality of the evidence will rest partly upon the evidence provider’s ability to explain the source of the evidence and how it was produced. Similarly, the qualifications of the auditor comes into play, as he will similarly need to be able to thoroughly understand the nature of the evidence and be familiar enough with the technology to be able to determine its veracity.
Objectivity Objective evidence may be considerably more reliable than subjective evidence. An audit log, for instance, is quite objective, whereas an auditee’s or auditor’s opinion of the audit log is less objective.
Timing The IS auditor needs to understand the availability of evidence in the systems being audited. Certain log files, extract files, debug files, and temporary files that may be of value during the examination of the system may be available only for short periods before they are recycled or removed. Often, intermediate files are not backed up or retained for long periods. When an IS auditor is tracing transactions through a system during substantive testing, she will need to understand early on what files or intermediate data should be retrieved so that she can later analyze the data after those intermediate files have been cycled out.
NOTE The IS auditor needs to gain a thorough understanding of the sufficiency of evidence gathered using ISACA audit standards S6, Performance of Audit Work, and S14, Audit Evidence.
Gathering Evidence
The IS auditor must understand and be experienced in the methods and techniques used to gather evidence during an audit. The methods and techniques used most often in audits include:
Organization chart review The IS auditor should request a current “org chart,” as well as the job descriptions of key personnel. This will help the auditor to understand management, control, and reporting structures within the organization.
Review of department and project charters These documents describe the roles and responsibilities of the IS organization overall, as well as specific departments within IS. The charters for any recent major projects should be requested as well in order to understand newer objectives that could represent adjustments in organizational behavior. If the audit is going to focus on applications used by other departments, the auditor should request those departments’ charters and descriptions, which will help him better understand those departments’ functions, roles, and responsibilities.
Review of third-party contracts and service level agreements (SLAs) Even if they are not a focus of the audit, certain third-party contracts and SLAs may provide additional insight into the workings and culture of the IS organization.
Review of IS policies and procedures The auditor should obtain and review IS policies as well as process and procedure documents that are related to the audit. This will help the auditor to better understand the tone and direction set by management, as well as give the auditor a better idea of how well organized the IS organization really is.
Review of IS standards The auditor should obtain any IS standards documents to understand current policy on the vendors, products, methods, languages, and protocols in use. She should review process and documentation standards as well to see how consistently the organization follows them; this will give the auditor valuable insight into the discipline in the organization.
NOTE The IS auditor should pay attention to what IS charters, policies, and procedure documents do say, as well as what they don’t say. He should perform corroborative interviews to determine if these documents really define the organization’s behavior or if they’re just window dressing. This will help the auditor to understand the maturity of the organization, a valuable insight that will be helpful when writing the audit report.
Review of IS system documentation If the subject of the audit (directly or indirectly) is an IS application, the auditor should obtain much of the project documentation that chronicles the development or acquisition of the system. This may include the following:
Feasibility study
Functional, technical, and security requirements
Responses from vendors (at least the one chosen)
Evaluation of vendor responses
System design documentation, including data flow diagrams, entity-relationship diagrams, database schema, and so on
Test plans and results
Implementation guides and results
User manuals
Operations manuals
Business continuity plans
Changes made since initial release
Reports of system stability, capacity, and availability
NOTE The IS auditor should examine the organization’s SDLC process and determine how closely system documentation follows it.
Personnel interviews The IS auditor should conduct walkthrough interviews with key personnel who can describe the function, design, use, and operation of the system. Rather than assume that all acquired documentation is absolutely complete and accurate, the auditor should ask open-ended questions to gain additional insight into how well the system really operates. He should develop questions in advance in order to keep the interview on track and to make sure that all topics are covered. The auditor should carefully select key questions and ask them of more than one individual to compare answers, which will give him more insight.
NOTE Some organizations may coach their personnel so that they do not provide any more than the minimum amount of information. An experienced auditor should recognize this, and may need to get creative (without compromising ethics standards!) in order to get to key facts and circumstances. The IS auditor must always be polite, friendly, and request cooperation of each interviewee. She must always be truthful and never threaten any interviewee.
Passive observation When an IS auditor is embedded in an organization, people will “let their guard down” after they are accustomed to his presence. The auditor may be able to observe people being themselves and possibly will hear or see clues that will give better insight into the culture and tone of the organization.
Observing Personnel
It is rarely sufficient for an auditor to obtain and understand process documentation and be able to make judgments about the effectiveness of the process. Usually, the auditor will need to collect evidence in the form of observations to see how consistently a system’s process documentation is actually followed. Some of the techniques in observing personnel include:
Real tasks The auditor should request to see some IS functions actually being carried out. For example, if an auditor is examining user access management processes, he should be able to observe the persons who manage user accounts to see how they perform their tasks. The auditor should compare the steps taken against procedure documentation; he can also observe the configuration settings that the interviewee has made to see if they are being done according to procedure documents.
Skills and experience The auditor should ask each interviewee about his or her career background to determine the interviewee’s level of experience and career maturity. This will help the auditor to understand whether key responsibilities are in the hands of personnel who can really handle them.
Security awareness The IS auditor should observe personnel to see if they are following security policies and procedures. She can casually ask the interviewee what they know about security procedures to see if the security awareness program is effective. This should implicitly be a part of every audit, even if not explicitly included in scope. Major deviations from policy or common sense could well constitute deficiencies.
Segregation of duties The IS auditor should observe personnel to see if adequate segregation of duties (SOD) is in place. Lapses could include a user account administrator creating or changing a user account without official approval, or a systems engineer making a quick change on a system without going through the change management process.
An experienced IS auditor will have a well-developed “sixth sense,” an intuition about people that can be used to better understand the people who execute procedures.
Sampling
Sampling refers to the technique that is used when it is not feasible to test an entire population of transactions. The objective of sampling is to select a portion of a population so that the characteristics observed will reflect the characteristics of the entire population.
There are several methods for sampling:
Statistical sampling Here, a technique of random selection is used that will statistically reflect the entire population. The auditor will need to determine the size of the sample (usually expressed as a percentage of the entire population) so that the results obtained through testing will statistically reflect the entire population, where each event in the population has an equal chance of being selected.
Judgmental sampling Here, the IS auditor judgmentally and subjectively selects samples based on established criteria such as risk or materiality. For instance, when reviewing a list of user accounts to examine, the auditor can purposely select those users whose accounts represent higher risk than the others in the population.
Attribute sampling This technique is used to study the characteristics of a given population to answer the question “how many?”. After the auditor has selected a statistical sample, she then examines the samples. A specific attribute is chosen, and the samples examined to see how many items have the characteristic and how many do not. For example, an auditor is testing a list of terminated user accounts to see how many were terminated within 24 hours and how many were not. This is used to statistically determine the rate at which terminations are performed within 24 hours among the entire population.
Variable sampling This technique is used to statistically determine the characteristic of a given population to answer the question “how much?”. For example, an auditor who wishes to know the total value of an inventory can select a sample and then statistically determine the total value in the entire population based on the total value of the sample.
Stop-or-go sampling This technique is used to permit sampling to stop at the earliest possible time. The IS auditor will use this technique when he feels that there is a low risk and rate of exceptions in the overall population.
Discovery sampling This technique is used when an IS auditor is trying to find at least one exception in a population. When he is examining a population where even a single exception would represent a high-risk situation (such as embezzlement or fraud), the auditor will recommend a more intensive investigation to determine if additional exceptions exist.
Stratified sampling Here, the event population will be divided into classes, or strata, based upon the value of one of the attributes. Then, samples are selected from each class, and results are developed from each class or combined into a single result. An example of where this could be used is a selection of purchase orders (POs), where the IS auditor wants to make sure that some of the extremely high-value and low-value POs will be selected to see if there is any statistical difference in the results in different classes.
When performing sampling, the IS auditor needs to understand several aspects of statistical sampling techniques, including:
Confidence coefficient Sometimes known as the reliability factor or confidence level, this is expressed as a percentage, as the probability that the sample selected actually represents the entire population. A confidence coefficient of 95 percent is considered high.
Sampling risk This is equal to one minus the confidence coefficient percentage. For example, if a given sample has a 93 percent confidence coefficient, the risk level is 7 percent (100 percent minus 93 percent equals 7 percent).
Precision This represents how closely the sample represents the entire population. A low precision figure means high accuracy, and a high precision figure means low accuracy. A smaller sample makes the precision higher, and the risk of exceptions in the entire population is higher.
Expected error rate This is an estimate that expresses the percentage of errors that may exist in the entire population. When the expected error rate is higher, the sample needs to be higher (because a population with a high rate of errors requires greater scrutiny). If the expected error rate is low, the sample can be smaller.
Sample mean This is the sum of all samples divided by the number of samples. This equals the average value of the sample.
Sample standard deviation This is a computation of the variance of sample values from the sample mean. This is a measurement of the “spread” of values in the sample.
Tolerable error rate This is the highest number of errors that can exist without a result being materially misstated.
NOTE Part of the body of evidence in an audit is a description of how a sample was selected and why the particular sampling technique was used.
Computer-Assisted Audit
When auditing complex information systems, IS auditors often need to obtain sample data from systems with a variety of operating systems, database management systems, record layouts, and processing methods. Auditors are turning to computer-assisted audit techniques (CAATs) to help them examine and evaluate data across these complex environments.
CAATs help IS auditors by making sampling easier and by capturing data that has varying degrees of persistence in an organization’s application environment.
IS auditors can use generalized audit software (GAS) to directly read and access data from database platforms and flat files. They can independently and directly acquire sample data from databases, which they can then analyze on a separate system. Generalized audit software has the ability to select samples, select data, and perform analysis on data. This can help the auditor better understand key data sets in a system, enabling him to determine the integrity and accuracy of a system.
When using CAATs, auditors need to document the evidence they obtain from systems and be able to link it to business transactions. Often, auditors will have to obtain several other items, including:
Application source code
Online reports that correlate captured data to transactions and results
Database schemas
Data flow diagrams
CAATs can also be used as part of a continuous audit approach, where samples are obtained over long periods instead of just during audit engagements.
Additional guidance on the use of CAATs is found in ISACA auditing guideline G3, Guideline on Computer-Assisted Audit Techniques.
NOTE IS auditors need to take care that the effort to set up the CAAT environment doesn’t expend more effort than other methods for sampling and analysis.
Reporting Audit Results
The work product of an audit project is the audit report, a written report that describes the entire audit project, including audit objectives, scope, controls evaluated, opinions on the effectiveness and integrity of those controls, and recommendations for improvement.
While an IS auditor or audit firm will generally use a standard format for an audit report, some laws and standards require that an audit report regarding those laws or standards contain specific information or be presented in a particular format.
The auditor is typically asked to present findings in a closing meeting, where he can explain the audit and its results, and be available to answer questions about the audit. The auditor may include an electronic presentation to guide his discussion of the audit.
Structure and Contents
While there are often different styles for presenting audit findings, as well as regulations and standards that require specific content, an audit report will generally include several elements:
Cover letter Audit reports frequently include a cover letter that describes the audit, its scope and purpose, and findings. Often, this letter is used as evidence to other organizations that the audit took place.
Introduction The report should contain an introduction that describes the contents of the audit report.
Summary The report should include an executive summary that briefly describes the audit, its purpose and scope, and findings and recommendations.
Description of the audit The report should include a high level description of the audit, its purpose, and its objectives.
Listing of systems and processes examined The report should contain a list of systems, applications, and business processes that were examined.
Listing of interviewees The audit report should contain a complete list of interviewees, when they were interviewed, and topics discussed.
Listing of evidence obtained The report should contain a detailed list of all evidence obtained, from whom, and when it was obtained. Electronic evidence should be described, including the time it was acquired, the system it was obtained from, and the method used to obtain it. The names of any staff members who assisted should be included.
Explanation of sampling techniques Each time the auditor performed any sampling, the techniques used should be described.
Description of findings and recommendations Here, detailed explanations describe the effectiveness of each control, based on evidence and the auditor’s judgment. Exceptions are described in detail to demonstrate that they actually occurred.
When the IS auditor is creating the report, he must make sure that it is balanced, reasonable, and fair. The report should not just be a list of everything that was bad; it should also include a list of controls that were found to be operating effectively.
The IS auditor also needs to take care when describing recommendations, realizing that any organization is capable of only so much change in a given period. If the audit report contains many findings, the auditor needs to realize that the organization may not be able to remediate all of them in an elegant manner. Instead, the organization will need to understand which findings should be remediated first—the audit report should provide this guidance.
NOTE The IS auditor should review ISACA auditing standard S7, Reporting, and guideline G20, Reporting, when developing the audit report to ensure that the report is complete and accurate.
Other Audit Topics
This section includes important discussions related to IS audits.
Detecting Fraud
Fraud is defined as the intentional deception made for personal gain or damage to another party. In the context of corporate information systems and IS auditing, fraud is an act whereby a person discovers and exploits a weakness in a process or system for personal gain.
Management is responsible for implementing controls designed to prevent, deter, and detect fraud. However, no system or process is without weaknesses—worse yet, if two or more employees agree to a conspiracy to defraud the organization, it is possible for the conspirators to, at least temporarily, steal from the organization.
While detecting fraud is certainly not the IS auditor’s primary responsibility, an IS auditor surely has many opportunities to discover exploitable weaknesses in processes and systems that could be used to defraud the organization. Occasionally, the IS auditor will discover evidence of fraud while examining transaction samples during substantive testing.
When the auditor detects signs of fraud, he should carefully evaluate what he has found, and then communicate his findings to the appropriate authorities. Precisely whom he contacts will depend on the nature and structure of the organization, and whether there is regulatory oversight of the organization. The auditor needs to be extremely careful when reporting his findings within the organization because the person he reports his findings to could be the perpetrator. This logic may prompt the auditor to report this finding directly to the audit committee, thereby bypassing all potential perpetrators in the organization (usually, members of the audit committee are not employees in the organization, have no role in the organization’s operations, and hence are probably not among the culprits).
If the organization has no audit committee or similar overseeing body, the auditor may be compelled to report his findings to regulators or law enforcement.
Audit Risk and Materiality
What if there are material errors in business processes that remain undetected by the IS auditor? There are a number of ways in which this can occur, including:
Control risk This is the risk that a material error exists that will not be prevented or detected by the organization’s control framework. For example, a manual control that is designed to detect unauthorized changes in an information system may fail if the personnel who review logs overlook significant errors or fraud.
Detection risk This is the risk that an IS auditor will overlook errors or exceptions during an audit. Detection risk should be a part of the IS auditor’s risk assessment that is carried out at the beginning of an audit; this would help the auditor focus on those controls that require additional scrutiny (meaning higher sampling rates) and thereby improve the chances of detecting errors.
Inherent risk This is the risk that there are material weaknesses in existing business processes and there are no compensating controls to aid in their detection or prevention. Inherent risks exist independent of the audit.
Overall audit risk This is the summation of all of the residual risks discussed in this section.
Sampling risk This is the risk that the sampling technique used will not detect transactions that are not in compliance with controls.
Materiality In financial audits, materiality is established as a dollar amount threshold that is calculated in one of several possible ways, including a percentage of pretax income, a percentage of gross profit, a percentage of total assets, a percentage of total revenue, a percentage of equity, or blended methods using two or more of these.
Then, when an auditor is examining transactions and controls during an audit, a finding can be classified as a material weakness if the dollar amount of the exceptions exceeds the materiality threshold. There is, however, some latitude (more in some cases and less in others) in the auditor’s judgment as to whether a finding is material.
In an IS audit, the controls being examined do not have dollar figures associated with them and deficiencies are not measured against materiality thresholds in the same way. Instead, materiality in an IS audit occurs when a control deficiency (or combination of related control deficiencies) makes it possible for serious errors, omissions, irregularities, or illegal acts to occur as a result of the deficiency(ies). Here more than in a financial audit, the judgment of the IS auditor is very important in determining if a finding is material.
Auditing and Risk Assessment
When assessing the effectiveness of controls in an organization, the IS auditor should take the time to understand how the organization approaches risk assessment and risk treatment.
Risk Assessment Organizations should periodically undertake risk assessments in order to identify areas of risk that warrant remediation. A risk assessment should identify, prioritize, and rank risks. The subject of risk assessment should be those business processes and supporting information systems and infrastructures that are central to the organization’s mission.
After identifying risks, the risk assessment should include one or more potential remedies, each with an analysis of the cost and effort to implement and the estimated reduction in risk. When these remedies and their impact (in terms of risk reduction) are then ranked, the result should be a list of the most effective initiatives for reducing risk in the organization.
There are two types of risk assessment: qualitative and quantitative. A qualitative risk assessment rates risks as high-medium-low, whereas a quantitative risk analysis rates risks in terms of actual probabilities and costs. A quantitative risk assessment is considerably more difficult and time-consuming to perform, since it can be difficult to ascertain reasonable probabilities of threats and their financial impact. However, when seriously considering measures to reduce risk on the highest-risk areas in the assessment, sometimes it makes sense to perform some quantitative risk assessment in order to verify which investments are the ones that will make the most difference.
Risk Treatment Once risks have been identified, risk treatment is the term that describes the action taken to address them. There are four possible avenues for risk treatment:
Risk reduction This involves making changes to processes, procedures, systems, or controls that will reduce either the probability of a threat or its impact. For example, if the risk assessment identifies a threat of a SQL injection attack on an application, the organization can reduce risk by implementing an application firewall that will block such attacks.
Risk transfer This typically involves the use of insurance, which is used to compensate the organization for the financial losses or damages that will occur if the threat were realized. For example, the organization can transfer the risk of a denial of service attack by purchasing a cyberinsurance policy that would compensate the organization if such an attack were to occur.
Risk avoidance Here, the organization will cease the activity associated with the risk. For instance, if the risk assessment identifies risks associated with the implementation of an e-commerce capability, the organization might choose to abandon this idea, thereby avoiding e-commerce–related risk.
Risk acceptance In this case, the organization feels that the risk is acceptable and that no measures need to be taken to reduce the risk further.
Rarely does an organization make a decision that fits entirely within a single risk treatment category. Rather, risk treatment is usually a blended approach, where, for instance, measures are taken to reduce risk; however, even a combination of measures rarely eliminates all risk—there is usually some risk left over after some risk treatment is performed. This leftover risk is known as residual risk. And like the dirt that can’t be picked up with a broom and dustpan, the leftover risk is usually accepted.
Using External Auditors
Despite the fact that so many IS and security professionals are entering a career of IS auditing (and earning their CISA certification along the way), there is still a scarcity of qualified IS auditors. Furthermore, many laws, regulations, and standards require that qualified external auditors perform key audits of business processes and information systems. Also, even with experienced IS audit generalists on staff, occasionally, experts with knowledge of specific technologies are needed for some audit engagements. These factors make it clear that many organizations—even those with qualified and available internal audit personnel—will be undergoing external audits performed by external auditors.
An organization that is entertaining the idea of using external auditors needs to consider several factors, including:
Regulatory restrictions on outsourcing
Independence and objectivity of internal versus external auditors
Impact on audit risk
Professional liability of external audit firms
Audit management controls used to manage external audit activities
Impact on overall audit objectives
External auditor loyalty
Communications between auditors and auditees
Professional and administrative qualification of auditors
Background checks for external audit staff
Protection and privacy of information made available to external auditors
Costs and the overhead required to manage external auditors
NOTE IS auditors should be familiar with ISACA audit guideline G1, Using the Work of Other Auditors, and standard S6, Performance of Audit Work, in order to properly manage the work performed by external auditors.
Control Self-Assessment
Control self-assessment (CSA) is a methodology used by an organization to review key business objectives, risks related to achieving these objectives, and the key controls designed to manage those risks. The primary characteristic of a CSA is that the organization takes initiative to self-regulate rather than engage outsiders, who may be experts in auditing but not in the organization’s mission, goals, and culture.
Advantages and Disadvantages
Like almost any business activity, control self-assessments have a number of advantages and disadvantages that the IS auditor and others should be familiar with. This will help the organization make the most of this process and avoid some common problems.
The advantages of control self-assessments include:
Risks can be detected earlier, since subject matter experts are involved earlier
Improvement of internal controls
Ownership of controls through involvement in their improvement
Improved employee awareness of controls through involvement in their improvement
Improved relationship between departments and auditors
Some of the disadvantages of control self-assessments are:
It could be mistaken as a substitute for an internal audit.
It may be considered extra work and dismissed as unnecessary.
It may be considered an attempt by the auditor to shrug off responsibilities.
Lack of employee involvement would translate to little or no process improvement.
The Self-Assessment Life Cycle
Like most continuous-improvement processes, the control self-assessment process is an iterative life cycle. The phases in the control self-assessment are:
Identify and assess risks Here, operational risks are identified and analyzed.
Identify and assess controls Controls to manage risks are identified and assessed. If any controls are missing, new controls are designed.
Develop questionnaire or conduct workshop Here, an interactive session is conducted, if possible, for discussion of risks and controls. If personnel are distributed across several locations, a questionnaire is developed and sent to them.
Analyze completed questionnaires or assess workshop If a workshop was held, the workshop results are assessed to see what good ideas for remediation emerged. If a questionnaire was distributed, the results are analyzed to see what good ideas for risk remediation were identified.
Control remediation Using the best ideas from the workshop or questionnaire, controls are designed or altered to better manage risk.
Awareness training This activity is carried out through every phase of the life cycle to keep personnel informed about the activities in the various phases.
The control self-assessment life cycle is illustrated in Figure 3-3.
Self-Assessment Objectives
The primary objective of a control self-assessment is to transfer some of the responsibility for oversight of controls to the control owners. The IS auditor’s role is not diminished, as the IS audit still needs to periodically test control effectiveness, but control owners will play a more active role in the audit of their controls.
Another objective of control self-assessment is the long-term reduction in exceptions. As control owners assume more responsibility for the performance of their controls, they will strive to avoid situations where IS auditors identify exceptions. The control self-assessment gives control owners an opportunity and a process for cleaning house and improving audit results.
Figure 3-3 The control self-assessment life cycle
NOTE The IS auditor should be involved in control self-assessments to ensure that the CSA process is not hijacked by efficiency zealots who try to tear the controls out of processes because they do not understand their significance.
Auditors and Self-Assessment
IS auditors should be involved in control self-assessments that various departments conduct. The role of IS auditors should be that of an objective subject matter expert who can guide discussions in the right direction so that controls will receive the right kind of development over time.
IS auditors should resist too large a role in control self-assessments. Responsibility for control development and maturation should lie within the department that owns the control self-assessment. However, if a department is new at CSA, it may take some time before they are confident and competent enough to take full ownership and responsibility for the process.
Implementation of Audit Recommendations
The purpose of internal and external audits is to identify potential opportunities for making improvements in control objectives and control activities. The handoff point between the completion of the audit and the auditee’s assumption of control is in the portion of the audit report that contains findings and recommendations. These recommendations are the imperatives that the auditor recommends the auditee perform to improve the control environment.
Implementation of audit recommendations is the responsibility of the auditee. However, there is some sense of shared responsibility with the auditor, as the auditor seeks to understand the auditee’s business so that she can develop recommendations that can reasonably be undertaken and completed. In a productive auditor-auditee relationship, the auditor will develop recommendations using the fullest possible understanding of the auditee’s business environment, capabilities, and limitations—in essence saying, “Here are my recommendations to you for reducing risk and improving controls.” And the auditee, having worked with the auditor to understand his methodology and conclusions, and who has been understood by the auditor, will accept the recommendations and take full responsibility for them—in essence saying, “I accept your recommendations and will implement them.” This is the spirit and intent of the auditor-auditee partnership.
Notes
An audit program is the audit strategy and the plans that include scope, objectives, resources, and procedures used to evaluate controls and processes.
IS auditors need to stay current with technology through training courses, webinars, ISACA chapter training events, and industry conferences.
Several laws, regulations, and standards require internal or external audits to ensure that organizations achieve and maintain compliance.
The types of controls are physical, technical, and administrative.
The classes of controls are preventive, detective, deterrent, corrective, compensating, and recovery.
The categories of controls are automatic and manual.
The types of audits are operational audits, financial audits, integrated audits, IS audits, administrative audits, compliance audits, forensic audits, and service provider audits. Pre-audits can be performed to help an organization prepare for an upcoming audit.
Compliance testing is used to determine if control procedures have proper design and are operating properly. Substantive testing is used to verify the accuracy and integrity of transactions as they flow through a system.
Audit methodologies define an audit subject, audit objective, type of audit, audit scope, pre-audit planning, audit statement of work, audit procedures, communication plan, report preparation, wrap-up, and post-audit follow-up.
The types of evidence that the auditor will collect during an audit include observations, written notes, correspondence, process and procedure documentation, and business records.
During an audit, the auditor should obtain org charts, department charters, third-party contracts, policies and procedures, standards, and system documentation. She should conduct several interviews with pre-written questions and carefully observe personnel to better understand their discipline, as well as organizational culture and maturity.
The types of sampling include statistical sampling, judgmental sampling, attribute sampling, variable sampling, stop-or-go sampling, discovery sampling, and stratified sampling. The IS auditor needs to understand the meaning of confidence coefficient, sampling risk, precision, expected error rate, sample mean, sample standard deviation, and tolerable error rate.
An audit report usually includes a cover letter, introduction, summary, audit description, list of systems examined, interviewees, evidence, explanation of sampling techniques, findings, and recommendations.
The types of risks that are related to audits include control risk, detection risk, inherent risk, overall audit risk, and sampling risk.
External auditors may be needed when the organization lacks specific expertise or resources to conduct an internal audit. However, some regulations and standards require external, independent audits.
Summary
The audit function in an organization should be defined and described in a charter. The audit program and audit strategy should support the organization’s mission and objectives, and facilitate business development and growth.
Auditors need to establish and maintain technical competence so that they can effectively evaluate technical controls and identify technical control risks. They will need to attend periodic training in the technologies in use by the organization, as well as in emerging technologies that the organization may use in the future.
The ISACA code of ethics defines the standards of behavior and conduct for IS auditors. The ISACA auditing standards framework defines mandatory audit standards, guidelines that contain suggestions for implementing the standards, and procedures that can be used to audit information systems. All persons who hold the CISA designation are required to uphold the ISACA code of ethics; violations will result in investigations and possible disciplinary actions, including expulsion.
IS auditors need to perform a risk analysis as an integral part of an audit project in order to identify risk areas that require additional audit resources. The result of the risk analysis will help the auditor to build a complete audit plan that includes the right level of activities to be carried out during the audit.
Internal controls are the policies, procedures, mechanisms, systems, and other means designed to reduce risk and facilitate the achievement of business objectives. Controls are classified in several different ways that describe how they are designed to control behaviors and outcomes.
Internal control objectives are statements of desired states and outcomes in the organization. They are supported by one or more controls that ensure the realization of control objectives. Controls are measurable and can be defined and enforced with processes, procedures, or automatic mechanisms within information systems. IS control objectives resemble internal control objectives, but are focused on the desired states and outcomes within the context of information systems.
General computing controls are controls that are applied across an entire IS environment. An organization will likely have additional controls that are applied to individual applications or components in the environment.
An audit is the planned, methodical evaluation of controls and control objectives. A key activity in an audit is the identification and acquisition of evidence that supports the operation of controls and helps the auditor reach a conclusion about the effectiveness of a control.
IS auditors generally develop and follow an audit methodology, which is a process that ensures consistent audits from start to finish.
Evidence is the information collected by the auditor during the course of the audit. The reliability and relevance of evidence helps the auditor reach sound conclusions on the effectiveness of controls and control objectives.
Sampling is the technique used when it is not feasible to test an entire population of transactions. Sampling techniques need to be carefully considered so that they accurately represent the entire population.
Computer-assisted audit techniques (CAATs) are used to automate sampling and analysis of information in complex application environments. CAATs can help to analyze and correlate data that would be too difficult to perform manually.
The audit report is the work product of the audit project. It contains a summary, a description of evidence gathered, and findings and conclusions.
In IS audits, materiality is the threshold where control deficiencies make it possible for serious errors, omissions, irregularities, or illegal acts to occur.
A control self-assessment is an activity used by an organization to take ownership of controls and make improvements in the implementation of its controls through workshops and other activities.
Questions
1. An IS auditor is planning an audit project and needs to know which areas are the highest risk. What is the best approach for identifying these risk areas?
A. Perform the audit; control failures will identify the areas of highest risk
B. Perform the audit and then perform a risk assessment
C. Perform a risk assessment first and then concentrate control tests in high-risk areas identified in the risk assessment
D. Increase sampling rates in high-risk areas
2. An auditor has detected potential fraud while testing a control objective. What should the auditor do next?
A. Notify the audit committee
B. Conduct a formal investigation
C. Report the fraud to law enforcement
D. Report the suspected fraud to management
3. The possibility that a process or procedure will be unable to prevent or detect serious errors and wrongdoing is known as:
A. Detection risk
B. Inherent risk
D. Control risk
4. The categories of risk treatment are:
A. Risk avoidance, risk transfer, risk mitigation, and risk acceptance
B. Risk avoidance, risk transfer, and risk mitigation
C. Risk avoidance, risk reduction, risk transfer, risk mitigation, and risk acceptance
D. Risk avoidance, risk treatment, risk mitigation, and risk acceptance
5. An IS auditor needs to perform an audit of a financial system and needs to trace individual transactions through the system. What type of testing should the auditor perform?
A. Discovery testing
B. Statistical testing
C. Compliance testing
D. Substantive testing
6. An IS auditor is auditing the change management process for a financial application. The auditor has two primary pieces of evidence: change logs and a written analysis of the change logs performed by a business analyst. Which evidence is best and why?
A. The change log is best because it is subjective
B. The written analysis is best because it interprets the change log
C. The change log is best because it is objective and unbiased
D. The written analysis is best because it is objective
7. Under which circumstances should an auditor use subjective sampling?
A. When the population size is low
B. When the auditor feels that specific transactions represent higher risk than most others
C. When the risk of exceptions is low
D. When statistical sampling cannot be performed
8. An IS auditor has discovered a high-risk exception during control testing. What is the best course of action for the IS auditor to take?
A. Immediately perform mitigation
B. Include the exception in the report and mark the test as a control failure
C. Immediately inform the auditee of the situation
D. Immediately inform the audit committee of the situation
9. What is the appropriate role of an IS auditor in a control self-assessment?
A. The IS auditor should participate as a subject matter expert
B. The IS auditor should act as facilitator
C. The IS auditor should not be involved
D. The IS auditor should design the control self-assessment
10. Which of the following would NOT be useful evidence in an IS audit?
A. Personnel handbook
B. Organization mission statement and objectives
C. Organization chart
D. Organization history
Answers
1. C. The IS auditor should conduct a risk assessment first to determine which areas have highest risk. She should devote more testing resources to those high-risk areas.
2. A. When the IS auditor suspects fraud, he should conduct a careful evaluation of the matter and notify the audit committee. Because audit committee members are generally not involved in business operations, they will be sufficiently removed from the matter, and they will have the authority to involve others as needed.
3. D. Control risk is the term that signifies the possibility that a control will fail to prevent or detect unwanted actions.
4. A. The four categories of risk treatment are risk mitigation (where risks are reduced through a control or process change), risk transfer (where risks are transferred to an external party such as an insurance company), risk avoidance (where the risk-bearing activity is discontinued), and risk acceptance (where management chooses to accept the risk).
5. D. The auditor should perform substantive testing, which is a test of transaction integrity.
6. C. The change log is the best evidence because it is objective and not subject to human judgment.
7. B. Subjective sampling is used when the auditor wants to concentrate on samples known to represent higher risk.
8. C. The IS auditor should immediately inform the auditee when any high-risk situation is discovered.
9. A. The IS auditor should act as a subject matter expert in a control self-assessment, but should not play a major role in the process.
10. D. Of the choices given, the organization history would be the least useful. The others will provide insight into the organization’s mission, goals, and how it sets out to achieve them.