Third-Party Vendor Management

PURPOSE:

This Third-Party Vendor Management Policy outlines the standards and procedures for managing the risks associated with engaging third-party vendors who provide products, services, or process institutional data on behalf of Idaho College of Osteopathic Medicine (ICOM). The purpose of this policy is to ensure that all third-party vendor relationships are established and maintained in a secure, compliant, and risk-aware manner, protecting institutional data, systems, reputation, and financial stability. Effective vendor management is essential for mitigating risks related to data breaches, security vulnerabilities, regulatory non-compliance, service disruptions, and reputational damage arising from third-party relationships. This policy applies to all third-party vendors who have access to institutional data or systems, or who provide services critical to institutional operations, including SaaS providers.
 

SCOPE:

This policy applies to all third-party vendors who:

• Provide products or services to ICOM that involve access to, processing, storage, or transmission of institutional data (including Restricted, Confidential, and Internal data as defined in the Data Classification Policy).
• Provide services that are critical to the Institution’s operations, academic mission, research, or compliance obligations, even if they do not directly access sensitive data (e.g., cloud infrastructure providers, managed service providers, critical software vendors, SaaS application vendors).
• Connect to the Institution's network or systems.

This policy applies to all types of third-party vendors, including but not limited to:

• Software as a Service (SaaS) providers
• Cloud service providers (IaaS, PaaS)
• Managed service providers (MSPs)
• Data processors and data hosting providers
• Software and hardware vendors
• Consultants and contractors
• Professional services firms
• Any external organization or individual that has access to institutional data or systems or
  provides critical services.

This policy applies to all individuals within ICOM who are involved in initiating, managing, or overseeing relationships with third-party vendors, including but not limited to:

• Department Heads and Budget Managers
• Business Department
• IT Department
• Data Owners and Data Custodians
• Legal Counsel
• Compliance Office
• Contract Managers
   

DEFINITIONS:

• Institutional Data: Refers to all data and information created, received, maintained, or transmitted by ICOM in support of its mission and operations, as further defined in the Data Classification Policy.
• Risk Assessment: A systematic process of identifying, analyzing, and evaluating potential risks associated with engaging a third-party vendor, including security, compliance, operational, and reputational risks.
• SaaS Application (Software as a Service): A software delivery model in which software is hosted by a vendor and made available to customers over a network, typically the internet, usually on a subscription basis.
• Service Level Agreement (SLA): A contractually agreed-upon set of metrics that define the expected level of service to be provided by a vendor, including performance, availability, and response times.
• Third-Party Vendor (Vendor): Any external organization or individual that provides products, services, or processes institutional data on behalf of ICOM. This includes contractors, consultants, service providers, SaaS vendors, cloud providers, and other external entities.
• Vendor Due Diligence: The process of conducting thorough investigations and assessments of a potential third-party vendor before entering into a contract, to evaluate their capabilities, security posture, compliance, financial stability, and other relevant factors.
• Vendor Risk Management (VRM): The overall process of identifying, assessing, treating, and monitoring risks associated with third-party vendors throughout the lifecycle of the relationship.
• Business Associate Agreement (BAA): A contract between a HIPAA-covered entity (like ICOM, if applicable) and a HIPAA business associate. The BAA ensures the business associate will protect the privacy and security of Protected Health Information (PHI) in accordance with HIPAA regulations.

POLICY:

Vendor Risk Assessment: A risk assessment must be conducted prior to engaging with any new third-party vendor who will have access to institutional data or systems or provide critical services. The risk assessment will evaluate:

• Security Risks: Vendor's security posture, security controls, vulnerability management practices, incident response capabilities, and history of security incidents.
• Compliance Risks: Vendor's compliance with relevant regulations (e.g., HIPAA, FERPA, GLBA, state privacy laws) and industry standards relevant to the data and services they will handle.
• Operational Risks: Vendor's financial stability, business continuity plans, service availability and reliability, and potential for service disruptions.
• Reputational Risks: Potential for negative impact on the Institution's reputation due to vendor actions, security breaches, or compliance failures.
• Data Privacy Risks: Vendor's data privacy practices, data handling procedures, data residency, and compliance with privacy policies and regulations.
• Specific Risks Related to SaaS Vendors: Cloud-specific security risks, data location, multi- tenancy considerations, vendor access to data, and vendor security certifications.

The risk assessment will be documented and approved by the Information Technology Department. The level of risk assessment rigor should be commensurate with the sensitivity of data and criticality of services involved.
 

