R OCAS E STRATIFICADAS :

The second part of the “COBIT 5 for Assurance” guide addresses how the IT assurance process can be executed. As such, this section further develops the “MEA-2— Executive Assurance Initiatives” process, and it proposes three parts:

1. Determining the scope of the assurance assignment

2. Understanding the subject matter, selecting the evaluation criteria, and executing the assessment

3. Communicating and reporting the results

6.3.1

Determining the Scope of the Assurance Assignment

In the fi rst phase, the assurance professional needs to determine the scope of the assurance assignment. The assurance professional evaluates who the involved stake- holders are and what the stakes are of each of them. Next, specifi c objectives for the assurance assignment can be agreed upon. These objectives can be expressed in terms of the IT-related risks and opportunities toward achieving enterprise goals. Depending on the agreed-upon objectives, the specifi c scope of the assurance assignment can be set, articulating which processes, structures, policies, and other enablers will be assessed.

Consider the example of an assurance scope for assessing “internet banking,” more specifi cally regarding the question whether internet banking is safe for the bank. The involved stakeholders in this case range from the board of directors up to IT management roles. Relevant IT goals that are selected for this case are “Manage IT-related business risks” and “security of information.” The selected enablers in scope include structures such as the IT development department, pro- cesses such as APO10-Manage suppliers and policies such as the security policy.

It should be clear that the cascade developed in COBIT 5, linking enterprise goals to IT-related goals and processes, can be very instrumental in determining an appropriate scope in the context of specifi c IT goals and/or enterprise goals.

141

6.3.2

Executing the IT Assurance Initiative

In the execution phase, two steps are crucial: understanding the subject matter and performing the assessment steps.

It is indeed important that the assurance professional has a good understanding and knowledge over the subject matter he/she is going to assess. ISACA has devel- oped more detailed guidance on each of the seven enablers (processes, structures, etc.) they propose, and of course this information will be helpful in understanding the subject matter.

Next, the appropriate assurance steps need to be executed. “Testing Control Design” (often also referred to as “testing the design effectiveness”) covers the assurance steps to be performed to assess the adequacy of the design of controls. This assurance activity includes the evaluating of the appropriateness of control measures for the process under review by considering identifi ed criteria, industry standard practices, and applying professional judgment.

Figure 6.13 provides examples for the COBIT process BAI6— Manage changes , as derived from the management practices and activities presented in the “COBIT 5—Enabling Processes” guide (see Chap. 5 ). The fi rst assurance steps provided is “Enquire whether and confi rm that the change management process allows business process owners and IT to request changes to infrastructure, systems, or applications.” These assurance steps typically are based on interviews with key stakeholders in the organization, leading to narratives describing the control mea- sures applied in the organization.

The “COBIT 5 for Assurance” guide refers to typical generic testing methods such as enquire, confi rm, observe, and inspect. “Enquire and confi rm” is about ask- ing management questions to obtain an understanding of the processes and/or applications and includes the search and examination of exceptions and deviations. “Observe” is about the observation and description of the processes and procedures. “Inspect” includes the review of plans, policies, and procedures, the tracing of

• Enquire whether and confirm that the change management

process allows business process owners and IT to request changes to infrastructure, systems or applications.

• Enquire whether and confirm that the overall change management

process includes emergency change procedures (e.g., defining, raising, testing, documenting, assessing and authorising emergency changes).

Fig. 6.13 Testing the control design

transactions through the processes/systems, physically inspection of the presence of documentation and assets, ….

To identify to key interviewees in this assurance process, the assurance profes- sional can leverage COBIT’s RACI charts, looking for those people who are in the fi rst place accountable (A) and responsible (R) (see Chap. 5 ) for these activities. Further, when asking for documentation the assurance professional can consult the inputs/outputs tables of COBIT, giving information on typical documentation to be expected in the process under review.

After “testing the control design,” “Testing the outcome of control objectives” (often also referred to as “testing the operational effectiveness”) addresses the assur- ance steps to be performed to ensure that the control measures established are work- ing as prescribed, consistently and continuously. These assurance steps typically are about inspecting samples, recalculations, etc. When looking for documentation to retrieve “evidence” in these activities, the assurance professional can consult the inputs/outputs tables of COBIT, giving information on typical documentation to be expected in this process.

The testing of the outcome in many cases is performed on the basis of samples. There are many factors that determine sample sizes. Figure 6.14 represents a com- mon sample size used in practice by auditors to test the operating effectiveness of controls.

Figure 6.15 provides examples for the COBIT process BAI6— Manage changes , such as “inspect a selection of changes and determine if requests have been cat- egorized.” Again, these questions are derived from the management practices and activities as defi ned in the “COBIT 5—Enabling Processes” guide.

6.3.3

Communicate and Report

If control weaknesses are identifi ed based on previous steps, “Testing the impact of the control weaknesses” encompasses the assurance steps to document and report on potential business risks if specifi c control objectives are not met. Main issue here is that the assurance professional should not just report on control weaknesses (e.g., “we found evidence that there is no project management methodology”),

143

but the assurance professional should demonstrate what the potential business impact of these weaknesses is (e.g., the likelihood of IT project failing increases, causing budgets overruns or a longer time-to-market). Typical examples are provided in Fig. 6.16 for the example of the COBIT process BAI6— Manage changes . In most cases, the assurance professional tries to estimate the potential cost, loss of time, business impact, etc. due to the control weaknesses. The IT assurance professional can leverage COBIT’s goals and metrics tables to clarify the business issues at risk.

• Inspect a selection of changes and determine if requests have

been categorised.

• Inspect a selection of changes and determine if changes have been

prioritised based on predefined criteria.

• Inspect a selection of changes and determine if changes have been

assessed in a structured method (e.g., security, legal, contractual and compliance implications are considered and business owners are involved).

• Inspect a sample of emergency changes and verify that they have

been processed in accordance with the change management framework. Verify that procedures have been followed to authorise, document, revoke access after change has been applied.

Fig. 6.15 Testing the outcome of control objectives

• Assess the time and cost of lack of formal change management

standards and procedures (e.g., improper resource allocation, unclear roles and responsibilities, security breaches, lack of rollback procedures, lack of documentation and audit trails, inadequate training).

• Assess the time and cost of lack of formal impact assessment to

prioritise and authorise changes.

• Assess the time and cost of lack of formal emergency change

standards and procedures (e.g., compromised security, failure tà properly terminate additional access authorisations, unauthorised access to corporate information).

Fig. 6.16 Testing the impact of control weaknesses