Preparation for WB

Follow ITIL processes for incident management, change management, and problem management

Incident Management

The goal of Incident Management is to restore normal service operation as quickly as possible and minimize the adverse effect on business operations, thus ensuring that the best possible levels of service quality and availability are maintained. 'Normal service operation' is defined here as service operation within Service Level Agreement (SLA) limits.

Problem Management
The goal of 'Problem Management' is to resolve the root cause of incidents and thus to minimize the adverse impact of incidents and problems on business that are caused by errors within the IT infrastructure, and to prevent recurrence of incidents related to these errors. A `problem' is an unknown underlying cause of one or more incidents, and a `known error' is a problem that is successfully diagnosed and for which either a work-around or a permanent resolution has been identified. The CCTA defines problems and known errors as follows:
A problem is a condition often identified as a result of multiple Incidents that exhibit common symptoms. Problems can also be identified from a single significant Incident, indicative of a single error, for which the cause is unknown, but for which the impact is significant.
A known error is a condition identified by successful diagnosis of the root cause of a problem, and the subsequent development of a Work-around.
Problem management is different from incident management. The principal purpose of problem management is to find and resolve the root cause of a problem and prevention of incidents; the purpose of incident management is to return the service to normal level as soon as possible, with smallest possible business impact.
The problem management process is intended to reduce the number and severity of incidents and problems on the business, and report it in documentation to be available for the first-line and second line of the help desk. The proactive process identifies and resolves problems before incidents occur. These activities are:
• Trend analysis;
• Targeting support action;
• Providing information to the organization.
The Error Control Process is an iterative process to diagnose known errors until they are eliminated by the successful implementation of a change under the control of the Change Management process.
The Problem Control Process aims to handle problems in an efficient way. Problem control identifies the root cause of incidents and reports it to the service desk. Other activities are:
• Problem identification and recording;
• Problem classification;
• Problem investigation and diagnosis.
The standard technique for identifying the root cause of a problem is to use an Ishikawa diagram, also referred to as a cause-and-effect diagram, tree diagram, or fishbone diagram. A brainstorming session—in which group members offer product improvement ideas—typically results in an Ishikawa diagram. For problem-solving, the goal is to find causes and effects of the problem.
First there is the main subject, which is the backbone of the diagram that we are trying to solve or improve. The main subject is derived from a cause. The relationship between a cause and an effect is a double relation: an effect is a result of a cause, and the cause is the root of an effect. But there is just one effect for several causes and one cause for several effects.
Change Management
The goal of Change Management is to ensure that standardized methods and procedures are used for efficient handling of all changes,
Main article: Change Management (ITSM)
A change is “an event that results in a new status of one or more configuration items (CI's)” approved by management, cost effective, enhances business process changes (fixes) - with a minimum risk to IT infrastructure.
The main aims of Change Management are:
• Minimal disruption of services
• Reduction in back-out activities
• Economic utilization of resources involved in the change

Compliance with financial controls, audit and SOX standards
Sox Standards: IT plays a critical role in the operations of an organization. Indeed, it is difficult to imagine a successful organization existing in the 21st century without some level of reliance on IT systems. In today’s environment, financial reporting processes are driven by IT systems. Such systems are deeply embedded in initiating, authorizing, recording, processing and reporting of financial transactions. As such, they are inextricably linked to the overall financial reporting process and need to be assessed, along with other important processes, for compliance with the Sarbanes-Oxley Act.
There are three key building blocks required to ensure that IT controls exist and are formalized or structured in a way required by an organization?s management or its auditors, such that their design, assessment and remediation is totally integrated into the Sarbanes-Oxley compliance initiative. A SOX404 compliance application must support all of these three building blocks.
Building Block #1: Seamless integration of the three process-level controls - IT application controls, IT general controls and manual controls.
Since business processes and technology are deeply intertwined, there are three types of business process specific controls that exist within an enterprise:
* Process-level IT application controls: These are controls that are implemented within an ERP system. Examples in an order-to-cash process include a control that ensures that the orders should only be processed within a customer?s credit limits or a control that ensures that all goods shipped are invoiced
* Process-level general IT controls: These are controls that are implemented to ensure consistency and predictability of the ERP application that supports the business process. Examples in an order-to-cash process include a control that implements adequate security to prevent unauthorized access into the order management application or a control that ensures the version upgrade process for order management application is well defined and always followed.
* Process-level manual controls: These are process-level controls implemented manually outside the ERP system. Examples in an order-to-cash process include a control that ensures that the orders and cancellations are input correctly into the ERP application or a control that ensures users are well trained on the sales order policies.
Any compliance software must ensure that these three controls are seamless integrated within a single environment. As a result, the compliance software must provide mechanisms to seamlessly combine all of the three types of controls into a test suite to enable risk-based internal control assessment of a process or a sub-process.

Building Block #2: Automatic testing of process-level IT application controls and incorporation of its result into the overall results of the test suite.
In absence of any automation, most organizations end up manually testing hundreds of process-level IT application controls within their environment. For example, let?s take a control that ensures that the orders should only be processed within a customer?s credit limit. This control is typically implemented within an organization?s ERP system, but can be overridden for exceptions with proper authorization. Typically, most companies would print a report that lists out all orders that were processed within the last quarter, their credit limit at that time and if the override was applied, who applied the override and their role/title at the time the override was applied. Then the internal audit team would manually review each and every entry in the report and ensure that the control worked for every situation to score the control test as ?having passed?. If not, they would score the control test as ?having failed? and would have to manually record every instance the test failed, so that proper disclosures and remediation processes could be triggered.
Such a manual process would have to recur every specified period for the testing that control and is repeated for every control within the organization. With hundreds of controls within an organization, manual testing of process-level IT application controls provides a major opportunity for reduction of cost of compliance. In addition, the sheer complexity of manually testing such controls in a large organization with heterogeneous systems increases exponentially.
Next generation of SOX compliance solution enables companies to address this issue and significantly reduce their cost of compliance by providing a framework that performs all of the following activities
* Identifies if a control within the test documentation is a manual or application control. As a result, an application control does not need to be documented separately and eliminates the potential nightmare from co-relating application control documentation to test documentation.
* Automates the testing of application controls via the ?push of a button? by reading the relevant data within the ERP system and applying the testing logic
* Reports the results for the entire test ? including manual and application controls, in an integrated manner. It captures the detailed scoring from the audit (for manual controls) and specifics details of records read and which records passed and which records failed the test and why (for application controls) as a part of integrated reporting, so the results can be easily reviewed by an internal or external auditor in future to ?prove? that the testing occurred and control is working as required. The compliance solution typically leverages the APIs to access the data within the popular ERP systems such as SAP, Oracle and PeopleSoft, as well as legacy/homegrown systems. Such a solution typically provides an out-of-the-box library containing hundreds of tests for automating the testing of application level controls within general ledger, procure-to-pay, order-to-cash, inventory / cost Accounting, asset management and payroll processes.
Building Block #3: Ability to easily define and assess relevant overall IT controls ? typically derived from COBIT model - and reconcile them for the selected assessment framework such as COSO

Most organizations implement overall IT controls, which apply to all information systems, to ensure secure and continuous operation of their entire information systems in order to mitigate risks with financial reporting. Such controls are typically derived from COBIT control processes and when implemented, not only reduce IT related risks in financial reporting, but also form the basis for good IT Governance. These overall controls affect the following IT related processes:
* Acquire or develop application system software: Controls within IT organization provide reasonable assurance that infrastructure application and system software that is acquired or developed effectively supports financial reporting requirements. If the software is acquired, the process ensures that requirements are adequately defined and approved and software is evaluated against those requirements. If the software is developed or customized, kit ensures software development lifecycle is followed to ensure that the application will implement the requirements.
* Acquire technology infrastructure: Controls within IT organization provide reasonable assurance that technology infrastructure including servers, networks and databases that are acquired provide a secure and reliable information processing platform to support financial reporting applications.
* Develop and maintain policies and procedures: Controls within IT organization provide reasonable assurance that Policies and procedures include the SDLC methodology, the process for acquiring, developing and maintaining applications, as well as service level agreements, operational practices and training materials etc have been developed and are maintained, and that they define the documentation needed to support the proper use of the applications and the technological solutions for financial reporting.
* Install and test application software and technology infrastructure: Controls within IT organization provide reasonable assurance that the systems are appropriately tested and validated prior to being placed into production processes and associated controls operate as intended and support financial reporting requirements.
* Manage changes: Controls within IT organization provide reasonable assurance that system changes of financial reporting significance are authorized and appropriately tested before being moved to production.
* Service Levels: Controls within IT organization provide reasonable assurance that service levels are defined and managed in a manner that satisfies financial reporting system requirements and provides a common understanding of performance levels with which the quality of services will be measured. The controls must support Information Technology Infrastructure Library (ITIL) guidelines.
* Third Party: Controls within IT organization provide reasonable assurance that third-party services are secure, accurate and available, support processing integrity and defined appropriately in performance contracts.
* Access Control: Controls within IT organization provide reasonable assurance that a user ID in any of their enterprise systems that affect financial reporting matches to a specific person.
* Security: Controls within IT organization provide reasonable assurance that financial reporting systems and subsystems are appropriately secured to prevent unauthorized use, disclosure, modification, damage or loss of data. The controls must also be in compliance with ISO17799 specifications.
* Configuration Management: Controls within IT organization provide reasonable assurance that all IT components, as they relate to security, processing and availability, are well protected, would prevent any unauthorized changes, and assist in the verification and recording of the current configuration.
* Incident Management: Controls within IT organization provide reasonable assurance that any problems and/or incidents are properly responded to, recorded, resolved or investigated for proper resolution. The controls must support ITIL guidelines.
* Operations: Controls within IT organization provide reasonable assurance that authorized programs are executed as planned and deviations from scheduled processing are identified and investigated, including controls over job scheduling, processing, error monitoring and system availability.
The next generation of SOX compliance software should be able to define IT as a separate function with various processes listed above, define risk & control definition for IT sub-processes (controls as shown above) and drive the assessment and remediation process associated with these controls. By implementing this framework, an organization can also ensure compliance with COBIT/ISO17799/ITIL, while confirming to the COSO framework for assessment of general IT controls for financial reporting.
Summary
IT systems are inextricably linked to the overall financial reporting process and need to be assessed, along with other important processes, for compliance with the Sarbanes-Oxley Act. In this brief, we have identified three key building blocks to ensure that IT controls exist and are structured in a way required by an organization?s management or its auditors, such that their design, assessment and remediation is totally integrated into the Sarbanes-Oxley compliance initiative. A next generation SOX404 compliance application must support all of these three building block
How Sarbanes-Oxley Will Change the Audit Process
SARBANES-OXLEY WILL MEAN BIG CHANGES FOR BOTH auditors and the companies they audit. The former now will be required to certify a company’s internal controls and will no longer be able to use certain common audit strategies. Management faces the cost of implementing the new rules.
ACCORDING TO THE EXPOSURE DRAFT OF A NEW SAS , the understanding of internal controls required for CPAs to express an opinion on financial statements is not adequate for them to offer an opinion on the controls themselves. This means auditors will have to make changes to the audit process.
THE AUDITOR MUST ATTEST TO MANAGEMENT’S assessment of the effectiveness of an entity’s internal controls using standards the Public Company Accounting Oversight Board issues or adopts. The auditor will require management to identify, document and evaluate significant internal controls—management cannot delegate this function to the auditor.
AUDITORS SHOULD ADVISE COMPANIES TO BEGIN the process of assessing the effectiveness of controls as early as possible. The task will be time-consuming, requiring management to determine which locations or business units to include in its evaluation.
AUDITORS SHOULD NOT BE TOO CLOSELY INVOLVED with a company’s assessment of its controls or they risk impairing their objectivity. The auditor cannot accept management’s responsibility to reach conclusions on the effectiveness of the entity’s controls nor can management base its assertion about the controls design and operating effectiveness on the results of the auditor’s tests.