Vendor Due Diligence: Based on the risk assessment, appropriate due diligence must be performed on potential vendors before entering a contract. Due diligence activities may include:

• Security Questionnaires and Assessments: Requiring vendors to complete security questionnaires and providing documentation of their security controls. For cloud service providers and SaaS vendors, utilizing the Higher Education Cloud Vendor Assessment Tool (HECVAT) is highly recommended as a standardized and comprehensive questionnaire specifically designed for evaluating the security posture of cloud services in the higher education context. HECVAT helps assess critical security areas such as data protection, access controls, incident response, and compliance. In addition to or in lieu of HECVAT (depending on risk level and vendor type), the institution may also use custom security questionnaires or industry-standard questionnaires (e.g., based on NIST Cybersecurity Framework, ISO 27001 controls). Conducting on-site or virtual security assessments or audits of vendor facilities and systems (where feasible and appropriate for high-risk vendors).
• Review of Security and Compliance Certifications: Reviewing vendor security certifications and attestations (e.g., SOC 2, ISO 27001, HITRUST, FedRAMP, PCI DSS) to verify their security posture and compliance with industry standards.
• Financial and Business Stability Checks: Conducting financial and business stability checks to assess the vendor’s long-term viability and ability to provide consistent services.
• Reference Checks: Contacting vendor references to assess their reputation, service quality, and security performance.
• Legal and Compliance Reviews: Reviewing vendor contracts and service agreements with legal counsel to ensure they meet institutional requirements and regulatory obligations.
• SaaS Vendor Specific Due Diligence: In addition to general due diligence, for SaaS vendors, focus on:
  • Verifying data encryption practices (in transit and at rest).
  • Reviewing vendor security policies and incident response plans.
  • Understanding data residency and data location.
  • Assessing vendor access controls and authentication mechanisms.
  • Verifying vendor patch management and vulnerability management processes.

Contractual Security and Compliance Requirements: All contracts with third-party vendors who access institutional data or systems, or provide critical services, should include legally binding clauses whenever possible that address:

• Data Security Requirements: Specifying required security controls, security standards, and security practices that the vendor must implement to protect institutional data (e.g., encryption requirements, access controls, security monitoring).
• Data Privacy and Confidentiality: Defining data privacy obligations, data handling procedures, and restrictions on data use and disclosure, in compliance with applicable privacy regulations (e.g., HIPAA, FERPA, GDPR, state privacy laws).
• Compliance Requirements: Stipulating vendor compliance with relevant regulations and industry standards (e.g., HIPAA Business Associate Agreements, FERPA compliance clauses, PCI DSS compliance).
• Incident Response and Breach Notification: Defining vendor responsibilities for security incident detection, reporting, and response, including breach notification timelines and procedures.
• Audit Rights: Reserving the institution's right to audit vendor security controls and compliance practices, either directly or through third-party audits.
• Service Level Agreements (SLAs): Defining service availability, performance metrics, and penalties for service failures or breaches of contract.
• Data Ownership and Data Return/Destruction: Clearly defining data ownership and vendor responsibilities for returning or securely destroying institutional data upon contract termination or service completion.
• Indemnification and Liability: Including clauses addressing vendor indemnification and liability for security breaches, data loss, or non-compliance.
• SaaS Vendor Specific Contract Requirements: In SaaS contracts, specifically address:
  • Data location and data residency requirements.
  • Vendor responsibility for data backup and disaster recovery.
  • Access to vendor security logs and audit trails (if feasible).
  • Vendor obligations regarding data portability and data migration upon contract termination.

Ongoing Vendor Monitoring and Management: Vendor management is an ongoing process, not a one-time event. The institution will implement procedures for ongoing monitoring and management of third-party vendor relationships, including:

• Periodic Vendor Security Reviews: Conducting periodic reviews of vendor security posture and compliance status, recommended annually for high-risk vendors, or triggered by significant changes in vendor services or risk landscape. This may involve updated security questionnaires, review of updated certifications, or focused security assessments.
• Performance Monitoring and SLA Compliance: Monitoring vendor service performance against SLAs and addressing any service quality issues or disruptions.
• Security Incident Monitoring and Vendor Communication: Establishing processes for monitoring for security incidents involving vendors and maintaining communication channels with vendors for incident reporting and response coordination.
• Contract Renewals and Vendor Re-evaluation: Before contract renewals, re-evaluating the vendor relationship, reassessing risks, and confirming ongoing compliance and service quality. Consider competitive bidding and vendor market reviews at contract renewal time.
• SaaS Vendor Monitoring: For SaaS vendors, ongoing monitoring should include:
  • Staying informed about vendor security updates and vulnerability disclosures.
  • Reviewing vendor-provided security reports and dashboards (if available).
  • Tracking vendor performance and availability against SLAs.
  • Monitoring user activity and security events within SaaS applications (using SaaS logging and monitoring tools).

