Third-Party Information Security Standard

1 PURPOSE

This standard outlines requirements for securing third-party services and products to manage, transmit, or store sensitive or restricted information to support the Â̾ÞÈËÊÓƵ (Â̾ÞÈËÊÓƵ) administrative, academic, and business unit needs. Using a vendor service does not absolve Â̾ÞÈËÊÓƵ from its responsibility to ensure that information is properly and securely handled, stored, and managed.Ìý

2 SCOPE

This standard applies to all Â̾ÞÈËÊÓƵ business and academic units and Â̾ÞÈËÊÓƵ-owned information systems that collect, store, process, share, or transmit institutional data. Personally owned devices connecting to the University Campus Network must meet the Bring Your Own Device standard requirements.Ìý

3 STANDARD

The vendor engagement lifecycle shall be effectively managed to manage cybersecurity and other risks specific to information technology services in conducting Â̾ÞÈËÊÓƵ or component institution business. This lifecycle includes the following stages:Ìý

  • Stage 1: Definition and DiscoveryÌý

  • Stage 2: Solution SelectionÌý

  • Stage 3: VettingÌý

  • Stage 4: EngagementÌý

  • Stage 5: Administration, Support, and ManagementÌý

Using unapproved vendor services to conduct Â̾ÞÈËÊÓƵ or component institution business or to capture, store, process, transmit, or otherwise manage institutional information is prohibited, including using vendor services like Google Docs, Dropbox, or similar for storing institutional information, data, files, or documentation.Ìý

Failure to follow this lifecycle and to engage with the appropriate Â̾ÞÈËÊÓƵ and institutional units at each stage can result in delays in contract signing, completion of vetting processes, and overall implementation of the requested functionality.Ìý

3.1 DEFINITION AND DISCOVERY

Administrative, academic, and business units interested in pursuing an information technology service or product shall engage Enterprise Technology & Services (ET&S) to assist with defining the unit's business needs and high-level requirements. ET&S shall determine if an existing solution provides this functionality and can meet the specified requirements.

3.2 SOLUTION SELECTION

3.2.1 Business unit needs that can be met with existing solutions shall be implemented as outlined in the System Acquisition, Development, and Maintenance Lifecycle Standard.Ìý

3.2.2 Administrative, academic, and business units with defined needs that cannot be met with existing solutions shall engage with Â̾ÞÈËÊÓƵ Procurement to identify potential vendor offerings via standard and ±è°ù´Ç³¦±ð²õ²õ±ð²õ.Ìý

3.3 VETTING

3.3.1 To effectively manage cybersecurity risk, Cybersecurity Governance Risk and Compliance (GRC) shall vet all services and products that store, process, and transmit Â̾ÞÈËÊÓƵ information. Based on the intended use of and institutional information involved, Cybersecurity GRC shall determine if the requested use of that vendor shall be permitted or if additional vetting and formal approval are required.Ìý

3.3.2 The formal approval process for vendor information technology services includes the following:Ìý

3.3.2.1 Completion of the process and SAR Approval from Cybersecurity GRCÌý

3.3.2.2 Contract/licensing agreement vetting by Â̾ÞÈËÊÓƵ Procurement and, where appropriate, assistance with licensing agreement or contract term negotiationsÌý

3.3.2.3 Â̾ÞÈËÊÓƵ/Institutional Data Steward approval for access to and use of the institutional information needed by the vendor serviceÌý

3.3.2.4 Designation of a Business Application Owner or Technology Service Owner for the vendor serviceÌý

3.4 ENGAGEMENT

3.4.1 Administrative, academic, and business units shall not sign any service contract, licensing agreement, or master services agreement or agree to any terms of service without engaging ET&S and Â̾ÞÈËÊÓƵ Procurement Services. Users engaging in renewal agreements should also work with Procurement Services to ensure legacy engagements are properly vetted.Ìý

3.4.2 Wherever possible, products and services shall leverage the central authentication services provided by ET&S Â̾ÞÈËÊÓƵ community members. If the service cannot implement single-sign-on (SSO), community members shall use their Â̾ÞÈËÊÓƵ username to access vendor services, and passwords shall abide by the Â̾ÞÈËÊÓƵ Password Policy.Ìý

3.5 ADMINISTRATION, SUPPORT, AND MAINTENANCE

3.5.1 Administrative, academic, and business units that procure information technology products and services shall:

Ìý Ìý 3.5.1.1 Be responsible for securely administering the service and providing support, maintenance, and vendor relationship management for that service directly or through negotiated support agreements ET&S.Ìý

Ìý Ìý3.5.1.2 Designate an individual as the business application/Technology Service Owner for vendor service/product and provide this information to ET&S.Ìý

Ìý Ìý3.5.1.3 Engage with Cybersecurity GRC to assist in determining security requirements for service administration.Ìý

Ìý Ìý3.5.2 The Business Application Owner or Technology Service Owner designated for an information technology product or service shall ensure any institutional information captured, stored, processed, transmitted, or otherwise managed by that service is backed up.Ìý

3.5.3 Information technology services used for Â̾ÞÈËÊÓƵ, or component institution business shall provide the ability to:Ìý

