Vendor & Third-Party Risk

Policy · v2026.06 · Owner: Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30

1. Purpose & scope

This policy governs how Foundry selects, contracts with, monitors, and offboards third parties whose access, integration, or services may touch Foundry systems, workforce data, customer data, or PHI handled on a member practice’s behalf. It applies to every Foundry workforce member procuring or sponsoring a third-party relationship and to every vendor, partner, subcontractor business associate, subprocessor, and contracted developer of Foundry.

Because Foundry is itself a business associate to its member practices, any third party that creates, receives, maintains, or transmits PHI on Foundry’s behalf is a subcontractor business associate under 45 CFR §160.103, and its BAA with Foundry must be at least as protective as Foundry’s BAA with the practice (§164.308(b), §164.504(e)(5)).

2. Policy statements

Foundry policy requires that:

(a) A list of approved vendors, subprocessors, and partners is maintained in the central vendor risk register and reviewed at least annually. Re-review is additionally triggered by defined material events (see §7).

(b) Approval from management, procurement, and the security team must be in place prior to onboarding any new vendor or contractor. Required approvers and evidence depend on the vendor’s assigned tier (see §4). All material changes to existing contractual agreements must be reviewed and approved before implementation.

(c) A standard HIPAA Business Associate Agreement (BAA) is defined and includes the security and privacy provisions required by 45 CFR §164.504(e), §164.314(a), and Foundry’s flow-down obligations from member practices. A BAA must be signed with any vendor that may have a business need to access, 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). The subcontractor BAA must be at least as protective as Foundry’s BAA with the practice.

(d) For any technology that integrates with Foundry’s production environment or operations, particularly Foundry’s FHIR service (R4) data plane and Conductor platform, a Vendor Technology Review must be performed by the security team prior to integration to understand and approve the risk. Periodic compliance assessment and SLA review may be required.

(e) Customers, member practices, and partners are not granted access outside their own tenant boundary. They cannot access, modify, or delete data belonging to other practices or third 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 accepted at hire. Procurement outside this process is prohibited and subject to discipline consistent with the HR & Personnel Security policy.

(g) Sub-processors of Foundry’s vendors (so-called “4th parties”) that handle Foundry, customer, or PHI data must be disclosed by the vendor and tracked. See §5.

(h) Tier 1 (PHI-processing) and Tier 2 (business-critical) vendors are monitored for publicly disclosed security incidents, ownership changes, and material service changes via the supplier threat-intelligence program (see §7).

(i) All evidence supporting vendor onboarding, tiering, contractual execution, re-review, and offboarding is retained for a minimum of seven (7) years, consistent with 45 CFR §164.316(b)(2)(i) and the Policy Management policy.

3. Vendor technology risk review

A risk review of vendor technology is required prior to any integration with Foundry operations or infrastructure. Workforce members are required to engage the security team to conduct the review. Requests are submitted by email to security@bioscopefoundry.com or by opening a ticket in the internal Third-Party Management project.

The security team conducts the review through interviews and documentation review to verify that the vendor meets regulatory requirements (notably HIPAA where PHI is in scope) and follows security practices that reduce risk to an acceptable level. A vendor technology risk (VTR) assessment is conducted using a standardized questionnaire (VSAQ or an equivalent appropriate to the vendor’s tier) in the following steps:

1. Once a new vendor or contractor is requested, the security team opens a tracking ticket. The ticket tracks the vendor security review Q&A and the assigned tier.
2. The security team collaborates with the requestor and the prospective vendor to complete the questionnaire and gather evidence.
3. Findings, residual risk, and the approval decision are recorded in the central vendor risk register.

A list of approved vendors and contractors is maintained by the security and operations teams in the centralized vendor risk register.

4. Vendor tiering & evidence requirements

Each vendor is assigned a tier at onboarding. Required evidence and approvers scale with tier. The tier is recorded in the vendor risk register and re-evaluated at each annual or event-triggered re-review.

Tier definitions

Required evidence by tier

Approval matrix

A Tier-3 fast-track is available for genuinely low-risk tools that meet all of the following: no PHI, no PII, no PCI, no integration with Foundry production systems (Conductor, Foundry’s FHIR service, Atlas, the Forge Agent fleet), and annual cost under USD 500; the fast-track does not waive the requirement to be recorded in the vendor risk register and on the approved-software list.

5. Vendor contractual agreements

