ISACA Journal
Volume 4, 2,017 


IS Audit Basics: Audit Programs 

Ian Cooke, CISA, CRISC, CGEIT, COBIT Assessor and Implementer, CFE, CPTE, DipFM, ITIL Foundation, Six Sigma Green Belt 

It was a great compliment, if somewhat daunting, to be invited to follow in the footsteps of Tommie Singleton and the late Ed Gelbstein to contribute to this column. I can only hope to match their insights by bringing my own experiences to bear.

Speaking of which, one of the most common requests I get as a community leader on the ISACA Knowledge Center1, 2, 3 is for audit/assurance programs or sources of assurance. So, what are our options and where should we look?

Utilize Existing Audit/Assurance Programs

Figure 1ISACA, the Institute of Internal Auditors (IIA) and other organizations have developed programs (figure 1) that address commonly audited areas such as cyber security, commonly utilized applications such as SAP and common requirements for compliance such as the Payment Card Industry Data Security Standard (PCI DSS). These are excellent resources and can save a lot of time. My only word of warning is that they are not one size fits all. They should be considered a starting point and adjusted based upon risk factors and criteria that are relevant to the organization you are auditing. Failure to do so can result in a checklist approach that can lead to the auditor recommending controls that are not applicable to the organization. This, in turn, can damage your reputation with the auditee and, ultimately, with senior management.

Build Your Own

During your career as an IS auditor, there will be a requirement to build your own audit/assurance programs. These would typically be required when the audit subject is a custom-built application or when the organization being audited is implementing tools or processes that are on the cutting edge. How do you approach such assignments?

In March 2016, ISACA released an excellent white paper titled Information Systems Auditing: Tools and Techniques Creating Audit Programs.7 The paper describes the five steps in developing your own audit program (figure 2). Essentially, these steps are:

  1. Determine audit subject—What are you auditing? This is often set as part of the overall audit plan.
  2. Define audit objective—Why are you auditing it? Again, this may have been set as part of the overall audit plan.
  3. Set audit scope—What are the limits to your audit?
  4. Perform preaudit planning—What are the specific risk factors?
  5. Determine audit procedures and steps for data gathering—How will you test the controls for these risk?

Figure 2

A crucial component of step 5 is developing the criteria for evaluating tests. “Criteria” is defined as the standards and benchmarks used to measure and present the subject matter and against which an IS auditor evaluates the subject matter.8 Many of these will be defined by the entity that is being audited (e.g., contracts, service level agreements, policies, standards); however, there will be instances, for example, when an organization has not defined its own standards when other criteria should be applied (figure 3).

Figure 3

One such instance might be when you are auditing an Oracle database. Where an organization has defined its own Oracle database standard, then you audit to that standard. However, if no standard exists, it is good practice to use an external benchmark if it is objective, complete, relevant, measurable, understandable, widely recognized, authoritative and understood by, or available to, all readers and users of the report.9 Further, IS audit and assurance professionals should consider the source of the criteria and focus on those issued by relevant authoritative bodies before accepting lesser-known criteria.23 I would also disclose the criteria used and why—in this case, auditors were required to give an opinion on the security of an Oracle database, but management had no standard defining what “secure” means. A further finding from such an audit may be that management should define such a standard. Selecting the right criteria is vital for the success of the audit.


We live in a world where it is very much a viable option to run a business using open-source software. I, therefore, pose a simple question: Why cannot we, as an ISACA community, develop open-source audit/assurance programs?

The Documents and Publications section of Audit Tools and Techniques24 allows every member to contribute user-created documents and publications. Members could, therefore (with their organization’s permission), upload completed audit/assurance programs, making them available (with the right terms and conditions) for other members to adopt for their own enterprise’s risk and criteria. Further, other members could contribute to and enhance these documents. Over time, we, as a community, could build up many audit/assurance programs that are continuously enhanced and kept up to date.


An audit/assurance program is defined by ISACA as a step-by-step set of audit procedures and instructions that should be performed to complete an audit.25 Many of these steps are common to most enterprises; however, each also has its own culture, ethics and behavior. We can utilize and share existing audit/assurance programs and even collaborate on the building of same if we remember that we have an obligation to consider the risk to our own organizations.

Editor’s Note

ISACA is currently exploring several methods for community-driven audit program sharing and development models.


1 ISACA Knowledge Center, Audit Tools and Techniques,
2 ISACA Knowledge Center, Oracle Databases,
3 ISACA Knowledge Center, SQL Server Databases,
4 ISACA, Audit/Assurance Programs,
5 Institute of Internal Auditors, Global Technology Audit Guides,
6 AuditNet, Audit Programs,
7 ISACA, Information Systems Auditing: Tools and Techniques: Creating Audit Programs, USA, 2016,
8 ISACA, ITAF: Information Technology Assurance Framework, USA, 2014,
9 Op cit, ITAF, p. 20
10 ISACA COBIT 5, USA, 2012,
11 ISACA, White Papers,
12 ISACA, Cloud Computing Guidance,
13 ISACA, Cyber Security Resources,
14 Department of Defense, Security Technical Implementation Guides, USA,
15 Center for Internet Security Benchmarks and Controls,
16 International Organization for Standardization/International Electrotechnical Commission, ISO/IEC 27000 Family—Information Security Management Systems,
17 Cloud Security Alliance,
18 National Institute of Standards and Technology, Framework for Improving Critical Infrastructure Cybersecurity, USA,
19 Security and Privacy Controls for Federal Information Systems and Organizations,
20 National Institute of Standards and Technology, NIST publications,
21 Payment Card Industry Data Security Standard,
22 Information Technology Infrastructure Library,
23 Op cit, ITAF, p. 20
24 Op cit, ISACA Knowledge Center
25 ISACA Glossary,

Ian Cooke, CISA, CRISC, CGEIT, COBIT Assessor and Implementer, CFE, CPTE, DipFM, ITIL Foundation, Six Sigma Green Belt
Is the group IT audit manager with An Post (the Irish Post Office based in Dublin, Ireland) and has 30 years of experience in all aspects of information systems. Cooke has served on several ISACA committees and is a current member of ISACA’s CGEIT Exam Item Development Working Group. He is the community leader for the Oracle Databases, SQL Server Databases, and Audit Tools and Techniques discussions in the ISACA Knowledge Center. Cooke assisted in the updates of the CISA Review Manual for the 2016 job practices and was a subject matter expert for ISACA’s CISA Online Review Course. He is the recipient of the 2017 John W. Lainhart IV Common Body of Knowledge Award for contributions to the development and enhancement of ISACA publications and certification training modules. He welcomes comments or suggestions for articles via email at [email protected], Twitter (@COOKEI) or on the Audit Tools and Techniques topic in the ISACA Knowledge Center. Opinions expressed in this column are his own and do not necessarily represent the views of An Post.


Add Comments

Recent Comments

Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and from opinions endorsed by authors’ employers or the editors of the Journal. The ISACA Journal does not attest to the originality of authors’ content.