The UD Technology Request Process

Overview

The Technology Request process helps University departments, units, and individuals procure the technology solutions that support their business needs in alignment with the University’s larger IT infrastructure, risk, and compliance obligations. This pathway offers communication checkpoints, along with consultation, technology expertise, and support from UDIT.

UDIT’s evaluation process considers the value and risks associated with each request. The UDIT team will look to answer several key questions about each solution:

• Does the solution advance the University’s or requesting unit’s mission(s) through enhanced core, consortial or specialized functionality?
• What is the service value of the solution?
• Does the solution duplicate or replace an existing service?
• Does the solution raise any security, privacy, or compliance concerns?
  Examples:
  • What data does the solution collect?
  • How much access does the solution need?
  • Do the terms of use meet UD standards?

How to use the Technology Request form

Submit the Technology Request form whenever you plan to:

• purchase a new technology solution or hardware
• renew an existing technology solution
• change a technology contract
• want to use an add-on / plug-in / extension for an existing technology solution
• are looking to assess / consult on potential technology solutions or business processes (pursuing a RFP / RFI, engaging in discovery, or ready to launch a project with technology components)

In addition, please select the Solution Type radio button for Add-On / Plug-In / Extension to request an add-on for an existing technology solution; Zoom, Canvas, O365, Google, however, these requests are reviewed on a monthly basis and are not always recommended.

Answer the high level questions in the request form and submit the request. A dedicated IT team reviews submissions received and works with the Requestor to (a) fully frame the business need; (b) identify stakeholders, policies, and procedures relevant to the request; and (c) establish expectations for next steps and time frames.

The new process also provides more visibility to the requestor as to what stage a request is in (Initial Triage, Under Review, Request Finalization), the active steps, and who is assigned to each step. The requestor can add comments to the request Feed at any time to inquire about their request, or add attachments.

You may also need to have the vendor complete the Higher Education Community Vendor Assessment Toolkit (HECVAT) and Voluntary Product Accessibility Template (VPAT) [WCAG Edition, latest version] for certain requests. You can also attach these completed documents to your request after it is submitted.

When to provide security documentation?

For a New solution you should have the vendor complete the Higher Education Community Vendor Assessment Toolkit (HECVAT). Below are the general guidelines that should be followed for the IT Information Security review for solutions that are not being hosted at UD. These guidelines should also be followed for Renewals and Add-Ons / Plug-Ins / Extensions if a security review was not previously conducted or the scope of the services or agreement has changed.

Refer to the following guidelines, based on the Classification of data involved in the solution:

• Level 1 data – HECVAT requested
  • Depending on use case and risk, the HECVAT could be required.
  • Documentation required every 3 years for renewals.
• Level 2 data – HECVAT required
  • IT may accept alternative independent assessment/certification if a HECVAT is unable to be completed (see alternatives below).
  • Documentation required every 3 years for renewals.
• Level 3 data – HECVAT required, plus at least one alternative independent assessment/certification (see alternatives below)
  • Documentation required annually for renewals.

Alternative Independent Assessment / Certification Options:

• SOC2
• PCI DSS
• HITRUST
• NIST 800-53
• NIST Cybersecurity Framework
• ISO 27001/27002
• BitSight (or comparable) cybersecurity rating report
• Other independent assessment/certification based on a common security framework

Note: Additional documentation may be required depending on the request complexity and data, for example; contract documents, scope of work, master services contract, FERPA, GDPR, BAA, etc.

When to complete a VPAT?

If the product has a user interface (UI) that more than 10 people will interact with, you must have the vendor complete a Voluntary Product Accessibility Template (VPAT) [WCAG Edition, latest version] then submit the completed VPAT using the Accessibility Review Request (VPAT) form for Procurement to conduct an accessibility review.

Process Workflow & Timing

NOTE: Please note that durations will fluctuate depending on the scope of a request, whether additional information or documents are required, the requestor’s response time, vendor’s response time, and review requirements of all parties involved in the review. In some cases, requests may have a potential enterprise impact or efficiency that will go to the IT Governance Steering Committee for review.

When to Submit a Technology Request

Project Levels

“A Project is a temporary endeavor (has a definitive start and end date), undertaken to create a unique product, service or result within defined constraints. A project concludes when its specific tangible and/or intangible objectives have been attained and the project resources have been released to do other work.” Refer to Project Tailoring Process for more information – 180801-P-012

Strategic Project (Level 2 or 3)

Any project request that meets any of the criteria below will be considered a Strategic Project.

• Request will impact more than one department or unit outside of the requester
• Request requires university funds to be expended, excluding staff salaries
• Request has a large university impact
• Request implements new technologies and processes that promote transformative change
• Request meets one or more of the following business drivers: Strategic, Innovation

Risk Avoidance Project (Level 3, 2, or 1)

• Request, if not fulfilled, will have adverse security or risk impacts
• Request has one or more of the Strategic Project criteria’s

Operational Project (Level 2 or 1)

Any project request that meets all of the criteria below will be considered an Operational Project.

• Request is in support of one department
• Request does not require university funds to be expended, excluding staff salaries
• Request does not have a large university impact
• Request will optimize performance and accommodate incremental growth and improvement

Enhancement Request

Any project request that doesn’t meet the criteria’s of a Strategic or Operational and is specific to an existing application/system.