HIPAA / Business Associate Agreement

If a vendor needs access to PHI or ePHI handled by Foundry on a member practice’s behalf, the vendor must be HIPAA-eligible and a Business Associate Agreement is required. The BAA must include explicit language covering:

• Reporting to Foundry of any pattern of activity or practice constituting a material breach or violation of the BAA;
• The vendor’s obligation to report security incidents and breaches of unsecured PHI to Foundry without unreasonable delay, on a timeline compatible with Foundry’s 60-day notification obligation to covered-entity practices under 45 CFR §164.410;
• The vendor’s obligation to enter into BAAs with its own subcontractors that may handle PHI, on terms at least as protective as Foundry’s BAA with the vendor;
• Reporting to the Secretary of HHS where termination is not feasible;
• Return or destruction of PHI at termination, with attestation; and
• Permitted uses and disclosures consistent with Foundry’s BAAs with member practices.

The subcontractor BAA must be at least as protective as Foundry’s BAA with the covered-entity practice. Where a practice’s BAA imposes obligations stricter than Foundry’s standard subcontractor BAA, the relevant terms flow down to the subcontractor.

Service-level agreements

For infrastructure and service providers that support Foundry’s production or critical operations, notably Foundry’s FHIR service, the identity provider, and the platform observability stack, a Service Level Agreement (SLA) is defined and included in the contract. SLA targets are aligned with Foundry’s RTO/RPO objectives in the BCDR policy.

Vendor-personnel NDAs

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

Executed agreements (BAA, DPA, NDA, MSA, order forms) are linked or attached to the vendor record in the vendor risk register.

6. Sub-subprocessor (4th-party) governance

Foundry’s vendors frequently engage their own subprocessors. Where a vendor’s subprocessor may have access to Foundry, customer, or PHI data, the following requirements apply:

1. Disclosure. Tier 1 vendors must maintain a current list of sub-subprocessors that touch Foundry data. The list is reviewed at onboarding and at each re-review.
2. Flow-down. Where PHI may reach a sub-subprocessor, the vendor must have an executed BAA with that sub-subprocessor on terms at least as protective as the BAA between Foundry and the vendor.
3. 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.

7. Monitoring vendor risks

Re-review cadence

All approved vendors receive a full re-review at least annually. Contracts are additionally reviewed against the signed contract duration, with renewal evaluation triggered automatically from the renewal calendar maintained in the vendor-management tooling.

Event-triggered re-review

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

• Vendor adds a new sub-subprocessor that handles Foundry, customer, or PHI data;
• Vendor introduces a new AI/GenAI feature, model, or processing path that may interact with Foundry data (see §9);
• 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;
• Foundry’s data classification with the vendor materially changes (e.g., PHI is introduced where previously absent, shifting the vendor from Tier 2 to Tier 1).

The re-review may include an updated risk analysis by the security team plus legal and business review of contract terms, scaled to the sensitivity and criticality of data the vendor has access to.

Operational monitoring

For service providers, the vendor status page is subscribed to and monitored by the security and operations teams. Material status events feed into Foundry’s incident-response workflow per the Incident Response policy.

8. Supplier threat intelligence

The security team monitors Tier 1 and Tier 2 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, including HHS Office for Civil Rights resolution agreements affecting the vendor.

A hit on any of these signals triggers an immediate event-driven re-review per §7.

9. AI / LLM vendor track

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

Today, Foundry’s primary AI/LLM vendors are Anthropic and OpenAI. Where PHI may touch these vendors, the relationship is governed by an executed BAA, and the deployment is configured so the vendor does not retain inputs or outputs for training or other purposes beyond what the BAA permits. Specifics:

• Anthropic. PHI workloads use the Anthropic-issued BAA-covered API tier
• OpenAI. Powers the Maverick Tier-1 executive assistant; PHI scope is excluded by Foundry policy and routing.

A GenAI vendor review additionally evaluates:

1. Training data use. Does the vendor train models on Foundry, customer, or PHI 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 the Secure SDLC and AI Governance policies.

Public consumer AI tools (ChatGPT, Claude.ai, Microsoft Copilot, Google Gemini consumer tier, etc.) are subject to the AI Governance policy and the prohibitions in the internal Third-Party Use & Procurement Process. PHI must not be submitted to consumer-tier AI tools.

10. Contractor track

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

Specific to the third-party track:

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

