Compliance Management Standard

Standard Number: 1.11.2.1.1
Category: Information Security
Owner: Information Security Services
Effective: March 24, 2023
Revision History: Replaces the Compliance Exception Management Standard originally effective September 22, 2020
Review Date: March 23, 2026

1. Purpose, Scope, and Responsibilities
   

   1. Pursuant to the Information Security Policy, Information Technology Services (“ITS”) implements University technology policies and standards (“Technology Governance”) that enhance the Security Posture of the University. Individual colleges, departments, programs, and/or third-party vendor must meet the minimum-security requirements identified within approved Technology Governance. In cases of non-compliance, ITS will act to secure the resource and may limit or disconnect access to the Campus Network. Exceptions to compliance with established Technology Governance may be granted when there is a valid justification for not being able to comply.
   2. The purpose of this Standard is to establish the rules and requirements for how the University will identify and address instances of non-compliance with Technology Governance, limit or disconnect access to the Campus Network, and assess requests for compliance exceptions.
   3. This Standard applies to all instances of non-compliance with established Technology Governance, regardless of where the information or University Technology Resource(s) reside or who manages them. It is based on NIST 800-30r1: Guide for Conducting Risk Assessments.
   4. The Chief Information Officer, supported by the Chief Information Security Officer, is responsible for the implementation and enforcement of this Standard.
   5. Information Security Services (“ISS”) is responsible for implementing new and updating existing Technology Governance, identifying instances of non-compliance across campus and notifying owners, their supervisors, and/or their IT Leader that they are out of compliance, establishing procedures to submit and review compliance exception requests, and maintaining and administrating the information system of record for all University compliance exceptions.
   6. IT Leaders are responsible for identifying instances of non-compliance within their area of responsibility, assisting individuals with remediation measures to correct the issue (if needed), being the first line of review of compliance exception requests and working with the individual to implement appropriate compensating controls to mitigate the risks associated with the compliance exception. IT Leaders are also responsible for annually reviewing approved compliance exception requests and being a liaison between the individual requesting the exception and ISS.
   7. Individuals who are identified as owners of an instance of non-compliance are responsible for remediating the issue by the identified remediation deadline or submitting a compliance exception request. Those who are seeking a compliance exception to Technology Governance must contact their IT support staff to discuss options, including implementation of compensating controls to mitigate the risks associated with the compliance exception.
   8. All University employees and students are required to adhere to the established Technology Governance until approval of a compliance exception is officially granted.

2. Non-Compliance Identification and Notification

   1. Once an instance of non-compliance with Technology Governance has been identified, the appropriate IT Leader can seek to remove the device or system from the Campus Network by notifying the owner of the non-compliant system/device in writing. Notification must include the following information. See Appendix I:
      1. Description of governance requirement and how the issue is not meeting the requirements;
      2. Remediation measures required to correct the issue; and,
      3. Deadline for owner to respond. Owner must respond no later than 15 days from the date of the notice.
   2. The initial notice must be sent to the owner, the owner’s supervisor, and Information Security Services.
   3. A second notice must be sent after the initial 15 days to identify the owner’s response. Resolution options include:
      1. Remediation of the issue by the identified deadline, or
      2. Submission of a compliance exception. See Section 3.
   4. The second notice must be sent to the owner, the owner’s supervisor, the owner’s senior leadership (e.g., dean, director), and Information Security Services identifying the deadline for remediation, or the device/system will be disconnected from the Campus Network.
   5. Failure of the owner to remediate the issue by the identified deadline or coordinate with their IT Leader to submit an exception request will result in the device/system being removed from the Campus Network.
   6. The requirements identified within this Section must be completed as identified before disconnecting any device/system from the Campus Network unless the issue poses an immediate risk to the University.

3. Compliance Exceptions
   

   1. Exceptions to compliance with established Technology Governance may be granted when there is valid justification for not being able to comply.
   2. Exceptions may be granted in one of the following categories only when there is a valid justification for not being able to comply:
      1. Regulatory compliance. Technology Governance conflicts with federal, state, or international regulations.
      2. Research compliance. Research project operations or contractual obligations necessitate an exception.
      3. Software or hardware conflict. Software or hardware constraints necessitate an exception.
   3. Approved compliance exceptions are considered and tracked as technology risks to the University.
   4. Compliance exceptions are only approved for a maximum of one year.
      1. Upon expiration, the exception request must be re-reviewed and re-approved to determine if it is still necessary, if additional controls must be implemented, or if the exception should be denied due to a change in the University’s risk tolerance levels.
      2. Exceptions not reviewed and re-approved will no longer be valid. IT directors must ensure all non-valid exceptions are not in operation; otherwise, ISS will remove the device(s) from the Campus Network.
   5. Compliance exceptions will not be granted for the following reasons:
      1. The exception is contrary to regulatory requirements or law;
      2. Convenience; or,
      3. Appropriate alternative security controls cannot be implemented to mitigate the risks posed.
   6. In the event a Security Incident occurs, and it was inherently caused by an existing compliance exception, ISS will disconnect the device(s)/systems(s) from the Campus Network immediately.

