Body
Overview
When departments request or purchase new technology, the solution must be reviewed to ensure it meets Central Piedmont’s security, operational, and support standards.
In some cases, a solution does not fully meet these standards but is still necessary to support departmental operations. When this occurs, ITS Cybersecurity & CISO and Enterprise Risk Management (ERM) perform a Risk-Based Decision (RBD) review.
The RBD process allows the college to evaluate and document potential risks associated with using the technology and determine whether those risks are acceptable with appropriate safeguards.
An RBD does not necessarily prevent the use of a solution. Instead, it ensures that risks are reviewed, documented, and formally accepted before implementation.
Relationship to the ITS Tiered Support Framework
Technology support at the college is defined by the ITS Tiered Support Framework.
The framework clarifies the level of support ITS can provide for different types of technology solutions and helps ensure that institutional resources are aligned with sustainable and supportable systems.
You can review the full framework here: ITS Tiered Support Framework
Within this framework:
Tier 1 – Full Support
- Enterprise or institution-wide solutions
- Fully supported by ITS
- Vendor support contracts required
Tier 2 – Partial Support
- Departmental solutions that meet ITS technical standards
- Vendor support is primary
- ITS assists with integrations, updates, and configuration
Tier 3 – Limited Support
- Solutions that do not meet ITS technical support standards
- Department or vendor responsible for most support activities
- Risk-Based Decision approval may be required before implementation
When a solution falls into Tier 3, the RBD process may be required to document and evaluate potential risks.
When a Risk-Based Decision Is Required
A Risk-Based Decision (RBD) is required when a technology solution introduces risk that cannot be fully addressed through existing security or operational controls, or when a solution deviates from institutional technology standards in a way that affects risk management.
The purpose of the RBD process is not to require strict adherence to every technical preference or architecture standard. Instead, the process ensures that any risk introduced by a system is properly evaluated, documented, and accepted.
Cybersecurity evaluates the system to determine whether the implementation still satisfies the intent of applicable controls within the CIS Critical Security Controls framework used by the college.
Examples include situations where:
-
A system does not support Single Sign-On but still implements appropriate role-based access control and user management.
-
A specialized device requires restricted network connectivity but can be secured through network segmentation or limited access controls.
-
A vendor-managed or department-managed system introduces operational dependencies that must be documented and accepted.
If the system introduces risk that cannot be fully mitigated through standard controls and requires formal documentation of residual risk, an RBD is required.
ITS Cybersecurity determines when the introduction of risk requires documentation through the RBD process.
Risk Evaluation
During the RBD review, Cybersecurity evaluates the system against the college’s security framework and operational standards.
The assessment considers:
-
identified threats or vulnerabilities associated with the system
-
alignment with CIS Critical Security Controls
-
operational and support considerations
-
compensating controls implemented to reduce risk
Cybersecurity documents the risk assessment in the Residual Risk Report, which includes the identified risk, likelihood, overall risk rating, and any compensating controls that will be implemented.
The report is then reviewed by Enterprise Risk Management before a final determination is made regarding whether the risk is acceptable.
What to Expect During an RBD Review
During this process, Cybersecurity may request additional information from the requestor in order to complete the assessment. This may include technical documentation, security information, or clarification about how the system will be used.
Because the RBD process involves additional analysis and coordination with Enterprise Risk Management, the review will extend the overall technology review timeline. In some cases, this may delay purchasing or implementation until the risk assessment and any required approvals are completed.
Providing vendor documentation and technical details early in the request process can help reduce delays and allow the assessment to be completed more efficiently.
Selecting Technologies That Align with ITS Standards
Departments can help avoid delays in the technology review process by selecting solutions that align with ITS technical and security standards. Solutions that meet these standards are more likely to qualify for Tier 1 or Tier 2 support and may not require a Risk-Based Decision review.
Departments should review applicable ITS technology and security standards when evaluating new solutions and ensure vendors can meet those requirements.
Risk Acceptance
After the Risk-Based Decision assessment is completed, the documented risks are reviewed through the college’s risk management process.
- ITS Cybersecurity performs the technical risk assessment and documents the findings in the Residual Risk Report.
- Enterprise Risk Management (ERM) reviews the assessment and determines whether the identified risk is acceptable.
- If ERM determines that the risk cannot be fully mitigated through technical or operational controls, the leadership of the system owner’s department may be required to formally acknowledge and accept responsibility for the residual risk in order for it to be accepted.
This acknowledgement confirms that departmental leadership understands the risks associated with implementing or operating the system and agrees to proceed under the documented conditions.
The risk acceptance process and signatures are recorded within the Residual Risk Report as part of the official documentation for the system.
Understanding Risk Acceptance
Risk acceptance does not mean that a technology purchase is being blocked or that Cybersecurity has determined the solution cannot be used. The purpose of the Risk-Based Decision process is to ensure that risks introduced by a technology solution are visible, documented, and understood before implementation.
In some cases, compensating controls can reduce risk to an acceptable level without additional action. In other situations, certain risks cannot be fully mitigated due to technical limitations, vendor constraints, or operational requirements. When this occurs, the remaining risk must be formally acknowledged through the college’s risk management process.
Requesting acknowledgement from departmental leadership ensures that decisions involving institutional risk are made with appropriate visibility and accountability. This allows departments to move forward with solutions that support their operational needs while ensuring that potential risks have been reviewed and accepted through the appropriate governance process.
Department Responsibilities for Tier 3 Technologies
When a technology solution is approved through the RBD process and classified as Tier 3 – Limited Support, the department is responsible for the ongoing operation and maintenance of the system. This typically includes:
-
Coordinating installation and support with the vendor
-
Managing system configuration and user access
-
Maintaining vendor support agreements where applicable
-
Applying vendor updates and patches
-
Contacting the vendor for troubleshooting and technical issues
Departments are also responsible for managing any security vulnerabilities identified on the system. This includes monitoring for vendor security updates, applying patches, and remediating vulnerabilities within the vulnerability remediation service level agreements (SLAs) defined by ITS.
If vulnerabilities are identified, the department must take prompt action to remediate them in accordance with the defined remediation timelines.
If a vulnerability cannot be remediated due to vendor limitations, technical constraints, or operational requirements, the department must coordinate with ITS Cybersecurity to determine appropriate mitigation measures.
Depending on the severity of the vulnerability and the level of risk to the college’s environment, ITS may require additional safeguards or take protective actions to reduce risk to institutional systems.
Further Reading