Vendor IT Risk Assessments
A VITRA must be completed prior to the procurement of third-party software. The risk assessment is either conducted at the “Departmental” or “Enterprise” level, depending on the scope of University data accessed and software integration requirements.
A Departmental VITRA is applicable if the technology:
- Interacts with public/non-sensitive or internal data as defined by the ASU Data Handling Standard
- Interacts with sensitive data of less than 1,000 individuals
- Software licenses are for individual end-point devices
- Is hardware or peripheral devices
- Is an IoT device that will not interact with sensitive or highly sensitive data
An Enterprise VITRA is applicable if:
- Requires an integration into a Tier 1 mission critical or Tier 2 enterprise system
- Interacts with Sensitive data of more than 1,000 individuals OR Highly Sensitive data for any number of individuals as defined by ASU's Data Handling Standard
Examples of Tier 1 or Tier 2 availability systems include, but are not limited to:
- ASU enterprise Canvas LMS (asu.instructure.com or canvas.asu.edu)
- Microsoft 365
- Office 365, Project, Visio, BI Server, etc.
- Google Workspace (formerly G Suite)
- Atlassian (Jira, Bitbucket, Confluence)
- Cloud Service Provider instances managed by ASU
- Amazon Web Services, Google Cloud Platform, Microsoft Azure, etc.
Technology purchases of the following:
- Endpoint hardware and components
- Basic computer peripherals
- Mice, keyboards, touch tablets, monitors, speakers, etc.
- Basic computer components
- CPUs, GPUs, motherboards, HDDs, SSDs, optical drives, network cards, etc.
- Basic computer peripherals
- Non-cloud connected audiovisual equipment
- Digital subscriptions where ONLY public data is provided to the vendor
- Digital print media like journals, magazines, newspapers, etc.
- Digital assets like fonts, images, music, etc.
- Streaming audiovisual on demand services (VIEWING ONLY, cases which upload audio or video may require a VITRA)
Our Data Handling Standard has explanations and examples, please see the appendix at the end of the document, for how ASU classifies certain data. Our standards break data up into 4 categories: Public, Internal, Sensitive, and Highly Sensitive.
Please check the ET Product Catalog to see if the technology is already in use at ASU. If it is not found in the Product Catalog, please submit your request via ServiceNow to see if there is a VITRA on file for the product you are purchasing. Please note - Another department’s VITRA can only be utilized if the data sensitivity, functionality, and integrations are the same.
Do I need to complete a new VITRA for renewals or purchasing additional licenses/units for products ASU has already assessed previously?
If a product or vendor service has an existing Vendor IT Risk Assessment, ISO Security Review, or a Departmental Security Review by your department or business unit, a new review is NOT needed given the following conditions:
- The low risk Department-level review is less than 3 years old, or the low risk Enterprise-level review is less than 2 years old. View this knowledge base article for more information and clarification.
- The medium/moderate or high risk review is less than 12 months old.
- Data sensitivity and integrations have not changed.
- No changes were made to data handling, vendor security patching or updating upon renewal.
Older form versions that did not include a risk rating are deprecated and cannot be reused. The following form versions are valid, given they are within limitations stated above:
- ISO Security Risk Assessment form version 2019 August and later.
- Internal Department Security Review form version 2.0a and later.
- Any ServiceNow Vendor IT Risk Management Assessment engagement with an “Active” status.
We will need any of the documents below from the vendor, if they have them:
- Any Industry standard security certifications
- AICPA SOC 2 Type 2 or SOC 3 report or executive summary
- ISO 27001
- NIST 800-53
- CIS controls
- HIPAA compliance audit (if HIPAA data is in scope)
- PCI DSS certification or attestation (if PCI data is in scope)
- ioXt Alliance certification (if IoT devices are in scope)
- Vulnerability scanning report or an executive summary listing findings
- Penetration testing report or an executive summary listing findings
- Data flow diagram (as required)
- Architecture diagram (as required)
My vendor requires a Non-Disclosure Agreement before they will share documents, how do I resolve this?
Some vendors will require a NDA before they will release sensitive security documentation and in these cases ASU’s Research Administration can assist you. You will need to complete an Internal Request Form (IRF) and send it to firstname.lastname@example.org.
Once Industry Agreements receives the request, a Contracts Officer will cooperate with you and the vendor to negotiate an agreement.
Please include our team in any communications with Industry Agreements and the vendor by including our distribution list DL.WG.UTO.ISO.SecurityArchitects@exchange.asu.edu as a copy.
Yes. Even with limited documentation or lack of a 3rd party audit we can still complete the VITRA; however, the lack of documentation in itself is a risk as we cannot verify the vendor’s security posture. It would then be to the discretion of Risk Management Services (which includes the Accountable Administrator) whether they are comfortable with the project moving forward or would require a re-assessment of the product with the missing documentation included.
Not necessarily. We do not approve or deny products; however, we identify risks to provide information for that decision to be made by an Accountable Administrator. We cannot speak for what each Accountable Administrator is willing to accept responsibility for. If at the moment, documentation is unavailable but will be available later, that is something that can be noted in the assessment for the Accountable Administrator to take into consideration, but again, that would still be their decision.
VITRA are an iterative process, so a re-assessment can be requested as new documentation is provided, risks are corrected or mitigated, or when changes are made to configurations or integrations.
Yes. Your vendor can visit our Vendor Relationship Information page for details.
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.
See the short video “ASU Purchasing Process for Technology-Related Products and Services” for an overview. In the video, the VITRA process is specified as “Technology Review”.
A complete training and certification program for the Department Technology Security Reviewer role within purchasing process is available on the Security/Purchasing/Risk Training Certification 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.
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.