Term Paper_Risk Management in IT Projects

7/31/2019 Term Paper_Risk Management in IT Projects

1/26

[Type text] Page 1

Risk

Management

in IT Projects

Submitted To: Submitted By:

Mr. Lovneesh Chanana Ankur Saini

Assoc. Director 11810016

Ernst & Young MBA 2nd

Year

DoMS IIT Roorkee


2/26

RISK MANAGEMENT IN IT PROJECTS

Management Information System Term Paper Page 2

Abstract

The development and implementation of IT (Information Technology) projects are plagued withproblems 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.


3/26



Contents1. INTRODUCTION ............................................................................................................................... 4

2. 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 STEP 1: SYSTEM CHARACTERIZATION ................................................................................ 9

3.2 STEP 2: THREAT IDENTIFICATION ..................................................................................... 10

3.3 STEP 3: VULNERABILITY IDENTIFICATION......................................................................... 10

3.4 STEP 4: CONTROL ANALYSIS ............................................................................................. 10

3.5 STEP 5: LIKELIHOOD DETERMINATION ............................................................................. 10

3.6 STEP 6: IMPACT ANALYSIS ................................................................................................ 11

3.7 STEP 7: RISK DETERMINATION ......................................................................................... 11

3.8 STEP 8: CONTROL RECOMMENDATIONS ......................................................................... 11

3.9 STEP 9: RESULTS DOCUMENTATION ................................................................................ 11

4. RISK MITIGATION .......................................................................................................................... 12

4.1 RISK MITIGATION OPTIONS ............................................................................................... 12

4.2 RISK MITIGATION STRATEGY ............................................................................................. 12

5. EVALUATION AND ASSESSMENT ................................................................................................... 14

5.1 GOOD SECURITY PRACTICE ............................................................................................... 14

5.2 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


4/26



1. INTRODUCTIONEvery organization has a mission. In this digital era, as organizations use automated informationtechnology (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.


5/26



2. RISK MANAGEMENT OVERVIEWThis 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.1IMPORTANCE 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, andmaintaining 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 ofhome 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.


6/26



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)

Phase 2Development or

Acquisition

The IT system is designed,

purchased, programmed,

developed, or otherwise

constructed

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 3Implementation The system security features

should be configured, enabled,

tested, and verified

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

Phase 4Operation or

Maintenance

The system performs its functions.

Typically the system is being

modified on an ongoing basis

through the addition of hardware

and software and by changes to

organizational processes, policies,

and procedures

Risk management activities are

performed for periodic system

reauthorization (or

reaccreditation) or whenever major

changes are made to an

IT system in its operational,

production environment (e.g., new

system interfaces)

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

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


7/26



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 ultimateresponsibility 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 makingprocess. 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 forensuring 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 andIT 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 theirorganizations 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, anddatabase 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


8/26



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 organizationspersonnel 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 andprotecting 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.

Riskis a function of the likelihoodof a given threat-sources exercising a particular potential

vulnerability, and the resulting impactof 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 ofvulnerability. 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 System Characterization (Section 3.1)

Step 2 Threat Identification (Section 3.2)

Step 3 Vulnerability Identification (Section 3.3)

Step 4 Control Analysis (Section 3.4)

Step 5 Likelihood Determination (Section 3.5)

Step 6 Impact Analysis (Section 3.6)

Step 7 Risk Determination (Section 3.7)

Step 8 Control Recommendations (Section 3.8)

Step 9 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.


9/26



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, theboundaries of the IT system are identified, along with the resources and the information that


10/26



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 threat-

sources, 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 governingfactors 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


11/26



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:

Effectiveness of recommended options (e.g., system compatibility). Legislation and regulation. Organizational policy. Operational impact. Safety and reliability.

3.9 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.


12/26



4. RISK MITIGATIONRisk 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 toimplement 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 impactof 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 thevulnerability 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 themethods 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?


13/26



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 assurancetechniques to reduce the likelihood of a vulnerabilitys being exercised.

When vulnerability can be exercisedapply 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 anattackers 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 andnontechnical protections to limit the extent of the attack, thereby reducing the potential for

loss.


14/26



5. EVALUATION AND ASSESSMENTIn 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 goodpractice 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.


15/26



6. Case Study: IT Risk Management in a BankBackground

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


16/26



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 withintechnology.

2. It should act as a reporting framework to demonstrate how technology satisfies reportingregulatory 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 earlierinformation. 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 anexample, the technology principal risk was further drilled down to:

Inadequate design/testing of IT systemsUnavailability 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


17/26



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 ITenvironment. 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 acomplete 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 veryimportant to capture any control and risk information ahead of go-live. This will allow thetarget 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 toadditional 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.


18/26



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.


19/26



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 asCertified 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, asimple 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 thatexplained 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 shouldbegin any risk assessment process. The training resources were used to facilitate the controlself-assessment (CSA) at different locations.


20/26



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

Benefit of Step 4

Due to this top-down approach, the importance of risk management was well accepted and it waseffective 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 controlswere 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 ofcontrols 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


21/26



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 andother regulatory processes. The RCA spreadsheet provided a separate filter for Sarbanes-

Oxley compliance applicability.

The process repository in the tool helped in maintaining consistency. This was done bycreating 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 teamand 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.


22/26



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).
http://www.isaca.org/Knowledge-Center/cobit/Pages/Risk-IT-Case-Study-Risk-IT-Framework-for-IT-Risk-Management-A-Case-Study-of-National-Stock-Exchange-of-India-Limited.aspx#ghttp://www.isaca.org/Knowledge-Center/cobit/Pages/Risk-IT-Case-Study-Risk-IT-Framework-for-IT-Risk-Management-A-Case-Study-of-National-Stock-Exchange-of-India-Limited.aspx#ghttp://www.isaca.org/Knowledge-Center/cobit/Pages/Risk-IT-Case-Study-Risk-IT-Framework-for-IT-Risk-Management-A-Case-Study-of-National-Stock-Exchange-of-India-Limited.aspx#ghttp://www.isaca.org/Knowledge-Center/cobit/Pages/Risk-IT-Case-Study-Risk-IT-Framework-for-IT-Risk-Management-A-Case-Study-of-National-Stock-Exchange-of-India-Limited.aspx#g


23/26



NSEs high-level objectives for each area of the framework are:

1. 1. Risk Governance:o

Maintain a common viewMaintain standard risk register to provide a risk updatein business terms.

o Define the organization structureDefine roles and responsibilities across theorganization to review and maintain IT risk profile.

o Make risk-informed decisionsProvide IT risk dashboard to IT management toenable risk-informed strategic decisions.

2. Risk Evaluation:o 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 Delphitechnique

wherever required.

o Maintain risk registerUpdate and maintain the risk register to develop the riskprofile by aggregating departmental risk.

3. Risk Response:o 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 reviewprocess.

o React to risk events: Establish a link to incident management, change managementand operations management to review risk.

NSEs Business and IT Mapping


24/26



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)


25/26



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 andlikelihood. 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 acrossthe organization. The Risk IT framework helped NSE in:


26/26


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)

Term Paper_Risk Management in IT Projects

Documents