RMC mission & vision
RMC mission
The RMC mission is to protect the confidentiality, integrity, and availability of university data and systems by providing consistent and meaningful risk assessments, by providing guidance to lessen identified risks. Through these assessments and recommendations, we minimize the impact of cybersecurity incidents to the university community and promote awareness of cybersecurity best practices.
RMC vision
The RMC vision is to establish a culture of cybersecurity awareness and continuous improvement on campus. We strive to be a trusted campus partner in the protection of UW’s information assets, by utilizing a formalized risk assessment program. Through collaboration efforts with campus partners, RMC will provide effective risk assessments, regulatory compliance, security metrics and risk mitigation guidance. We aim to enable the campus community to operate in a secure and reliable digital environment that supports the University’s mission.
Frequently asked questions (FAQ) for UW–Madison Risk Review Services
This is an accordion element with a series of buttons that open and close related content panels.
Under what circumstances should I request a risk assessment?
- To comply with UW Policy or other industry frameworks
- To meet regulatory requirements
- As part of routine governance
- Before implementing new technologies (e.g., Public Cloud, Secure Storage)
- When onboarding vendors
- When a significant change occurs (See “Assistance defining significant change”)
- After a security incident or breach
- When collecting credit card information (PCI DSS)
- When collecting any Sensitive or Restricted information (SSN, PHI, FERPA, etc.)
What information and documentation are required to begin the process?
- Providing supporting materials upfront, including SOC 2, CAIQ, HECVAT, and relevant architectural or data flow diagrams, as part of your risk assessment request, can greatly expedite the review.
- Other examples of helpful supporting materials may include: privacy documentation, AI security documentation, vulnerability assessments, penetration test results, etc.
- Is the service provider willing to sign a contractual agreement to share responsibilities to protect University data (e.g., BAA, DUA, SLA)?
- The risk assessment process requires input from your team to reach completion. Lack of documentation or vendor responsiveness can lead to delays and a potential increase in overall assessed risk.
How does the risk assessment process start?
- Complete the OneTrust intake form.
- If you have questions, please contact rmc-cybersecurity@cio.wisc.edu.
What baselines and guidance are used to evaluate risk?
Security and regulatory frameworks are leveraged when assessing risk. They include, but are not limited to:
- National Institute of Standards and Technology (NIST)
- Center for Internet Security (CIS)
- Open Web Application Security Project (OWASP) Top 10 / Top 10 for Large Language Model (LLM)
- Payment Card Industry Data Security Standard (PCI DSS)
- Health Insurance Portability and Accountability Act (HIPAA / Office of Compliance)
- Cloud Security Alliance (CSA) – Consensus Assessments Initiative Questionnaire (CAIQ)
- Tailored security controls relevant to the specific service or compliance requirements (e.g., CMMC, NSPM-33, GDPR)
What key factors influence the urgency and significance of conducting a risk assessment?
Who are the key participants in the risk assessment process?
- Office of Cybersecurity – Leads the effort
- Campus Partner (Faculty, Staff, Local-IT) – Support/Collaborate
- Privacy and Security Coordinators/Officers (HIPAA) – Support/Collaborate – Clarify the classification of Protected Health Information (PHI) and advise on privacy considerations
- Data, Academic Planning & Institutional Research (DAPIR) – Clarify the classification of non-PHI data
- Office of Legal Affairs (OLA) – Additional privacy evaluations and review of non-disclosure agreements (NDAs)
- Risk Executive or Delegate – Informed/Signatory
How long does a typical risk assessment take to complete?
- 1-3 months depending on the complexity and scope of the assessment, response time of the vendor, and the resources available from your team.
- High demand for risk assessment work may delay the start of your project. These estimates apply once your risk assessment has been assigned to a risk analyst.
What are the final deliverables and how will they be shared?
- Formal documentation will be developed to capture the overall risk, which may include a Risk Report, Memo, Addendum, email, or other official artifacts.
- Official documentation is distributed to key stakeholders, including the Risk Assessment Team, Cybersecurity Leadership, the HIPAA Security and Privacy Officer (HIPAA), and the designated Risk Executive.
- The overall risk rating determines whether the formal documentation is shared for informational purposes or submitted for signature:
- Inconsequential to Moderate – Email Risk Executive for informational purposes; signature not necessary.
- Moderate-High to Critical – Schedule a formal Risk Executive Meeting (optional); signature through DocuSign is required by the Risk Executive.
What should you do with the final deliverables?
- The Requestor is responsible for acknowledging identified risks, which are tracked in the OneTrust Risk Register, and taking proactive steps toward their resolution.
- Risk Owners are responsible for managing their assigned OneTrust risks and ensuring they remain current, enabling accurate and timely reporting to Risk Executives.
What does the entire risk assessment process look like?
Risk Assessment Process is described below on the RMC webpage
Risk Assessment Process
To support the mission and vision of the University and the Risk Management and Compliance team, the process below details roles and responsibilities needed during the collaborative risk assessment process. Securing data for the University of Wisconsin–Madison is most successful when all stakeholders participate. Working jointly, we can maintain security compliance with standards, policies, laws, and regulations to protect sensitive information.
This is an accordion element with a series of buttons that open and close related content panels.
Step 1: Planning
Introductions
- Scoping / Expectations
- Acknowledgements
Kick-off Meeting
- Timelines / Expectations
- Personnel Inclusions
- Task Assignments
| Activity | Mechanism | Details | Participating Party; Expected Action |
Estimated Timeline |
|---|---|---|---|---|
| Low risk exception (Optional) |
If data used in the system is Public or Internal and research into the system is indicating low or low-moderate risks, an email can be generated to summarize the assessment results and recommend best practices for the campus partner, instead of a signed report. A copy of the email would be saved in the same way as a full report (i.e., in the same Secure Box location, using the same folder naming convention for tracking). | Cybersecurity to lead | 1-4 hours | |
| Introductions | This email communication is meant to help prepare the Campus Partner for the risk assessment by discussing scope (e.g., assets, data classification, business impacts), expectations, and understanding of the process. This activity helps drive the agenda for the kick-off meeting. | Cybersecurity to lead; campus partner to participate | 30 minutes | |
| Kick-off Meeting | Virtual | This meeting is intended to communicate the risk assessment process to the Campus Partner, set expectations, confirm the cadence of risk assessment sessions, and designate personnel to include in the process. | Cybersecurity to lead; campus partner to participate | 1 hour |
Step 2: Risk Assessment
Risk Assessment Sessions
- Security Controls
- Security Gaps
- Risk Scoring
Vulnerability Assessment (as needed)
- Qualys Scans
- Other Technical Testing
| Activity | Mechanism | Details | Participating Party; Expected Action |
Estimated Timeline |
|---|---|---|---|---|
| Risk assessment sessions | Virtual | The risk assessment sessions are meant to identify security controls, determine potential security gaps, and discuss risk scoring (based on likelihoods and impacts). Some risk assessment sessions may include additional scoping conversations to validate the accuracy of assets being considered and reviewed.
Weekly meetings are preferred. The complexity of the analysis will determine the number of meetings needed. The expectation is for the Campus Partner to have availability and provide any documentation in advance. The risk assessment is completed in collaboration with the Office of Cybersecurity to ensure clear understanding and assistance is made available as needed. |
Cybersecurity to lead; campus partner to participate | 1-10 sessions |
| Vulnerability assessment | Virtual | A vulnerability assessment scan is coordinated using campus tools. Campus partners would provide IP ranges, coordinate timing and will review results. May not be needed or possible (based on assessment type). | Cybersecurity to lead; campus partner to coordinate | 24 hours |
Step 3: Reporting
Executive Report Drafting
- Written Findings and Observations
- Stored in Secure Box
Informal Review
- Report Shared in Advance
- Feedback and Changes
- Confirmation of Findings
| Activity | Mechanism | Details | Participating Party; Expected Action |
Estimated Timeline |
|---|---|---|---|---|
| Executive report drafting | Box, email | A risk letter is created to document findings and observations and is stored in secure Box. Estimated timeline includes time to coordinate informal review. | Cybersecurity to lead | Variable: 3-5 business days |
| Informal review | Virtual | The risk letter is discussed with the campus partner before it reaches the risk executive or other risk delegate. The meeting is set up to discuss feedback, incorporate feedback into the report and validate that findings are understood. | Cybersecurity to lead; campus partner to participate | 1 hour |
Step 4: Signatory
Internal Review
- Cybersecurity Review
- CISO/Delegate Signature
Formal Review
- Risk Executive Hand-off
- Risk Executive Feedback
Risk Executive Signature
| Activity | Mechanism | Details | Participating Party; Expected Action |
Estimated Timeline |
|---|---|---|---|---|
| Internal review | Virtual | The Office of Cybersecurity analyst and leadership will review final risk score results, gather feedback from the HIPAA Security and Privacy Officers for PHI assessments, and sign the report for presentation to the campus partner. | Cybersecurity to lead | Variable: 3-14 business days |
| Formal review | Virtual | The Office of Cybersecurity will present the final report in advance of a discussion or meeting with the campus partner. This meeting allows for discussion of findings and opportunities for the campus partner to plan for future activity to reduce risk. Once there is a mutual understanding and acknowledgement of the risk, the Office of Cybersecurity will ask the campus partner to sign the report. | Cybersecurity to lead; campus partner and risk executive to participate | 1 hour |
| Risk executive signature | DocuSign | The Risk Executive or delegate is sent a signatory request via DocuSign, which is integrated with secure Box. | Cybersecurity to lead; risk executive to respond/sign | 1-4 business days |
Addressing risks in OneTrust and documenting treatment actions taken to reduce risk will complete this process. Best security practice is to dedicate resources to continued risk management.
Service Owners, in collaboration with their IT support staff, should address all risks identified during this process, to further secure data where and to the extent resources permit. Should this system undergo any significant changes, please reach out to The Office of Cybersecurity for a risk assessment (See below). Results presented during the risk review process are not an approval/denial of the use of analyzed technologies. Results presented outline the continued risk of use of this technology in its current state. UW–Madison encourages a continual focus on securing data which requires the review and remediation of all risks as an ongoing activity.
Campus partner resources
Find additional resources to assist with the interpretation and evaluation of risk for services used on the UW–Madison campus.
Data classification
Classifying data allows Cybersecurity a clearer vision of the data type to be included in an assessment. Campus partners should understand the security necessary to protect their data because each data type has its own security requirements. If help is needed verifying data classification, these resources are available:
- Protected Health Information (PHI): HIPAA Privacy Officer / Office of Compliance (Email: hipaa@wisc.edu Subject Line: “Data Classification”)
- Institutional Data: Data, Academic Planning & Institutional Research (DAPIR)
- Research Data: Principal Investigator with support from distributed IT
Other variables to consider when evaluating risk:
|
• Where data is stored |
• How data flows |
|
• Source of data |
• Scope of the data to protect |
|
• Who has access to it |
• Retention schedules of data |
Public
Data should be classified as Public prior to display on web-sites or once published without access restrictions; and when the unauthorized disclosure, alteration or destruction of that data would result in little or no risk to the University and its affiliates.
Sensitive
Data should be classified as Sensitive when the unauthorized disclosure, alteration, loss or destruction of that data could cause a moderate level of risk to the University, affiliates or research projects. Data should be classified as Sensitive if the loss of confidentiality, integrity or availability of the data could have a serious adverse effect on university operations, assets or individuals.
Internal
Data should be classified as Internal when the unauthorized disclosure, alteration, loss or destruction of that data could result in some risk to the University, affiliates, or research projects. By default, all Institutional Data that is not explicitly classified as Restricted, Sensitive or Public data should be treated as Internal data.
Restricted
Data should be classified as Restricted when the unauthorized disclosure, alteration, loss or destruction of that data could cause a significant level of risk to the University, affiliates or research projects. Data should be classified as Restricted if protection of the data is required by law or regulation or UW–Madison is required to self-report to the government and/or provide notice to the individual if the data is inappropriately accessed.
Additional information about data classification
Determining risk
When calculating risk, the Office of Cybersecurity will always rely on the ability to trust the risk math. This risk is a combination of qualitative and quantitative measurements and is a joint effort between risk analysts and the business unit. The formula for calculation of risk looks like this:
| Risk | = | Likelihood | x | Impact |
Likelihood
Likelihood is a frequency-based measurement. UW–Madison bases frequency on a 3 year period.
Impact
Impact is the outcome that effects the political, financial, legal, operational or reputational areas of campus.
Risk Rating Scoring At A Glance
Risk Rating Scores are calculated by multiplying the Likelihood score (1-5) by the Impact score (1-5).
For example, the risk rating score for an exploit with a likelihood score of 1 (very unlikely) which has an impact score of 5 (highest impact) is calculated by the following multiplication: 1 x 5 = 5 giving a moderate risk rating score.
|
↑ Likelihood ↓ |
5 | 10 | 15 | 20 | 25 |
|---|---|---|---|---|---|
| 4 | 8 | 12 | 16 | 20 | |
| 3 | 6 | 9 | 12 | 15 | |
| 2 | 4 | 6 | 8 | 10 | |
| 1 | 2 | 3 | 4 | 5 | |
| ← Impact Score (1-5) → | |||||
Campus Risk Ratings
| wdt_ID | Rating (Likeihood x Impact) | Rating definition & prescribed action |
|---|---|---|
| 1 | Critical Risk (20-25) |
Likelihood: Evidence of exploitation of a vulnerability by a threat actor against the asset has been discovered or enough evidence is seen to suspect exploitation has occurred in the past. Mission Impact: Political, financial, legal, operational or reputational impacts will be felt for two or more years. Damages impact at least an entire UW-Madison Division, or multiple departments across divisions. Action: Immediate action is required to reduce the risk. Systems designated with CRITICAL risk exposure may be required to be disconnected until resolutions or mitigations are found. CRITICAL risks found during a security risk assessment must be communicated upon discovery. Mean time to remediate or mitigate: Within 96 hours |
| 2 | High Risk (10-16) |
Likelihood: Exploitation of a vulnerability by a threat actor against the asset is highly likely, although evidence to suggest exploitation has occurred has not been found. Mission Impact: Political, financial, legal, operational or reputational impacts will be felt for 6 months, up to two years OR damages impact at least an entire UW-Madison Division, or multiple departments across divisions. Action: Prompt action is required to reduce the risk. All HIGH risks must be reduced before the close of the next semester of instruction. Mean time to remediate or mitigate: Within 15 days |
| 3 | Moderate Risk (5-9) |
Likelihood: Exploitation of a vulnerability by a threat actor against the asset is likely in general; some controls are in place to reduce the likelihood of occurrence against the specific asset. Mission Impact: Political, financial, legal, operational or reputational impacts may be felt for a month or more, but less than a year AND damages would impact three of fewer departments contained in a single UW-Madison division. Action: Prioritization of remediation efforts is required for all MEDIUM risks. Prioritization must be completed in less than three months. Execution of remediation efforts for MEDIUM risks is based on prioritization relative to other MEDIUM rated risks for the same system or environment. Mean time to remediate or mitigate: Within 90 days There may be security gaps that result in a risk score between moderate and high, which could result in a ‘split’ risk rating (moderate-high). Risk remediation is recommended at a pace faster than the lower rating but not to exceed the highest rating to lower the overall risk (likelihood x impact). |
| 4 | Low Risk (2-4) |
Likelihood: Exploitation of a vulnerability by a threat actor is difficult in general requiring expertise beyond one person with advanced computer skills or resources beyond those generally possessed by an individual. If exploitation is within reach of individuals, then our systems have controls to make it unlikely to experience an incident, in a defined time frame. Mission Impact: Political, financial, legal, operational or reputational impacts will be minimal. Operational impacts include: short term reallocation of current IT professionals and resources with localized or minor interruption of project work and non-mission critical services; the data custodian will be inconvenienced for some hours, but definitely less than one week. Action: Required action is limited to making the data custodians and their leadership aware of the risk. The risk must be tracked and reviewed at the next risk assessment, or sooner if changes to the likelihood or impact become apparent. Mean time to remediate or mitigate: Within 1 year There may be security gaps that result in a risk score between low and moderate, which could result in a ‘split’ risk rating (low-moderate). Risk remediation is recommended at a pace faster than the lower rating but not to exceed the highest rating to lower the overall risk (likelihood x impact). |
| 5 | Inconsequential Risk (1) |
Likelihood: Exploitation of this risk is not expected over the course of a defined time frame. The difficulty or expense of exploitation of the documented vulnerability is beyond most known organized crime groups. Mission Impact: No noticeable impact to any part of UW–Madison is predicted if the exploitation occurs. Action: Documentation in the risk register is required. Included the findings of NO RISK for the asset, from the specified threat-vulnerabilty. |
The matrix presented is consistent with the NIST Risk Management Framework (RMF) process and Federal Information Processing Standards (FIPS) guidance. Generalized presentation of FIPS specific matrix can be found in FIPS 199, February 2004, Table1.
- The Risk Levels presented here are the standard terms to be used at UW to facilitate improved communication across diverse groups.
- Risk ratings aid all parties in decision making throughout the RMF process.
- Typically, the table is not used in isolation: Impact and Likelihood must be defined and assessed. Discussion of these parameters follows.
- The impact to your group’s mission and the assessment of likelihood of realization of the impact from a threat-vulnerability combination should be tailored to your individual environment and needs.
- The likelihood and impact help in scoring risks of individual security gaps. The resulting risk scores assist in assessing an overall risk for analyses.
Risk ratings — calculating meaningful scores
A brief discussion follows, along with some examples. Please consult the UW–Madison Cybersecurity team if a more detailed discussion is needed regarding the development of a tailored impact score matrix, as well as the building of a Risk Register (not shown) from the resulting scoring.
Risk is attributed to assets based on the analysis of multiple factors which influence the Availability, Integrity or Confidentiality (AIC) of the asset.
- Confidentiality – preserving authorized restrictions on information access and disclosure, including means for protecting personal privacy and proprietary information.
- Integrity — guarding against improper information modification or destruction and ensuring information non-repudiation and authenticity.
- Availability – ensuring timely and reliable access to and use of information.
Factors include:
- Threats posed to that asset
- Vulnerabilities that expose the asset
- The impact to any of the UW–Madison mission, values or guiding principles
- The likelihood that the availability, integrity or confidentiality of the asset will be compromised through a given vulnerability by a threat actor
In a quasi-equation format:
[Risk(to AIC of an asset), (from a threat-vulnerability pairing)] = [the Likelihood of exploitation in a given time frame] × [the impact of such exploitation]
Or simply, Risk = Likelihood × Impact
Risk-scoring notes:
- The cataloging of risk calculations for assets is accomplished through OneTrust which acts as a Risk Register.
- Existing security controls need to be considered when evaluating the likelihood of an event.
- Similarly, existing controls are considered if they limit the felt impact to your mission.
- When a single score is requiring a complex system, the final highest risk level found for all components of the asset is used.
- Risks of a threat-vulnerability pairing can be evaluated individually for Availability, Integrity and Confidentiality (AIC) of the asset. Similarly, a single risk scoring can consider two of these or all three parameters.
Risk level is influenced by the type of data in question and the volume of data in question. Type and volume are considerations influencing the Impact score.