Ìý Ìý3.5.3.1 Make institutional information available to Â̾ÞÈËÊÓƵ or its component intuition upon request.Ìý

Ìý Ìý3.5.3.2 Permanently remove institutional information as dictated in the Information Technology Resource Secure Disposal Standard at the request of Â̾ÞÈËÊÓƵ or its component institution.Ìý

3.6 Management of Institutional Information Used by Services

Community members leveraging third-party vendors shall leverage the Â̾ÞÈËÊÓƵ Information Classification Policy to help inform decisions on the appropriateness of services for different administrative, academic, or business situations.

3.6.1 Tier 1 - PUBLIC

3.6.1.1 New vendor services or products that capture, store, process, transmit, or otherwise manage PUBLICÌý

3.6.1.2 Cybersecurity GRC shall authorize information.ÌýUse of existing approved vendor services for PUBLIC institutional information is allowed and does not require Cybersecurity GRC approval.Ìý

3.6.1.3 Each new use of a previously approved vendor service requires Data Steward approval via the Data Access Request process outlined belowÌý

3.6.1.4 Administrative, academic, or business units shall:Ìý

3.6.1.4.1 Ensure that vendor services or product use do not violate any existing Â̾ÞÈËÊÓƵ or component institution licensing agreements.Ìý

3.6.1.4.2 Ensure that only approved PUBLIC information is captured, stored, processed, transmitted, or managed in this service.Ìý

3.6.2 Tier 2 – SENSITIVE and Tier 3 – PROTECTED

3.6.2.1 Use of new information technology services or products to capture, store, process, transmit, or otherwise manage institutional information classified as SENSITIVE and PROTECTED requires formal approval.Ìý

3.6.2.2 Previously approved information technology services that are allowed but require confirmation from Cybersecurity GRC that:3.6.2.2.1 The classification of the information involved matches the classification of information the vendor has been approved to handle.Ìý

3.6.2.2.2 The existing vendor has an active SAR approval in placeÌý

3.6.2.3 Data Steward approval for the use of the specific data elements via the Data Access Request processÌý

3.6.3 Tier 3 - RESTRICTED

3.6.3.1 Use of new vendor services to capture, store, process, transmit, or otherwise manage institutional information classified as RESTRICTED requires formal approval as outlined above

Ìý Ìý Ìý 3.6.3.1.1 Previously approved cloud services that are allowed but require confirmation from Cybersecurity GRC that:Ìý

  • The classification of the information involved matches the classification of information the vendor has been approved to handle.Ìý

  • The existing vendor has an active SAR approval in place.Ìý

  • Data Steward approval for the use of the specific data elements via the Data Access RequestÌý

3.6.3.2 Where applicable, approval from the appropriate institutional HIPAA Privacy Officer and the HIPAA Security Officer may be required.Ìý

3.6.3.3 Â̾ÞÈËÊÓƵ or component institution PCI Manager or Committee shall approve any service or product intended to capture, store, process, transmit, or otherwise manage RESTRICTED institutional information related to the processing of credit card payments.Ìý

3.7 VENDOR SECURITYASSESSMENTREVIEW (SAR)

3.7.1 Any product or service used to capture, store, process, transmit, or otherwise manage institutional information with a classification other than PUBLIC shall be vetted using the Security Assessment Review (SAR) process. This process requires the proposed vendor to complete an industry-standard security control assessment, may involve several rounds of review and clarification between Cybersecurity GRC and the vendor, and can take an extended period. In most cases, the time needed to complete this process is determined by the vendor and how quickly they respond to requests for information. Administrative, academic, and business units shall plan accordingly to ensure adequate time to complete the SAR process before contract signing.Ìý

3.7.2 An administrative, academic, or business unit representative engaging with the vendor shall be assigned as the primary liaison between Cybersecurity GRC and the proposed vendor. Additional information about this process is available at request from Cybersecurity GRC.Ìý

3.7.3 If an administrative, academic, or business unit chooses to move forward with a vendor product or service that does not receive Cybersecurity GRC approval after completing the SAR process, acceptance of that risk shall be required. The unit's senior leadership licensing the unapproved vendor information technology service shall be responsible for risk acceptance as outlined in the Risk Management standardÌý

3.8 DATA ACCESS AND USEREQUEST PROCESS

3.8.1 Approval to access and/or use any institutional information, regardless of classification, in a vendor service shall be granted by the appropriate Data Steward via the Data Access and Use Request process administered by Cybersecurity GRC.

DOCUMENT HISTORY

  • Approved by: Tom Nudd, Chief Information Security Officer,ÌýAugust 19, 2021, V1Ìý
  • Reviewed by:ÌýDr. David Yasenchock, Director, Cybersecurity GRCÌý
  • Revision History:ÌýReview Draft Finalized, R Boyce-Werner, March 9, 2020Ìý
    • V 1.2 Updated March 10, 2023, Cybersecurity GRC Working GroupÌý
    • V 1.3 April 23, 2024, 2024 Cybersecurity GRC Working GroupÌý
    • Revised formatting, K Sweeney, MAY 30 2024