Risk Notification Form Instructions

This Knowledge Base Article provides step-by-step instructions for completing the Risk Notification Form, ensuring accurate risk identification, assessment, and documentation. It guides faculty, staff, and researchers in disclosing potential risks related to university operations, research, and information security while maintaining compliance with institutional policies and regulatory standards.

The CoE Risk Notification Form is used to formally identify, assess, and document risks related to university operations, research, and information security. Completing this form ensures compliance with university policies, state and federal regulations, and industry standards. Please follow these instructions carefully to provide accurate and thorough information.

  1. REQUESTOR FULL NAME: The requestor must be the individual submitting this notification. Enter your full legal name as the responsible party. If you need assistance with any technical details, you may consult your Department Support Person (DSP) for guidance.
  2. E-MAIL(S): Provide your UW email address and any additional email addresses that should receive updates on this request.
  3. RISK TYPE: Select the category that best describes the area where security requirements cannot be fully met. This helps assess the scope of the risk and determine appropriate mitigation strategies:
    • Users: The security requirement cannot be met due to issues related to faculty, staff, students, or others engaged in UW business. This may include account management challenges, inability to enforce multi-factor authentication, excessive access privileges, or exceptions to standard identity and access management policies.
    • Assets: The security requirement cannot be met due to limitations with physical or virtual devices used for UW business. This may involve outdated or unsupported hardware/software, inability to apply required security patches, use of non-compliant personal devices, or restricted ability to encrypt university-owned assets.
    • Systems: The security requirement cannot be met for a system with access to UW resources, whether on-premises or cloud-based. This could include applications or platforms that lack necessary security controls, legacy systems that cannot support modern security standards, or third-party services that do not fully align with university compliance requirements.
    • Other: If the security requirement does not fall under the categories above, provide a brief description. Examples may include specific research needs, unique infrastructure, or external collaborations that prevent full adherence to security standards.
  4. APPLICABLE POLICY/PROCEDURE/DEPLOYMENT CRITERIA: Identify the specific UW System, UW Madison, or College of Engineering information policies, procedures, or deployment criteria that cannot be fully complied with due to the accepted risk. Provide document references if possible. Explain the specific policy or procedure that is impacted and the reasons compliance is not feasible. Include any relevant challenges or limitations that prevent adherence to the required security standards or deployment criteria.
  5. REQUEST CATEGORY: Select the category that best describes the situation regarding compliance and risk mitigation. This section helps clarify how the risk is being managed and what actions, if any, are being taken to address the identified gaps:
    • Compensating controls exist or are readily available: This option should be selected if alternative security measures or controls are in place to mitigate the risk. These compensating controls should be effective in addressing the risk and maintaining an acceptable level of security, even if they do not fully align with the original security requirements. Examples might include implementing multi-factor authentication or additional monitoring in place of a required encryption standard.
    • Compensating controls do not exist, but risk is within acceptable tolerances: Select this option if no alternative security measures are currently in place, but the risk is considered acceptable based on the university’s risk management framework. This means that while the non-compliance may pose some level of risk, the overall impact is manageable and does not pose an immediate threat to the institution's security or operations. Provide justification for why the risk is acceptable, such as low likelihood or minor consequences.
    • A policy, procedure, or deployment is not applicable: Choose this category if the identified policy, procedure, or deployment requirement is not relevant to the specific situation or use case. This could happen if the policy or procedure was designed for a different type of system, technology, or business process that does not apply to the current scenario. Be sure to explain why the policy does not apply.
    • Legacy system to be retired: This category should be selected if the system in question is outdated and will be decommissioned or replaced in the near future. Specify an estimated retirement or replacement date to indicate when the risk will be mitigated. It is important to provide a timeline for this action to ensure the risk is managed until the system is retired.
    • Other: If the situation does not fit within any of the above categories, select "Other" and provide a detailed explanation. This could include unique circumstances, special considerations, or additional context that does not align with the standard categories but still requires risk acceptance.
  6. REQUEST: Provide a detailed explanation of the challenges preventing full compliance with the relevant UW System policy or procedure. These challenges may be operational, technical, financial, or functional, and should clearly describe why compliance is not feasible in the current situation.
    • Operational Challenges: Describe any internal processes, workflows, or organizational limitations that prevent compliance. For example, this could include lack of resources, insufficient staffing, or difficulty integrating security practices into everyday operations.
    • Technical Challenges: Explain any technical barriers that prevent meeting the policy or procedure requirements. This might include legacy systems, incompatible software, hardware limitations, or challenges in applying required security patches or configurations.
    • Financial Challenges: If cost is a factor in non-compliance, explain the financial barriers. This could include high costs for upgrading systems, acquiring new tools or technologies, or insufficient funding for staff training or support.
    • Functional Challenges: Identify any functional limitations that hinder compliance. This could include specialized use cases or research environments where standard security measures cannot be easily applied or where certain features are incompatible with security protocols. Additionally, if compensating controls have been implemented to mitigate the risk, provide a brief description of the controls in place. For example, if encryption cannot be applied, a compensating control might involve increased network monitoring or access control measures.
      If security controls exist, provide a summary of how they help mitigate the risk. This could include firewalls, intrusion detection systems, encryption, or any other safeguards in place to address security gaps. Be specific about how these controls reduce the risk to an acceptable level and explain their effectiveness in the current environment.
  7. REQUESTOR SIGNATURE: You are required to enter your full name as your digital signature in this Google Form. If your signature does not match your full name on record, this notification will be invalid and you may have to resubmit. By signing, you acknowledge that:
    • This form serves as a request for exemption from compliance with certain UW policies, pending approval by the appropriate risk executives.
    • Submitting this risk notification does not grant immediate permission to deviate from university policies; approval is contingent upon the assessment of the associated risk executives.
    • If granted, the exemption will be valid for a maximum of one year, with the exact duration determined by the risk executives. A new risk notification must be submitted before the expiration of the exemption for reassessment. A renewal is only necessary if the risk will still be present after the expiration date. If the notification expires without renewal, it will no longer be valid, and continuing actions without review will violate UW policy.
    • You are responsible for adhering to cybersecurity best practices and ensuring the confidentiality, integrity, and availability of university resources.
    • Any negligence, misuse, or intentional violations may lead to disciplinary actions, civil penalties, or criminal prosecution under SYS 25-3 Acceptable Use of IT Resources.

Final Steps

  • Review your responses for accuracy before submission.
  • Select "Send me a copy of my responses" if you would like to retain a copy for your records.
  • Submit the form through the designated university system or email as instructed.

For further assistance, contact the Information CAE IT Compliance Team at compliance-request@cae.wisc.edu.



Keywords:
risk notification form instructions 
Doc ID:
148358
Owned by:
Matt T. in CAE
Created:
2025-02-14
Updated:
2025-02-18
Sites:
Computer-Aided Engineering