Published: April 25, 2008 | Updated: October 10, 2008
Risk management is IT’s attempt to address risk while achieving management objectives. IT organizations achieve long-term success by managing risk through the effective use of internal controls.
Internal controls are specific activities performed by people or systems designed to ensure that business objectives are met. Careful design, documentation, and operation of controls are crucial at every level of the organization. Being “in control” means the chances of experiencing adverse impacts from undesirable events are at acceptable levels and that the likelihood of achieving objectives is satisfactory. Internal control is intertwined with and directly affected by an organization’s governance activities.
Figure 5 illustrates the activities of risk management. It is important to understand that the process of managing each risk goes through all of these activities at least once and often cycles through numerous times. Because each risk has its own timeline, multiple risks might be in each stage at any given point.
Figure 5. The generalized cycle of assessing, monitoring, and controlling risk
Activities: Assess, Monitor, and Control Risk
The process of identifying risks and controls touches all aspects of the enterprise. It provides a foundation for the enterprise’s compliance efforts by clearly laying out the relationship among goals, factors that might prevent achieving the goals, and how those potential events are being addressed.
Each phase of the IT service lifecycle has an associated set of characteristic risks and corresponding activities to manage them:
In the Plan Phase, the focus is on risks related to specific strategies, information architectures, and risk across the IT portfolio.
The Deliver Phase evaluates risk from a project-oriented perspective, which is more targeted and time-limited.
The Operate Phase focuses on day-to-day activities and the risks that might affect reliable operations.
Finally, the Manage Layer deals with risk management from both a general and focused point of view: general in terms of governance structures, organizational coordination, decision making, and communication plans; focused in terms of managing change and configuration and the risks that come from modifying elements of the IT service environment as well as processes and resources that are part of that environment.
Categories of risk arise throughout the various phases of the service lifecycle. They involve financial, operational, reputational, market share, revenue, and regulatory risks, as well as other risks that are more specific to a particular organization’s industry (for example, healthcare) or a presently occurring activity (such as a merger or acquisition).
By approaching risk management in a way that encourages thinking about the potential consequences of activities, evaluating their impact, and then taking a very explicit approach to addressing these risks, IT gains a considerable advantage. An organization cannot intelligently address risk without both IT and the business sitting down together and defining risk tolerances and control objectives. Since the consequences of risk are evaluated in terms of reaching business goals, this helps integrate IT into business discussions and tradeoffs and eliminates after the fact finger-pointing by virtue of the transparency involved in risk management.
This process includes the following activities:
Improving processes to meet management objectives
Identifying risk
Analyzing and prioritizing risks
Identifying controls
Analyzing controls
Planning and scheduling implementation
Tracking and reporting risks and controls
Operating controls
Learning from prior efforts and updating knowledge base
Table 6. Activities and Considerations for Assessing, Monitoring, and Controlling Risks
Activities
Considerations
Assumptions
Risk management extends beyond security and privacy of data to a variety of risks that might affect the fulfillment of management’s objectives (including, among others: financial risk, risk of not fulfilling performance commitments, project risk, and reputational risk).
Address management objectives
Key questions:
What could happen that might affect achieving management’s goals and objectives?
What can be done to maximize the ability to meet objectives?
What are the risk-sensitive business processes that use IT systems?
What is the risk tolerance profile that best describes this company?
Results (success and failure) of risk management to date
Output:
The organization’s risk tolerance and approach to risk management
Best practices:
Risk management occurs many times during each phase of the IT service lifecycle. Understanding the risks relative to the goals of a particular phase will establish the risk domain.
That risk domain, combined with the unique risk tolerance of the company, will guide the approach to managing risks in that phase of the IT service lifecycle.
Risk tolerance is fluid and changes with opportunities and potential rewards, as well as incidents and potential penalties.
Identify risk
Key questions:
How are business services classified in terms of business criticality and the nature of data used in those services?
What is the history of change for the systems that make up each service? What upcoming changes are planned?
What is the complexity of the end-to-end system (does it cross multiple interfaces, extend to business partner systems, rely on data or services outside of company control)?
Inputs:
Mission of the company (and business units, where appropriate)
Ensure that senior management is committed to the risk management process.
Ensure that participants in risk management have expertise in IT systems and business processes and an understanding of the potential impact to the business.
Review critical business services; evaluate each for standard risks and brainstorming for possible risks. Do this with a team that represents differing perspectives and areas of expertise.
Risk identification should also include notification to the risk stakeholder. Risk identification should be repeated frequently.
What impacts will risks and threats (situations or states that might cause harm) have on the organization as a whole?
What are the likely impacts of threats to specific management objectives and associated business processes?
Can threats and impacts be broken down into those that could harm IT service performance but not compromise data?
What are the known vulnerabilities in the systems that make up IT services?
What are the threats to individual systems?
Inputs:
IT services risk characterization
Threats
Vulnerabilities
Output:
Threat and vulnerability listings with prioritized riskratings
Best practices:
Transform the estimates or data about specific risks that developed during risk identification into a form that can be used to make decisions about prioritization.
Measure risk in terms of likelihood multiplied by impact and use the resulting scores to help prioritize.
Prioritize risks so that the most important ones can be addressed with sufficient resources.
Brainstorm for possible unsuspected risks. If some are identified, try to assess whether their potential impact (even if there is a low probability) still merits attention.
Based on threats and vulnerabilities for the company, what are the best control points and activities to mitigate those risks?
What data confidentiality, integrity, and access vulnerabilities should be addressed with explicit controls?
Inputs:
Threat and vulnerability listings with ratings
List of primary controls and compensating controls (which usually operate to detect issues after the fact )
Interviews with personnel responsible for business objectives and associated processes
Interviews with personnel in IT control areas
Issues and audit reports
Output:
Plan that maps controls to IT services and to business processes
Best practices:
Controls work together to create a control environment. When evaluating a single control, keep in mind the constellation of related controls, and consider how one control might compensate for another.
Analyze controls
Key questions:
What business objectives are being addressed by the identified controls?
What evidence demonstrates that the controls are functioning as desired?
What does audit require in terms of the type of evidence and its retention?
Inputs:
Audit reports
List of existing controls
Interviews with personnel in each control area
Plan that maps controls to IT services and to business processes
Output:
Control development plan
Best practices:
Audit reports provide an independent analysis of controls and usually have recommendations for improving the control environment.
A priority focus should be on fundamental controls that must function correctly so that other controls can depend on them (for example, controls for data access).
Design controls with evidence collection processes built in to make auditing and other control testing more efficient and effective. Control tests require proof (in the form of evidence) that the control is in place and functions as expected.
Plan and schedule implementation
Key questions:
Of the list of planned controls, which controls are not in place?
What is the development priority for controls that are not in place?
Inputs:
Threat and vulnerability listings with prioritized riskratings
Control development plan
Outputs:
Risk and control development plan
Identified mitigations
Schedule of control-related change requests
Best practices:
Use the information obtained from risk analysis to help formulate strategies, plans, change requests, and actions.
Use change management processes to ensure that risk plans are approved and incorporated into the standard day-to-day processes and infrastructure. See the MOF Change and Configuration SMF.
Track and report risks and controls
Key questions:
What is the status of risks and controls?
Inputs:
IT service monitoring
Evidence retained from control activity
Status reports for control development projects
Outputs:
Risk reporting
Control development status reporting
Best practices:
Monitor the status of specific risks and the progress in their respective action plans.
Monitor the probability, impact, exposure, and other measures of risk for changes that could alter priority or risk plans (and ultimately the availability of the related IT service).
Make sure that the operations staff, service manager, and other stakeholders are aware of the status of top risks and the plans to manage them.
Operate controls
Key questions:
Are controls operating as expected?
Are risk tolerance levels and action triggers operating as required?
Are risk management action plans tracking as expected?
Inputs:
Risk reporting
Control development status reporting
SLA compliance reporting
Outputs:
Control operations reporting
Service level impacts
Best practices:
Execute risk action plans and evaluate their status through risk reporting.
Initiate change control requests when changes in risk status or risk plans could affect the availability of the service or SLA.
Collect and store evidence that controls are operating. This may take many forms (for example, system logs, documentation that is under change control, or sign-offs from authorized individuals).
Notify stakeholders of changes to services that address risk issues.
Learn from prior efforts and update knowledge base
Key questions:
Is management satisfied with the way controls deal with known risks?
Are risk tolerance levels set appropriately and expected actions triggered when conditions exceed acceptable levels?
Have new risks been identified?
Do audits indicate an effective control environment?
Inputs:
Audit of normal operations
Control operations reporting
Cost/benefit analysis of controls
Outputs:
Risk reporting on at least a monthly basis
Risk dashboard if available
Up-to-date risk knowledge base
Results reported to the Operational Health MR
Best practices:
The application of controls is a cost/benefit exercise; it should reflect management’s assessment of the business objective, the identified risk, and the benefit of developing and applying the control. The cost/benefit analysis should reflect the willingness of the company to assume risk, acknowledging that it exists, but its potential impact will be allowed to happen(as opposed to mitigating the risk, which involves attempting to reduce the impact or probability of the risk).
Risk learning formalizes the lessons learned and uses tools to capture, categorize, and index that knowledge in a reusable form that can be shared with others in the organization.
.jpg "Cc531022.image5(en-us,TechNet.10).jpg")