Security Program Overview

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

1. Purpose & scope

Bioscope Foundry is committed to protecting its workforce, partners, member practices, patients, and the company itself from damaging acts, whether malicious or unintentional. This program establishes the policies, standards, controls, and procedures that maintain the confidentiality, integrity, and availability of Foundry systems and the data those systems handle, scaled to the risk level of each asset.

The program rests on two principles:

1. Security is everyone’s responsibility, from the founders through every workforce member, contractor, and third-party operating under Foundry’s name.
2. Self-management is encouraged by rewarding the right behaviors, by making the safe path the easy path, and by writing controls into code wherever feasible.

Foundry’s role under HIPAA is that of a business associate. Each member physician practice is the covered entity for its patients and issues its own Notice of Privacy Practices. Patient rights, to access, amend, restrict, or obtain an accounting of disclosures of PHI, flow through the practice. Foundry supports the practice in honoring those rights but does not respond to patient rights requests directly unless the practice directs us to do so.

2. Guiding principles

Foundry operates an AI-enabled back office for a regulated environment. Our security posture reflects that:

• PHI boundary, enforced in code. PHI lives only in Foundry’s clinical data plane, the workflow database and the FHIR R4 service, both Foundry-operated on AWS. It never lands on a workstation, in object storage outside that perimeter, in a log, in an LLM prompt, in an agent’s memory, or in a generated document.
• Zero trust by default. No flat network; no implicit trust based on location. Every request is authenticated and authorized regardless of where it originates.
• Least privilege, just in time. Standing access to PHI systems is minimized. Elevation to production is short-lived; each console enforces the strongest MFA factor it supports, with phishing-resistant WebAuthn passkeys preferred wherever the surface allows it.
• Defense in depth. Identity, network, data, and application controls layer on top of each other so that no single control failure compromises PHI.
• Augmentation, not replacement. AI assistance supports human judgment; it does not substitute for clinical or administrative decision-makers.
• Visibility before complexity. Inventory, audit logs, and monitoring are non-negotiable. We accept feature scope only when the corresponding observability is in place.

3. Compliance posture

Foundry has built a security program designed to meet HIPAA. The policies in this Trust Center are written against the HIPAA Privacy, Security, and Breach Notification Rules.

HIPAA Security Rule, Privacy Rule, and Breach Notification Rule govern this policy. Mapping to other frameworks (CCPA, ISO/IEC 27001, SOC 2) is maintained in the framework crosswalk.

To request the current state of any compliance activity, attestation, or audit summary, see the Compliance, audits & external communications policy.

4. Program coverage

At a high level, the Foundry information security program covers:

1. Inventory and protection of all critical assets: cloud accounts, code repositories, workforce endpoints, the agent control plane (Atlas), and the practice-scoped systems that touch PHI.
2. Data lifecycle management: from creation through retention to deletion or return, with explicit treatment of PHI under each member practice’s BAA.
3. Protection of data at rest, in transit, and in use, using TLS 1.2+, AES-256, and customer-managed encryption keys (CMEK) where the BAA so requires.
4. Segmented architecture: the cloud environment that hosts Foundry’s clinical data plane is isolated from non-PHI workloads. Tier-4 sandboxed worker hosts (Moltworkers) cannot reach PHI by design.
5. Automated security configuration and remediation, expressed as infrastructure as code and policy as code wherever feasible.
6. Centralized identity and access management: the identity provider for the workforce, passwordless authentication, and federated identity for platform access. the cloud identity broker governs access to non-PHI cloud workloads.
7. Secure product development: threat modeling, peer review, SAST and dependency scanning, and Foundry’s secure-development standards binding on all new web application code.
8. Continuous monitoring and auditing: every read and write of PHI is logged with the actor, time, patient, record, scope, and outcome, and audit records are retained for at least six years.
9. Validated business continuity, disaster recovery, and emergency response plans for both Foundry’s own services and the orderly offboarding of a member practice.
10. End-user computing protection and awareness training: MDM-managed endpoints, role-based training, and a standing security-awareness program.

The program applies to all Foundry workforce members, which we define broadly to include full-time and part-time employees in all job roles, founders, temporary staff, contractors and subcontractors, volunteers, interns, advisors, and any third party acting on Foundry’s behalf with access to Foundry systems or data.

The program is managed by dedicated security and compliance personnel under the authority of the Security Officer.

5. Document structure

Policies are organized one document per domain of concern. Each policy carries a version number (YYYY.MM), an owner, the effective date, and the next scheduled review. The body is structured into:

• Purpose & scope: what the policy covers and who it binds.
• Policy statements: the lettered commitments that constitute the policy itself.
• Controls & procedures: how those statements are implemented and operated.
• Roles & responsibilities: which roles do what under the policy.
• Review & revision: cadence and triggers for changes.
• Related policies: cross-references for navigation.

Maintenance, approval, and exception handling are governed by the Policy Management policy. Items that require confirmation by Foundry leadership have been resolved in this draft.

6. Review & reporting

The information security program, its policies, procedures, and controls are reviewed on a regular basis, internally by cross-functional reviewers and externally by qualified assessors when retained. A formal program review is conducted each quarter with the key metrics of the Foundry information security program, measuring its adoption and effectiveness across:

• PHI access patterns and audit-log completeness;
• Endpoint compliance against the MDM baseline;
• Identity hygiene: MFA enrollment, dormant accounts, privileged-role review status;
• Vulnerability remediation against SLA;
• Change-management adherence on production systems;
• Open incidents and findings carried over from previous quarters.

The scorecard is owned by the Security Officer and reviewed by Foundry leadership.

7. Related policies

• Policy management
• Roles, responsibilities & training
• Risk management
• Security architecture & operating model
• AI governance
• HIPAA Notice & Business Associate Statement