Sunset and ASU buildings

Vendor IT Risk Assessment

A VITRA must be completed before any sensitive or regulated data can be accessed, processed, or stored with a third-party. 

All third-party engagements involving sensitive or regulated data require an ASU contract or Purchase Order to be processed in the Workday Financial Management System.

Integrations with core university systems or using cloud software applications typically require a VITRA.

Scenario Examples Requiring a VITRA:

 

  • An instructor would like to add an LTI tool to the LMS
  • A researcher would like to use a cloud software tool to assist with human subject data analysis
  • A staff member is purchasing a cloud software license to process employee records or sensitive internal data

 

A VITRA is not required if the requestor is not sharing any ASU data with the third-party.

 

Scenario Examples Not Requiring a VITRA:

  • Staff member would like to purchase technology hardware such as a computer mouse
  • Faculty member would like to be reimbursed for a SaaS subscription to a research database
  • Researcher would like to use an Enterprise Technology offered solution such as MyAIBuilder

 

The requestor can leverage the ET Data Classification Tool

The VITRA is not an approval process to purchase or use a technology. 

Please work with your department IT leadership to assist with any approval questions.

Third-Parties that are processing or accessing ASU sensitive or regulated data are required to be reassessed on a regular schedule. If the supplier has already completed an initial VITRA, a new VITRA must be initiated (not completed) before renewing a license or contract.

We will request the following documentation from all of our suppliers processing ASU sensitive or regulated data

  • Latest SOC 2 Type 2 Report or similar audit (e.g. ISO27001, StateRAMP, FedRAMP)
  • HECVAT

     

  • PCI DSS certification or attestation (if PCI data is in scope)
  • ioXt Alliance certification (if IoT devices are in scope)

     

  • Third-Party Penetration testing report or an executive summary listing findings
  • Data flow diagram (as required)
  • Architecture diagram (as required)

The requestor must first work with industryagreements@asu.edu

Some suppliers will require a NDA before they will release sensitive security documentation and in these cases
ASU’s Research Administration can assist you. 

Once the NDA is processed, please email or slack our team so that we may continue processing this request.

The VITRA will be completed with a high risk score and be documented in the university risk register. Your business unit risk manager will be required to take action on this risk to document the response, deciding whether or not to continue with the relationship or not.

ServiceNow has a short video on how your supplier will use the "Vendor Portal": ServiceNow's Vendor Portal: one of the pillars of VRM success. What it does, how to use it in 5 min.

The following document below can be shared with the supplier that includes screenshots on how to access the vendor portal.

Accountable Administrator is defined as dean or department head of the highest level of the business unit.

Directory of DT Leads, Accountable Administrators, Business Administrators and IT technical representatives by department

For additional information, see our ASU Enterprise Technology Community of Practice page.

You can request an SSO integration via CAS, Shibboleth/SAML, or Active Directory Federation Services (ADFS) with the ServiceNow request: Shibboleth connections for connection and authentication to externally hosted applications/sites.

It is the responsibility of the site/application owner to implement the integration on their end. Before purchasing software, contact  the vendor to ensure that it supports SSO capabilities via CAS or SAML. If it does not support this capability, then it is recommended to find an alternative solution that does.

CAS SSO

For CAS SSO, all HTTPS (SSL) asu.edu URLs are automatically permitted, so no registration is needed. For non-asu.edu URLs, you will need to submit a ServiceNow form with the details and the SSO team will add it to the CAS registry.

SAML (via the InCommon Federation)

For Shibboleth, if the remote site is part of the InCommon Federation (wiki), no action is required on ASU’s end since we are a participating member. The vendor will only need to add asu.edu as an allowed domain on their end.

SAML (Shibboleth of ADFS)

If the remote site is not part of the InCommon Federation, you will need to submit a ServiceNow form with contact details for exchanging signed metadata for the SAML integration. That is, you provide your service provider (SP) signed metadata, and the SSO team will give you ASU’s identity provider (IdP) signed metadata. Each of you will then add the respective metadata to your configurations.

For SAML, using Shibboleth provides identity data from the ASU Directory Service (DS LDAP) environment via CAS SSO. Using ADFS provides identity data from the ASU Windows Active Directory environment. Since it uses its own login, it is not a “true” single sign-on.

Please visit Digital Trust Guidelines for Generative Artificial Intelligence Use for complete guidance on the usage of AI at ASU.

Generally, material produced by Generative AI is not protected by copyright.  Each Generative AI system has its own terms of use, including data privacy and intellectual property policies that may impact these rights.  Keep in mind that these systems learn from every interaction you have with them.  Do not share information that you don't have permission to share, or that you don’t mind giving away publicly.  If you have questions on a specific system, check out our Vendor IT Risk Assessment process.