University of Wisconsin–Madison
Digital shield in cyberspace with a person selecting it with their finger.

Risk Management and Compliance (RMC)

Line art image of a lock with a red cross

RMC Service catalog

It’s never too late to ensure data security on campus. The Cybersecurity Risk Management & Compliance team can assist at any point in your use of a new service, application or vendor.

Pre-purchase

Cybersecurity can take a high-level look at how data is handled prior to purchase.

  • CCR
  • RTP
  • Interim RMF

As Needed

Some services can be made available as new needs arise.

  • Secure Box
  • Restricted Research Drive
  • JSPR

Active use

Once a service is in place, Cybersecurity can ensure data is being completely secured.

  • HIPAA Risk Assessment
  • Full Department Risk Assessment
  • CCR
  • Interim RMF

Note: CCR and Interim RMF can be done before of after purchase.

RMC Assessment Types

This is an accordion element with a series of buttons that open and close related content panels.

Cybersecurity Consultative Review (CCR)(Technology Request Non-Procurement)

Use Case

HIPAA or Non-HIPAA used prior to various Cybersecurity Assessments and Consultations to offer expertise on various ad hoc requests. May also be requested when a vendor or service is discovered in use. Can apply to specific HIPAA Security Rule. Can assist with development of procedures to comply with the security rule; advise on security configurations.

How To request

Complete the OneTrust intake form.
If you have questions, please contact rmc-cybersecurity@cio.wisc.edu.

Risk Exec Signature Required

Any Risk – E-mail to Risk Executive, no Risk Executive signature needed.  Report should be e-mailed to the researcher/PI for return with signature.

Estimated Time

Generally happens before any other stage of assessment, but could also happen at any stage. Time varies based on request.

Next Steps Could Include

RTP and/or Full RMF once installation is complete.

Request to Procure (RTP) Technology Request HIPAA or Non-HIPAA

Use Case

Used for reviewing initial risk before purchase (may include contract review or participation in an RFP process). Technological assessment of system/application/software that is considered for acquisition by UW. Generally has a very defined scope.

How To request

Complete the OneTrust intake form.
If you have questions, please contact rmc-cybersecurity@cio.wisc.edu.

Risk Exec Signature Required

Any Risk – E-mail to Risk Executive. No approval needed from Risk Executive. Can be forwarded to Purchasing.

Estimated Time

2-4 weeks

Next Steps Could Include

Full RMF once installation is complete.

Interim Risk Assessment RMF/Recommendation for Operation Interim (non-HIPAA)

Use Case

An assessment conducted prior to normal operations. May require remediation prior to approval to enter full operations. May also be requested when a vendor or service is discovered in use.

How To request

Complete the OneTrust intake form.
If you have questions, please contact rmc-cybersecurity@cio.wisc.edu.

Risk Exec Signature Required

Yes.

Estimated Time

2-4 weeks

Next Steps Could Include

Full RMF once installation is complete and remediation has occurred.

Full Risk Assessment

Use Case

RMF/Recommendation for Operation (RO) (non-HIPAA OR HIPAA)  Assess a defined-scope technology, infrastructure, process, or department against our expectations for security posture. Include HIPAA criteria for ePHI as applicable. May require a BAA with vendor based on results of vendor data.

How To request

Complete the OneTrust intake form.
If you have questions, please contact rmc-cybersecurity@cio.wisc.edu.

Risk Exec Signature Required

Yes

Estimated Time

2-4 Months, 8-10 Sessions.

Next Steps Could Include

Annual review and reduction of items in Risk Register

Joint Security & Privacy Review (JSPR) (HIPAA)

Use Case

For groups or research projects that process Protected Health Information (PHI), and don’t need a full HIPAA Risk Analysis. Used for reviewing research projects. Evaluate research proposal to use or disclose PHI. Also used for evaluating software that will be used in a research proposal. UW–Madison Principle Investigators (PI) should request a Joint Security and Privacy Review to evaluate their proposal to process or disclose PHI. Use cases include IRB research, educational activities, projects involving another entity receiving UW PHI, or projects receiving PHI from another entity for a reason other than treatment.

How To request

Complete the OneTrust intake form.
If you have questions, please contact rmc-cybersecurity@cio.wisc.edu.

Risk Exec Signature Required

Low Risk – email, no approval needed. Signed by Researcher.

Moderate to Critical – Schedule a formal Risk Executive Meeting. Signature required by the Risk Executive.

Estimated Time

3-6 weeks

Next Steps Could include

Full RMF

Secure Storage RMC Services

This is an accordion element with a series of buttons that open and close related content panels.

Secure Box / Secure Storage

Use Case

Available to UW-Madison staff for the storage and collaboration with restricted data (including ePHI) with a maximum available space of 50GB.

How To request

Complete the OneTrust intake form.
If you have questions, please contact rmc-cybersecurity@cio.wisc.edu.

Risk Exec Signature Required

No, but communication back to distributed IT will accompany letter to researcher. Risk Analyst will request researcher signature. 

Estimated Time

2-4 weeks.

Next Steps

None unless scope of work changes.

Restricted Research Drive

Use Case

Available to UW-Madison faculty Primary Investigators (PIs), permanent PIs and their research groups for storage, back-up and collaboration on restricted data. Maximum space availability is 5TB with the option to purchase additional storage space.

How To request

