Third Party Security, Vendor Risk Management and Systems/Services Acquisition

2026.06

Bioscope AI makes every effort to assure all third party organizations are compliant and do not compromise the integrity, security, and privacy of Bioscope AI or Bioscope AI Customer data. Third Parties include Vendors, Customers, Partners, Subcontractors, Subprocessors, and Contracted Developers.

Policy Statements

Bioscope AI policy requires that:

(a) A list of approved vendors/partners must be maintained and reviewed annually. Re-review must additionally be triggered by defined material events (see Monitoring Vendor Risks).

(b) Approval from management, procurement and security must be in place prior to onboarding any new vendor or contractor. Required approvers and evidence depend on the vendor’s assigned tier (see Vendor Tiering). Additionally, all changes to existing contract agreements must be reviewed and approved prior to implementation.

(c) A standard HIPAA Business Associate Agreement (BAA) is defined and includes the required security controls in accordance with the organization’s security policies. Additionally, responsibility is assigned in these agreements. A BAA must be signed with any vendor that may have a business need to access, and/or unsupervised access to PHI or ePHI. BAA termination, cure, and material-breach reporting obligations follow §164.504(e)(1)(ii) and §164.314(a)(2)(i)(C).

(d) For any technology solution that needs to be integrated with Bioscope AI production environment or operations, a Vendor Technology Review must be performed by the security team to understand and approve the risk. Periodic compliance assessment and SLA review may be required.

(e) Bioscope AI Customers or Partners should not be allowed access outside of their own environment, meaning they cannot access, modify, or delete any data belonging to other 3rd parties.

(f) All workforce members procuring third-party software, services, contractors, or AI tools for business purposes must follow the Third-Party Use & Procurement Process, maintained internally and signed in Rippling at hire. Procurement outside this process is prohibited and subject to disciplinary action consistent with the HR and Personnel Security policy.

(g) Sub-processors of Bioscope AI’s vendors (so-called “4th parties”) that handle Bioscope or Customer data must be disclosed by the vendor and tracked where they touch PHI. See Sub-Subprocessor Governance.

(h) Tier 3 and Tier 4 vendors must be monitored for publicly disclosed security incidents, ownership changes, and material service changes via the supplier threat-intelligence program (see Supplier Threat Intelligence).

(i) All evidence supporting vendor onboarding, tiering, contractual execution, re-review, and offboarding must be retained for a minimum of seven (7) years consistent with §164.316(b)(2)(i) and Bioscope AI’s Policy Management policy.

Controls and Procedures

Vendor Technology Risk Review

Bioscope AI security policy requires a risk review of vendor technology, prior to any technology being integrated to Bioscope AI operations and/or infrastructure. Employees are required to engage the security team to conduct such review. The request may be submitted by email directly to the security team, or by opening a Linear ticket in the Third Party Management project.

The security team is responsible to conduct the reviews via interviews and reviews of documentation, to ensure the vendor complies with regulatory requirements such as HIPAA and follows security best practices to minimize risk to an acceptable level.

A vendor technology risk (VTR) assessment is conducted using Google VSAQ or an equivalent questionnaire appropriate to the vendor tier, in the following steps:

1. Once a new vendor or contractor is requested, the Security team opens a Linear Ticket
   1. The Linear ticket tracks the Vendor Security Review Q&A, and ranks the vendor
2. The Security Team collaborates with the requestor and the new third party to complete the questionnaire

A list of approved vendors / contractors is maintained by the Security and Operations teams in the centralized vendor risk register.

Vendor Tiering and Evidence Requirements

Each vendor is assigned a tier based on the Risk × Criticality scoring below. Required evidence and approvers scale with tier. Tier assignment is recorded in the vendor risk register at onboarding and re-evaluated at each annual or event-triggered re-review.

Risk and Criticality Scoring

Risk

1. Vendor hosts no sensitive data and has no critical findings in a vendor review.
2. Vendor hosts 1 of the three sensitive data tags (PHI, PII, PCI), or has no sensitive data but does have a critical finding in a vendor review.
3. Vendor hosts 2 of the three sensitive data tags (PHI, PII, PCI), or hosts 1 sensitive data tag and has a critical finding.
4. Vendor hosts 3 of the three sensitive data tags (PHI, PII, PCI), or hosts 2 sensitive data tags and has a critical finding.

Criticality

1. Bioscope AI considers this to be a ‘quality of life’ vendor. If we had to stop using this vendor no noticeable impact would occur.
2. Bioscope AI uses this vendor in its daily operations, but could find a replacement quickly and without disruptions to customers or SLAs.
3. Bioscope AI would be challenged to perform basic functionality without this vendor. Any changes in operations with this vendor will require strict review by the Security Team.
4. Bioscope AI cannot operate without this vendor. If this vendor went out of business tomorrow we would follow suit soon after.

Tier Assignment

Required Evidence by Tier

Approval Matrix

A Tier-1 fast-track is available for genuinely low-risk tools that meet all of the following: no PHI, no PII, no PCI, no integration with Bioscope production systems, and annual cost under USD 500. The fast-track does not waive the requirement to be added to the vendor risk register and approved software list.

Vendor Contractual Agreements

HIPAA. If the vendor needs access to PHI/ePHI, the vendor must be HIPAA compliant and a Business Associate Agreement (BAA) is required. The BAA must include explicit language covering:

• Reporting to Bioscope of any pattern of activity or practice constituting a material breach;
• Obligation to report to the Secretary of HHS if termination is not feasible;
• Return or destruction of PHI at termination.

SLA for Service Providers. For network and infrastructure service providers that support production and/or critical operations at Bioscope AI, a Service Level Agreement (SLA) is defined and included in the service contract.

Vendor-personnel NDAs. Vendor staff who will access Bioscope confidential data must be covered by either (a) the vendor’s own NDA program, with written attestation to Bioscope that all such personnel are bound; or (b) individual NDAs executed with Bioscope.

As appropriate, the executed agreement(s) are linked or attached to the vendor record in the vendor risk register.

Sub-Subprocessor (4th Party) Governance

Bioscope’s vendors frequently engage their own subprocessors. Where a vendor’s subprocessor would have access to Bioscope or Customer data (especially PHI), the following requirements apply:

1. Disclosure. Tier 3 and Tier 4 vendors must maintain a current list of sub-subprocessors that touch Bioscope data. The list is reviewed at onboarding and at each re-review.
2. Public surface. Where a vendor or its sub-subprocessor handles PHI in the customer-facing data path, the entity is reflected on the public Subprocessors page.

Monitoring Vendor Risks

Re-Review Cadence

All approved vendors receive an annual full re-review.

Vendor contracts are additionally reviewed according to the signed contract duration, with renewal evaluation triggered automatically from the vendor renewal calendar maintained by Torii.

Event-Triggered Re-Review

A vendor is subject to an immediate re-review (regardless of cadence) on any of the following events:

• Vendor adds a new sub-subprocessor that handles Bioscope or Customer data;
• Vendor introduces a new AI/GenAI feature, model, or processing path that may interact with Bioscope data (see GenAI Vendor Track);
• Vendor changes data residency, including new regions or new cross-border transfers;
• Vendor experiences a publicly disclosed security incident or data breach;
• Vendor undergoes ownership change, acquisition, divestiture, or material reorganization;
• Bioscope’s data classification with the vendor materially changes (e.g., PHI is introduced where previously absent).

Based on the risk level and the sensitivity/criticality of data the vendor has access to, the vendor review may include an updated risk analysis performed by the security team in addition to legal and business review of contract terms.

Operational Monitoring

If the vendor is a service provider, their status page is added to an automated feed monitored by the security team.

Supplier Threat Intelligence

Aligned with ISO 27001:2022 A.5.7 (threat intelligence), the security team monitors Tier 3 and Tier 4 vendors for adverse signals on at least a quarterly basis, including:

• CISA Known Exploited Vulnerabilities (KEV) catalog entries naming the vendor or its core technology;
• SEC 8-K filings disclosing cyber incidents affecting the vendor;
• Public breach disclosure databases and credible reporting on the vendor;
• Regulatory enforcement actions or HHS Office for Civil Rights settlements.

A hit on any of these triggers an immediate event-driven re-review per Event-Triggered Re-Review.

GenAI Vendor Track

Any vendor - whether new or already approved - that introduces AI or generative-AI functionality interacting with Bioscope or Customer data is subject to additional review. This includes new vendors marketed as AI products and existing vendors that add AI features (e.g., document summarization, search assistance, AI-authored content).

A GenAI vendor review additionally evaluates:

1. Training data use. Does the vendor train models on Bioscope or Customer data? If so, what opt-out mechanisms are documented and contractually enforceable?
2. Per-tenant isolation. Are prompts, responses, and intermediate state isolated from other tenants at the application and infrastructure layers?
3. Data residency. Where is inference executed, and where is associated data stored?
4. Retention. How long are prompts and responses retained by the vendor, and how is deletion verified?
5. HIPAA eligibility. If PHI may interact with the AI feature, is the underlying model and endpoint covered under an executed BAA? Reference Secure Software Development and Product Security and the AI Governance policy.

Public consumer AI tools (ChatGPT, Claude.ai, Copilot, etc.) are subject to the AI Governance policy §D - Third-Party AI Tools - and the prohibitions listed in the internal Third-Party Use & Procurement Process.

Contractor Track

Contractors are workforce members for the purposes of access control, security awareness training, conflict-of-interest disclosure, and policy acceptance, and follow the lifecycle defined in the HR and Personnel Security policy.

Specific to the third-party track:

• All contractors are onboarded through Rippling regardless of engagement duration. NDA, Acceptable Use Policy acceptance, security awareness training, and COI disclosure must be completed before access is provisioned.
• Contractors do not have access to ePHI by default. Per Access policy, non-US contractors are categorically restricted from ePHI; US contractors require an explicit Linear ticket and CISO approval to be granted ePHI access, and the contractor’s engaging firm must have an executed BAA with Bioscope if access is approved.
• Contractor offboarding follows the employee termination process: access revoked within 24 hours of last day, equipment returned, accounts terminated.

Shadow IT Controls

Bioscope AI implements a defense-in-depth control set to detect and investigate procurement of SaaS, AI tools, contractors, or integrations outside this policy:

1. Detective - Continuous SaaS sweep. The security team utilizes an automated system to continuously review OAuth grants and new SaaS applications.
2. Cultural - employee attestation. All workforce members sign the internal Third-Party Use & Procurement Process in Rippling at hire and re-attest on material policy change.

Reports of suspected shadow IT may be made via Linear (Third Party Management project) or Slack #it-support without penalty for the reporter, even when the reporter is the procurer.

Vendor Offboarding

A vendor relationship may end through non-renewal, vendor sunset, vendor incident escalation, or internal decision. The Security Team owns the offboarding process. The relationship owner supports execution.

1. Credential revocation (within 24 hours of offboarding decision). Revoke all human and machine credentials, including SSO/IdP federation, Opal grants, OAuth grants, API keys, and service accounts tied to the vendor.
2. Data export. Export Bioscope’s data from the vendor per applicable retention requirements and Customer data obligations.
3. Data destruction attestation. Request written certification from the vendor that all Bioscope and Customer data - including backups - has been destroyed or returned, consistent with BAA §12 and §164.504(e)(2)(ii)(I). The attestation must be received within 30 days of termination.
4. Infeasibility exception. If the vendor cannot return or destroy data, document the infeasibility decision per §164.504(e)(2)(ii)(J), including the data scope retained, the continuing protections extended, and the eventual destruction trigger.
5. Public surface update. If the vendor was listed on the Subprocessors page, the page is updated within 5 business days of termination, and Customer notice is issued per the DPA.
6. Internal records. Update the vendor risk register, the approved software list, and the evidence vault. Final BAA termination notice is filed.
7. Retrospective. If the offboarding was triggered by a vendor security incident, conduct a documented retrospective and feed lessons learned into the supplier threat-intelligence program.

Evidence Retention

All artifacts supporting the vendor lifecycle are retained for a minimum of seven (7) years from the date of the artifact or the end of the vendor relationship, whichever is later. This includes:

• VTR questionnaires and responses;
• SOC 2 / ISO 27001 attestations reviewed;
• Executed BAAs, DPAs, NDAs, MSAs, and order forms;
• Approval ticket records and approver decisions;
• Sub-subprocessor disclosure lists and change notices;
• Offboarding attestations and destruction certifications;
• Event-triggered re-review records.

Artifacts are organized in the evidence vault by vendor name and lifecycle stage to support auditor sampling.

Software and Systems Acquisition Process

Bioscope AI Security maintains a list of pre-approved business software and a list of approved vendors / contractors.

If additional commercial software, hardware system, or cloud services is needed, a request should be submitted as a Linear ticket in the Third Party Management project. This triggers the tiering and approval process described in Vendor Tiering and Evidence Requirements.

As applicable, Bioscope AI security team may conduct a risk analysis on the software or system to ensure it complies with Bioscope AI security, compliance and legal requirements and does not interfere with the security controls. If a risk is identified, additional controls should be identified and implemented (or planned) prior to acquisition. An alternative product may be considered as a result of the risk analysis.

Customer Subprocessor Change Notice

Bioscope AI provides Customers with notice of changes to its subprocessor list. Notice is delivered through the Subprocessors page and through an opt-in email channel for Customers who have subscribed to subprocessor change notifications. Customer notification timing follows the DPA and BAA terms in effect, and at minimum provides 30 days’ pre-notice for new subprocessors that handle PHI.