Vendor Access Control and Least Privilege: Access granted to third-party vendors to institutional systems and data must be strictly controlled and limited to the principle of least privilege and need-to-know.

• Principle of Least Privilege: Grant vendors only the minimum level of access necessary to perform their contracted services.
• Role-Based Access Control: Implement role-based access control for vendor accounts, assigning specific roles and permissions based on vendor responsibilities.
• Multi-Factor Authentication (MFA) for Vendor Access: Require MFA for all vendor accounts accessing institutional systems or data remotely. 
• Regular Review of Vendor Access: Periodically review and re-validate vendor access permissions to ensure they remain appropriate and are still required. Revoke access promptly when no longer needed.
• Managed Vendor Accounts: Use managed and auditable vendor accounts, rather than shared or generic accounts.
• SaaS Vendor Access Management: Apply the same principles of least privilege and access control to vendor access within SaaS applications. Manage vendor accounts and roles within SaaS applications.

Vendor Termination and Off-boarding: Establish procedures for vendor termination and off-boarding to ensure secure data handling and service continuity.

• Data Return or Secure Destruction: Ensure that all institutional data held by the vendor is returned securely or securely destroyed upon contract termination, in accordance with contractual requirements and data retention policies. Obtain confirmation of data destruction from the vendor.
• Account Deactivation and Access Revocation: Promptly deactivate vendor accounts and revoke all vendor access to institutional systems and data upon contract termination.
• Knowledge Transfer and Service Transition: Plan for knowledge transfer and service transition if replacing a vendor providing critical services.
• SaaS Vendor Off-boarding: For SaaS vendors, off-boarding procedures must include:
  • Data export and migration planning (if migrating data to a new system).
  • Secure data deletion from the SaaS vendor's environment, with vendor confirmation of data deletion.
  • Subscription cancellation and account termination.
  • Verification of data deletion and contract termination terms.

Incident Response for Vendor-Related Incidents: The Institution’s Incident Response Plan must include specific procedures for addressing security incidents involving third-party vendors.

• Vendor Incident Reporting Requirements: Ensure vendor contracts clearly outline vendor responsibilities for reporting security incidents to the institution in a timely manner.
• Joint Incident Response Procedures: Establish joint incident response procedures with key vendors, outlining communication protocols, roles and responsibilities during an incident, and data sharing protocols for incident investigation and remediation.
• Vendor Participation in Incident Exercises: Where feasible, include vendors in incident response exercises and tabletop drills to test incident response coordination and communication.

Policy Exceptions: Exceptions to this Third-Party Vendor Management Policy may be granted in limited circumstances by the Chief Information Officer, with appropriate justification, risk assessment, and documented approval. Exceptions should be rare and subject to periodic review.
 

ENFORCEMENT:

Enforcement of this Third-Party Vendor Management Policy is the responsibility of all managers, supervisors, department heads, procurement staff, IT staff, security staff, contract managers, and individuals involved in vendor relationships, under the overall direction of the Chief Information Officer. Failure to adhere to vendor management procedures, engaging with unapproved or high-risk vendors without proper due diligence, or other policy violations may result in disciplinary actions, up to and including warnings, limitations on procurement authority, and termination of employment or access privileges, and potential financial or legal consequences for the Institution and individuals. The Information Technology Department will monitor compliance with this policy, track vendor risk assessments, and investigate reported violations or vendor management deficiencies.
 

POLICY REVIEW AND UPDATES:

This Third-Party Vendor Management Policy and associated procedures will be reviewed and updated at least annually, or as needed to reflect changes in technology, security threats, regulations, industry best practices in vendor risk management, institutional risk assessments, business needs, or the evolving vendor landscape (including SaaS vendor market). The Information Technology Department is responsible for coordinating policy reviews and updates, in consultation with relevant stakeholders (e.g., Legal Counsel, Compliance Office, department heads).
 

PRIMARY POLICY OWNER:

Chief Information Officer

APPROVAL:

Effective: 7/8/25

Last Reviewed: 7/8/25

Review Requirement: Annual

CROSS REFERENCE AND SUPPORTING DOCUMENTS:

Information and links to other policies or supporting documents referenced within this policy.