Risk Management in IT Projects

Submitted To: Mr. Lovneesh Chanana Assoc. Director Ernst & Young
[Type text]

Submitted By: Ankur Saini 11810016 MBA 2nd Year DoMS IIT Roorkee
Page 1

RISK MANAGEMENT IN IT PROJECTS

Abstract
The development and implementation of IT (Information Technology) projects are plagued with problems of cost and time over runs, technical inadequacy, inability to meet user requirements, lack of utilization, and failure to achieve anticipated benefits. These problems occur to some projects and not to other because 1) IT projects have different profiles of risk, and 2) IT project risks have been managed more or less effectively. This paper provides a foundation for the development of an effective risk management program, containing both the definitions and the practical guidance necessary for assessing and mitigating risks identified within IT systems. The ultimate goal is to help organizations to better manage IT-related mission risks. In addition, this paper provides information on the selection of cost-effective security controls. These controls can be used to mitigate risk for the better protection of mission-critical information and the IT systems that process, store, and carry this information. Organizations may choose to expand or abbreviate the comprehensive processes and steps suggested in this guide and tailor them to their environment in managing IT-related mission risks.

Management Information System Term Paper

Page 2

RISK MANAGEMENT IN IT PROJECTS

Contents
1. 2. INTRODUCTION ............................................................................................................................... 4 RISK MANAGEMENT OVERVIEW ..................................................................................................... 5 2.1 IMPORTANCE OF RISK MANAGEMENT ............................................................................... 5

2.2 INTEGRATION OF RISK MANAGEMENT INTO SDLC ................................................................... 5 2.3 KEY ROLES ........................................................................................................................... 7

3. RISK ASSESSMENT .............................................................................................................................. 8 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 4. STEP 1: SYSTEM CHARACTERIZATION ................................................................................ 9 STEP 2: THREAT IDENTIFICATION ..................................................................................... 10 STEP 3: VULNERABILITY IDENTIFICATION......................................................................... 10 STEP 4: CONTROL ANALYSIS ............................................................................................. 10 STEP 5: LIKELIHOOD DETERMINATION............................................................................. 10 STEP 6: IMPACT ANALYSIS ................................................................................................ 11 STEP 7: RISK DETERMINATION ......................................................................................... 11 STEP 8: CONTROL RECOMMENDATIONS ......................................................................... 11 STEP 9: RESULTS DOCUMENTATION ................................................................................ 11

RISK MITIGATION .......................................................................................................................... 12 4.1 4.2 RISK MITIGATION OPTIONS............................................................................................... 12 RISK MITIGATION STRATEGY ............................................................................................. 12

5.

EVALUATION AND ASSESSMENT ................................................................................................... 14 5.1 5.2 GOOD SECURITY PRACTICE ............................................................................................... 14 KEYS FOR SUCCESS ............................................................................................................ 14

6.

Case Study: IT Risk Management in a Bank .................................................................................. 15

7. Risk IT Case Study: Risk IT Framework for IT Risk Management: A Case Study of National Stock Exchange of India Limited ..................................................................................................................... 21

Management Information System Term Paper

Page 3

RISK MANAGEMENT IN IT PROJECTS

1. INTRODUCTION
Every organization has a mission. In this digital era, as organizations use automated information technology (IT) systems to process their information for better support of their missions, risk management plays a critical role in protecting an organizations information assets, and therefore its mission, from IT-related risk. An effective risk management process is an important component of a successful IT security program. The principal goal of an organizations risk management process should be to protect the organization and its ability to perform their mission, not just its IT assets. Therefore, the risk management process should not be treated primarily as a technical function carried out by the IT experts who operate and manage the IT system, but as an essential management function of the organization.

Management Information System Term Paper

Page 4

RISK MANAGEMENT IN IT PROJECTS

2. RISK MANAGEMENT OVERVIEW

This paper describes the risk management methodology, how it fits into each phase of the SDLC, and how the risk management process is tied to the process of system authorization (or accreditation). 2.1 IMPORTANCE OF RISK MANAGEMENT

