Export (0) Print
Expand All

Process 2: Assess, Monitor, and Control Risk

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.

Cc531022.image5(en-us,TechNet.10).jpg

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?

Inputs:

  • Strategic plan and resulting management objectives
    (see the Business/IT Alignment SMF)
  • Regulatory and business conditions
  • 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)
  • Risk tolerance and approach to risk management
  • IT portfolio (see the Business/IT Alignment SMF)
  • IT service maps (see the Business/IT Alignment SMF)
  • Incident reports, security events
  • Regulatory environment, non-compliance events

Output:

  • IT services risk characterization report

Best practices:

  • 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.
  • For more information on risk identification, see NIST SP 800-30 (http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf).

Analyze and prioritize risks

Key questions:

  • 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 risk ratings

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.
  • See Microsoft Threat and Vulnerability Mitigation Resources at http://www.microsoft.com/technet/security/learning/threats/all/default.mspx.

Identify controls

Key questions:

  • 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 risk ratings
  • 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.
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft