Vendor Relationship Information

Initial Vendor Relationship Requirements

Information Security Office (ISO) Contract Language

All systems containing 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. To diminish information security threats ASU has developed the ISO contract in order to set expectations between ASU and outside vendors. To review the ISO contract language, click here.

Data Definitions:


Sensitive refers to information intended for limited use within the University by faculty, researchers, staff, students or University affiliates, including information that is regulated or must be protected due to proprietary or privacy concerns; e.g. private student records according to FERPA, protected health information (PHI) according to HIPAA, personally identifiable information (PII), according to state and federal laws and industry regulations or control systems related to critical infrastructure.

Unauthorized disclosure, compromise, or destruction would directly or indirectly have an adverse impact on the University, its students or employees. Violation of statutes, regulations, or other legal obligations, actual or potential financial loss, damage to the University’s reputation and possible legal action could occur.

Highly Sensitive

Highly Sensitive refers to information involving human health, life, and safety matters or hazardous materials situations. This information is intended for extremely limited use within the University on a need to know basis. Statutes, regulations, other legal obligations or mandates protect much of this information. Unauthorized disclosure, compromise or destruction would result in severe damage to the University, its students or employees or other individuals providing the information. Physical harm or endangerment, violation of legal obligations, actual or potential financial loss, damage to the University’s reputation and possible legal action could occur.

Security Review Process

The ASU security review process provides guidance to implement technology solutions efficiently while minimizing security risks. As an ASU technology vendor, you will be asked to provide information and to participate in the security review process. Items that will be reviewed:

  • Evidence of security maturity

    • It is HIGHLY recommended to provide as many of the following applicable security documents for your product(s) to help streamline the security review process

      • Third-party attestation of security controls

        • SOC 2 Type 2, ISO 27001, CMMC, and FedRAMP are examples of acceptable documentation.
      • Scanning and Pen Testing

        • Third-party scanning and penetration tests for unauthorized applications, services, code, and system vulnerabilities on the networks and systems.
        • Scanning and pen testing are expected to be conducted annually in accordance with industry standards and ASU standards (as documented in NIST 800-115) or equivalent.
        • Evidence of vulnerabilities remediation within a reasonable period.
      • PCI DSS

        • Used if vendors are handling financial transactions involving credit cards.
        • Attestation can be proven by providing ASU with a PCI DSS certification.
      • HIPAA/PHI

        • HITRUST certification shows that a healthcare vendor has met the basics of healthcare measures regarding data management, processing, and handling.
  • System architecture design

    • Whether the product will integrate with any enterprise or “tenant-level” applications or services
    • Architectural Diagram 

      • Only for integrations to ASU technological infrastructure
      • Consists of the infrastructure used by the operations of the product

        • IP addresses, port numbers, fully qualified domain names (FQDNs), and firewall rules or a combination of the aforementioned.
    • Data Flow Diagram

      • Only for integrations to ASU technological infrastructure and SSO
  • Encryption of data at rest and in transit

    • Ensure all systems use an industry-standard encryption protocol (a minimum of TLS 1.2 and AES-256 encryption) for sensitive data, personal data, or personally identifiable data—as those terms may be defined in applicable laws, rules, and regulations (PII)—in transit and at rest (as documented in NIST 800-57, or equivalent)
    • Secure communications

      • HTTPS and certificates

        • Certificates correctly configured and installed

          • Periodically updated
          • Can be quickly updated if a compromise is suspected
      • Application-unique credentials

        • Stored in a manner that requires authorization to access
  • Database server protections
  • Key Management System policies and procedures
  • Identity and Access Management processes and procedures
  • Audit logging procedures
  • Data retention and lifecycle management including deletion and retention
  • Secure Development Lifecycle policies and procedures

    • Software Integrity

      • Operating systems, utilities, applications, and any other executable code is only obtained from trusted sources.
      • Distributed using mechanisms that automatically ensure it is not altered

        • Files are cryptographically signed or delivered over a channel that ensures end-to-end file integrity.
      • Current versions of software are initially installed
      • Patching and upgrades are performed regularly and as needed

        • Automatically verified so administrators and users cannot be tricked into installing a malicious update.
  • Whether the product will incorporate any offshoring

    • Are any of the following conducted outside the borders of the United States:

      • Data storage, access, and processing.
      • Development and modification of software.
  • Legal contracts

Please work with your ASU contact for additional information which requires log-in access.

Ongoing Vendor Relationship Requirements

Scanning and Pen Testing

Scanning and Penetration tests must be performed to identify and remediate risks. Periodic scans, including penetration tests, for unauthorized applications, services, code, and system vulnerabilities on the networks and systems. Scanning and pen testing is expected to be conducted in accordance with industry standards and ASU standards (as documented in NIST 800-115 ) or equivalent. Additionally all web based applications (e.g. HTTP/HTTPS accessible URLs, APIs, and web services) are required to have their own web application security scan and remediation plan. Vendors must correct weaknesses within a reasonable period, and vendors must provide proof of testing to ASU upon ASU’s request. 

SOC2 Report 

SOC 2 was developed by American Institute of Certified Public Accountants (AICPA). The SOC 2 was created in part because of the rise of Cloud computing and the outsourcing of functions to service organizations. It addresses the demand for assurance of confidentiality and privacy of information processed by the system due to liability concerns. ASU requires a SOC2 Type 2 or substantially equivalent review in accordance with industry standards.  Reviews are subject to annual review by ASU upon ASU’s request.


Notify ASU immediately if Entity receives any kind of subpoena for or involving ASU Data, if any third party requests ASU Data, or if Entity has a change in the location or transmission of ASU Data. All notifications to ASU required in this Information Security paragraph will be sent to ASU Information Security at, in addition to any other notice addresses in this Agreement.

Contact information

Please contact Information Security at for additional information.