Risk management encompasses three processes: risk assessment, risk mitigation, and evaluation and assessment. Section 3 of this paper describes the risk assessment process, which includes identification and evaluation of risks and risk impacts, and recommendation of risk-reducing measures. Section 4 describes risk mitigation, which refers to prioritizing, implementing, and maintaining the appropriate risk-reducing measures recommended from the risk assessment process. Section 5 discusses the continual evaluation process and keys for implementing a successful risk management program. The DAA or system authorizing official is responsible for determining whether the remaining risk is at an acceptable level or whether additional security controls should be implemented to further reduce or eliminate the residual risk before authorizing (or accrediting) the IT system for operation. Risk management is the process that allows IT managers to balance the operational and economic costs of protective measures and achieve gains in mission capability by protecting the IT systems and data that support their organizations missions. This process is not unique to the IT environment; indeed it pervades decision-making in all areas of our daily lives. Take the case of home security, for example. Many people decide to have home security systems installed and pay a monthly fee to a service provider to have these systems monitored for the better protection of their property. Presumably, the homeowners have weighed the cost of system installation and monitoring against the value of their household goods and their familys safety, a fundamental mission need. The head of an organizational unit must ensure that the organization has the capabilities needed to accomplish its mission. These mission owners must determine the security capabilities that their IT systems must have to provide the desired level of mission support in the face of real-world threats. Most organizations have tight budgets for IT security; therefore, IT security spending must be reviewed as thoroughly as other management decisions. A well-structured risk management methodology, when used effectively, can help management identify appropriate controls for providing the mission-essential security capabilities. 2.2 INTEGRATION OF RISK MANAGEMENT INTO SDLC Minimizing negative impact on an organization and need for sound basis in decision making are the fundamental reasons organizations implement a risk management process for their IT systems. Effective risk management must be totally integrated into the SDLC. IT systems SDLC has five phases: initiation, development or acquisition, implementation, operation or maintenance, and disposal. In some cases, IT system may occupy several of these phases at the same time. However, the risk management methodology is the same regardless of the SDLC phase for which the assessment is being conducted. Risk management is an iterative process that can be performed during each major phase of the SDLC. Table 2-1 describes the characteristics of each SDLC phase and indicates how risk management can be performed in support of each phase. Management Information System Term Paper Page 5

RISK MANAGEMENT IN IT PROJECTS

Table 2-1 Integration of Risk Management into the SDLC

Support from Risk Management Activities Phase 1Initiation The need for an IT system is expressed and the purpose and scope of the IT system is documented Identified risks are used to support the development of the system requirements, including security requirements, and a security concept of operations (strategy) The risks identified during this phase can be used to support the security analyses of the IT system that may lead to architecture and design trade- offs during system development

Phase 2Development or Acquisition

The IT system is designed, purchased, programmed, developed, or otherwise constructed

Phase 3Implementation

Phase 4Operation or Maintenance

The risk management process supports the assessment of the system implementation against its requirements and within its modeled operational environment. Decisions regarding risks identified must be made prior to system operation Risk management activities are The system performs its functions. performed for periodic system Typically the system is being reauthorization (or modified on an ongoing basis reaccreditation) or whenever major through the addition of hardware changes are made to an and software and by changes to IT system in its operational, organizational processes, policies, production environment (e.g., new and procedures system interfaces) The system security features should be configured, enabled, tested, and verified Risk management activities are performed for system components that will be disposed of or replaced to ensure that the hardware and software are properly disposed of, that residual data is appropriately handled, and that system migration is conducted in a secure and systematic manner Page 6

Phase 5Disposal

This phase may involve the disposition of information, hardware, and software. Activities may include moving, archiving, discarding, or destroying information and sanitizing the hardware and software

Management Information System Term Paper

RISK MANAGEMENT IN IT PROJECTS

2.3

KEY ROLES

Risk management is a management responsibility. This section describes the key roles of the personnel who should support and participate in the risk management process.

Senior Management. Senior management, under the standard of due care and ultimate responsibility for mission accomplishment, must ensure that the necessary resources are effectively applied to develop the capabilities needed to accomplish the mission. They must also assess and incorporate results of the risk assessment activity into the decision making process. An effective risk management program that assesses and mitigates IT-related mission risks requires the support and involvement of senior management. Chief Information Officer (CIO). The CIO is responsible for the agencys IT planning, budgeting, and performance including its information security components. Decisions made in these areas should be based on an effective risk management program. System and Information Owners. The system and information owners are responsible for ensuring that proper controls are in place to address integrity, confidentiality, and availability of the IT systems and data they own. Typically the system and information owners are responsible for changes to their IT systems. Thus, they usually have to approve and sign off on changes to their IT systems (e.g., system enhancement, major changes to the software and hardware). The system and information owners must therefore understand their role in the risk management process and fully support this process. Business and Functional Managers. The managers responsible for business operations and IT procurement process must take an active role in the risk management process. These managers are the individuals with the authority and responsibility for making the trade-off decisions essential to mission accomplishment. Their involvement in the risk management process enables the achievement of proper security for the IT systems, which, if managed properly, will provide mission effectiveness with a minimal expenditure of resources. ISSO. IT security program managers and computer security officers are responsible for their organizations security programs, including risk management. Therefore, they play a leading role in introducing an appropriate, structured methodology to help identify, evaluate, and minimize risks to the IT systems that support their organizations missions. ISSOs also act as major consultants in support of senior management to ensure that this activity takes place on an ongoing basis. IT Security Practitioners. IT security practitioners (e.g., network, system, application, and database administrators; computer specialists; security analysts; security consultants) are responsible for proper implementation of security requirements in their IT systems. As changes occur in the existing IT system environment (e.g., expansion in network connectivity, changes to the existing infrastructure and organizational policies, introduction of new technologies), the IT security practitioners must support or use the risk management Management Information System Term Paper Page 7

