Home / Resources / ISACA Journal / Issues / 2019 / Volume 3 / Developing the IT Audit Plan Using COBIT 2019



IS Audit Basics: Developing the IT Audit Plan Using COBIT 2019

Author: Ian Cooke, CISA, CRISC, CGEIT, COBIT Assessor and Implementer, CFE, CIPM, CIPP/E, CIPT, CPTE, DipFM, FIP, ITIL Foundation, Six Sigma Green Belt
Date Published: 1, May 2019
Download PDF

The IT Assurance Framework (ITAF) requires that the IS audit and assurance function shall use an appropriate risk assessment approach and supporting methodology to develop the overall IS audit plan and determine priorities for the effective allocation of IS audit resources.1 However, despite this requirement, there is little ISACA documentation on defining an IT audit plan. Perhaps this is because the seminal Developing the IT Audit Plan Global Technology Audit Guide (GTAG 11)2 is so good. Nonetheless, this document was published in July 2008, so the question should be asked, given current practices, can this be improved upon?

In December 2018, ISACA published what I believe will become an equally influential document, the COBIT 2019 Design Guide: Designing an Information and Technology Governance Solution.3 I am proposing that the steps described therein for designing a tailored governance system can be adopted to developing the IT audit plan (figure 1).

Figure 1

Understand the Enterprise Context and Strategy

Before developing an audit plan, one should understand the enterprise under review. Enterprises can have different strategies, which the design guide expresses as archetypes (figure 2). Enterprise strategy is realized by the achievement of (a set of) enterprise goals.4 These goals are structured along the balanced scorecard (BSC) dimensions,5 an example being business service continuity and availability. A risk profile identifies the sort of IT-related risk to which the enterprise is currently exposed and indicates which areas of risk are exceeding the risk appetite.6 Good sample risk scenarios have been developed by ISACA to aid with understanding IT-related risk.7

Figure 2

Closely related to IT risk are information and technology (I&T)-related issues—also called pain points—from which the enterprise is suffering.8 These could be considered risk that have materialized. An example might be service delivery problems by the IT outsourcer(s).

At the end of this step, it is important to have a clear and consistent view of the enterprise strategy, the enterprise goals, IT-related risk and current I&T issues. The design guide provides concrete examples of these. An appropriate perspective to keep in mind is that technology only exists to support and further the organization’s objectives and is a risk to the organization if its failure results in the inability to achieve the business objective.9

Determine the Components of the IT Audit Universe

ISACA defines a portfolio as a grouping of “objects of interest” (i.e., investment programs, IT services, IT projects, other IT assets or resources) managed and monitored to optimize business value.10 A key consideration for IT portfolio management is getting the mix right to achieve this business value, one of the motives being that, just like a financial portfolio, some of the areas may not provide the expected value. Therefore, it makes sense to consider these portfolios when developing the IT audit plan—to match this mix we should audit across each of the areas defined in the portfolios.

Of course, this raises a question: What if there are no discernible portfolios? In that case, I propose using COBIT 2019’s components of the governance system11 to define the IT audit portfolios (figure 3). These are factors that, individually and collectively, contribute to the good operations of the enterprise’s governance system over I&T12 and, therefore, should be considered when developing the IT audit plan.

Figure 3

The portfolios should include all activities that will be performed by IT audit. Why? Because performing audit recommendation follow-ups, attending training or reporting on the status of the audit activities takes time, and the only way to ensure that time is properly allocated for them is to include them in the audit plan.

Once the IT audit portfolios have been defined, they can be expanded to create the IT audit universe (figure 4).

Figure 4

Risk Assess the IT Audit Universe

Risk analysis is the process of estimating the two essential properties of each risk scenario:13

  • Frequency—The number of times in a given period (usually in a year) that an event is likely to occur
  • Impact—The business consequences of the scenario

Risk factors are those conditions that influence frequency and impact. They can be of different natures and can be classified into two major categories:14

  • Contextual factors—Can be divided into internal and external factors, the difference being the degree of control an enterprise has over them
  • Capabilities—How effective and efficient the enterprise is in a number of IT-related activities

The importance of risk factors lies in the influence they have on risk. They should be considered during every risk analysis.