11. Shadow IT controls

Foundry 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 uses automated tooling to continuously review OAuth grants in the identity provider and new SaaS application registrations.
2. Detective: endpoint visibility. Workforce devices are enrolled in MDM (see Endpoint & MDM); installed applications are inventoried and reviewed against the approved-software list.
3. Preventive: supply-chain pinning. Code dependencies follow Foundry’s supply-chain rules: third-party GitHub Actions are pinned to commit SHAs, production container images are pinned to explicit version tags (content-digest pinning is a near-term roadmap item), and new npm releases are subject to a 7-day cooldown before adoption. These pinning rules limit the blast radius of an unvetted upstream change.
4. Cultural: workforce attestation. All workforce members sign the internal Third-Party Use & Procurement Process at hire and re-attest on material policy change.

Reports of suspected shadow IT may be made via the internal Third-Party Management ticket queue or the IT support channel without penalty for the reporter, even when the reporter is the procurer.

12. 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 designated relationship owner supports execution.

1. Credential revocation (within 24 hours of offboarding decision). Revoke all human and machine credentials, including SSO/IdP federation, OAuth grants, API keys, and service accounts tied to the vendor.
2. Data export. Export Foundry’s data from the vendor per applicable retention requirements and member-practice data obligations.
3. Data destruction attestation. Request written certification from the vendor that all Foundry data, including any PHI and any backups, has been destroyed or returned, consistent with the BAA and 45 CFR §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. Notify affected member practices where required by their BAAs.
5. Public surface update. If the vendor was listed on the Subprocessors page, the page is updated within 5 business days of termination, and member-practice notice is issued per the BAA and any applicable DPA.
6. Internal records. Update the vendor risk register, the approved-software list, and the evidence vault. The final BAA termination notice is filed.
7. Retrospective. If offboarding was triggered by a vendor security incident, conduct a documented retrospective and feed lessons learned into the supplier threat-intelligence program.

13. 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;
• Independent third-party security 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.

14. Software and systems acquisition

Foundry’s security team maintains a list of pre-approved business software and a list of approved vendors and contractors.

If additional commercial software, hardware, or cloud services are needed, a request is submitted as a ticket in the Third-Party Management project. This triggers the tiering and approval process described in §4.

As applicable, the security team may conduct a risk analysis on the software or system to ensure compliance with Foundry’s security, compliance, and legal requirements and to confirm the acquisition does not interfere with existing security controls (notably the PHI boundary and the FHIR data plane). If a risk is identified, additional controls are identified and implemented (or planned) prior to acquisition. An alternative product may be considered as a result of the risk analysis.

15. Customer subprocessor change notice

Foundry provides member practices with notice of changes to its subprocessor list. Notice is delivered through the public Subprocessors page and through an opt-in email channel for member practices subscribed to subprocessor change notifications. Notification timing follows the BAA and any applicable DPA in effect; at a minimum, Foundry provides 30 days’ pre-notice for new subprocessors that may handle PHI, subject to the practice’s right to object as set forth in the BAA.

16. Roles & responsibilities

• Security Officer: owns this policy; approves Tier 1 and Tier 2 onboarding; signs off on event-triggered re-reviews; supervises the supplier threat-intelligence program.
• Privacy Officer: co-approves Tier 1 vendor relationships where PHI is in scope and reviews BAA terms for alignment with practice BAAs.
• Legal: owns BAA, DPA, NDA, MSA, and order-form execution; advises on data-residency and contractual obligations.
• Relationship owner: the named Foundry workforce member accountable for the operational vendor relationship; supports re-review and offboarding.
• Workforce members: follow the Third-Party Use & Procurement Process; do not procure SaaS, AI tools, or contractors outside the policy.

17. Review & revision

This policy is reviewed at least annually and whenever business, technology, or regulatory change makes it stale, including changes to Foundry’s subprocessor list, material changes to the AI/LLM vendor stack, or changes to the supply-chain pinning rules in Configuration & Change Management. Material revisions are approved by the Security Officer in coordination with the Policy Management process and recorded in the policy changelog.

18. Related policies

• Security program overview
• Compliance, audits & external communications
• AI governance
• HR & personnel security
• Access control
• Configuration & change management
• Incident response
• Breach notification
• BCDR
• HIPAA Notice & Business Associate Statement
• Business Associate Agreement
• Subprocessors