RISK MANAGEMENT IN IT PROJECTS process to identify and assess new potential risks and implement new security controls as needed to safeguard their IT systems. Security Awareness Trainers (Security/Subject Matter Professionals). The organizations personnel are the users of the IT systems. Use of the IT systems and data according to an organizations policies, guidelines, and rules of behaviour is critical to mitigating risk and protecting the organizations IT resources. To minimize risk to the IT systems, it is essential that system and application users be provided with security awareness training. Therefore, the IT security trainers or security/subject matter professionals must understand the risk management process so that they can develop appropriate training materials and incorporate risk assessment into training programs to educate the end users.

3. RISK ASSESSMENT
Risk assessment is the first process in the risk management methodology. Organizations use risk assessment to determine the extent of the potential threat and the risk associated with an IT system throughout its SDLC. The output of this process helps to identify appropriate controls for reducing or eliminating risk during the risk mitigation process, as discussed in Section 4. Risk is a function of the likelihood of a given threat-sources exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization. To determine the likelihood of a future adverse event, threats to an IT system must be analyzed in conjunction with the potential vulnerabilities and the controls in place for the IT system. Impact refers to the magnitude of harm that could be caused by a threats exercise of vulnerability. The level of impact is governed by the potential mission impacts and in turn produces a relative value for the IT assets and resources affected (e.g., the criticality and sensitivity of the IT system components and data). The risk assessment methodology encompasses nine primary steps, which are described in Sections 3.1 through 3.9 Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9 System Characterization (Section 3.1) Threat Identification (Section 3.2) Vulnerability Identification (Section 3.3) Control Analysis (Section 3.4) Likelihood Determination (Section 3.5) Impact Analysis (Section 3.6) Risk Determination (Section 3.7) Control Recommendations (Section 3.8) Results Documentation (Section 3.9).

Steps 2, 3, 4, and 6 can be conducted in parallel after Step 1 has been completed. Figure 3-1 depicts these steps and the inputs to and outputs from each step.

Management Information System Term Paper

Page 8

RISK MANAGEMENT IN IT PROJECTS

3.1

STEP 1: SYSTEM CHARACTERIZATION

In assessing risks for an IT system, the first step is to define the scope of the effort. In this step, the boundaries of the IT system are identified, along with the resources and the information that Management Information System Term Paper Page 9

RISK MANAGEMENT IN IT PROJECTS constitute the system. Characterizing an IT system establishes the scope of the risk assessment effort, delineates the operational authorization (or accreditation) boundaries, and provides information (e.g., hardware, software, system connectivity, and responsible division or support personnel) essential to defining the risk. 3.2 STEP 2: THREAT IDENTIFICATION

A threat is the potential for a particular threat-source to successfully exercise a particular vulnerability. Vulnerability is a weakness that can be accidentally triggered or intentionally exploited. A threat-source does not present a risk when there is no vulnerability that can be exercised. In determining the trigger likelihood of a threat, one must consider specific threatsources, potential vulnerabilities, and existing controls. 3.3 STEP 3: VULNERABILITY IDENTIFICATION

The analysis of the threat to an IT system must include an analysis of the vulnerabilities associated with the system environment. The goal of this step is to develop a list of system vulnerabilities that could be exploited by the potential threat sources. 3.4 STEP 4: CONTROL ANALYSIS

The goal of this step is to analyze the controls that have been implemented, or are planned for implementation, by the organization to minimize or eliminate the likelihood (or probability) of a threats exercising a system vulnerability. To derive an overall likelihood rating that indicates the probability that a potential vulnerability may be exercised within the construct of the associated threat environment, the implementation of current or planned controls must be considered. For example, a vulnerability (e.g., system or procedural weakness) is not likely to be exercised or the likelihood is low if there is a low level of threat-source interest or capability or if there are effective security controls that can eliminate, or reduce the magnitude of, harm. 3.5 STEP 5: LIKELIHOOD DETERMINATION

