This working document is the implementation plan for the Cybersecurity Risk Management Policy. The plan will be reviewed by the community, Information Technology (IT) governance, and the IT Committee.

IMPLEMENTATION

For each information system, the Office of Cybersecurity will maintain a separate and detailed implementation plan that is jointly developed with the System Owner, also known as a System Security Plan. The Office of Cybersecurity will assist distributed Information Technology groups with developing implementation plans tailored to their group’s needs.

Data Classifications⁽¹⁾

The University has classified its institutional data assets into risk based categories for determining who is allowed to access institutional data and what security precautions must be taken to protect it against unauthorized access and use (see UW-504 Data Classification).

Data Classifications

Classification	Definition
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 the University is required to self-report to the government and/or provide notice to the individual if the data is inappropriately accessed or disclosed.
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 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.
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.

Risk Levels

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] X [the impact of such exploitation]

Incidents are categorized based on the severity of potential or actual impact to the university. The graphic below shows the color code as used in the Weekly IT Security Report provided to the University CIO and interested University leadership. Color codes are supported by a short narrative statement that summarizes the major impact of the incident.

Risk Rating Color Codes

Risk Level	Description
CRITICAL	Event in progress or significant loss of data and damage to university networks.
HIGH	Realized impact to the university.
MODERATE	Potential significant impact to the university.
LOW	No significant events.
NONE	No evidence of risk.

Please consult the Office of Cybersecurity if a more detailed discussion is needed or for assistance in the development of a tailored impact score matrix, as well as the building of a Risk Register (not shown) from the resulting scoring.

Risk Registration

Information systems proposed to undergo Risk Assessment are entered into the Risk Register managed by the Office of Cybersecurity. A Risk Analyst will be assigned as resources become available. Organizations desiring to accelerate the process can contact the Chief Information Security Officer for guidance and options for meeting Risk Analyst resource requirements.

Timeline

With the volume of systems and networks at the University, a full implementation of the Risk Management Framework will take approximately five years to complete. Implementation will initially focus on systems handling or storing data classified as Restricted, then Sensitive. Since exposure or loss of Internal or Public data does not pose an immediate operational impact or significant financial risk, those information systems will be reviewed as resources allow.

Priorities and Timeframe

Priority	Category	Timeframe
1	Systems with Restricted Data (PII/SSN’s, Financial Accounts, HIPAA)	2017 through 2018
2	Research systems where grant funding is tied to security requirements	2017 through 2019 and ongoing
3	New or significantly updated systems with Sensitive Data	2019 through 2020
4	Remaining systems with Sensitive Data	2020 through 2021 and ongoing
5	Systems that only handle Internal Data	2021 through 2022 and ongoing
6	Systems that only handle Public Data	2022 and ongoing

Throughout the implementation period, systems of all kinds will benefit from advanced firewalls and network protections as those capabilities are further deployed. Public facing web servers will be monitored on a monthly basis for unwanted traffic, evidence of cyber-attack or potentially harmful data loss activity to ensure openly accessible data is protected.

Training

Training on the processes, tools and use of or completion of artifacts will be provided by the Office of Cybersecurity with the details considered to be out of scope for this document. Ongoing security awareness training will be provided by the Cybersecurity Training Lead and access to training tools will be widely publicized on the Office of Cybersecurity web pages.

Training for Risk Executives will be provided by the Chief Information Security Officer on an individual or group basis depending on the need and executive schedules. Training is tailored to the Risk Executive’s needs and will include the items in the Step 5 Accept Risk section, including review of RMF packages aligned with the Risk Executive areas of responsibility.

PROCESS FOR MANAGING CYBERSECURITY RISK

This section describes process specific activities necessary to carry out the Cybersecurity Risk Management Policy. The process steps summarized below are required by UW-503 Risk Management. Amplification of process steps and a helpful background on the Risk Management Framework (RMF) are in Appendix A to this Implementation Plan.

Preparation for Risk Assessment

The first three steps of the Risk Management Framework (RMF) prepare the information system for a certifiable risk assessment. As shown in Appendix A, an information system is categorized according to the potential impact should the availability, integrity or confidentially of the system or data be compromised, (RMF Step 1.) Security controls are selected to reduce the likelihood and impact of a compromise, (RMF Step 2.) The security controls are implemented, then tested to measure how well they are functioning, (RMF Step 3.) At this point the information system is ready for a certifiable risk assessment.

Assessing, Accepting and Monitoring Risk

The Cybersecurity Risk Management Policy focuses on the final three steps of the RMF. The following describes the process which is mandated by the policy.

1. Assess Risk (RMF Step 4)

   The academic / functional unit and the Office of Cybersecurity cooperatively assess the cybersecurity risk associated with a system and if needed, consultation with other experts on campus.

2. Certify Risk (RMF Step 5)

   The University Chief Information Security Officer (CISO) signs the Risk Assessment to certify that the represented risk is accurate. The CISO may include recommended risk reduction strategies.

