{"id":818,"date":"2011-09-08T03:00:26","date_gmt":"2011-09-08T03:00:26","guid":{"rendered":"https:\/\/live.lleox.org\/?p=818"},"modified":"2013-10-04T00:59:45","modified_gmt":"2013-10-04T00:59:45","slug":"cobit-22-23","status":"publish","type":"post","link":"https:\/\/live.lleox.org\/2011\/cobit-22-23\/","title":{"rendered":"cobit 22-23"},"content":{"rendered":"
\n
\n
\n

Develop and Report Overall Conclusion and Recommendations<\/p>\n

The substantiated risk of the control weaknesses must be communicated to the different stakeholders of the assurance initiative. The assurance professional should document any identified control weaknesses and resulting threats and vulnerabilities, and identify and
\ndocument the actual and potential impact. In addition, the assurance professional may provide comparative information, e.g., through benchmarks, to establish a reference framework in which the test results ought to be evaluated. The objective is to identify items of significance to be able to articulate to the stakeholder the recommended actions and reasons for taking action.<\/p>\n

This phase includes aggregating the results of the previous phases, developing a conclusion concerning the identified control weaknesses and communicating:<\/p>\n

\u2022 Recommended actions to mitigate the impact of the control weaknesses<\/p>\n

\u2022 Performance comparison to standards and best practices for a relative view on the results<\/p>\n

\u2022 The risk associated with a failure to perform the process effectively<\/p>\n

The formulated conclusion and recommendations should allow the responsible party to take further steps and remedial actions. When the assurance initiative is performed within an assurance context, the assurance professional needs to be thoughtful of formal assurance communication and compliant with assurance reporting standards and guidelines.<\/p>\n

EXAMPLES OF THE USE OF DETAILED ASSURANCE STEPS<\/p>\n

The following sections provide illustrative examples of how the assurance testing steps could be applied.<\/p>\n

Testing of Control Design<\/p>\n

Situation: General computer controls review in a transaction processing organisation; assessment of the COBIT process AI6<\/p>\n

Manage Changes; COBIT control objective AI6.2 Impact assessment, prioritisation and authorisation<\/p>\n

Observations: For the selected systems (e.g., application, platform or network), the assurance professional inventoried the types of changes that can be implemented, procedures (formal or informal) currently in place, all parties involved in the change
\nmanagement process, tools used, etc. This was done through interviews with involved persons and enquiries for documented procedures. The result of this work was a comprehensive and correct flowchart of the change management process.<\/p>\n

The assurance professional reviewed the identified process flow to determine whether there was a step defined in the procedure to assess the impact of a change by a competent person or group of persons. The assurance professional observed that the template for requesting and approving changes included a section on impact assessment. However, the change management procedure did not mention that this information is mandatory, and the absence of this information did not lead to a rejection of the change request. In addition, the procedure did not mention any documentation standards or required verification and approval steps for the impact assessment.<\/p>\n

Test Result: The design of this control is flawed, because a fundamental component of the control, i.e., impact assessment, is incomplete at best. It is possible that changes are implemented without proper risk assessment, which can lead to unplanned and difficult-to-contain operational disruptions or malfunctions.<\/p>\n

Testing for the Effectiveness of the Control<\/p>\n

Situation: General computer controls review in a transaction processing organisation; assessment of the COBIT process AI6<\/p>\n

Manage Changes; COBIT control objective AI6.3 Emergency changes<\/p>\n

Observations: As part of the evaluation of the control design, the assurance professional identified that, for all relevant change management procedures, there is a control defined to help ensure that emergency change requests are reintroduced into the normal change management cycle. In addition, the assurance professional found that there is a procedure that ensures that all emergency changes are appropriately logged in a change management tool.<\/p>\n

As part of the control effectiveness testing, a sample of emergency change requests was selected from the change management tool and traced to their reintroduction as normal changes. This tracing included verification of whether the emergency change was actually introduced again as a normal change and whether it was processed following the
\nnormal change management procedure.<\/p>\n

The assurance professional observed that from the sample of 25 emergency changes selected, three were not subsequently reprocessed as normal changes. In addition, the assurance professional found that from the 22 emergency changes that had been duly reintroduced, only 10 were discussed at the change management board\u2014or at
\nleast that there was a trace available that indicated that the 10 changes were discussed (trace included information stored in the change management tool).<\/p>\n

Test Result:
\nThe emergency change procedure is not effective for two reasons:<\/p>\n

\u2022 Not all emergency changes are reintroduced in the system, leading to a risk of losing emergency changes from sight and not learning from them.<\/p>\n

\u2022 Emergency changes that have been reintroduced are most likely inadequately discussed and documented, leading to the same risk.<\/p>\n

Documenting the Impact of Control Weaknesses<\/p>\n

Situation: General computer controls review in a transaction processing organisation; assessment of the COBIT process AI6<\/p>\n

Manage Changes; COBIT control objective AI6.3 Emergency changes<\/p>\n

Observations: Using the situation as described, the assurance professional needed to gain additional information and perform further analysis to assess and document the impact of the control weaknesses. For the aforementioned examples, the assurance professional needed to consider the types and numbers of changes affected by the control weaknesses.<\/p>\n

Some of the required information might\/should already be gathered at the planning stage. This information should be used to evaluate the materiality of the weaknesses noted. Notably, the changes affected should be mapped back to the relevant infrastructure components and the applications\/information they support\/process. In addition, SLA penalties might apply. Analysis of problems noted in the past can help establish the real potential impact of the weaknesses noted.<\/p>\n

In this case, it turns out, after discussion with the responsible change manager and confirmation with other change management board members, that the missing emergency changes relate to non-critical systems, and that the missing documentation was only a documentation issue, whereas the actual change, its cause and consequences had, indeed,
\nbeen discussed but were not formally documented.<\/p>\n

Test Result: Although the control weaknesses remain as they have been observed, further analysis and documentation showed that the weaknesses were of a lesser importance than originally assessed.<\/p>\n

CONCLUSION<\/p>\n

An assurance initiative involves three phases. First, the assurance professional must develop a plan that identifies the assurance universe and uses an appropriate IT control framework to identify the assurance objectives based on a high-level risk assessment. Second, the initiative must be scoped through a top-down analysis that identifies the business goals to be examined and the IT goals that support those business goals, then identifies the IT processes and resources necessary to accomplish the IT goals and the key control objectives that must be accomplished for those processes to function effectively. Third, the initiative must be executed by refining understanding of the key control objectives within the assurance universe, evaluating the design and operational effectiveness of control procedures that address key control objectives, evaluating the impact of any deficiencies that come to light, and communicating findings and recommendations to stakeholders.<\/p>\n<\/div>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

Develop and Report Overall Conclusion and Recommendations The substantiated risk of the control weaknesses must be communicated to the different…<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-818","post","type-post","status-publish","format-standard","hentry","category-blog"],"featured_image_urls_v2":{"full":"","thumbnail":"","medium":"","medium_large":"","large":"","1536x1536":"","2048x2048":"","post-thumbnail":""},"post_excerpt_stackable_v2":"

Develop and Report Overall Conclusion and Recommendations The substantiated risk of the control weaknesses must be communicated to the different stakeholders of the assurance initiative. The assurance professional should document any identified control weaknesses and resulting threats and vulnerabilities, and identify and document the actual and potential impact. In addition, the assurance professional may provide comparative information, e.g., through benchmarks, to establish a reference framework in which the test results ought to be evaluated. The objective is to identify items of significance to be able to articulate to the stakeholder the recommended actions and reasons for taking action. This phase…<\/p>\n","category_list_v2":"Blog<\/a>","author_info_v2":{"name":"lleox","url":"https:\/\/live.lleox.org\/author\/lleox\/"},"comments_num_v2":"0 comentarios","_links":{"self":[{"href":"https:\/\/live.lleox.org\/wp-json\/wp\/v2\/posts\/818","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/live.lleox.org\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/live.lleox.org\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/live.lleox.org\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/live.lleox.org\/wp-json\/wp\/v2\/comments?post=818"}],"version-history":[{"count":0,"href":"https:\/\/live.lleox.org\/wp-json\/wp\/v2\/posts\/818\/revisions"}],"wp:attachment":[{"href":"https:\/\/live.lleox.org\/wp-json\/wp\/v2\/media?parent=818"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/live.lleox.org\/wp-json\/wp\/v2\/categories?post=818"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/live.lleox.org\/wp-json\/wp\/v2\/tags?post=818"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}