To derive an overall likelihood rating that indicates the probability that a potential vulnerability may be exercised within the construct of the associated threat environment the following governing factors must be considered: Threat-source motivation and capability Nature of the vulnerability Existence and effectiveness of current controls. The likelihood that a potential vulnerability could be exercised by a given threat-source can be described as high, medium, or low

Management Information System Term Paper

Page 10

RISK MANAGEMENT IN IT PROJECTS 3.6 STEP 6: IMPACT ANALYSIS

The next major step in measuring level of risk is to determine the adverse impact resulting from a successful threat exercise of vulnerability. Before beginning the impact analysis, it is necessary to obtain the following necessary information as discussed in Section 3.1.1: System mission (e.g., the processes performed by the IT system) System and data criticality (e.g., the systems value or importance to an organization) System and data sensitivity. 3.7 STEP 7: RISK DETERMINATION

The purpose of this step is to assess the level of risk to the IT system. The determination of risk for a particular threat/vulnerability pair can be expressed as a function of The likelihood of a given threat-sources attempting to exercise a given vulnerability. The magnitude of the impact should a threat-source successfully exercise the vulnerability. The adequacy of planned or existing security controls for reducing or eliminating risk. 3.8 STEP 8: CONTROL RECOMMENDATIONS

During this step of the process, controls that could mitigate or eliminate the identified risks, as appropriate to the organizations operations, are provided. The goal of the recommended controls is to reduce the level of risk to the IT system and its data to an acceptable level. The following factors should be considered in recommending controls and alternative solutions to minimize or eliminate identified risks: 3.9 Effectiveness of recommended options (e.g., system compatibility). Legislation and regulation. Organizational policy. Operational impact. Safety and reliability. STEP 9: RESULTS DOCUMENTATION

Once the risk assessment has been completed (threat-sources and vulnerabilities identified, risks assessed, and recommended controls provided), the results should be documented in an official report or briefing. A risk assessment report is a management report that helps senior management, the mission owners, make decisions on policy, procedural, budget, and system operational and management changes. Unlike an audit or investigation report, which looks for wrongdoing, a risk assessment report should not be presented in an accusatory manner but as a systematic and analytical approach to assessing risk so that senior management will understand the risks and allocate resources to reduce and correct potential losses. For this reason, some people prefer to address the threat/vulnerability pairs as observations instead of findings in the risk assessment report.

Management Information System Term Paper

Page 11

RISK MANAGEMENT IN IT PROJECTS

4. RISK MITIGATION
Risk mitigation, the second process of risk management, involves prioritizing, evaluating, and implementing the appropriate risk-reducing controls recommended from the risk assessment process. Because the elimination of all risk is usually impractical or close to impossible, it is the responsibility of senior management and functional and business managers to use the least-cost approach and implement the most appropriate controls to decrease mission risk to an acceptable level, with minimal adverse impact on the organizations resources and mission.

4.1

RISK MITIGATION OPTIONS

Risk mitigation is a systematic methodology used by senior management to reduce mission risk. Risk mitigation can be achieved through any of the following risk mitigation options: Risk Assumption. To accept the potential risk and continue operating the IT system or to implement controls to lower the risk to an acceptable level. Risk Avoidance. To avoid the risk by eliminating the risk cause and/or consequence (e.g., forgo certain functions of the system or shut down the system when risks are identified). Risk Limitation. To limit the risk by implementing controls that minimize the adverse impact of a threats exercising vulnerability (e.g., use of supporting, preventive, detective controls). Risk Planning. To manage risk by developing a risk mitigation plan that prioritizes, implements, and maintains controls. Research and Acknowledgment. To lower the risk of loss by acknowledging the vulnerability or flaw and researching controls to correct the vulnerability. Risk Transference. To transfer the risk by using other options to compensate for the loss, such as purchasing insurance. The goals and mission of an organization should be considered in selecting any of these risk mitigation options. It may not be practical to address all identified risks, so priority should be given to the threat and vulnerability pairs that have the potential to cause significant mission impact or harm. Also, in safeguarding an organizations mission and its IT systems, because of each organizations unique environment and objectives, the option used to mitigate the risk and the methods used to implement controls may vary. The best of breed approach is to use appropriate technologies from among the various vendor security products, along with the appropriate risk mitigation option and nontechnical, administrative measures. 4.2 RISK MITIGATION STRATEGY

