Vendor IT Risk Assessment
Request a Vendor IT Risk Assessment
Why Does this Matter?
Supply-chain data breaches are among the most common forms of attacks that malicious actors and hackers leverage to gain access to target systems and information. Many regulatory bodies and institutions require that due diligence is completed and suppliers are continuously monitored within an organization's supply-chain to ensure that the organization remains resilient to malicious actors and maintains good faith with their customers. The failure to perform this due diligence can result in significant compliance-based fines and data breach impacts.
What is the Vendor IT Risk Assessment Service?
The Vendor IT Risk Assessment is a supply-chain data breach-focused risk assessment that evaluates the risks associated with sharing different classifications of data with third parties. This is a vital due-diligence step in the procurement process to ensure that suppliers that ASU engages in business with can adequately protect ASU data in accordance with our risk tolerance. Once an assessment is completed, a report will be provided to the product requestor and their business unit distributed technology leader with a total risk score and any additional comments the ET Cybersecurity Risk and Analysis team provide to assist business unit leadership in making a risk-based decision on the third-party relationship.
Questions?
Slack: #et-vitra
Email: [email protected]
Initial Assessment
Step 1: The VITRA onboarding process will begin once the request has been submitted. If sensitive or regulated data is in scope for the assessment, the requestor will be required to provide a valid vendor point of contact or the SOC 2 Type 2 from the supplier's trust portal.
Step 2: After the documentation has been received from the supplier, the assessment will be assigned an assessors queue. The assessor will assign a risk score to determine if further actions will be required before finalizing the vendor relationship
Step 3: The completed report provided to the requestor and their business unit Distributed Technology Leader. If the requestor is also requesting an integration with an enterprise system, they will need to provide a copy of the report to the system owner and coordinate the integration with that administrator.
Supplier Monitoring
Step 1: Check the expiration date or continuous monitoring date on the latest provided VITRA report to determine when another assessment is required.
Step 2: Repeat the process above
Supporting Tools
Additional articles and resources, in addition to those listed below, can be found by accessing the ET Cybersecurity Risk and Analysis Knowledge Base link above.
KB0025952 - Vetted Vendors List
KB0025644 - The Vendor IT Risk Assessment Process
KB0025739 - Vendor IT Risk Assessment Processing Timelines
KB0026058 - VITRA Guidelines for Third-Party AI Products
KB0025968 - Workday FMS DTSR Role Approval Requirements
KB0025756 - Cybersecurity Financial Risk Calculation Guide
Starting Your Relationship with ASU
Information Security Contract Language
All systems processing ASU data must be designed, managed, and operated in accordance with information security best practices and in compliance with all applicable laws, rules, and regulations. Third-Party relationships that include the processing of data that ASU considered confidential, sensitive, and regulated require our third-parties to accept ASU information security and privacy terms attached to a purchase order or negotiated contract.
ASU Third-Party InfoSec Assessment and Onboarding
Before ASU data can be shared with a third-party, a Vendor IT Risk Assessment (VITRA) must be initiated by the sponsoring business unit. Relationships with confidential, sensitive, and regulated data in scope will trigger the creation of a questionnaire and request for evidence. Once the third-party submits the completed questionnaire, a risk assessment will be completed. The associated risk score will be provided to the sponsoring business unit technology leader to make a risk based decision on the future relationship with the third-party.
Third-Party Requested Documentation
- SOC 2 Type 2 or similar third-party audit document or information security certification (FEDRAMP, StateRAMP, HITRUST, ISO27001, CMMC, etc.)
- If the SOC audit is more than 1 year old, include the bridge letter
- System Architecture Diagram
- Latest third-party conducted penetration test findings executive summary generated by the testing organization
- (If Applicable) Include industry supporting compliance documentation
- Completed Security Questionnaire (HECVAT, SIG, CAIQ, etc.)
System Architecture Diagram
- Fully qualified domain names, IP addresses, ports, protocols, and encryption, cloud servers, and authentication methods used by your internet-facing servers that will communicate with ASU endpoints or users.
- Documentation on integration implementation, when applicable, including the level of permissions and authentication required.
How to Interact with the Vendor Portal
The ASU VITRA process utilizes the Vendor Risk Management solution provided by ServiceNow and includes a simple Vendor Portal which you will access to provide documentation. Please watch this 5-minute video to learn how you will use the Vendor Portal.
ASU InfoSec Third-Party Continuous Monitoring
The ASU sponsoring business unit that is managing the third-party relationship is responsible for initiating and managing the due diligence process. ASU Information Security is available to assist in facilitating this process at request by the sponsoring business unit.
Third-Parties processing any ASU data considered confidential, sensitive, or regulated will be required to provide updated due diligence documentation annually to ASU. If the supplier is unable to meet this requirement, this may be considered a breach of contract and could result in the termination of services.
Generative Artificial Intelligence
ASU generally does not allow its data to be used in the training of third or fourth party AI models. If a third-party solution includes the use of AI, they are expected to disclose which subcontractors and models they are using to support this capability.
Non-Disclosure Agreements
We understand the confidentiality of the security information that you are expected to provide. Should your company require a Non-Disclosure Agreement, please inform your ASU business sponsor so that they may work with ASU’s Industry Agreement’s office to facilitate the NDA process.
Questions
Questions regarding third-party specific negotiations and solution implementation requirements will need to be facilitated between the requesting ASU business unit and the third-party.
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)
- 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 [email protected]
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 (AA) is defined as dean or department head of the highest level of the business unit. Your business unit technology leader is your first point of contact for any risk approvals that need to be actioned by your Accountable Administrator.
For additional information, or to find out who your Department's Distributed tech lead or Accountable Administrator are please work with our GRC Smart Assistant.
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.