3. Accept Risk (RMF Step 5)

   The risk of operating the system is accepted by the Risk Executive on behalf of The University. This is a leadership decision and should be based on the following:

   1. Assessed risk and impact to the University should a system be compromised or data lost.
   2. Recommended remediation to include consideration for cost to implement.
   3. Impact on the business process should the system, while in operation, lose availability of the system or data, encounter data integrity issues, or breach confidentiality of Restricted or Sensitive data.
   4. The Risk Executive role is guided by the following:
      1. Risk Executives will be named within 60 days of the Cybersecurity Risk Management Policy being finalized. The initial list of Risk Executives will be the executives who reported IT spending for their unit as part of the second “IT Spend” report. The units reporting are listed in Appendix B to this implementation plan.
      2. The Risk Executive should be an executive or director, (e.g., Dean or their appointee, department chair, director of a research lab, etc.,) within the academic / functional unit, or in the line of authority above that unit. The Risk Executive must have the authority to accept the risk of operating the system on behalf of the institution and should be in the unit who will ultimately be responsible for paying for a breach (i.e., Dean or their appointee, department, research lab, etc.)
      3. Delegation of the Risk Executive role is not encouraged. If delegation of the work is made under the Risk Executive’s authority, the Risk Executive remains accountable for the outcomes.
      4. Risk Executives may access the expertise, training and support available from the Office of Cybersecurity for advice in making their risk determination or for additional guidance.
      5. The Risk Executive must be afforded a sufficient understanding of the information system through the technical experts and managers associated with the system.
      6. The Risk Executive balances the business needs, the potential financial and reputational cost of adverse events, and the cost of reducing the likelihood and severity of those events.
      7. After reviewing the Risk Assessment and recommendations of the Office of Cybersecurity, the Risk Executive will:
         1. accept the risk as certified, or
         2. assure that recommended action is taken to reduce the risk to an acceptable level, or
         3. decline to authorize the system to operate.
      8. Training for Risk Executives will be provided by the Chief Information Security Officer on an individual or group basis depending on the need and executive schedules. Training is tailored to the Risk Executive’s needs and will include the items in 4.a. through g. above and will include review of a representative RMF package.

4. Reduce Risk (RMF Step 5 and 6)

   The acceptable level of risk may be constrained by legal, regulatory or contractual requirements, and is subject to review by university leadership.

   If the certified level of risk is unacceptable:

   1. The Risk Executive assures that changes are made to the system that reduce the risk to an acceptable level.
   2. The assessment and certification described in A. Assess Risk and B. Certify Risk are revised following confirmation of corrective actions. The reduced level of risk is then accepted as described in C. Accept Risk.

   Following the Risk Assessment and subsequent acceptance by the Risk Executive, information systems with vulnerability, threat and impact changes that elevate the level of risk will have to be corrected or mitigated back to the assessed level (or lower) within the following time limits:

   1. Issues that elevate the risk level to Critical should be corrected or mitigated to no greater than High within 72 – 96 hours or the system should be disconnected.
   2. Issues that elevate the risk to High should be corrected or mitigated to Moderate within 15 calendar days.
   3. Issues that elevate the risk to Moderate should be corrected or mitigated to Low within 90 calendar days.
   4. If the issue occurs on a system evaluated at Low risk, but does not elevate the risk to Medium, it should be corrected within one year.

   In all cases, the Risk Register maintained by the office of Cybersecurity should be updated along with adjusting the existing risk assessment and plan of action and milestones.

5. Monitor Risk (RMF Step 6)

   The academic / functional unit and the Office of Cybersecurity continually monitor the system to assure that the level of risk remains at or below the level accepted in C. Accept Risk.

   1. There must be policy and procedural safeguards to assure that monitoring activity respects privacy and academic freedom.
   2. The design and implementation of monitoring is included in the assessment and certification described in A. Assess Risk and B. Certify Risk. Monitoring must be designed and implemented to, at a minimum:
      1. detect known security vulnerabilities and threats, and
      2. detect known indications that the system may be compromised.
   3. Where the identified problems are individually or collectively significant enough to increase the level of risk above the level accepted in C. Accept Risk, the identified problems must be sufficiently mitigated, as described in D. Reduce Risk, to return the level of risk to the level accepted in C. Accept Risk.

6. Re-evaluate Risk (RMF Step 6)

   Risk evaluation occurs throughout the system life cycle as follows:

   1. The schedule for risk evaluation is part of the assessment and certification described in A. Assess Risk and B. Certify Risk. A typical schedule includes a formal evaluation every three years and an informal evaluation annually.
   2. Change management is part of the assessment and certification described in A. Assess Risk and B. Certify Risk. Changes to the system that increase risk may require more immediate evaluation.
   3. Following an evaluation, the assessment and certification described in A. Assess Risk and B. Certify Risk are revised, the risk is accepted or reduced as described in C. Accept Risk and D. Reduce Risk, and monitoring continues as described in E. Monitor Risk.

Special cases

Non-University-owned devices and services used for university business may be treated as part of a University information system, and if so, are subject to this policy. There must be policy and procedural controls in place to assure respect for property and privacy. Also see UW-526 Endpoint Management and Security.

CONTACT

Questions and comments to this document can be directed to Risk Management and Compliance.