Design factors are factors that can influence the design of an enterprise’s governance system and position it for success in the use of I&T.15 If we accept that success includes managing risk, then it makes sense that the COBIT 2019 design factors can also be used as risk factors (figure 5).

Figure 5

The factors include those that helped with our understanding of the enterprise context and strategy and are described in detail in the COBIT 2019 Design Guide.16 Their influence as risk factors is described in figure 6.

Figure 6

It should be noted that not all risk factors may be applicable to each enterprise or IT audit portfolio, nor should more traditional risk factors such as the market, economic factors, geopolitics and industry competition necessarily be ignored.

Once the risk factors have been decided upon, they can be used to perform the risk analysis. Practical guidance on performing this and the risk assessment is explained well in the Risk Scenarios Using COBIT 5 for Risk17 and the GTAG 11 documents.18

In addition, the IT audit follow-ups, training and audit committee requirements should also be subject to a risk assessment. Example questions include: What follows-ups should be performed first? Is the training addressing perceived risk? Is the right information being provided to the audit committee?

Conclude and Validate the IT Audit Plan

At this stage, one should have a list of ranked audit universe items by portfolio. Unless the element of surprise is required, these should be discussed and validated with senior management of the auditee. Why? Because management will be aware of factors such as scheduled upgrades, application replacements and external audits, which may affect audit’s ability to deliver the plan on time. In addition, they may have insights or special requests for audits that are not currently part of the universe. When this is complete, the plan should be reviewed from audit’s perspective. Are there any inherent conflicts? Is specialist help needed for specific audits?

Finally, publish the IT audit plan, including the proposed sequence and timings. This may prove controversial—what if management remediates risk scenarios before audit arrives? This is a positive. The purpose of audit is not to have audit findings; the purpose of audit is to help mitigate risk.


When developing the IT audit plan, remember that one of the basic rules of the (audit) universe is that nothing is perfect. Perfection simply does not exist.19 However, by adapting a portfolio-based approach along with COBIT 2019’s design factors as risk factors, the IT audit plan should be closely aligned with the business strategy and direction. The process makes this demonstrable and allows audit to add value.


1 ISACA, ITAF, A Professional Practices Framework for IS Audit/Assurance, USA, 2014,
2 The Institute of Internal Auditors, Global Technology Audit Guide (GTAG) 11: Developing the IT Audit Plan, USA, 2008,
3 ISACA, COBIT 2019 Design Guide: Designing an Information and Technology Governance Solution, USA, 2018,
4 Ibid., p. 22
5 Ibid.
6 Ibid., p. 23
7 ISACA, Risk Scenarios Using COBIT 5 for Risk, USA, 2014, p. 33,
8 Ibid.
9 Op cit GTAG 11, p. 4
10 ISACA Glossary, Portfolio,
11 ISACA, COBIT 2019 Framework, Introduction and Methodology, USA, 2018,
12 Ibid., p. 21
13 Op cit Risk Scenarios Using COBIT 5 for Risk
14 Ibid., p. 16
15 Op cit COBIT 2019 Design Guide, p. 21
16 Ibid.
17 Op cit Risk Scenarios Using COBIT 5 for Risk
18 Op cit GTAG 11
19 Goodreads, Stephen Hawking Quotes,

Ian Cooke, CISA, CRISC, CGEIT, COBIT Assessor and Implementer, CFE, CIPM, CIPP/E, CIPT, CPTE, DipFM, FIP, 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 ISAC® committees and is a past member of ISACA’s CGEIT Exam Item Development Working Group. He is the topic leader for the Audit and Assurance discussions in the ISACA Online Forums. Cooke supported the update of the CISA Review Manual for the 2016 job practices and was a subject matter expert for the development of ISACA’s CISA and CRISC Online Review Courses. 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 (, Twitter (@COOKEI), LinkedIn ( or on the Audit and Assurance Online Forum ( Opinions expressed are his own and do not necessarily represent the views of An Post.

language icon

Journal Translated Articles Are Currently Unavailable

We’re in the process of moving our translated Journal articles to our new platform. Please hold tight—they’ll be available again in mid-February.