Information Security: IT Risk Management Standard

Original Issuance Date: October 13, 2020
Last Revision Date: November 11, 2026
Effective Date: May 1, 2027

1. Purpose of Procedures

This standard establishes baseline requirements for implementing Information Technology (IT) risk management processes across the Universities of Wisconsin. It supports consistent risk identification, assessment, ownership, treatment, documentation, and review to strengthen decision-making, promote accountability, and enable system-wide visibility of IT risks.

2. Responsible UW System Officer

Associate Vice President for Information Security

3. Definitions

Please see SYS 1000, Information Security: General Terms and Definitions, for a list of general terms and definitions. Terms and definitions found within this procedure include:

Inherent Risk
Residual Risk
Risk Appetite
Risk Executive
Risk Owner

4. Procedures

A. Standards

I. Risk Identification

Risk identification should focus on potential events or conditions that could adversely affect institution mission or strategic objectives, reputation, financial condition, operations or safety, or legal, regulatory, or compliance obligations. Threats, vulnerabilities, control deficiencies, incidents, and other operational issues may inform risk identification but do not, by themselves, constitute a complete statement of risk. A risk should describe the potential event or condition and the adverse impact that could result.

Each institution must use a repeatable process for identifying IT risks.
Risk identification should consider, as applicable:
1. Review of audit findings, security incidents, assessment results, vulnerabilities, and known control deficiencies.
2. Consideration of risks introduced by new technologies, significant changes, major projects or initiatives, and emerging threats.
3. Third-party relationships and external dependencies
4. Input from relevant academic, administrative, and IT units.
Institutions are encouraged to conduct a broader, institution-wide IT risk identification exercise at least once every five (5) years to identify significant, cross-cutting, or systemic IT risks that may not be surfaced through routine risk management activities.

II. Risk Assessment

Each institution must use a consistent and repeatable methodology for assessing IT risks that considers both likelihood and impact.
Institutions may use informal screening or triage to determine whether a potential risk warrants formal assessment.
Formal risk assessments must:
1. Be documented in an assessment record or other appropriate risk management record;
2. Determine and document a residual risk level; and
3. Consider the institution’s defined risk appetite when determining whether additional treatment, escalation, or ongoing oversight is required.
Risks subject to ongoing oversight must be reviewed periodically to confirm that the risk and selected response remain appropriate. At a minimum:
1. Risks that exceed the institution’s defined risk appetite must be reviewed at least annually; and
2. A formal reassessment must be performed when material changes occur that could affect the likelihood, impact, or effectiveness of existing controls.

III. Risk Ownership and Decision-Making

Each risk maintained in the institution’s designated risk register must have an assigned risk owner.
Risk ownership must align with responsibility and authority for the activity, process, system, service, or business outcome affected by the risk. Risk ownership should not default to an IT or information security role solely because the risk was identified through an IT or security process.
Risk acceptance authority must align with the extent of the risk and the areas affected. When a risk affects multiple units, institutions, or enterprise services, it must be escalated to a level with authority and accountability for the affected areas.
Risk owners are responsible for:
1. Reviewing the risk and associated assessment;
2. Determining or approving an appropriate risk response within their authority.
3. Ensuring agreed-upon treatments actions are carried out;
4. Escalating risks that exceed their authority, extend beyond the areas for which they are accountable, or require resources beyond their authority to commit.
Each institution must identify its designated risk executive(s) and individuals authorized to act as risk executive designees.
The risk executive (or designated authority) is responsible for:
1. Reviewing escalated risks.
2. Determining the appropriate risk response; and
3. Formally approving risk acceptance, when applicable.

IV. Risk Treatment

Each identified IT risk must be addressed through one or more appropriate risk treatment strategies. Treatment options include:
1. Mitigation
2. Transfer
3. Avoidance
4. Acceptance
When treatment requires actions to be completed, a responsible party and expected timeframe must be identified.
When risk treatment is completed, the institution should confirm that planned actions were implemented.

V. Documentation and Risk Registers

Each institution must maintain a designated risk register for IT risks that warrant ongoing oversight, treatment, or decision-making. The risk register may be maintained within one or more risk management systems or other appropriate tools based on local needs and capabilities.

At a minimum, risks assessed as exceeding the institution’s defined risk appetite must be entered into and maintained in the institution’s designated risk register.

1. Minimum Risk Record Information

Each risk maintained in the designated risk register must include, at a minimum:

1. 1. Risk statement, including the affected area and potential impact.
  2. Assigned risk owner.
  3. Residual risk rating and assessment date.
  4. Selected risk response
  5. Current status.
  6. Treatment owner and expected completion timeframe, when applicable.
  7. Review date or review trigger.
  8. Approval information when formal risk acceptance is required.

2. Supporting Records

Risk assessments, treatment plans, and other supporting records may be maintained within the risk register or in another appropriate system of record, provided they can be associated with the applicable risk when needed.

3. Policy Exceptions

Institutions must document decisions not to implement controls or processes required by UW information security policy or procedure. The risk associated with a policy exception must be assessed in accordance with Section II.

1. Policy exceptions may be maintained separately from the institution’s risk register.
2. Exception documentation must identify, at a minimum:
  1. The requirement being excepted;
  2. The affected area, system, service, process, or activity;
  3. The rationale for the exception;
  4. The associated risk rating and compensating controls, where applicable;
  5. The approving authority; and
  6. The period or conditions for which the exception applies.
3. Policy exceptions that result in residual risk above the institution’s defined risk appetite must be linked or otherwise associated with a corresponding risk-register entry.
4. Active policy exceptions must be reviewed periodically and when material changes occur to determine whether the exception remains necessary and whether the associated risk remains appropriate.

4. Record Maintenance and Availability

Risk and policy exception records must be kept current and made available to the UW System Office of Information Security, Internal Audit, or other authorized parties upon request.

5. Risk Closure

A risk may be marked closed or removed from active tracking when it no longer warrants ongoing oversight, treatment, or decision-making. The basis for closure must be documented.