Senior management, the mission owners, knowing the potential risks and recommended controls, may ask, When and under what circumstances should I take action? When shall I implement these controls to mitigate the risk and protect our organization?

Management Information System Term Paper

Page 12

RISK MANAGEMENT IN IT PROJECTS The risk mitigation chart in Figure 4-1 addresses these questions. Appropriate points for implementation of control actions are indicated in this figure by the word YES.

This strategy is further articulated in the following rules of thumb, which provide guidance on actions to mitigate risks from intentional human threats: When vulnerability (or flaw, weakness) exists implement assurance techniques to reduce the likelihood of a vulnerabilitys being exercised. When vulnerability can be exercised apply layered protections, architectural designs, and administrative controls to minimize the risk of or prevent this occurrence.

When the attackers cost is less than the potential gain apply protections to decrease an attackers motivation by increasing the attackers cost (e.g., use of system controls such as limiting what a system user can access and do can significantly reduce an attackers gain). When loss is too great apply design principles, architectural designs, and technical and nontechnical protections to limit the extent of the attack, thereby reducing the potential for loss.

Management Information System Term Paper

Page 13

RISK MANAGEMENT IN IT PROJECTS

5. EVALUATION AND ASSESSMENT

In most organizations, the network itself will continually be expanded and updated, its components changed, and its software applications replaced or updated with newer versions. In addition, personnel changes will occur and security policies are likely to change over time. These changes mean that new risks will surface and risks previously mitigated may again become a concern. Thus, the risk management process is ongoing and evolving. This section emphasizes the good practice and need for an ongoing risk evaluation and assessment and the factors that will lead to a successful risk management program. 5.1 GOOD SECURITY PRACTICE The risk assessment process is usually repeated at least every 3 years for federal agencies, as mandated by OMB Circular A-130. However, risk management should be conducted and integrated in the SDLC for IT systems, not because it is required by law or regulation, but because it is a good practice and supports the organizations business objectives or mission. There should be a specific schedule for assessing and mitigating mission risks, but the periodically performed process should also be flexible enough to allow changes where warranted, such as major changes to the IT system and processing environment due to changes resulting from policies and new technologies. 5.2 KEYS FOR SUCCESS A successful risk management program will rely on (1) senior managements commitment; (2) the full support and participation of the IT team; (3) the competence of the risk assessment team, which must have the expertise to apply the risk assessment methodology to a specific site and system, identify mission risks, and provide cost-effective safeguards that meet the needs of the organization; (4) the awareness and cooperation of members of the user community, who must follow procedures and comply with the implemented controls to safeguard the mission of their organization; and (5) an ongoing evaluation and assessment of the IT-related mission risks.

Management Information System Term Paper

Page 14

RISK MANAGEMENT IN IT PROJECTS

6. Case Study: IT Risk Management in a Bank

Background The bank in the given case is a global conglomerate with operations in more than 50 countries and with more than 125,000 employees across the globe. The banks technology teams are located throughout the world to support global lines of business. The IT teams include development centres that are part of the bank and others that are outsourced to vendors, as well as technology back offices that support IT infrastructure and services. The bank had a history of multiple governance and assurance templates and processes followed by different teams, regions and locations. Hence, the key challenge was to create a common governance and assurance process across technology teams. The technology governance and assurance programme was designed through a risk management framework to ensure effective risk and control management. The framework was defined to address existing risk and control management weaknesses, such as:

Immature processes for assessing and testing compliance Lack of a single control repository, resulting in control duplication Lack of a clear, repeatable process for completing risk assessments

The new framework was expected to enable technology teams to understand the significant operational risks and their impact on the wider organisation by:

Addressing areas in which risks were not effectively controlled Allowing technology executives to demonstrate regulatory responsibilities efficiently Using a common platform for reporting all regulatory requirements across regions and countries Effectively reporting technology risk and control weaknesses that may impact the business Implementing a standard process across regions and offices to ensure consistency and avoid duplication of reporting

A team of professionalsincluding risk, IT security and US Sarbanes-Oxley Act process expertswas set up to define the processes and templates. The team primarily worked on three areas: 1. Defining a framework to useControl objective framework (COF) 2. Identifying a standard definition of entities against which risks and controls were to be evaluatedKey entity management model 3. Identifying a risk management processRisk and control assessment (RCA) Key steps in the process of developing a new risk management framework are described in the following sections. Step 1Defining COF

Management Information System Term Paper

Page 15

