Step 3: Identify and Define Risks – It should be noted that the term ‘risk’, as used here, represents problems, threats, and vulnerabilities with respect to information technology assets. A list of common IT risks that must be considered for every critical asset is contained in Table D, with definitions and examples for each risk available HERE. If a risk does not apply to a particular asset, simply leave the rating column next to that risk blank (in YOUR ITRA template). Many of the risks described include questions that may help you consider the scope of a particular risk. If you have identified other threats and vulnerabilities that represent unique risks to your information assets that are not covered on this list, please add lines to your tables in Step 3, and list those risks along with their definitions. The risks listed in Table D are covered in various university policies and standards.

For information about how to rate likelihood and impact of risks and an explanation of risk responses, view:
Understanding Likelihood and Impact Ratings & Risk Responses (DOCX | 32KB)

Once the risks pertaining to each asset have been identified and rated, the specific impact of any risk that rated a HIGH impact should be briefly defined. How much detail to include in each definition will be left to the discretion of assessment team members, and may depend on how much is known about the specific risk.

Step 4: Recommendations to Mitigate Risks to Critical Assets – For each risk pertaining to an asset listed in Step 3 that carries a High impact, the ITRA team members should document whether:

  • Current controls are in place and enforced to mitigate the high impact risk.
  • The risk can be addressed within a specific timeframe. A brief explanation should be included to define the proposed mitigation solution(s).
  • The risk merits remediation, but no controls will be implemented at the current time due to factors that are expected to change in the near future (e.g., new software expected, pending move to new location, etc.).
  • Mitigation of the risk is not feasible, due to external factors (time, budget, etc.) affecting the department or operating unit.

Step 5:  Provide Complete Documentation to Address Critical Risks – For each risk that can be addressed, the template provides a section where team members can describe a proposed solution, justify the solution, provide a cost/benefit analysis, and propose an implementation date. It may be appropriate for the team to offer more than one recommendation, in which case each should be described using the template. Documentation for reducing risks to ‘Essential’ or ‘Normal’ assets can also be included in this section.

Initially, the team should consider the probability of an incident (risk) occurring, then enumerate the steps that would be required for a complete recovery. This process will help team members to clarify whether to proceed with a more detailed analysis (as described below) or simply document that the risk is going to be accepted, and the department is not planning any mitigation.

If the team feels there are appropriate solutions, the following steps should be followed:

  • Identify each solution that might be implemented (technical or non- technical, as well as any policies or procedures that would apply). Each solution should be described completely.
  • If only one solution is applicable, that fact should be noted as well, including some discussion of why other options were dismissed.
  • Develop a cost/benefit analysis for each proposed solution. This should include capital and direct costs, staff costs, training and support, and any other one-time or ongoing costs.
  • Specify a proposed implementation timeline for each solution. This could depend on the severity of the risk and the timeframe for implementation.