4. Compliance Exception Threat Assessment
   

   1. All compliance exception requests must be submitted to the individual’s appropriate IT support group for review.
   2. Once received, IT Leaders must identify the potential Threat(s) the exception would pose to the University and the likelihood such a Threat would occur related to the specific device(s)/information system(s) associated with the request. Threat sources can be adversarial, accidental, structural, or environmental. See Appendix I.
   3. The following Threat categories will be used for all identified Threat sources. Common Vulnerability Scoring System (CVSS) scores are provided for guidance:
      1. Rare. Indicates error, accident, exploit, or act of nature is highly unlikely to occur (e.g., occurs less than once every 10 years) and that rare circumstances are required to be able to be exploited (CVSS score 0).
      2. Unlikely. Indicates error, accident, exploit, or act of nature is unlikely to occur (e.g., occurs less than once a year but more than once every 10 years) and would require unlikely circumstances to be able to successfully exploit (CVSS score 0.1-3.9).
      3. Possible. Indicates error, accident, exploit, or act of nature is somewhat likely to occur (e.g., occurs between 1 and 10 times per year) and although they may be more difficult to exploit but could still lead to compromise under certain circumstances (CVSS score 4.0-6.9).
      4. Likely. Indicates error, accident, exploit, or act of nature is highly likely to occur (e.g., occurs between 10 and 100 times per year) and is exploitable by local users and authenticated remote users (CVSS score 7.0-8.9).
      5. Almost Certain. Indicates error, accident, exploit, or act of nature is almost certain to occur (e.g., occurs more than 100 times per year) and can be easily exploited by an unauthenticated remote attacker leading to compromise (CVSS score 9.0-10.0).
   4. IT Leaders must also identify the possible adverse impacts of the compliance exception, should an actual Threat event occur as follows:
      1. Insignificant. Indicates the effects of the error, accident, exploit, or act of nature are minimal (i.e., affects user), involving few, if any, of the cyber resources of the University and no Mission Critical, Business Critical, or Core Services.
      2. Minor. Indicates the effects of the error, accident, exploit, or act of nature are limited (i.e., affects group of users, class, lab), involving some of the cyber resources of the University, but no Mission Critical, Business Critical, or Core Services.
      3. Moderate. Indicates the effects of the error, accident, exploit, or act of nature are wide-ranging (i.e., affects building, department), involving significant portion of the cyber resources of the University, including Business Critical or Core Services, but not Mission Critical Services.
      4. Major. Indicates the effects of the error, accident, exploit, or act of nature are extensive (i.e., affects campus, identity management system, finance systems), involving most of the cyber resources of the University, including many Business-Critical Services, Core Services, or Mission Critical Services.
      5. Catastrophic. Indicates the effects of the error, accident, exploit, or act of nature are sweeping, affecting University emergency, life safety, or life support systems, and involving almost all cyber resources of the University.

5. Compliance Exception Risk Level
   

   1. Based on the results of the Threat assessment, the compliance exception is assigned one of the following risk severity levels based on the likelihood and the adverse impact should an actual Threat event occur due to the exception. See Risk Matrix Appendix II.
      1. Very High. Indicates a Threat event could be expected to have multiple severe or catastrophic adverse effects on University operations, organizational assets, individuals, or other organizations.
      2. High. Indicates a Threat event could be expected to have a severe or catastrophic adverse effect on University operations, organizational assets, individuals, or other organizations.
      3. Moderate. Indicates a Threat event could be expected to have a serious adverse effect on University operations, organizational assets, and individuals, or other organizations.
      4. Low. Indicates a Threat event could be expected to have a limited adverse effect on University operations, assets, and individuals, or other organizations.
      5. Very Low. Indicates a Threat event could be expected to have negligible adverse effect on University operations, assets, and individuals, or other organizations.

6. Compliance Exceptions Review

   1. All requests for compliance exceptions must be entered into the system of record and include the following information:
      1. Name of exception owner;
      2. Description of the exception;
      3. Name of the Technology Governance that applies and requirements therein;
      4. Threat Assessment. See Section 3 of this document;
      5. List of mitigating controls in place;
      6. Resolution timeline and plan to remove need for exception in the future;
      7. End date for risk acceptance;
      8. Potential alternate solutions, if available; and,
      9. Overall level of risk and justification for determination.
   2. ISS will review all compliance exception requests submitted to confirm initial Threat Assessment and overall risk rating, identify alternate solutions, and/or identify compensating controls.
      1. IT directors may approve all compliance exceptions requests with Very Low or Low risk level determination.
      2. Medium-risk exception requests must be approved by a department chair/director.
      3. High-risk exception requests must be approved by a dean/vice president.
      4. Compliance exceptions with Very High-risk rating will not be approved.

7. Definitions

   1. “Risk” means the relative impact that an exploited vulnerability would have to a user’s environment.
   2. “Security Incident” means a violation or imminent threat of violation of Technology Governance or standard security practices.
   3. “Security Posture” means the security status of an enterprise’s networks, information, and systems based on information security resources (e.g., people, hardware, software, policies) and capabilities in place to manage the defense of the enterprise and to react as the situation changes.
   4. “Threat” means any circumstance or event with the potential to adversely impact the University’s operations, assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, modification of information, and/or denial of service. Threats inherently include Vulnerabilities.
   5. “University Technology Resource” means the Campus Network, University-owned hardware, software, and communications equipment, technology facilities, and other relevant hardware and software items, as well as personnel tasked with the planning, implementation, and support of technology.

8. Related Documents

   1. Information Security Policy