RISK MANAGEMENT IN IT PROJECTS The COF was defined to link risks affecting technology offices and industry standard best practice. Three objectives were set whilst defining the COF: 1. It should act as a tool to facilitate the effective assessment of risks and controls within technology. 2. It should act as a reporting framework to demonstrate how technology satisfies reporting regulatory requirements, including those of Sarbanes-Oxley. 3. It should act as an aid to drive management assurance. The steps in implementing COF:

Identify principal risks: The principal risks of level I were defined and frozen based on earlier information. Those identified included risks related to technology, operations, people, legal and regulatory, financial reporting, financial crime, brand, and change. Identify level II risks: The principal risk was further broken down into level II risks. As an example, the technology principal risk was further drilled down to: Inadequate design/testing of IT systems Unavailability of IT systems Lack of IT security Identify control objectives: For each of the level II risks, control objectives were identified u. Figure 1 indicates the mapping of the level II risks with the control objectives identified against each of the technology risks.

Benefit of Step 1

Management Information System Term Paper

Page 16

RISK MANAGEMENT IN IT PROJECTS Prior to implementing this framework, each entity, organisation and location had its own set of controls. In turn, this assisted with the attestation of each type of risk, which provided confidence to senior executives on the reporting and attestation process. Subsequently, a risk assessment process was developed to define risks and controls. This helped in ensuring that adequate controls were deployed to cover the principal risks and level II risks. Step 2Identifying Entities for Managing Risks and Controls The key entity management model was defined to include IT building blocks, against which risk and control assessments were to be performed. The IT building blocks are logically linked together for reporting purposes to provide a risk and control assessment for all supporting services within the purview of the technology office. The IT building blocks were defined as:

Process entities: These represent the processes used to support, control and manage the IT environment. Any control issues in a process entity would affect many IT services, e.g., change control is pervasive across most IT services. Supporting services entities: Linking with process and technology entities allows for a complete end-to-end risk and control assessment for that supporting service, e.g., interfacing risks amongst technology entities, service-level risks for end-to-end IT service, and integration risks (the management of handoffs between departments). Technology entities: These represent the traditional IT components, e.g., servers, applications, networks and firewalls. The service maps and the RCA process were used to facilitate the identification of the key technology entities that make up each supporting service. Project entities: Whilst project entities have no effect on the top 20 services, it is very important to capture any control and risk information ahead of go-live. This will allow the target state controls for a new development/project change to be assessed, reported and communicated prior to go-live. Some examples of the top 20 services include ATM connectivity and core banking application support services.

The banks method for defining IT services is through an IT service catalogue. As part of its IT service catalogue, each of the top 20 services was identified for the supporting services that underpin it. A service map was created for each supporting service. The service maps illustrate the technology components that are linked together to support the end-to-end services. Each process entity and technology entity is distinct and can be linked to multiple supporting services. As a result, the key entity management model is flexible and can support expansion to additional IT services as required. The linkage amongst entities allows risk assessments to be aggregated to provide an end-to-end service risk profile, which is meaningful to management and the different clusters managing the entities in the overall service. Benefit of Step 2 Prior to implementing the new risk management process, each region, country, etc., of the bank had its own risk and control matrices. The risk and controls evaluation was based on the understanding of each team working on risk management within the region, and there was no focus on the end result, i.e., the impact of risk on customer service.

Management Information System Term Paper

Page 17

RISK MANAGEMENT IN IT PROJECTS Step 3Defining and Implementing the RCA Process The process overview in figure 2 highlights the five steps to performing a risk assessment. Within each of the steps, the key tasks were identified. A series of tools/process aides was defined to assist with the scoping, scheduling and delivery of the risk assessment, and is outlined in figure 2.

The objective in developing the common RCA process was to ensure that the analyses of risks and controls were consistent across the teams globally.

Management Information System Term Paper

Page 18

RISK MANAGEMENT IN IT PROJECTS One of the tools was a simple Excel template defined to capture risk and control information. The template then was frozen for use by all of the entities. The template was defined to capture the following key information: Principal and level II risks Reference to Sarbanes-Oxley control requirements Control owner Control assessmenteffective, ineffective Actions to make the control effective Action closure detailsaction owner, target date The templates were filled by the risk and control owner and were sent to the central risk team for review. They were then entered into the risk management tool to track actions for closure and reporting on open risks. Each was tagged with: Entity ownersTypically the owners of the RCA Risk ownersThe owners responsible for the risk Control ownersThe owners responsible for maintaining control effectiveness Action ownersThe owners of actions defined due to ineffective controls Benefit of Step 3