Available upon request through Research Cyberinfrastructure intake form which will forward to Cybersecurity.

Risk Exec Signature Required

No, but communication back to distributed IT will accompany letter to researcher. Risk Analyst will request researcher signature. 

Estimated Time

2-4 weeks.

Next Steps

None unless scope of work changes.

Data Classification

Classifying data allows Cybersecurity a clear vision of what kind of data is in a school, department, college or network.

This also provides a clearer methodology to understand:

  • Where data is stored
  • Who has access to it
  • What security risks exist

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.

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.

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.

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.

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.

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.

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.

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.

Note: Increased data fields in higher data classifications may result in the need for greater security, i.e. multiple sensitive data points could result in an overall data classification of restricted.

Data Classification

Data Stewards are required by UW System Administrative Policy 1031 to classify major data systems based on risk and to review the classifications annually. UW–Madison classifies data as Public, Internal, Sensitive, or Restricted. UW–Madison also uses these classifications for provisioning access to data to individuals. Descriptions of UW–Madison’s four data classification categories follow.

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.

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.

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.

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.

Likelihood and Impact

When calculating risk, the Office of Cybersecurity will always rely on the ability to trust the risk math. The formula for calculation of risk looks like this:

Risk = Vulnerability (Impact x Likelihood) ∝ Vulnerability Age ÷ Known or Approved Mitigation (People, Process or Tools)

Likelihood

Likelihood is a frequency-based measurement. UW–Madison bases frequency on a 3 year period.

Likelihood Frequency Probability
1) Not foreseeable / Very Unlikely not in 3 years Exploitation of the vulnerability is not reasonable without extensive expertise, time and resources. The effort level is great enough to discourage most organized crime groups.
2) Foreseeable / Somewhat Likely once in 3 years Security Controls are in place to stop most attempts by attackers. No automated tools are well known which allow remote discovery and execution of the vulnerability. Exploitation of the vulnerability would require technical expertise, time or resources beyond those of small groups of individuals.
3) Repeated / Likely 2-3 times in 3 years Security controls are not in place to stop attacks with certainty. Tools to remotely discover or exploit the vulnerability are known to exist, but not widely/freely available.
Exploitation methods require some expertise, time and resources exceeding most individuals.
4) Recurring / Very Likely more than once a year Security controls are not in place to effectively stop attacks, or detection-response capabilities are in adequate to appreciably slow the progress of attempted attacks.
Methods of exploitation of this vulnerability are discoverable or known; tools to do so are free or easy to obtain.
Limited skills are need to employ the tools successfully.
5) Frequent / Almost certain or already occurred monthly or greater Security Controls are not implemented to stop, thwart, or detect successful exploitation of the vulnerability.
Methods of exploitation of the vulnerability are easily found, freely available, or trivial to employ.
Evidence discovered during testing indicates that exploitation may have already occurred.

Impacts

Impact is the outcome that effects the political, financial, legal, operational or reputational areas of campus.

  • Mission A: Education of new Healthcare Practitioners
  • Mission B: Delivery of Health Care
  • Mission C: R1 level research (Doctoral University, Highest Research activity)
  • Mission D: Service Delivery
wdt_ID Impact to Mission of Division or HCC Mission A Mission B Mission C Mission D
1 1) Negligible Minor delay in access to records for teaching purposes, classes continue Minor records inconvenience or access to medical records disruption, not affecting final patient care Minor delays (< 1 week) to research Minor delays in service provision less than 24 hours
2 2) Noticeable Cancelation of one class, or rounds, for one day 1 ~ 5 patients not able to receive scheduled health care; forced reschedule Research delayed one week to one month Service Provision delays of 24 hours to 3 days
3 3) Significant Loss of the authority to use PHI in teaching of one or more courses. Loss of access rights to PHI for multiple students. more than 5 patients forced to reschedule on a single day, or one patient needing prompt care required to be sent to another provider Research delayed more than one month, up to six months; avoidable additional costs incurred. Third party suspension of access to some PHI for one or more faculty. Service Provision delays of 4 days to 2 weeks
4 4) Highly Disruptive Loss of clinical rotation at UW forcing multiple students delay or relocation for rotation. Suspension of access rights for students to PHI for a week, up to a semester 2 or more patients needing prompt care, or one patient needing urgent care forced to be sent to another provider; clinic is forced to stop operations for more than 2 days Denied or loss of a single, major grant, or cumulative grants totally >= $1Million; Delays of 6~ 12 months Service Provision delays of 2 weeks to a month; Some loss of data requiring time to restore/rebuild
5 5) Catastrophic Delay of graduation of an entire Med Class for up to a year Suspension of operations of a clinic or facility for a month or more Major Funding body (e.g. NIH) sanctions/fines resulting in loss of, one or more grants in total > $5Million; Suspended indefinitely Service Provision delays and outage greater than a month; Extensive loss of data with inability to restore some or all data elements

Campus Risk Ratings

wdt_ID RATING (LIKELIHOOD 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.

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.

3 MEDIUM 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.

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.

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 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.

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. Factors include:

  • Threats posed to that asset
  • The vulnerabilities that expose the asset
  • The impact to any of the UW-Madison mission, values or guiding principles and
  • 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 often accomplished through some tool, such as a spreadsheet, acting as a “Risk Register.” Cybersecurity has a template to get you started.
  • 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.

Campus Risk Executives