Risk Analysis: Then and Now

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

As part of ISACA’s 50th anniversary celebration, I am looking at the past and evaluating how risk analysis has changed by comparing the approach proposed in my recent IS Audit Basics column, “Developing the IT Audit Plan Using COBIT 2019” from the ISACA Journal, volume 3, with the “Automated Audit Risk Analysis,” article written for the EDP Auditor,1 vol. 2, in 1984. A lot has changed from then until now, but it can be incredible to examine the foresight ISACA/EDP volunteers had in the past.

My Proposed Approach

My column’s proposed approach uses the COBIT 2019 design factors as illustrated in figure 1 as risk factors when developing the IT audit plan.

Figure 1—COBIT Design Factors

Source: ISACA, COBIT 2019 Design Guide: Designing an Information and Technology Governance Solution, USA, 2018. Reprinted with permission.

To recap, risk factors are those conditions that influence the frequency and/or business impact of risk scenarios. They can be of different natures and can be classified into 2 major categories:

  • 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 are heavy influencers on the frequency and impact of IT scenarios and should be taken into account during every risk analysis.

My IS Audit Basics column also discusses the influence of the COBIT 2019 design factors as risk factors as illustrated in figure 2.

Figure 2—Cooke Article Risk Factors

Contextual Factor Type

Contextual Factor

Influence on Frequency, Impact or Capability

Internal

 

 

 

 

 

 

 

 

Enterprise strategy

The strategy archetype will influence the importance of different governance and management processes, applications, etc. Therefore, poor implementation, unforeseen issues, etc., will have a higher business impact.

Enterprise goals

Enterprise goals will influence the selection of IT goals and the importance of different processes, applications, etc., Therefore, poor implementation, unforeseen issues, etc., will have a higher business impact.

Risk profile of the enterprise

Any processes, applications, etc., where a likely event would result in the risk appetite being exceeded will have a higher business impact.

Current I&T-related issues of the enterprise

Known issues (e.g., from previous audits) should increase the frequency (likelihood) of an event. Known issues will also affect IT’s capability to get the job done.

Role of IT

If the business level of reliance on IT is strategic for a given process or application, this would increase the frequency and business impact of an event. The capability of IT will have a business impact.

Sourcing model for IT

If IT is outsourced or relies on the cloud, this increases the reliance on these parties. This, in turn, increases the frequency and impact of vendor issues on a given process or application. The capability of vendors will have a business impact.

IT implementation methods

If the enterprise is moving from a traditional model to Agile or DevOps, this would increase the frequency of events. Different applications may be developed using different methods.

Technology adoption strategy

If the enterprise is a first mover with a particular application or service, this this would increase the frequency of events.

Enterprise size

A smaller enterprise may not have the resources for controls such as separation of duties, in turn, increasing the frequency of events.

External

 

Threat landscape

The greater the threats to the enterprise, the greater the frequency of adverse events.

Compliance requirements

If the enterprise is subject to new, complex or everchanging regulations, this will increase the frequency of an event and/or the business impact.

EDP Auditor Approach

Now when examining the EDP Auditor article, Godier notes that in the past, the audit risk factor has been determined largely by personal judgement, which, to date, has been as good as any method of selection. I interpreted this to mean that this was one of the first papers to propose a qualitative approach to risk analysis. The risk factors proposed in the article are described in figure 3.

Figure 3—Godier Article Risk Factors

Contextual Factor Type

Contextual Factor

Godier Article Description

Internal

 

 

 

 

Type of system

This element is used only to indicate where, historically, the greatest chance of fraud exists by system.

Activity

This element states that the more a system is processed, the larger the problem it can create. Therefore, activity is defined as how often a system is processed.

Dependence

This element represents the relative importance each system has to an organization.

Modifications

This element states that the more a system is changed, the greater the chance that its internal controls are affected.

Audit comfort

This element states reasons why the system may not need to be audited at any one point in time. Audit comfort is defined as the amount of confidence the auditor can place in the controls built into a system.

Comparing Old and New

The most striking thing to note is that there are no external contextual factors in the article from the EDP Auditor. The most logical explanation is, first, that in 1984 there was no Internet to speak of, which means that cybersecurity risk did not yet exist and, second, there was little or no IT-related regulation and, therefore, the associated compliance requirements. This may have been a great time to be an IT auditor.

When reviewing the internal contextual factors, my immediate reaction was that much has changed. We are now defining risk factors with the full power of COBIT 2019. Consider all the volunteer hours, over 50 years, before and after the first release of COBIT, that it took to make COBIT 2019 what it is today—one of the most widely respected frameworks in the world. It is, therefore, unfair to expect the 1984 article to meet these standards.

However, after rereading the EDP Auditor article several times, something struck me: Considering the type of system and fraud is considering current I&T-related issues. Considering system activity is considering IT goals. Considering system dependence is considering the role of IT. In taking account audit comfort, the article reflects upon whether the application was purchased or developed in house—in other words the sourcing model for IT. In fact, there is a correlation between the risk factors in both articles, as shown in figure 4.

Figure 4—Article Risk Factors

Godier Article Risk Factors

Cooke Article Risk Factors

Type of system

Current I&T-related issues of the enterprise

Activity

Enterprise or IT goals

Dependence

Role of IT

Modifications

IT implementation methods

Audit comfort

Sourcing model for IT

When you consider the time period in which the EDP Auditor article was written, it is quite remarkable and demonstrates true foresight. In fact, rather than considering it unfair to make a comparison, it is important to see it for what it is: a building block that has added to ISACA’s understanding, which led to the development of frameworks such as COBIT.

Conclusion

A lot has changed over the years, including the rise of the Internet and more stringent compliance requirements. Nonetheless, even back in 1984, ISACA (or the EDP) was seeing what was next, now. The article from the EDP Auditor added to ISACA’s body of knowledge and enabled other volunteers to develop COBIT, the Certified Information Systems Auditor (CISA) Review Manual and more. Sir Isaac Newton’s saying has never been truer than now, “If we have seen further, it is by standing upon the shoulders of giants.”

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 ISACA committees and is a past member of ISACA’s Certification in Governance of Enterprise IT (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 Certified in Risk and Information Systems Control (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 (Ian_J_Cooke@hotmail.com), Twitter (@COOKEI), LinkedIn (www.linkedin.com/in/ian-cooke-80700510/) or on the Audit and Assurance Online Forum (engage.isaca.org/home). Opinions expressed are his own and do not necessarily represent the views of An Post.

1 Godier, D.; “Automated Audit Risk Analysis,” EDP Auditor, vol. 2, 1984