Through training programs, the terms entity/RCA owners, risk owners, control owners and action owners were explained using a Responsible, Accountable, Consulted and Informed (RACI) chart . The responsibilities were also mapped in the job descriptions and in performance evaluation criteria of the staff. Step 4Training Key Stakeholders One of the main challenges was to explain the entire process to all of the stakeholders with different backgrounds and understanding of risks and controls and at various locations. The challenge was managed by creating additional training programs at various levels. This involved:

Creating risk experts (typically with background experience and certifications such as Certified Information Systems Auditor [CISA] and Chartered Accountant [CA]) across the regions and offices who were trained under a train-the-trainer program. Such resources were used to train the stakeholders. Tailoring the training delivered by the risk experts to the audience. For entity owners, a simple process overview was provided through mandatory computer-based training. For risk and control owners, training was detailed and included examples and tests, and it was delivered through classrooms at different locations or through web-based training sessions. Offering, as part of the mandatory training program, an awareness training session that explained the process and provided links and contacts for local risk experts within the organisation for further information and guidance. Arranging a workshop to disseminate the relevant information to stakeholders; this should begin any risk assessment process. The training resources were used to facilitate the control self-assessment (CSA) at different locations. Page 19

Management Information System Term Paper

RISK MANAGEMENT IN IT PROJECTS

Modifying the role description and performance evaluation process to include specific tasks for risks and controls

Benefit of Step 4 Due to this top-down approach, the importance of risk management was well accepted and it was effective at all levels of the organisation. Step 5Using a Reporting Tool A simple spreadsheet was used for maintaining a risk and control repository for each entity. Within the entity, the risk team member used an Excel spreadsheet for tracking risks, actions, etc. However, there was a requirement to have a single, common database repository for maintaining organisation wide risks and controls. Hence, a tool was developed to gather information for all entities. This helped in: Tracking all risks related to a service Centralising a repository for all risks and control information Tracking all actions defined and agreed to in the RCA process Tracking closure of actions Reporting to senior executives on risks based on the specific requirements and levels of risk Basing regulatory requirements reporting on a common, single database of risks and controls Benefit of Step 5 A single repository of all risks, controls and actions was used by assurance teams in their reporting to the chief information officer (CIO) and for tracking compliance at a high level. Conclusion The entire development and implementation of the new process took almost two years. While the central team was responsible for developing the process, the location-based risk resources were instrumental in implementation, training, etc. Since the implementers at the different locations were part of the team, their feedback was used in making suitable changes and corrections that helped improve the maturity of the process. Other tangible benefits of this initiative included:

Prior to this implementation, there were more than 500 entities for which risks and controls were tracked. The number was optimised to around 100 entities. This was possible due to the implementation of the key entity management model. Earlier, there were more than 1,000 controls defined. At the global level, the number of controls was reduced to almost 350. However, within a particular entity, region, country, etc., further drilling down of a control was allowed for tracking locally. For example, globally, in the RCA, a single control was identified for local compliances: local regulatory compliance control. However, this control was further drilled down to various compliances based on country-specific requirements. In India, for example, this was managed through a separate

Management Information System Term Paper

Page 20

RISK MANAGEMENT IN IT PROJECTS spreadsheet that covered all of the Indian regulations, such as employee/labour laws and taxation regulations.

The exercise helped the bank in managing risk and control process for Sarbanes-Oxley and other regulatory processes. The RCA spreadsheet provided a separate filter for SarbanesOxley compliance applicability. The process repository in the tool helped in maintaining consistency. This was done by creating a separate sub-unit within the risk team to check the quality of each RCA before it was entered in the RCA tool. A common training pack was seen as an important and valuable deliverable by the risk team and was defined based on the audience. For example, a training pack of 15 minutes for all entity owners (typically centre heads in each country or region) was developed and implemented using the e-learning portal, whereas a detailed process training pack was developed for risk and control owners.

7. Risk IT Case Study: Risk IT Framework for IT Risk Management: A Case Study of National Stock Exchange of India Limited
National Stock Exchange (NSE) is the largest stock exchange in India catering to 1,200-plus members. Globally, NSE has been ranked second in stock index options and third in single stock futures and stock index futures. The business processes of NSE are heavily dependent on IT. Average daily turnover of trades processed by NSE are INR 1,441,010. At a national level, NSE is a critical organization for the Indian economy and is identified as one of its most sensitive organizations. The criticality of business operations required NSE to focus on risk management as an integral element of its day-to-day business processes. Up until this new focus, the existing risk management process mainly focused on addressing business risk. The IT risk assessment method was complementary to the business risk processes, and the approach adopted was periodic assessment (once a year), which until now was considered adequate. However, during the review of risk assessment, it was observed that the dynamic nature of the business environment had been prompting frequent changes in IT infrastructure. These changes constituted not only changes in hardware, but also included revamping applications and identifying new service delivery channels. This prompted the decision to revisit the IT risk management approach. IT Risk Management Project The IT risk management project was initiated with a primary objective to ensure that ongoing risk assessment was an integral part of IT operational and governance processes. Milestones and deliverables for this project are listed in figure 1.

Management Information System Term Paper

Page 21

RISK MANAGEMENT IN IT PROJECTS

Choosing a Guiding Risk Management Framework As a first step to achieve the objective, a comparative study of available standards and frameworks3 was performed to identify a framework that would meet NSEs IT risk management requirements. The criteria used for evaluation is described in figure 2

NSEs Risk Management Framework Following this study, NSEs risk management framework has been developed based upon Risk IT (figure 3).

Management Information System Term Paper

Page 22

RISK MANAGEMENT IN IT PROJECTS

NSEs high-level objectives for each area of the framework are: 1. 1. Risk Governance: Maintain a common viewMaintain standard risk register to provide a risk update in business terms. o Define the organization structureDefine roles and responsibilities across the organization to review and maintain IT risk profile. o Make risk-informed decisionsProvide IT risk dashboard to IT management to enable risk-informed strategic decisions. 2. Risk Evaluation: Collect dataPrepare risk scenarios, conduct risk-identification workshop, establish process touch points for risk updating and link the impact assessment with the business impact analysis (BIA). o Analyze riskUse a standard table for defining likelihood and Impact. Use the Delphi technique wherever required. o Maintain risk registerUpdate and maintain the risk register to develop the risk profile by aggregating departmental risk. 3. Risk Response: Articulate risk: Establish a process for defining risk response and communicating to stakeholders. o Manage risk: Maintain a control catalogue with risk mapping, and define the review process. o React to risk events: Establish a link to incident management, change management and operations management to review risk. NSEs Business and IT Mapping Management Information System Term Paper Page 23
o o o

RISK MANAGEMENT IN IT PROJECTS NSE provides IT-based services to members and brokers for trading in securities on behalf of their clients and investors. There are multiple different market segments. Each market segment has four major processes: trading (consisting of placing orders by members that are matched by matching engine and confirmed), risk management (online monitoring of activities), surveillance (online pattern matching to identify out-of-turn trades to restrict malpractices), and clearing and settlement (involving delivery of securities), in addition to various supporting processes. Figure 4 depicts the mapping of risk management processes covering these high-level IT processes.

Implementation Approach The implementation approach for the risk framework at NSE is described in figure 5.

The implementation of risk management was conducted at two levels: 1. Develop risk register for business functions. 2. Define aggregation process to arrive at an organization-level risk profile. Business processes were categorized in the following areas: Most critical (core production) Management Information System Term Paper Page 24

RISK MANAGEMENT IN IT PROJECTS Critical (production) Support functions For each business function, the following activities were performed: Conduct risk evaluation facilitated workshops. Generate risk profile for inherent risk (risk without considering controls). Determine response options. Identify and assess controls from control catalogue. Identify positive (excess) and negative (missing) control gaps. Define a plan for closing control gaps. Finalize the risk register. Obtain confirmation from risk owner (department heads). For aggregation of the risk profile at the organization level, the following activities were performed: Build a matrix for all identified risk. Collect department-wide data, and build the matrix. Add weight age of criticality for each department. Arrive at organization-level risk profile. Review and sanitize the risk profile by eliminating mathematically inappropriate impacts and likelihood. Present risk profile to board and senior management. Risk Management Processes NSE concluded that changes in risk need to be tracked on an ongoing basis and identified the following triggers as having an impact on risk status: incidents, events, changes in IT and business environment, and procurement based on strategic IT decisions. Figure 6 shows the risk updating process based on these identified triggers.

A uniform scale for quantifying the likelihood and qualitative impact assessment was defined for use across the organization. Conclusion Use of the Risk IT framework helped NSE in building a uniform structure and view of IT risk across the organization. The Risk IT framework helped NSE in: Management Information System Term Paper Page 25

RISK MANAGEMENT IN IT PROJECTS

Presenting a uniform view of IT risk to stakeholders The use of scenarios and avoiding jargon encouraged stakeholders to participate in the process Defining a monitoring process for continuous updating of changes in the risk profile Acceptance by risk owners

The risk profile is presented in three stages:

Inherent risk (total risk without controls) Current risk (overview of current risk based on existing controls) Residual risk (risk after applying control gaps)

Management Information System Term Paper

Page 26