# Bioscope Foundry Trust Center — Policies This file contains all security policies, standards, and procedures. Generated automatically from https://trust.bioscopefoundry.com/ --- _Policy · v2026.06 · Owner: Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Access to Bioscope Foundry systems is granted on a **minimum necessary** basis and governed by role, business need, and the practice's Business Associate Agreement. Protected health information (PHI) is reached only through the Foundry platform, never copied to workforce devices. Doctor onboarding uses email magic links with short-lived, HttpOnly sessions. The production workforce identity provider is being selected (a signature-verifying OIDC IdP with MFA); until it lands, workforce access to consoles that support MFA is protected by the strongest factor each console offers, and any elevation to production cloud accounts is **zero-standing**, granted just-in-time and expires automatically. All access events are logged and reviewed. {{< /callout >}} ## 1. Purpose & scope {#purpose} This policy governs access to all Bioscope Foundry information systems, including the Foundry platform (`conductor`), the multi-agent operating system (`foundry-master-agent`), the identity provider, our cloud infrastructure (AWS), GitHub, and the SaaS applications used to run the business. It applies to every person granted an identity in a Foundry-managed system: workforce members (employees and contractors), member-practice clinicians and staff using the platform under a BAA, and any vendor with administrative access. The covered entity for the patient record at issue is the physician practice; Foundry's access controls are designed to honor that boundary while meeting our obligations as a HIPAA business associate. Foundry's safeguards address the HIPAA Security Rule's Access Control and Person-or-Entity Authentication standards (45 CFR § 164.312(a) and § 164.312(d)). 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](/frameworks/crosswalk/). ## 2. Policy statements {#statements} ### 2.1 Access control {#access-control} Foundry policy requires that: 1. Access to all computing resources, workstations, servers, network equipment, cloud accounts, services, and applications, must be protected by strong authentication, authorization, and auditing. 2. Interactive user access must be associated with an identity that uniquely identifies a single human or service principal. 3. Credentials, including session tokens, service accounts, and access keys, must meet the strength, lifetime, and rotation requirements defined in this policy and in Foundry's credential baseline (aligned with current authentication best practice). 4. Phishing-resistant multi-factor authentication is required for any access to systems that can read or write PHI, and for any privileged action in production environments. 5. Unused accounts, credentials, and access keys are disabled within 30 days of last use and removed within 90 days. 6. A unique service identity is used for each application-to-application integration; sharing of identities or credentials between humans and services is prohibited. 7. Authenticated sessions time out after a defined period of inactivity and are bounded by an absolute maximum lifetime. ### 2.2 Access authorization & termination {#access-authorization-termination} Foundry policy requires that: 1. Access authorization uses role-based access control (RBAC) or an equivalent attribute-based mechanism. Standard role bundles are pre-approved by the Security Officer. 2. Standard access based on a workforce member's job role may be pre-provisioned during onboarding. Any additional access requires the manager's approval before provisioning. 3. Access to PHI-bearing systems and to production cloud environments requires the approval of both the requester's manager and the Security Officer (or delegate). 4. Access is reviewed at least annually, and additionally whenever a workforce member changes role or whenever a member practice's clinical staff turns over. 5. On termination of employment, contract, or member-practice engagement, all system access is revoked within **one business day**; for any account that has handled PHI, access is removed the same business day. Hardware credentials (e.g. security keys), where issued, are recovered before final separation. 6. All access is reviewed whenever a workforce member's job role changes. ### 2.3 Shared credentials {#shared-credentials} Foundry policy requires that: 1. Shared credentials are minimized and permitted only as a documented exception, approved by the Security Officer. 2. Where a shared credential is unavoidable for business reasons, it is stored in an encrypted secrets vault that meets our data-protection standards, and access to the vault is itself logged. 3. Any shared credential that grants access to a PHI-bearing or production system must be paired with a complementary control (e.g. session recording, just-in-time approval) that uniquely identifies the human operator. ### 2.4 Privileged access management {#privileged-access-management} Foundry policy requires that: 1. Workforce members do not log in directly as a privileged identity. A privileged identity is one that holds administrative authority over a critical system, for example, an identity-provider super administrator, a cloud-provider root or organization-admin principal, the FHIR store administrator, or a host root account on a sandboxed worker. 2. Privileged access is obtained through a brokered, just-in-time mechanism that supports phishing-resistant MFA, attaches the human's individual identity to every action, and produces a complete audit record. 3. Direct administrative access to production systems is kept to an absolute minimum and produces a Linear ticket each time it is used. 4. The Security team reviews privileged and direct-administrative access patterns at least every 60 days and tunes role and break-glass scopes to remove access that is no longer needed. ## 3. Controls & procedures {#controls} ### 3.1 Workforce clearance {#workforce-clearance} 1. The level of access assigned to a workforce member is set against the _minimum necessary_ standard: the smallest data scope and the lowest privilege that lets the person carry out their job. 2. All access is granted on a least-privilege basis. New roles default to no PHI access; PHI access is added explicitly, with a documented business justification, and only after the PHI-access onboarding gates (see [HR & Personnel Security](/docs/hr-personnel-security/)) are complete. 3. The majority of Foundry workforce members do not require routine access to PHI in the FHIR store. Access is concentrated in clinical-support and platform-engineering roles that need it to operate the platform on a practice's behalf. ### 3.2 Identity provider & single sign-on {#identity-provider-single-sign-on} Foundry uses **the identity provider** as the primary identity provider (IdP) for workforce identity. SSO is the default; local authentication in business applications is permitted only when SSO is not technically available, and is tracked as an exception. - SSO is configured via SAML 2.0 or OIDC between the identity provider and each target application. - The Security team owns IdP administration, including user lifecycle and group membership. Delegated administration of a single application may be granted to that application's owner. - Workforce identities, group memberships, and role assignments are sourced from the HR system of record and reconciled to the identity provider through documented provisioning runbooks. - Patient-facing identity (when a member practice's patients authenticate to a Foundry-hosted surface) is mediated by the practice's own identity provider or by a separate patient IdP, never by the workforce the identity provider tenant. ### 3.3 Authentication & credentials {#authentication-credentials} Foundry authentication varies by user population: - **Doctor / clinician onboarding.** Email magic links with short-lived, HttpOnly session cookies (30-minute idle, 24-hour absolute cap). This is the intended v1 design for onboarding, chosen to keep the first-touch flow low-friction while remaining safe because no PHI passes through the onboarding channel. - **Production workforce and clinical access.** A signature-verifying OIDC identity provider is being selected (see _ADR-011_ in the `conductor` repo). Until that IdP is wired, workforce access to each console uses the strongest factor that console supports today, and every elevation to a production cloud account is zero-standing and just-in-time. - **Patient authentication** (where Foundry hosts a portal on a practice's behalf). Email or SMS one-time codes, per the threat model in §3.4. The credential baseline that follows applies to any password-bearing system Foundry operates today and to the recovery factors that back the flows above. 1. Unique identifiers: every workforce member has a single, unique identity-provider account. Shared accounts are not permitted on Foundry systems. 2. Where a password is unavoidable (legacy SaaS without SSO, local administrator accounts, or break-glass credentials): - Minimum 15 characters; 12 characters acceptable only when phishing-resistant MFA is enforced. - Passphrases are encouraged; spaces and the full printable character set are permitted. - No mandatory periodic expiration: passwords rotate on suspicion of compromise, not on a calendar. - No composition rules that reduce entropy (no forced "one of each character class"). - Reuse of the last 24 passwords is prevented. - Account lockout after 5 invalid attempts, with an exponential back-off. 3. All passwords stored at rest are hashed using **Argon2id**, scrypt, bcrypt, or PBKDF2 with parameters that meet current work-factor guidance for password hashing. Passwords transmitted over the network are protected by TLS 1.2 or higher. 4. Passwords are screened against known-breached corpora (Have I Been Pwned or equivalent) at creation, on every reset, and continuously thereafter. Detection of a breached credential triggers a forced reset. 5. On termination, all credentials are deactivated immediately (see [HR & Personnel Security](/docs/hr-personnel-security/)). 6. Default credentials shipped by a vendor or generated at provisioning time are changed before the system reaches production. 7. Configuration secrets used by Foundry services are never stored in source code. They live in the cloud provider's managed secrets store or in GitHub Actions encrypted secrets, depending on the runtime. 8. An approved password manager (1Password or equivalent) is used to store shared and personal credentials that cannot be brought under SSO. The vault master password meets the requirements above and is protected by MFA. ### 3.4 Multi-factor authentication {#multi-factor-authentication} MFA is required at every console and application that supports it. The strongest available factor is enrolled per surface; recovery factors are audited alongside primary factors. When the production workforce IdP is selected (see §3.3 and _ADR-011_), MFA enforcement will be centrally configured at the IdP. **Approved factor types, in preference order:** 1. **WebAuthn / FIDO2 passkey MFA**: phishing-resistant, the preferred factor everywhere the surface supports it. Enforced today on the AWS root account. Dedicated hardware security keys are being rolled out as sealed break-glass authenticators. 2. **Platform passkeys** on a managed workforce device: phishing-resistant, device-bound; used where a dedicated authenticator is not available. 3. **Push approval with number matching**. Acceptable as a second factor for general workforce access; push approvals without number matching are not permitted. 4. **TOTP authenticator apps** (e.g. 1Password). Acceptable where WebAuthn or a passkey is not feasible for a given application. 5. **Device-bound cryptographic certificates** issued by MDM, used in conjunction with another factor. **Prohibited factors for workforce MFA:** - **SMS one-time codes**: vulnerable to SIM-swap and SS7 attacks; not used for workforce identity at Foundry under any circumstance. - **Voice-call one-time codes**: same vulnerability profile as SMS. - **Email-delivered codes** as a second factor: the email account is itself a primary credential and cannot serve as its own second factor. (Note: email magic links are used as a _primary_ onboarding credential for doctors, see §3.3, not as an MFA second factor.) Patient-facing surfaces may use email or SMS one-time codes for patient identity because the threat model and population differ from the workforce. **MFA operating rules:** - Every workforce console that supports MFA has it enabled and enrolled. - Every workforce member registers at least two MFA devices or methods per console to prevent lockout. - Recovery codes, where applicable, are stored in the workforce password manager, never on paper, in chat, or in email. - MFA devices are revoked at termination on the same business day; lost or stolen devices are reported to Security immediately. - Re-authentication is required at least every 12 hours for privileged actions and every 30 days for routine workforce access. ### 3.5 Role-based access control {#role-based-access-control} Access is granted by job-function role, defined as user groups in the identity provider. Indicative roles include: - Engineering: platform, services, web - Security - IT / Operations - Clinical Operations (PHI-access) - Practice Success (PHI-access) - Finance / Administrative - Marketing / Growth Roles that may touch PHI are tagged _PHI-access_ in the IdP. Membership in a PHI-access group requires the workforce member to have completed background check, signed confidentiality agreement, signed HIPAA acknowledgment, and completed PHI-handling training, as set out in [HR & Personnel Security](/docs/hr-personnel-security/). Access to a specific member practice's PHI is further scoped by clinic, a Clinical Operations workforce member supporting Practice A does not see Practice B's records by default. ### 3.6 Just-in-time access to cloud production (zero standing access) {#just-in-time-access-to-cloud-production-zero-standing-access} Foundry operates a **zero-standing-access** model for production cloud environments. No workforce identity holds persistent permissions to production cloud accounts or the environments that host the FHIR service and PHI-adjacent workloads. All access is time-bounded, requested for a specific task, and recorded. **Cloud production environments** - The AWS root account is enrolled in passkey MFA (WebAuthn) per the account-setup runbook; day-to-day workforce access does not use the root identity. - Console and CLI/SDK access is federated through the identity provider (see §3.2); the workforce IdP selection is tracked in _ADR-011_ and MFA is enforced at each console until the central IdP lands. - Just-in-time elevation is time-bound, approved per request, and scoped to a single environment, a single role, and a documented duration; the automated elevation tooling that enforces this is being finalized. - Standard access to non-production environments may be auto-approved by policy for engineering and security roles. - Break-glass access to PHI is the strictest case: access to the FHIR service environment and any environment holding PHI _always_ requires manual approval, on the product side, break-glass PHI access requires practice (or data-subject) approval and expires automatically, and the request must include a business justification linked to a Linear or support ticket. - Sessions expire on schedule; no roll-over. **Cloud account structure** - The cloud organization is structured with Management, Infra, Dev, and Prod accounts. A cloud identity broker is the canonical access path to Foundry's cloud accounts. - Console and CLI/SDK access flow through the identity broker, authenticated through federated SSO with the strongest MFA factor each account supports. CLI/SDK credentials obtained through the broker are short-lived. - Just-in-time requests follow the same approval rules as the cloud IAM path above. **Logging and review.** Every just-in-time access grant, role assumption, and session is logged to a tamper-resistant audit store and reviewed by the Security team on a rolling basis. ### 3.7 Troubleshooting / break-glass access {#troubleshooting-break-glass-access} Routine troubleshooting is performed against logs and against non-production environments. When direct production access is unavoidable: - The request flows through the same time-bound elevation process as ordinary production access, with explicit "break-glass" tagging. - Break-glass roles are read-only where possible; they exclude PHI payload reads. PHI may be reached only through the platform's audited APIs, not by reading the FHIR store directly. - Break-glass requests require approval from engineering leadership _and_ the Security Officer (or delegate). - Every break-glass session generates a post-session note in Linear describing what was done and why. ### 3.8 Dual control for cloud root and organization-admin access {#dual-control-for-cloud-root-and-organization-admin-access} Foundry maintains a dual-control / split-knowledge process for root credentials on its cloud accounts: - Root credentials are protected under a dual-control, split-knowledge arrangement between senior staff, so that no single individual can exercise root authority alone. The account itself is protected by MFA. - When root use is required (e.g. recovering a billing change, replacing a security baseline), a Linear ticket is opened and both parties to the dual-control arrangement must jointly act. A post-action review is logged. ### 3.9 SSH and direct host access {#ssh-and-direct-host-access} - SSH is permitted only where there is no alternative. Where used, it requires Ed25519 or 4096-bit RSA-SHA2 keys; weaker key types are rejected at the server. - Host-level access to any machine that can read PHI is mediated by a brokered bastion with session recording and MFA. - Public-key material lives in a Foundry-managed key store; private keys remain on hardware tokens or MDM-managed devices. ## 4. Access to PHI {#phi-access} PHI lives in **Foundry's clinical data plane**: a private, Foundry-operated HAPI FHIR service (R4) and the clinical workflow database, in a dedicated AWS account that is segregated from Foundry's general workloads. The PHI boundary is enforced through identity, network, and application-layer controls together. 1. **Foundry does not store PHI outside the FHIR store.** Workstations, agent worktrees, generated documents, agent memory, prompts, logs, and the public marketing site never carry PHI. 2. **No local downloads.** Workforce members may not download, export, screenshot, copy/paste, or otherwise extract PHI from the platform onto workstations or removable media. Where a clinical workflow requires a document for a patient, the document is generated server-side and routed through an audited delivery path. 3. **Platform-mediated access.** PHI is reached only through the `conductor` platform's authenticated APIs and UI surfaces. Direct queries against the FHIR store, against backups, or against the underlying cloud account's storage are prohibited outside of break-glass. 4. **Agent surfaces.** Where an automated agent (a Forge Agent under Atlas) needs to act on PHI, the action runs in a Tier-3 clinic-scoped agent context with auditable identity. Tier-4 sandboxed workers (Moltworkers) operate on a separate network and _cannot_ hold PHI, clinic-scoped data, or peer-private memory; the Beacon Layer redacts before any cross-tier surface is built. 5. **Audit logging.** Every PHI read and write is logged: who, when, which patient and record, the outcome, the practice (covered entity), and the business reason. Audit records are retained for at least six years and are designed to capture identifiers, not PHI content. 6. **Geographic scope.** Access to PHI is restricted to workforce members physically located in the United States; contractors based outside the US do not receive PHI-access roles. Workforce members traveling outside the US must notify IT and Security; PHI access is suspended for the duration of foreign travel. 7. **Member-practice patient access.** Patient-facing surfaces (when offered by a practice through Foundry) authenticate the patient against the practice's chosen patient IdP, usually email or SMS one-time codes. The patient sees only their own records; this access is enforced server-side, not in the browser. ## 5. Workstation & remote access {#workstation} Foundry is a remote-first organization. Workforce members access systems primarily over the public internet from managed devices. ### 5.1 Approved hardware and operating systems {#approved-hardware-and-operating-systems} - Standard workforce device: **Apple Silicon MacBook** running a current macOS release supported by Apple. - Engineering may, by exception, run Linux (Ubuntu LTS or equivalent) on Foundry-provisioned hardware, brought under the same MDM and EDR baseline. - Personal devices (BYOD) are not permitted to access Foundry production systems or PHI-bearing surfaces. ### 5.2 Workstation use {#workstation-use} 1. Workstations may not be used for activity that is illegal, harassing, or in violation of Foundry policies. 2. Foundry information systems may not be used to transmit, retrieve, or store communications of a discriminatory or harassing nature, nor materials that are obscene. Hostile, profane, or offensive language directed at colleagues is not tolerated. 3. Foundry systems may not be used for personal commercial gain or for activity contrary to the organization's interests. Messages relating to a lawsuit or investigation may not be sent without prior approval. 4. Workforce members may not misrepresent or obscure another user's identity in transmitted or stored messages. 5. Disk encryption (FileVault on macOS, LUKS on Linux) is enforced through MDM. 6. The host firewall is enabled on all workstations; inbound connections are blocked by default. 7. An EDR agent is installed and actively running on every workstation (see [Endpoint & MDM](/docs/mdm/)). 8. Workstations lock automatically after no more than five minutes of inactivity. Workforce members manually lock devices when stepping away. ### 5.3 Office network and wireless {#office-network-and-wireless} 1. Production systems are not reachable over wireless from the Carmel office or any other location. There is no on-premises path to production; access is the same brokered, MFA-protected path workforce members use from anywhere. 2. The same access policies apply regardless of network: wired, wireless, residential, or cellular. 3. Office Wi-Fi at Foundry's Carmel, Indiana office is segmented from any device that handles workforce credentials; guest traffic uses a separate SSID. ## 6. Secrets & service accounts {#secrets} ### 6.1 Secrets management {#secrets-management} - Foundry uses **the managed secrets store** for runtime secrets used by services in the platform account and for cloud-side secrets, and **GitHub Actions encrypted secrets** for CI/CD. - Secrets are always encrypted at rest with customer- or platform-managed keys, and access is logged. - Secrets never appear in source code, environment dumps, support tickets, or chat. GitHub secret scanning with push-protection rejects known-secret formats at the remote, and Foundry contributor guides enumerate the shapes reviewers must reject on sight. - Where a workforce member must handle a secret directly (for example, configuring a third-party integration), the secret is passed through the password manager's secure-share feature, not by email or chat. ### 6.2 Service accounts {#service-accounts} - Application-to-application communication uses dedicated service identities, scoped narrowly with IAM policies. Each integration has its own identity. - Generic accounts and shared service identities are not allowed. - In AWS, service identities are IAM roles, managed in Terraform and bound to least-privilege policies. - Role assumption and workload identity federation are preferred over long-lived access keys; any long-lived key requires Security Officer approval and is rotated on a schedule. - An inventory of service accounts, their owners, and their grants is maintained automatically and reviewed at least quarterly. ## 7. Access reviews & helpdesk {#reviews} ### 7.1 Provisioning workflow {#provisioning-workflow} 1. An access request is created in Linear, either as part of the onboarding workflow or as a standalone ticket. 2. The Security or IT team grants the standard role bundle for the workforce member's position. The default bundle includes an identity-provider account in _Everyone_ and the role-specific group, Slack access to public channels, the HR system account, Linear access, and any role-specific tools (e.g. GitHub for engineering). 3. Anything beyond the standard bundle, particularly PHI access, production cloud roles, or repository-admin rights, requires a separate request, a business justification, and the Security Officer's approval. 4. On approval, IT or Security provisions the access, links the audit trail to the Linear ticket, and marks the ticket done. 5. Any temporary credentials issued at provisioning time are sent over an authenticated channel and must be changed on first use. ### 7.2 Termination {#termination} - HR notifies Security on the day of termination (or the day an engagement ends). - Security disables the workforce member's identity-provider account, which cascades through SSO to revoke application access. - Time-bound access grants, repository organizations, secrets vaults, MDM, and any unfederated tool are reconciled on the same business day. - Foundry hardware (laptops and any issued security keys) is returned through the offboarding checklist tracked in the HR system. - For any account that has handled PHI, revocation is completed the same business day, and a confirmation note is filed in the offboarding Linear ticket. ### 7.3 Access reviews {#access-reviews} - The Security team runs a quarterly access review across the identity provider groups, GitHub organization membership, the cloud identity broker permission sets, cloud IAM bindings on PHI cloud environments, and SaaS administrators. - Owners attest to each grant; unowned or unjustified grants are removed. - PHI-access group membership is reviewed at least quarterly and is reconciled against HR-confirmed role. - Outputs of the review are stored with audit records; deficiencies feed the Security team's remediation backlog. - Where increased risk is detected (suspicious sign-in, credential leak, insider threat indicator), the Security Officer may immediately restrict access pending investigation. ### 7.4 Helpdesk & identity verification {#helpdesk-identity-verification} - Workforce members reset their own credentials via the IdP's self-service flow wherever possible. - Support requests open a Linear ticket. The assigned supporter must verify the requester's identity through a second channel (Slack DM plus a brief video call, for high-risk changes) before acting. - "User identity verified" is recorded as a comment on the ticket. Where a credential or recovery token is issued, the supporter confirms separately that the requester received it on the expected channel. - Out-of-band identity verification is mandatory for any helpdesk request that would result in a credential reset, MFA device change, or privileged-access grant, the same population of requests that social-engineering attackers target. ## 8. Roles & responsibilities {#roles} - **Security Officer**: owns this policy, approves PHI-access and production-cloud access grants, reviews exceptions, runs access reviews, signs off on dual-control root use. - **IT / Operations**: runs the IdP, provisions standard bundles, manages the workstation fleet, executes terminations. - **Engineering Lead**: approves break-glass to production, owns service-account hygiene. - **People Operations (HR)**: initiates onboarding/termination tickets, owns the master onboarding/offboarding checklists, attests to role on access reviews. - **Managers**: approve standard role assignments for their direct reports and attest to each report's access at the quarterly review. - **Every workforce member**: protects their credentials, registers and maintains at least two MFA factors, reports suspected compromise to Security immediately. ## 9. Review & revision {#review} This policy is reviewed at least annually and whenever business, technology, or regulatory change makes it stale. Material revisions are approved by the Security Officer in coordination with the [Policy Management](/docs/policy-management/) process. Changes that affect a member practice's BAA-protected workflows are communicated to those practices before they take effect. ## 10. Related policies {#related} - [Security program overview](/docs/overview/) - [HR & personnel security](/docs/hr-personnel-security/) - [Asset management](/docs/asset-mgmt/) - [Endpoint & MDM](/docs/mdm/) - [Facility & physical security](/docs/facility/) - [Data protection](/docs/data-protection/) - [System audits & monitoring](/docs/system-audits/) - [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/) - [Framework crosswalk](/frameworks/crosswalk/) --- _Policy · v2026.06 · Owner: Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Bioscope Foundry runs an AI-enabled back office for member physician practices. This policy establishes the framework for the responsible development, deployment, and use of AI systems at Foundry: the Atlas orchestrator, the tiered Forge Agents (including the Tier-4 Moltworkers that cannot hold PHI), the Beacon Layer redaction surface, and third-party AI tools used by the workforce. AI assistance augments human judgment; it does not replace it. PHI used by AI components lives only within Foundry's FHIR service; PHI is never sent to third-party AI tools. {{< /callout >}} ## 1. Purpose & scope {#purpose} This policy establishes the framework for the responsible and ethical development, deployment, and use of artificial intelligence (AI) systems at Bioscope Foundry. As an AI-enabled MSO supporting independent physician practices, Foundry deploys agentic systems to operate over administrative and clinically-adjacent workflows on a member practice's behalf, under that practice's Business Associate Agreement. The policy: - Ensures compliance with all applicable laws, regulations, and ethical standards, including HIPAA, the HITECH Act, and the frameworks tracked in the [framework crosswalk](/frameworks/crosswalk/); - Promotes the responsible, transparent, and accountable use of AI technologies in healthcare-adjacent applications; - Mitigates the risks associated with AI: bias, privacy violations, security vulnerabilities, hallucination, prompt-injection, and the unique risks of multi-tier agentic systems; - Sustains trust in Foundry's use of AI when operating over PHI on a member practice's behalf; - Defines roles, responsibilities, and processes for AI governance across the organization; - Holds Foundry to a conservative posture: AI augments human judgment; it does not replace clinical or administrative decision-makers. This policy applies to: - All workforce members, contractors, partners, and stakeholders involved in the development, implementation, management, or use of AI systems at Foundry; - All AI systems deployed in Foundry production environments, principally the Atlas orchestrator (Tier-0 control plane), Forge Agents at Tiers 1–3 that may access PHI under appropriate scope, and the Tier-4 Moltworkers that are sandboxed and cannot hold PHI; - The Beacon Layer redaction surface that separates raw PHI from physician-facing insights; - HIPAA-eligible AI services consumed under executed BAAs (for example, model endpoints offered by approved cloud providers); - Third-party AI tools used by the workforce for non-PHI business purposes; - AI models and systems under development or evaluation for potential deployment. ## 2. Background {#background} Foundry operates the foundry-master-agent multi-agent system, in which the Foundry Orchestrator (canonical `agent_id = atlas-orchestrator`, commonly referred to as "Atlas"; legacy alias `orchestrator` per ADR 005) coordinates Forge Agents across five tiers to support a member practice's operations. Tier-1 executive assistants (Goose and Maverick) help workforce members; Tier-2 Foundry operations and specialist agents handle the back office; Tier-3 clinic-scoped clinical agents operate within a single practice's BAA; and Tier-4 sandboxed Moltworkers run untrusted or experimental tasks on dedicated `sandboxed_public` hosts that cannot reach PHI by construction. The Beacon Layer redaction surface converts clinic-scoped data into sanitized physician-facing insights, never exposing raw PHI or peer-practice `:private` memory. Foundry uses two model providers under BAA, mapped to distinct agent tiers: - The **Atlas orchestrator core** and **Tier-3 clinic-scoped clinical agents** run on the [Anthropic](https://www.anthropic.com) Claude API. PHI may flow to these endpoints under the Anthropic BAA, subject to the Tier-3 isolation invariants. - The **Maverick** Tier-1 executive assistant runs on the [OpenAI](https://openai.com) API (currently `gpt-5.5`) via the OpenClaw agent-gateway runtime. PHI scope for OpenAI is governed by Foundry policy and routing: by default, Maverick does not receive PHI; any change requires Security Officer sign-off and an executed BAA addendum with OpenAI. Where Foundry consumes hosted model inference for PHI-eligible workloads, that consumption occurs only via HIPAA-eligible services covered by a BAA with the provider. Foundry does not send PHI to consumer AI products or to model endpoints not covered by a BAA. The current set of approved AI subprocessors is maintained on the [Subprocessors](/legal/subprocessors/) page. This policy acknowledges both the value and the inherent risks of AI in a healthcare-adjacent operating environment and establishes the governance framework that ensures AI is used responsibly, ethically, and in compliance with healthcare regulations and the BAA with each member practice. ## 3. Definitions {#definitions} 1. **Artificial Intelligence (AI):** the development of computer systems able to perform tasks that normally require human intelligence, including natural language processing, decision support, summarization, prediction, and tool-using agents. Includes generative AI, machine learning, deep learning, and large language models (LLMs). 2. **AI System:** a specific implementation of AI technology, including software, infrastructure, data, and supporting processes. At Foundry, AI Systems include the Atlas orchestrator and the Forge Agents. 3. **AI Model:** a learned representation of data used by an AI System to make predictions, classifications, or decisions. Includes hosted LLMs accessed via API and any fine-tuned or auxiliary models Foundry operates. 4. **Atlas:** the Tier-0 master orchestrator and control plane for the Foundry agent operating model. Canonical agent identifier `atlas-orchestrator`. 5. **Forge Agent:** any agent coordinated by Atlas at Tiers 1–4 (executive assistants, operations, specialist, clinical, and sandboxed worker agents). 6. **Moltworker:** a Tier-4 worker that runs on a `sandboxed_public` host. Cannot hold PHI, cannot read clinic-scoped or `:private` memory, and cannot reach the PHI cloud. 7. **Beacon Layer:** the redaction surface that sanitizes physician-facing outputs. The Beacon Layer never exposes raw PHI or peer-practice `:private` memory across the boundary. 8. **Vector Engine:** the deterministic, scored routing and placement planner inside Atlas. Despite its name, it is not vector search. 9. **Production AI System:** any AI System deployed in a Foundry production environment that processes data on behalf of a member practice. Production AI Systems that process PHI must operate on HIPAA-eligible infrastructure under executed BAAs. 10. **Third-Party AI Tool:** external AI services (such as ChatGPT, Claude.ai, Microsoft Copilot, Cursor, or similar) used by workforce members for general business purposes. Third-Party AI Tools must never process PHI or confidential business information not approved for that tool. 11. **Data Privacy:** the protection of personal information, including PHI, from unauthorized access and misuse. 12. **Data Security:** the appropriate handling of data to ensure its confidentiality, integrity, and availability and to comply with applicable laws and the HIPAA Security Rule. 13. **Bias:** systematic and unfair discrimination or prejudice in AI outputs due to flawed or unrepresentative data, algorithms, or development processes. In healthcare-adjacent AI this includes potential disparities in model performance across demographic groups. 14. **Transparency:** the extent to which the inner workings of an AI System are understandable and explainable to relevant stakeholders, including practice staff, clinicians, and Foundry's own workforce. 15. **Accountability:** the ability to assign responsibility for the outcomes and actions of an AI System. 16. **HIPAA:** the Health Insurance Portability and Accountability Act of 1996, as amended. 17. **PHI / ePHI:** Protected Health Information; ePHI is PHI in electronic form. Foundry handles PHI as a business associate. 18. **Clinical Decision Support (CDS):** AI systems that assist licensed healthcare providers in making clinical decisions. Foundry's posture is conservative on CDS; the Foundry platform is not marketed as a CDS device and any CDS-adjacent feature requires explicit assessment against FDA guidance and the AI Governance Committee. ## 4. Policy statements {#statements} ### 4.1 Compliance with laws and regulations (A) {#compliance-with-laws-and-regulations-a} All AI systems developed, deployed, or used at Foundry must comply with all applicable laws, regulations, and ethical standards, including but not limited to: - HIPAA Privacy Rule (45 CFR Part 160 and Part 164, Subparts A and E); - HIPAA Security Rule (45 CFR Part 164, Subpart C); - HITECH Act; - FDA regulations applicable to clinical decision support software, where engaged; - State-specific healthcare data-protection and AI laws; - Applicable AI safety and ethics guidelines, including the AI-management frameworks tracked in the [framework crosswalk](/frameworks/crosswalk/) and Executive Order 14110. ### 4.2 Data privacy and security (B) {#data-privacy-and-security-b} AI systems handling PHI must adhere to the strictest data-privacy and -security standards: 1. **Access controls.** Role-based access controls (RBAC) and least privilege are enforced for any AI surface that touches PHI. All reads and writes of PHI by AI components are logged and auditable with the same controls described in the [Access Control](/docs/access/) and [System Audits & Monitoring](/docs/system-audits/) policies. 2. **Encryption.** Strong encryption protects PHI at rest (AES-256) and in transit (TLS 1.2+). All API calls to AI model endpoints handling PHI are made over TLS 1.2+ to HIPAA-eligible endpoints covered by a BAA. 3. **Security assessments.** Foundry conducts regular security assessments, vulnerability scanning, and periodic penetration testing of AI systems processing PHI as part of the [Vulnerability Management](/docs/vuln-mgmt/) program. 4. **Incident response.** Incident-response procedures cover incidents involving AI systems and are regularly tested. Breaches involving PHI are handled per the [Breach Notification](/docs/breach/) policy and the BAA. 5. **Data minimization.** AI systems process only the minimum necessary PHI required for their intended purpose. Tier-4 Moltworkers cannot hold PHI under any circumstance. 6. **Purpose limitation.** Use of PHI in AI systems is restricted to the specified, explicit, and legitimate purposes set out in the member practice's BAA. 7. **Secure development.** AI systems follow the [Secure SDLC](/docs/sdlc/) practices, including threat modeling, secure coding, code review, and security testing. 8. **Prompt-injection & tool-use safety.** Agents that consume content from untrusted sources isolate that content from instructions and from PHI. The agent tier model is the primary structural control: untrusted content is handled at Tier 4 or behind explicit sanitization before being passed to a PHI-eligible tier. ### 4.3 Production AI systems handling PHI (C) {#production-ai-systems-handling-phi-c} 1. **HIPAA-eligible infrastructure.** All production AI systems handling PHI operate on HIPAA-eligible infrastructure (Foundry's FHIR service for the PHI substrate; HIPAA-eligible model endpoints for inference) with executed BAAs. 2. **Operational validation.** AI components used in clinically-adjacent workflows undergo validation appropriate to the use case, accuracy, calibration, robustness on edge cases, and behavior under failure, before deployment to production. 3. **Human oversight.** AI outputs that affect a member practice's clinical or operational decisions are subject to review by qualified humans, either the practice's clinicians or Foundry workforce members in the appropriate role. AI augments judgment; it does not replace it. 4. **Sensitive-category handling.** Categories of PHI requiring heightened protection (for example, behavioral health, substance-use, HIV/AIDS, reproductive health, genetic information) are handled with additional controls. Such data is not used to train Foundry models without explicit, lawful authorization, and access is more tightly scoped than baseline PHI access. 5. **Model performance monitoring.** Continuous monitoring of the behavior of deployed AI components, success rates, refusal patterns, drift, and fairness signals where applicable, with thresholds for intervention. 6. **Regulatory awareness.** Foundry tracks FDA guidance on clinical decision-support software and adjusts the product posture if any feature begins to resemble a regulated device. The current posture is conservative: Foundry does not market the platform as a CDS device. ### 4.4 Third-party AI tools (D) {#third-party-ai-tools-d} The use of external, non-Foundry AI tools is permitted only under the following conditions. **Prohibited uses.** Third-Party AI Tools may **never** be used to process: - Protected Health Information (PHI) or electronic Protected Health Information (ePHI), including patient names, dates of service, clinical content, identifiers, or any patient-identifying detail; - Practice-confidential information whose disclosure could harm a member practice or its patients; - Confidential Foundry business information or trade secrets; - Security credentials, API keys, signing keys, or access tokens; - Data subject to contractual confidentiality obligations to a third party. **Permitted uses.** Third-Party AI Tools may be used for: - General research and information gathering on public topics; - Drafting non-sensitive internal communications and templates; - Marketing and content review where no patient or practice information is involved; - Code assistance for non-PHI, non-production code, subject to [Secure SDLC](/docs/sdlc/) review before merging. **Vendor assessment.** All Third-Party AI Tools used at organizational scale must undergo vendor risk assessment per the [Vendor & Third-Party Risk](/docs/vendor/) policy before being approved for workforce use. **Training and awareness.** Workforce members receive training on the appropriate use of Third-Party AI Tools and the data-exposure risks associated with them, as part of onboarding and the annual refresh. ### 4.5 Ethical considerations (E) {#ethical-considerations-e} AI systems must be developed and used ethically, considering potential impacts on fairness, equity, and well-being: 1. **Bias mitigation.** AI systems are designed, deployed, and monitored to minimize bias and discrimination. Where Foundry can measure performance across population subgroups, it does; where it cannot, it accepts a conservative deployment posture and discloses the limitation. 2. **Transparency and explainability.** AI outputs used in workforce or practice workflows include sufficient information for the human reviewer to understand the basis for the output to the extent technically feasible. 3. **Human autonomy.** AI systems are designed to respect and support human judgment. Clinical AI, where introduced, augments, not replaces, the professional judgment of licensed healthcare providers. 4. **Beneficence and non-maleficence.** AI systems are designed to maximize benefit and minimize harm to patients, workforce members, and member practices. 5. **Privacy respect.** AI development and deployment respect patient privacy rights as defined by the covered entity (the practice) and exercised through the practice. ### 4.6 Risk management (F) {#risk-management-f} 1. **Pre-deployment risk assessment.** A risk assessment is conducted before deploying any AI system that processes PHI or can influence clinically-adjacent decisions. The assessment covers data privacy and security risks, clinical safety risks where applicable, bias and fairness risks, regulatory compliance risks, technical performance risks, and operational risks. 2. **Risk mitigation.** Identified risks are addressed through appropriate mitigations before deployment. Residual risks are documented and accepted by named stakeholders per the [Risk Management](/docs/risk-mgmt/) policy. 3. **Ongoing risk monitoring.** Continuous monitoring of deployed AI systems detects new or emerging risks: security vulnerabilities, model behavior degradation, bias or fairness issues, and regulatory changes that may require system updates. ### 4.7 Transparency and explainability (G) {#transparency-and-explainability-g} 1. **Model documentation.** Each production AI System is documented: its architecture and algorithms, training data sources and characteristics (for fine-tuned components), performance metrics and validation results, known limitations and biases, intended use cases, and contraindications. 2. **Decision transparency.** For agent actions that affect practice workflows, the audit trail records the agent identity, the inputs considered, the policy decisions made, and the outputs produced, sufficient for a human reviewer to reconstruct the agent's behavior. 3. **Auditability.** Comprehensive audit trails of AI system decisions, data access, and configuration changes are maintained to support compliance reviews and investigations, per the [System Audits & Monitoring](/docs/system-audits/) policy. ### 4.8 Human oversight and control (H) {#human-oversight-and-control-h} 1. **Clinical oversight.** Human oversight by licensed healthcare providers is required for any AI output that would inform a clinical decision. Foundry's posture is to keep clinical AI in an advisory role. 2. **Escalation procedures.** Clear escalation paths exist for situations requiring human intervention: low-confidence outputs, detection of potential safety issues, unusual or unexpected results, system errors, prompt-injection signals. 3. **Override capability.** Human reviewers can override AI recommendations based on their judgment and case-specific factors. Override actions are logged. 4. **Feedback mechanism.** Workforce members and the practices we support can give feedback on AI behavior. Feedback is reviewed and integrated into improvements. ### 4.9 Training and awareness (I) {#training-and-awareness-i} 1. **Role-based training.** Workforce members involved in AI development, deployment, or use receive role-appropriate training: - **Engineering & data:** AI ethics, secure development practices, bias detection and mitigation, HIPAA compliance, prompt-injection awareness, the agent tier model and Beacon Layer redaction; - **Practice-facing workforce:** appropriate use of AI tooling, capabilities and limitations, when to escalate; - **Operations and IT:** AI system monitoring, incident response, security operations; - **All workforce members:** appropriate use of Third-Party AI Tools, the PHI boundary, data-protection requirements. 2. **Continuous education.** Training is updated to reflect evolving AI technology, regulatory requirements, and Foundry policy. 3. **Competency assessment.** Periodic assessment of AI-related competencies is performed for workforce members in critical roles. ### 4.10 AI system documentation (J) {#ai-system-documentation-j} Every production AI system that processes PHI maintains: 1. System architecture documentation: design, components, data flows, integration points; 2. Data management documentation: sources, processing methods, quality controls, retention; 3. Model details: algorithms, models, methodologies, validation; 4. Performance metrics: ongoing documentation including accuracy, calibration, fairness signals, and clinical-utility measures where applicable; 5. Security controls: access management, encryption, audit mechanisms; 6. Change management: version control and change history for all AI system components. ### 4.11 Monitoring and auditing (K) {#monitoring-and-auditing-k} 1. **Continuous monitoring.** Performance metrics, behavior signals, security events and anomalies, data quality, and availability; 2. **Regular audits.** Compliance with HIPAA Security and Privacy Rules, adherence to this policy, bias and fairness assessments, security vulnerability assessments, and validation of any clinically-adjacent outputs; 3. **Audit documentation.** Findings and remediation actions are documented and tracked to closure; 4. **Third-party audits.** Foundry supports external audits by regulators, certification bodies, and member practices as required. ### 4.12 Continuous improvement (L) {#continuous-improvement-l} 1. This policy is reviewed at least annually and more frequently when AI technology, regulatory requirements, organizational structure, or incident learning requires it; 2. AI systems are continuously improved based on monitoring, workforce and practice feedback, advances in the field, and observed fairness or bias issues; 3. Foundry tracks the state of the art in agentic systems, evaluation methods, and safety research as part of normal engineering work. ## 5. Governance structure {#governance} ### 5.1 AI Governance Committee {#ai-governance-committee} An AI Governance Committee (AIGC) oversees the implementation and adherence to this policy. **Composition ():** - Security Officer: chair; - Privacy Officer; - The Engineering Lead; - The Clinical Advisor (consulted on clinically-adjacent features); - The Operations Lead. **Responsibilities:** 1. Review and approve AI system deployments to production; 2. Establish guidelines and acceptable-use policies for AI technologies at Foundry; 3. Monitor compliance with ethical, regulatory, and contractual standards; 4. Oversee risk management and mitigation for AI systems; 5. Evaluate the effectiveness of AI systems and this policy; 6. Review and approve changes to this policy; 7. Investigate and address AI-related incidents or ethics concerns; 8. Monitor for potential bias, discrimination, or harm resulting from AI systems. **Cadence:** the AIGC meets at least quarterly, with additional meetings as needed for urgent matters. ### 5.2 AI ethics responsibilities {#ai-ethics-responsibilities} An AI ethics function is assigned to a designated workforce member who is the point of contact for ethical concerns or violations. This responsibility may be held by the Security Officer or the Privacy Officer rather than by a separate AI Ethics Officer. The assignment is recorded in the AIGC charter in internal governance records. The AI ethics function: 1. Advises on ethical considerations during AI system design and deployment; 2. Conducts ethics reviews of proposed AI systems and use cases; 3. Investigates and addresses ethical issues or complaints related to AI systems; 4. Facilitates training on ethical AI use and practice; 5. Monitors AI systems for ethical compliance and potential harm; 6. Participates in AIGC meetings; 7. Stays informed on evolving AI ethics standards and best practices; 8. Reports significant ethical concerns to senior leadership and the AIGC. ### 5.3 Senior leadership accountability {#senior-leadership-accountability} Final responsibility for Foundry's adherence to AI governance principles and this policy rests with the CEO and senior leadership team. Senior leadership must: - Allocate appropriate resources for responsible AI development and governance; - Foster a culture of ethical AI development and use; - Support the AIGC and the AI ethics function; - Ensure accountability for AI-related incidents or policy violations; - Communicate AI governance priorities throughout the organization. ## 6. Development & deployment procedures {#lifecycle} ### 6.1 Assessment and approval {#assessment-and-approval} Before an AI system that processes PHI or that influences a workflow with patient-safety implications is deployed to production, it completes a multi-stage approval: 1. **Technical review.** Architecture and design, code quality and security, performance and scalability, integration and testing. 2. **Security risk analysis.** Threat modeling and risk assessment, security control validation, vulnerability and penetration testing results, HIPAA Security Rule compliance verification. 3. **Ethical review.** Bias and fairness assessment, transparency and explainability evaluation, human oversight and control mechanisms, privacy impact assessment. 4. **Legal and compliance review.** HIPAA compliance verification, BAA validation (with the member practice and with subprocessors), FDA regulatory review where applicable, data-use and consent verification. 5. **Clinically-adjacent validation** (for features that produce outputs intended for clinical or operational decision-making). Validation on representative cases, evaluation by workforce members in the relevant role, comparison to existing operational standards. 6. **Final approval.** AIGC review and approval; sign-off by the Security Officer and the engineering lead; documentation of the approval decision and any conditions. ### 6.2 Documentation requirements {#documentation-requirements} Comprehensive documentation is created and maintained for AI systems: 1. **System design.** Architecture diagrams, data-flow diagrams, integration points, infrastructure and deployment configuration. 2. **Model documentation.** Algorithm description and rationale, training data characteristics (for fine-tuned components), training methodology and hyperparameters, validation approach and results, performance across relevant populations, known limitations and contraindications. 3. **Security documentation.** Threat model, implemented controls, access-control policies, encryption and key management, audit logging configuration. 4. **Operational documentation.** Deployment procedures, monitoring and alerting, incident-response procedures, maintenance, BCDR. 5. **Compliance documentation.** HIPAA compliance assessment, privacy impact assessment, BAAs, regulatory filings (if applicable). Documentation is maintained under version control and updated as systems change. ### 6.3 Change management {#change-management} All changes to production AI systems follow the [Configuration & Change Management](/docs/ccm/) process: 1. Changes are documented, tested, and approved before implementation; 2. Security and compliance impacts are assessed for each change; 3. Changes to AI models that alter behavior require re-validation and AIGC approval; 4. Changes are tracked in the production-change tracker and applied through GitHub-Actions-driven workflows where applicable; 5. Rollback procedures are documented and tested. ## 7. Monitoring & evaluation {#monitoring} ### 7.1 Continuous monitoring {#continuous-monitoring} AI systems handling PHI are continuously monitored for: 1. **Performance metrics.** Accuracy and other relevant metrics, inference latency, system response time, availability and uptime, error rates and exception handling; 2. **Fairness signals.** Performance differences across population subgroups where measurable, representation in processed data, potential bias sources; 3. **Security events.** Access attempts and authorization failures, data-access patterns and anomalies, security-control effectiveness, suspected incidents; 4. **Data quality.** Completeness and accuracy of inputs, distribution drift, missing or invalid data patterns, integrity verification; 5. **Operational outcomes.** Workforce acceptance and use rates, integration with practice workflows, observed effects on practice operations, feedback and reported issues. ### 7.2 Regular audits and reviews {#regular-audits-and-reviews} 1. **Quarterly reviews.** Monitoring data, incidents and issues, compliance with this policy, opportunities for improvement; 2. **Annual comprehensive audits.** HIPAA compliance, security assessment and penetration testing, bias and fairness assessment, validation review for any clinically-adjacent outputs, refresh of all AI system documentation; 3. **Incident-triggered reviews.** Investigation of security incidents involving AI systems, analysis of failures or unexpected errors, review of bias or fairness concerns, assessment of any safety events. ### 7.3 Feedback mechanisms {#feedback-mechanisms} 1. **Practice feedback.** Member practices have an accessible channel to report concerns, provide feedback, or request clarification about AI behavior in their operations. 2. **Internal reporting.** Workforce members can report AI-related concerns through direct contact with the AI ethics function, the Security Officer, the Privacy Officer, anonymous whistleblower channels, the Linear ticketing system, and dedicated a dedicated AI-governance channel. 3. **Patient concerns.** When patients raise concerns about AI in their care, those concerns are routed through their physician practice (the covered entity). Foundry supports the practice in addressing such concerns but does not engage patients directly except where the practice directs us to. 4. **Feedback integration.** Feedback is systematically reviewed and integrated into AI system and policy improvements. ## 8. Enforcement & accountability {#enforcement} ### 8.1 Policy violations {#policy-violations} Violations of this policy are taken seriously and addressed promptly: 1. **Investigation.** Reported or suspected violations are investigated by the AI ethics function in coordination with the Security Officer, the Privacy Officer, and (where applicable) HR. 2. **Workforce action.** Violations may result in actions up to and including mandatory retraining, suspension of AI system access privileges, formal written warning, performance plan, or termination of employment or engagement, in line with the [HR & Personnel Security](/docs/hr-personnel-security/) sanction framework. 3. **System action.** AI systems found to be in violation of this policy may be immediately disabled, taken offline, required to undergo remediation, required to undergo re-approval, or permanently decommissioned. 4. **Legal consequences.** Violations that result in regulatory non-compliance, breaches, or harm may result in regulatory enforcement, civil or criminal liability, contractual penalties, and reputational harm. Foundry will cooperate fully with regulators and member practices in such cases. ### 8.2 Reporting requirements {#reporting-requirements} 1. **Internal reporting.** Workforce members and stakeholders report suspected policy violations, AI system malfunctions or unexpected behavior, potential bias or fairness concerns, security incidents involving AI systems, and patient-safety concerns related to AI systems. 2. **External reporting.** Foundry reports to external parties as required: - Breach of unsecured PHI: notification to affected member practices per the BAA and per the [Breach Notification](/docs/breach/) policy; the practice notifies HHS and individuals as the covered entity; - FDA adverse-event reports if and where applicable; - State data-breach notifications as required; - Subprocessor and member-practice notifications per contractual obligation. 3. **Reporting channels.** - AI ethics function: reachable via ; - Security team: ; - Privacy team: ; - Linear: Security or Compliance projects; - Anonymous reporting: via the anonymous reporting channel. ## 9. Policy approval & maintenance {#approval} ### 9.1 Approval authority {#approval-authority} This policy is approved by: - Chief Executive Officer (CEO); - Security Officer; - Privacy Officer; - Engineering lead; - AI Governance Committee. ### 9.2 Review and revision {#review-and-revision} 1. **Scheduled reviews.** This policy is reviewed at least annually by the AIGC. 2. **Triggered reviews.** Reviews are also conducted when significant changes to AI technology occur, new regulations or guidance affecting AI use are issued, significant incidents or policy violations occur, organizational changes affect AI governance, or industry best practices evolve. 3. **Revision process.** Proposed revisions are drafted by the AIGC, circulated for review and comment, approved by the AIGC and senior leadership, communicated to all workforce members, and reflected in updated training. 4. **Version control.** Each version is maintained with version number and date, summary of changes, approvals, and effective date. ## 10. Applicable regulations & standards {#applicable} This policy is designed to comply with and align to the following: - Health Insurance Portability and Accountability Act (HIPAA); - Health Information Technology for Economic and Clinical Health (HITECH) Act; - FDA regulations for clinical decision support software (21 CFR Part 820, where applicable); - Executive Order 14110 on Safe, Secure, and Trustworthy AI; - Foundry's secure-development standards for LLM-enabled applications. HIPAA Security Rule, Privacy Rule, and Breach Notification Rule govern this policy. Mapping to other frameworks (CCPA, ISO/IEC 27001, ISO/IEC 42001, SOC 2) is maintained in the [framework crosswalk](/frameworks/crosswalk/). ## 11. Related policies {#related} - [Security program overview](/docs/overview/) - [Security architecture & operating model](/docs/security-architecture/) - [Risk management](/docs/risk-mgmt/) - [Data management](/docs/data-mgmt/) - [Data protection](/docs/data-protection/) - [Incident response](/docs/ir/) - [Breach notification](/docs/breach/) - [Vendor & third-party risk](/docs/vendor/) - [Configuration & change management](/docs/ccm/) - [Secure SDLC](/docs/sdlc/) - [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/) --- _Policy · v2026.06 · Owner: IT Lead & Security Officer (joint) · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Foundry cannot protect what it cannot see. This policy requires an accurate, up-to-date inventory of every physical workforce device and every digital asset (cloud resource, repository, service, identity, integration). Each asset has a designated owner and a data-classification tag. The inventory feeds access reviews, vulnerability management, vendor risk, and incident response. Data-lifecycle and classification details live in [Data Management](/docs/data-mgmt/). {{< /callout >}} ## 1. Purpose & scope {#purpose} This policy governs the inventory, ownership, classification, and lifecycle of every asset Bioscope Foundry uses to operate as a HIPAA business associate. Assets include: - Physical computing devices issued to workforce members (laptops, mobile phones, security keys, peripherals); - Cloud resources in AWS accounts (the clinical workflow database, the FHIR service, S3 buckets, queues, functions, VPCs); - Source-code repositories and CI/CD configurations; - SaaS applications and their administrative roles; - Human and service identities; - Third-party integrations and webhooks; and - Foundry-issued domain names, certificates, and other naming/cryptographic material. The policy supports HIPAA Security Rule expectations around device and media controls (45 CFR § 164.310(d)). 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](/frameworks/crosswalk/). ## 2. Policy statements {#statements} Foundry policy requires that: 1. IT and Security jointly maintain an inventory of all critical company assets, physical and digital, with sufficient detail to identify, locate, and assess the risk attached to each asset. 2. Every asset has a named owner and a risk / data-classification tag derived from the categories in [Data Management](/docs/data-mgmt/). 3. Every physical asset issued to a workforce member is labeled with a Foundry property identifier and is tracked through the IT asset system. 4. Asset inventories do not duplicate other authoritative inventories unnecessarily; where two systems hold an inventory, the source of truth is named in this policy and reconciliations run automatically. 5. Inventory data is refreshed continuously by automation; the Security team treats stale inventory as a finding. 6. Assets that fall out of inventory (untagged hardware, untagged cloud resources, unowned repositories) are escalated to the Security Officer and remediated promptly. ## 3. Controls & procedures {#controls} ### 3.1 Sources of truth {#sources-of-truth} Foundry distinguishes between the source of truth for an asset class and the consolidated inventory views built on top of it. Sources of truth, by asset class: - **Workforce devices**: the MDM is authoritative for fleet membership and configuration state; the HRIS holds the assignment to a workforce member; the IT asset register reconciles both. - **Cloud resources (AWS)**: Terraform state plus the live AWS APIs. AWS Config and resource inventory produce the canonical real-time view. - **Repositories & CI/CD**: GitHub organization membership and repository metadata. - **SaaS applications**: the Foundry application register, maintained by Security, reconciled monthly against the IdP's SSO catalog. - **Identities**: the identity provider for humans, AWS IAM for service principals. - **Domains and certificates**: the domain registrar's portal and the certificate-management system used by the platform. ### 3.2 Classification & ownership {#classification-ownership} Every asset record carries at minimum: - **Owner**: a named workforce member (or role) accountable for the asset. - **Classification**: derived from [Data Management](/docs/data-mgmt/). Assets that can reach PHI are tagged _PHI-bearing_ and are subject to stricter controls (encryption, audit logging, restricted access, accelerated patching). - **Lifecycle stage**: provisioned, in-service, retired. - **Linkages**: the workforce member, vendor, or workload the asset is tied to. Ownership transfers (a workforce member changing role, a service being handed between teams) are recorded as transactions in the asset record, not silently overwritten. ## 4. Physical asset inventory {#physical} ### 4.1 Scope {#scope} Foundry's physical assets are predominantly workforce computing devices. The Carmel office contains no on-premises production servers and no PHI-bearing hardware. Physical assets include: - Workforce laptops (Apple Silicon MacBooks; Linux workstations by engineering exception). - Workforce mobile phones (where Foundry-issued). - Phishing-resistant MFA hardware (WebAuthn / FIDO2 security keys such as YubiKeys), as dedicated keys are rolled out to workforce members responsible for privileged or PHI-adjacent surfaces. - Peripherals: external displays, keyboards, mice, docks, printers held at the Carmel office. - Networking equipment at the Carmel office, where Foundry-owned. ### 4.2 IT asset register {#it-asset-register} The IT Lead maintains an inventory in the MDM and reconciles it against the HRIS-driven assignment register. Each record includes: - Manufacturer, model, serial number, and Foundry property tag; - The workforce member or location it is assigned to; - Provisioning date, last MDM check-in, and configuration state (FileVault on, EDR present, OS version); - Classification tag (PHI-bearing by default for workforce laptops that reach the platform); - Any transfers and the date of each transfer; - Lifecycle stage and, when retired, the disposition path (re-issue, return, destruction). The IT Lead ensures every Foundry-issued device is tagged with a Foundry property identifier (label or asset sticker) and that the MDM record matches the physical device. Devices that fail to check into MDM for more than 14 days are flagged for follow-up. ### 4.3 Security keys {#security-keys} Phishing-resistant WebAuthn passkeys are enforced today on privileged surfaces, starting with the AWS root account per its setup runbook. Foundry is rolling out dedicated WebAuthn / FIDO2 hardware security keys as sealed break-glass authenticators, extending as additional consoles adopt WebAuthn or as Foundry's workforce identity provider is wired per _ADR-011_. Any issued hardware keys are inventoried with serial numbers in the IT asset register; two keys per holder are registered to prevent lockout. Lost keys are reported to Security immediately, deregistered from every surface they were enrolled on, and replaced. ## 5. Digital asset inventory {#digital} ### 5.1 Continuous discovery {#continuous-discovery} The Security team uses automated tooling to query AWS continuously and produce a unified view of the digital fleet. The query surface includes (non-exhaustive): - AWS accounts, including the dedicated PHI environment that hosts the clinical workflow database and Foundry's FHIR service; - PHI-environment resources: the clinical workflow database (Amazon RDS for PostgreSQL), the Foundry-operated HAPI FHIR service (Amazon ECS), encrypted S3 buckets, SQS queues, and serverless functions; - AWS resources more broadly: accounts, IAM principals and roles, S3 buckets, Lambda functions, EC2 instances (where present), DynamoDB tables, KMS keys; - GitHub organizations, repositories, deploy keys, GitHub App installations; - SaaS applications connected to federated SSO; - Vendor and partner integrations, including any third-party that has been issued an API key or OAuth grant. ### 5.2 Tagging {#tagging} Every digital asset carries owner, project, and classification tags. Resources that may handle PHI are tagged `data-class=phi` and are deployed only inside the PHI environment; cross-account access is mediated by IAM and network perimeter controls (see [Security Architecture](/docs/security-architecture/)). Untagged or mis-tagged resources are escalated to the resource owner and remediated. ### 5.3 Repositories {#repositories} Source-code repositories under the `bioscope-foundry` GitHub organization are inventoried and tagged. Each repository identifies: - Owner team and CODEOWNERS; - Data class the repository's runtime touches (e.g. _PHI-bearing platform service_ versus _marketing site, no PHI_); - Branch protection state; - Required-status checks and dependency-scanning configuration; - Whether deployment targets the PHI environment, the platform account, or non-production. ### 5.4 Identities & integrations {#identities-integrations} Human and service identities are inventoried in the IdP and in IAM, and a consolidated view is reviewed quarterly per [Access Control](/docs/access/). Every third-party integration (OAuth grant, API key, webhook) has a designated owner, a documented purpose, and a contract or BAA where required by data class. ## 6. Paper records {#paper} Foundry does not use paper records for PHI or for any sensitive operational data. Where paper exists (executed contracts, occasional signed forms, audit binders), it is collected at the Carmel office in a locked drawer or safe and the executed digital copy is held in the e-signature system (DocuSeal, self-hosted) and a managed corporate document store. Production of paper PHI by a workforce member is a policy violation and follows the policy-violation process (see [HR & Personnel Security](/docs/hr-personnel-security/)). ## 7. Lifecycle, transfer, & disposal {#lifecycle} ### 7.1 Provisioning {#provisioning} Assets are provisioned through the workflows in [Access Control](/docs/access/) (for digital identities) and the onboarding workflow in [HR & Personnel Security](/docs/hr-personnel-security/) (for physical devices). Provisioning creates the asset record and stamps the initial owner and classification. ### 7.2 Transfer {#transfer} When a device or repository changes owner (workforce member role change, team handoff), the transfer is logged in the asset record. For physical devices, IT wipes and re-enrolls the device before reassignment. ### 7.3 Decommissioning & destruction {#decommissioning-destruction} - **Workforce devices.** On separation or refresh, the device is wiped through MDM, and the disk is cryptographically erased (FileVault key destruction). The MDM record is moved to "retired" and the property tag is retained for inventory history. - **Cloud resources.** Resources retired from production are removed via Terraform, with destruction events captured in audit logs. - **Storage media.** Foundry does not use removable media for PHI. Where storage media holding non-PHI confidential data is decommissioned, destruction follows the methods in [Endpoint & MDM](/docs/mdm/): cryptographic erasure where the media is encrypted, physical destruction otherwise. - **Vendor termination.** Where a subprocessor is retired, Foundry confirms in writing that the vendor has returned or destroyed Foundry data, per the contract or BAA in place. Where return or destruction is infeasible, the contract limits ongoing use of the data. ### 7.4 Loss or theft {#loss-or-theft} Lost or stolen devices are reported to Security and IT immediately. The device is remotely locked and wiped through MDM; the workforce member's credentials are rotated; an incident ticket is opened under [Incident Response](/docs/ir/); the matter is escalated to [Breach Notification](/docs/breach/) only if the device could plausibly have held PHI (which, given the PHI boundary, is not the expected case). ## 8. Roles & responsibilities {#roles} - **IT Lead**: owns the physical asset register, the MDM-driven device baseline, and the labeling program. - **Security Officer**: owns the digital-asset inventory, the classification taxonomy, the asset-review cadence, and exceptions. - **Engineering Leads**: own their team's cloud resources and repositories; ensure owner and classification tags are present at creation. - **Workforce members**: take care of devices entrusted to them; report loss, theft, or unexpected behavior immediately. ## 9. Review & revision {#review} This policy is reviewed at least annually and whenever new asset classes (e.g. new cloud platforms, new vendor SaaS) come into scope. Material revisions are approved by the Security Officer in coordination with the [Policy Management](/docs/policy-management/) process. ## 10. Related policies {#related} - [Data management](/docs/data-mgmt/) - [Endpoint & MDM](/docs/mdm/) - [Access control](/docs/access/) - [Facility & physical security](/docs/facility/) - [Vendor & third-party risk](/docs/vendor/) - [Incident response](/docs/ir/) --- _Policy · v2026.06 · Owner: Security Officer / Engineering Lead · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Bioscope Foundry maintains a documented contingency plan to restore the MSO operating platform, and the practices that depend on it, after a disruption. PHI resides exclusively in Foundry's FHIR service (R4); recovery is therefore built on AWS regional and multi-region capabilities, Foundry's FHIR service's export and import procedures, and infrastructure-as-code rebuild automation. The plan is tested at least annually. {{< /callout >}} ## 1. Purpose & scope {#purpose} This Contingency Plan establishes procedures to recover Bioscope Foundry's operations following a disruption resulting from a natural disaster, political disturbance, man-made disaster, external human threat, internal malicious activity, infrastructure-provider outage, or any other event that interrupts normal operations. It applies to Foundry's operating platform (`conductor` on AWS), the agent control plane (`foundry-master-agent` and the Forge Agent fleet), Foundry-owned tooling, identity systems (the identity provider), and the work-site arrangements supporting Foundry's workforce. HIPAA reference: this Contingency Plan satisfies the HIPAA Security Rule's contingency-plan standard at 45 CFR § 164.308(a)(7), including its required implementation specifications: data backup plan, disaster recovery plan, emergency mode operation plan, testing and revision procedures, and applications-and-data criticality analysis. NIST reference: the plan is informed by NIST SP 800-34 ("Contingency Planning Guide for Federal Information Systems") and is consistent with the Foundry security program's broader alignment with the NIST cybersecurity guidance set. ## 2. Policy statements {#statements} Bioscope Foundry policy requires that: \(a\) A plan and process for business continuity and disaster recovery (BCDR), including the backup and recovery of systems and data, is defined and documented. \(b\) BCDR is simulated and tested at least once a year. Metrics are measured and identified recovery improvements are filed and tracked. \(c\) Security controls and HIPAA requirements are maintained during all BCDR activities. \(d\) Recovery time and recovery point objectives are defined for the operating platform and the PHI store, and are reviewed annually. \(e\) When an engagement with a practice ends, Foundry executes the 90-day clean offboarding commitment, including return or destruction of PHI in accordance with the BAA. ## 3. BCDR objectives {#objectives} The following objectives are established for this plan: 1. Maximize the effectiveness of contingency operations through an established plan that consists of: - **Notification / Activation phase**: to detect and assess damage and to activate the plan; - **Recovery phase**: to restore temporary operations and recover damage done to the original systems; - **Reconstitution phase**: to restore full processing capabilities to normal operations. 2. Identify the activities, resources, and procedures needed to carry out Foundry's processing requirements during prolonged interruptions to normal operations. 3. Identify and define the impact of interruptions to Foundry systems and to the practices Foundry supports. 4. Assign responsibilities to designated personnel and provide guidance for recovering Foundry during prolonged periods of interruption. 5. Ensure coordination with other Foundry staff who will participate in the contingency planning strategies. 6. Ensure coordination with external points of contact and vendors (AWS, the identity provider, and any subprocessors handling PHI under BAA) who will participate in the contingency planning strategies. ## 4. Recovery time and recovery point objectives {#rtorpo} Foundry defines distinct RTO and RPO targets for each tier of system. Targets are reviewed annually and after each tabletop or technical test. | System tier | Example components | RTO | RPO | Recovery posture | | ------------------------ | --------------------------------------------------------------- | ----------------- | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **PHI store** | Foundry's FHIR service (R4) datastore | Being established | Being established | FHIR-service export to encrypted managed object storage; a continuous export schedule and cross-region replication are being established as part of the resilience buildout. Customer-managed encryption keys. | | **Operating platform** | `conductor` (services + SSR web) | Being established | Being established | Container images and infrastructure-as-code in source control; production environment is reproducible from code; configuration is in secrets-managed stores; rebuild from scratch into an alternate region. | | **Agent control plane** | `foundry-master-agent` (Atlas, orchestrator, dashboard, policy) | Being established | Being established | Rust workspace pinned by Nix flake; reproducible bootstrap. The control plane can be brought back without re-derived PHI access; Forge Agents resume only after Atlas is healthy. | | **Identity** | the identity provider (workforce + providers) | Being established | ≤ 1 hour | Managed by the identity provider; recovery follows the provider's continuity SLAs. Foundry maintains a documented break-glass account access path. | | **Non-critical systems** | Internal dashboards, analytics, support tooling | ≤ 1 business day | ≤ 24 hours | Restored after the critical tier is online. | The targets above describe Foundry's planning posture for the operating platform and are not contractual SLAs unless reflected in a Master Services Agreement or BAA. RTO is the time between the start of an outage and the resumption of service; RPO is the maximum tolerable data loss measured in time. ## 5. Critical and non-critical systems {#systems} Foundry classifies systems for DR purposes into: 1. **Critical systems**: host production application services, the FHIR PHI store, the agent control plane, or are required for the functioning of those systems. If unavailable, they affect the integrity of data or the ability of practices to operate, and must be restored, or have a restoration begun, immediately upon becoming unavailable. 2. **Non-critical systems**: all systems not classified as critical. They may affect performance or convenience but do not prevent critical systems from functioning or being accessed appropriately. Restored at a lower priority than critical systems. The criticality assignment is documented in Foundry's asset inventory and reviewed annually. ## 6. Line of succession {#succession} The following order of succession ensures decision-making authority for the Contingency Plan is uninterrupted: 1. **Security Officer**: authority for the entire Contingency Plan; responsible for executing its procedures and ensuring the safety of personnel. 2. **Engineering Lead**: responsible for the recovery of Foundry technical environments. 3. **Chief Executive Officer**: assumes authority for the entire Contingency Plan if neither of the above can function in that role, or chooses to delegate to an alternative. Succession contacts (recorded in the current org chart): - The Security Officer () - The Engineering Lead - The Chief Executive ## 7. Response teams & responsibilities {#teams} The following teams have been developed and trained to respond to a contingency event affecting Foundry's infrastructure and systems: 1. **IT**: responsible for recovery of Foundry's corporate environment (the identity provider, MDM-managed workstations, internal SaaS). Includes personnel responsible for daily IT operations and maintenance. Leader: Security Officer, reporting to the CEO. 2. **People & Facilities**: responsible for ensuring physical safety of all Foundry personnel and environmental safety at each Foundry work site. Includes site leads where applicable. Leader: the Operations Lead, reporting to the CEO. 3. **Platform Engineering**: responsible for restoring the operating platform (`conductor`), the agent control plane (`foundry-master-agent`), and their supporting cloud infrastructure. Also responsible for testing redeployments and assessing damage to the environment. Leader: Engineering Lead. 4. **Security**: responsible for assessing and responding to all cybersecurity-related incidents according to the [Incident Response](/docs/ir/) policy and procedures. The Security team also assists the above teams in recovery as needed in non-cybersecurity events. Leader: Security Officer. Each team lead maintains a local copy of this policy and the relevant team contact information (including a printed copy) so that the plan can be executed even if Internet access is unavailable. All executive leadership is informed of any contingency event. ## 8. General disaster recovery procedures {#procedures} ### 8.1 Notification and activation phase {#notification-and-activation-phase} This phase addresses the initial actions taken to detect and assess damage inflicted by a disruption to Foundry. Based on the assessment, the Contingency Plan may be activated by the Security Officer or the Engineering Lead. The Security Officer may also activate the plan in the event of a cyber disaster. Notification sequence: - The first responder notifies the Operations Lead. All known information is relayed. - The Security Officer contacts the Response Teams and informs them of the event. The The Operations Lead or delegate begins assessment procedures. - The Security Officer notifies team members and directs them to complete the assessment procedures to determine the extent of damage and estimated recovery time. If damage assessment cannot be performed locally because of unsafe conditions, the Security Officer follows the alternate-assessment path below. - **Damage assessment procedures.** The Security Officer assesses damage logically, gains insight into whether the infrastructure is salvageable, and begins to formulate a recovery plan. - **Alternate assessment procedures.** Upon notification, the Security Officer follows the procedures for damage assessment with the Response Teams from a safe location. - The Contingency Plan is activated if one or more of the following criteria are met: - Foundry's operating platform will be unavailable for more than 48 hours; - The cloud environment hosting `conductor` or Foundry's FHIR service is damaged and will be unavailable for more than 24 hours; - Other criteria as appropriate and as defined by Foundry leadership at the time. - If the plan is activated, the Security Officer notifies team members and informs them of the details of the event and whether relocation is required. - Group leaders notify their respective teams. Team members are informed of all applicable information and prepared to respond and relocate if necessary. - The Security Officer notifies vendor and infrastructure partners (AWS support and any subprocessors required for recovery) that a contingency event has been declared. - The Security Officer notifies remaining personnel and executive leadership of the general status of the incident. - Notification can be made by Slack, email, or phone, in that order of preference. - If PHI is or may be implicated, the [Breach Notification](/docs/breach/) workflow is invoked in parallel, notifying affected practices per the BAA. ### 8.2 Recovery phase {#recovery-phase} These procedures cover recovering Foundry infrastructure and operations at an alternate site (typically an alternate AWS region), while other efforts are directed to repair damage to the original system and capabilities. Each procedure should be executed in the sequence presented, with parallel work permitted where indicated. Recovery goal: rebuild Foundry's operating platform to a production state, with PHI restored from the latest authorized FHIR export. 1. Contact affected practices to begin initial communication (Platform Engineering, with Communications Lead). 2. Assess damage to the environment (Platform Engineering). 3. Create a new production environment using infrastructure-as-code (Terraform/Pulumi) and the new-environment bootstrap automation (Platform Engineering). 4. Ensure secure access to the new environment, including identity federation, secrets distribution, and break-glass account provisioning (Security). 5. Begin code deployment and data restoration: - Application services and SSR web tier from container registry / source (Platform Engineering); - FHIR R4 PHI restoration via Foundry's FHIR service import from the most recent encrypted export (Platform Engineering, with Security oversight). 6. Test the new environment and applications using pre-written tests, including smoke tests, schema validation, and PHI sampling validation (without exporting PHI to test outputs) (Platform Engineering). 7. Test logging, security alerting, and audit logging functionality (Platform Engineering and Security). 8. Confirm systems and applications are patched and up to date (Platform Engineering). 9. Update DNS and other necessary records to point to the new environment (Platform Engineering). 10. Update affected practices through established channels and the Foundry status page (Communications Lead). For detailed recovery instructions, consult the Backup and Recovery section of [Data Management](/docs/data-mgmt/) and the platform-internal runbook (link held in the Engineering wiki). ### 8.3 Reconstitution phase {#reconstitution-phase} This section discusses activities necessary for restoring full Foundry operations at the original or new region. The goal is to provide a controlled transition of operations from the alternate site back to the primary site (or to formally adopt the alternate site as the new primary). 1. **Original or new site restoration.** Repeat the relevant Recovery-phase steps at the chosen primary site. Restoration of the original site is unnecessary for purely cloud-hosted environments except when required for forensic purposes. 2. **Plan deactivation.** If the Foundry environment is moved back to the original site from the alternate site, any temporary cloud resources used during the alternate-site operation are decommissioned per Foundry's media disposal practices, including verified destruction of any storage used to stage PHI exports during recovery. ## 9. Production environments and PHI recovery {#data} PHI lives only in Foundry's FHIR service (R4) store. Backup, replication, and recovery for the PHI store follow Foundry's FHIR service procedures: - **Backup posture.** the FHIR service store use our provider's intra-region durability; managed object storage exports run on a continuous schedule into a dual-region bucket with object versioning and a retention policy aligned with HIPAA recordkeeping. The recovery posture is a fast in-region rebuild from infrastructure-as-code plus a managed object storage replay; the dual-region export protects against any single-region loss. - **Replication.** Where supported by AWS, exports are replicated to an alternate region distinct from the primary production region. - **Encryption.** Exports are encrypted at rest with AES-256, using provider-managed or customer-managed encryption keys (CMEK) when CMEK is selected by the practice via BAA addendum. - **Restoration.** In a worst-case scenario, complete loss of the production project, Foundry rebuilds the project from infrastructure-as-code and restores PHI from the most recent authorized FHIR export held in the alternate-region bucket. The restored store is validated against pre-defined integrity checks before being placed back into service. - **No PHI on local disk.** Workstations, agent worktrees, and Foundry-owned tooling never store PHI. Recovery does not depend on, and does not produce, any local PHI artifact. Detailed recovery procedures are in the Backup and Recovery section of [Data Management](/docs/data-mgmt/) and the Engineering wiki. ## 10. 90-day clean offboarding {#offboarding} Independent of disaster events, Foundry commits to a clean 90-day offboarding for any practice that chooses to discontinue services. Offboarding is treated as a planned continuity event: - The practice notifies Foundry of its intent to offboard. Foundry confirms in writing and assigns an offboarding lead. - Within the 90-day window, Foundry produces a complete export of the practice's PHI from the FHIR store, in a portable format (FHIR R4 bundle), and delivers it through the channel agreed in the BAA. - Foundry completes any operational handoffs required for the practice to resume independent operation, including documentation and identity offboarding. - At the end of the 90-day window, Foundry returns or destroys all PHI in its possession in accordance with the BAA and HIPAA § 164.504(e)(2)(ii)(J). Destruction is documented with a certificate of destruction; return is documented with confirmation of receipt from the practice. - Foundry retains documentation of the offboarding event for the HIPAA retention period. ## 11. Work-site recovery {#worksite} If a Foundry facility is not functioning due to a disaster, employees work from home or from a secondary site with Internet access until the physical recovery of the affected facility is complete. Recovery is performed by the facility-management firm under contract with Foundry and coordinated by the Facility Manager or site lead. Foundry's engineering organization is location-independent and does not require an office-provided Internet connection to continue operating. Workstations are MDM-managed and operate over the public internet to Foundry-controlled services; no on-prem network access is required for normal work. ## 12. Service event communications {#statuspage} Foundry maintains a status page that provides real-time updates on service status. The status page is updated with details about events that may cause service interruption or downtime. A follow-up root-cause analysis (RCA) is made available to affected practices upon request after the event has been resolved. ### Short event (hours) - Practices experience a short delay in service. - Foundry monitors the event and determines course of action. Escalation may be required. ### Moderate event (days) - Practices experience a modest delay in service; processes running may need to be restarted. - Foundry monitors the event and determines course of action. Escalation may be required. - Foundry notifies affected practices of the delay and provides updates on the status page. ### Long event (a week or more) - Practices experience an extended delay in service; processes running may need to be restarted. - Foundry monitors the event and determines course of action. Escalation may be required. - Foundry notifies affected practices of the delay and provides regular updates on the status page; if PHI is implicated, the [Breach Notification](/docs/breach/) workflow applies. ## 13. Testing & maintenance {#testing} The Security Officer and the Engineering Lead establish criteria for validation and testing of this Contingency Plan, set an annual test schedule, and ensure implementation of the test. The testing process also serves as training for personnel involved in execution. At a minimum, the Contingency Plan is tested annually (within 365 days). Validation and testing exercises include tabletop and technical testing. All application systems are covered by at least the tabletop process. If an application system's contingency plan is included in the technical testing of a supporting system, that technical test satisfies the annual requirement for the application. ### 13.1 Tabletop testing {#tabletop-testing} Tabletop testing validates that designated personnel are knowledgeable and capable of performing the notification/activation requirements and procedures in a timely manner. Exercises include, but are not limited to: - Simulating a specific crisis to test the ability to respond in a coordinated, timely, and effective manner; - Walking through the line of succession with key roles temporarily unavailable; - Scenario play covering an agent runaway, an Atlas control-plane compromise, and a regional AWS outage. ### 13.2 Technical testing {#technical-testing} Technical testing ensures that communication processes and data storage and recovery processes can function at an alternate site to perform the functions and capabilities of the system within the designated requirements. Technical testing includes, but is not limited to: - Processing from a backup system at the alternate site; - Restoring the FHIR store from the most recent encrypted export into an alternate-region store; - Switching compute and storage resources to the alternate processing site. Findings from each exercise are tracked to closure in Linear and feed into the next annual revision of the plan. ## 14. Roles & responsibilities {#roles} - **Security Officer**: authority for the entire Contingency Plan; activates the plan; coordinates with executive leadership; chairs post-event review. - **Engineering Lead**: leads technical recovery; owns the rebuild-from-code procedures and FHIR restoration; co-authority for activation. - **Platform Engineering**: executes recovery procedures. - **Security**: assesses cyber incidents per the IR policy; secures alternate sites during recovery. - **People & Facilities**: physical safety, site recovery, work-site logistics. - **Communications Lead (per-event role)**: updates affected practices and the status page. - **CEO**: line of succession; external communications above a defined threshold. - **Workforce members**: follow the activation instructions issued by their team lead. ## 15. Review & revision {#review} This policy and the underlying Contingency Plan are reviewed at least annually, after every executed activation, and whenever a significant infrastructure or organizational change makes the plan stale. Material revisions are approved by the Security Officer in coordination with the Engineering Lead and the Policy Management process. ## 16. Related policies {#related} - [Incident Response](/docs/ir/) - [Breach Notification](/docs/breach/) - [Data Management](/docs/data-mgmt/) - [Data Protection](/docs/data-protection/) - [System Audits & Monitoring](/docs/system-audits/) - [Vendor & Third-Party Risk](/docs/vendor/) - [Business Associate Agreement](/legal/business-associate-agreement/) --- _Policy · v2026.06 · Owner: Security & Privacy Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Bioscope Foundry is a HIPAA **business associate**. When we discover a breach of unsecured PHI in our handling, we notify the affected physician practice (the covered entity) without unreasonable delay and within the timeframes required by HIPAA and the Business Associate Agreement (BAA). The practice, not Foundry, issues the patient, HHS, and (where applicable) media notifications required by the HIPAA Breach Notification Rule. Foundry provides the practice with the information it needs to make those notifications. {{< /callout >}} ## 1. Purpose & scope {#purpose} This policy governs how Bioscope Foundry investigates and reports breaches of unsecured PHI that occur in the course of services Foundry provides as a HIPAA business associate. It implements the HIPAA Breach Notification Rule (45 CFR §§ 164.400–414), the Health Information Technology for Economic and Clinical Health (HITECH) Act, and the breach-notification obligations Foundry assumes under its BAAs with member practices. The policy covers PHI that Foundry creates, receives, maintains, or transmits on behalf of a practice, including PHI in Foundry's FHIR service (R4) store, in transit between Foundry services, in agent decision contexts, and in any audit or operational artifact derived from PHI. Foundry's PHI boundary is enforced in code: PHI lives only in the FHIR store; it is never written to workstations, agent worktrees, generated documents, or logs. As a business associate, Foundry's role differs from a covered entity's. Foundry _reports_ breaches to the affected practice. The practice is the covered entity and is responsible for notifying its patients, HHS, and (in some circumstances) the media. Where the BAA delegates one of those notifications to Foundry in writing, Foundry executes that delegation; otherwise Foundry provides the practice with the data it needs and supports its work. ## 2. Policy statements {#statements} Bioscope Foundry policy requires that: \(a\) Breach notification procedures are invoked upon confirmation of a security incident that results in unauthorized acquisition, access, use, or disclosure of unsecured PHI. \(b\) The affected practice (covered entity) is notified without unreasonable delay and in no event later than **thirty (30) calendar days** from discovery of the breach by Foundry. This commitment is set by Foundry's Business Associate Agreement and is well inside the 60-calendar-day outer limit at 45 CFR § 164.410. Where a Practice's negotiated BAA sets a shorter window, that BAA controls. \(c\) When a data breach involves unsecured PHI, Foundry provides the practice with all information required under 45 CFR § 164.410(c) so the practice can satisfy its own obligations under 45 CFR §§ 164.404 and 164.406 (and § 164.408 for HHS reporting). \(d\) Foundry maintains a breach log and retains breach-investigation documentation for at least six years. ## 3. "Unsecured PHI" and the encryption safe harbor {#unsecured} "Unsecured PHI" means PHI that has not been rendered unusable, unreadable, or indecipherable to unauthorized persons through a technology or methodology specified in HHS guidance (currently: encryption to NIST specification, or destruction by a documented destruction method). PHI in Foundry's environments is configured to satisfy the safe-harbor conditions when at rest and in transit: - **At rest.** PHI in the FHIR service store is encrypted with provider-managed or customer-managed encryption keys using AES-256. - **In transit.** PHI between Foundry services and between Foundry and the practice is encrypted with TLS 1.2 or higher. An impermissible acquisition, access, use, or disclosure of PHI that satisfies the safe harbor is not a "breach" requiring notification under the Breach Notification Rule. Foundry still investigates such incidents through the [Incident Response](/docs/ir/) process and documents the determination. ## 4. Breach investigation process {#process} ### 4.1 Discovery {#discovery} A breach of PHI is "discovered" as of the first day the breach is known to Foundry, or the first day on which the breach would have been known by exercising reasonable diligence. Foundry is deemed to have knowledge of a breach if it is known, or would have been known with reasonable diligence, by any workforce member or agent of Foundry, other than the person committing the breach. Following discovery of a potential breach, Foundry immediately begins an investigation (see [Incident Response](/docs/ir/)), conducts a risk assessment (§4.3), and, based on the assessment, begins the process to notify each affected practice. ### 4.2 Investigation {#investigation} The Security Officer names an investigator (typically the Privacy Officer, Security Officer, or a designated incident lead). The investigator is responsible for: - Managing the breach investigation; - Completing the risk assessment; - Coordinating with internal stakeholders (engineering, the SIRT, people operations, legal counsel, and executive leadership); - Acting as the key facilitator for notifications to the affected practice and any other authorized recipient. All documentation related to the investigation, including the risk assessment, is retained for at least **six years**. The Security and Privacy Officer maintains a breach log (§9). ### 4.3 Risk assessment {#risk-assessment} For an acquisition, access, use, or disclosure of PHI to be a "breach," it must violate the HIPAA Privacy Rule. A use or disclosure that is incident to an otherwise permissible use, occurs despite reasonable safeguards, and follows the minimum-necessary principle is not a Privacy Rule violation and does not qualify as a breach. To determine whether an impermissible use or disclosure constitutes a breach, the investigator performs the four-factor risk assessment required by 45 CFR § 164.402: - The nature and extent of the PHI involved, including the types of identifiers and the likelihood of re-identification; - The unauthorized person who used the PHI or to whom the disclosure was made; - Whether the PHI was actually acquired or viewed; - The extent to which the risk to the PHI has been mitigated. The investigator also documents, for the internal record but separately from the four-factor analysis, the cause of the incident and the party responsible, the practice, Foundry, or a subprocessor, and the resulting remediation plan. The risk assessment is documented as part of the investigation and recorded in the Linear incident ticket. Foundry bears the burden of demonstrating that all required notifications were made and, where Foundry concludes that no breach occurred, that the underlying impermissible use or disclosure did not in fact rise to the level of a breach under the rule. ## 5. Timing of notification {#timing} Upon discovery of a breach, Foundry notifies the affected practice without unreasonable delay and in no event later than **thirty (30) calendar days** from discovery, well inside the 60-calendar-day outer limit at 45 CFR § 164.410(b). Where a Practice's negotiated BAA sets a shorter window, that BAA controls. Foundry maintains evidence demonstrating that all notifications were made within the required timeframes, including documentation of any circumstances that necessitated a delay. ## 6. Content of the notification to the practice {#content} The notification to the practice contains, to the extent possible at the time of notice (45 CFR § 164.410(c)): - The identification of each individual whose unsecured PHI has been, or is reasonably believed to have been, accessed, acquired, used, or disclosed during the breach; - A brief description of what happened, including the date of the breach (if known) and the date of discovery; - A description of the types of unsecured PHI involved (such as name, Social Security number, date of birth, home address, account number, diagnosis, disability code, lab result, or other types of information); - Any steps the practice or its patients should take to protect themselves from potential harm; - A brief description of what Foundry is doing to investigate the breach, mitigate harm, and protect against further breaches; and - Contact procedures for follow-up questions, including a Foundry contact, a phone or email address, and (when relevant) a web page with status updates. Where information required by 45 CFR § 164.410(c) is not available at the time of the initial notification, Foundry provides it to the practice promptly as it becomes available. ## 7. Method of notification {#method} The affected practice is notified by Foundry through the contact and method established in the BAA, typically a written notice delivered by email to the practice's designated privacy contact, with phone follow-up by the Security Officer. Where the BAA specifies a different mechanism, Foundry uses the specified mechanism. The notification is documented in the Linear incident ticket and the breach log. ## 8. Law-enforcement delay (45 CFR § 164.412) {#delay} If a law-enforcement official states to Foundry that a notification, notice, or posting would impede a criminal investigation or cause damage to national security: - If the statement is in writing and specifies the time for which a delay is required, Foundry delays the notification, notice, or posting for the time period specified by the official. - If the statement is made orally, Foundry documents the statement (including the identity of the official) and delays the notification, notice, or posting temporarily, for no longer than 30 days from the date of the oral statement, unless a written statement specifying the required delay is submitted during that time. Any delay invoked under § 164.412 is logged in the incident ticket with the official's name, agency, and contact information. ## 9. Breach log and recordkeeping {#log} In addition to the per-incident record described in the Incident Response policy, Foundry maintains a breach log capturing all breaches of unsecured PHI regardless of the number of records and practices affected. For each breach, the log captures: - A description of what happened, including the date of the breach, the date of discovery, and the number of records and individuals affected (if known); - The affected practice(s); - A description of the types of unsecured PHI involved (such as name, Social Security number, date of birth, home address, account number, diagnosis); - The date Foundry notified the affected practice and the method used; - Any law-enforcement delay invoked under § 164.412; - Resolution steps taken to mitigate the breach and to prevent recurrence. Breach log entries and supporting investigation documentation are retained for at least **six years**, consistent with HIPAA documentation requirements at 45 CFR § 164.530(j). ## 10. Practice (covered entity) responsibilities {#practice} Once notified by Foundry, the affected practice is responsible for these notifications under the HIPAA Breach Notification Rule: - **Breaches affecting 500 or more individuals in a single state or jurisdiction.** The practice notifies HHS contemporaneously with notifying individuals (without unreasonable delay and in no event later than 60 calendar days from the practice's discovery), and provides notice to prominent media outlets serving the state or jurisdiction within the same window. - **Breaches affecting fewer than 500 individuals.** The practice notifies individuals without unreasonable delay and in no event later than 60 calendar days from discovery. The practice reports such breaches to HHS through the OCR Breach Portal no later than 60 days after the end of the calendar year in which the breach was discovered. Media notification is not required. Where a practice agrees in its BAA to delegate one of these notifications to Foundry (for example, where Foundry maintains the practice's contact list and is best positioned to send patient notifications), Foundry executes the delegated obligation in accordance with the BAA and the rule. Absent a delegation, Foundry's role is limited to providing the practice with the information required by § 164.410(c) and supporting the practice's own notification work. ## 11. Sample notification letter to the affected practice {#sample} [Date] [Privacy / Compliance Contact Name] [Practice Name] [Practice Address] Re: Notification under 45 CFR § 164.410, Business Associate report of breach affecting protected health information Dear [Name]: I am writing on behalf of Bioscope Foundry, LLC, your HIPAA business associate under the Business Associate Agreement effective [BAA effective date], to notify you of a breach of unsecured protected health information ("PHI") that affects [Practice Name]. Foundry discovered this breach on [date of discovery]. Based on the information available at this time, the breach occurred on or about [date of breach]. What happened [Brief description of what occurred, the systems involved, and the period of exposure.] Who is affected [Identification of each affected individual whose unsecured PHI has been, or is reasonably believed to have been, accessed, acquired, used, or disclosed. Where the list is large, attach as a separate, encrypted file delivered through the channel agreed in the BAA.] Types of PHI involved [A description of the types of unsecured PHI involved, for example, name, date of birth, address, FHIR resource types, diagnosis, medication, lab results, to the extent known.] What we are doing [A description of Foundry's investigation, containment, and remediation steps; mitigation measures already taken; and steps being taken to prevent recurrence.] What you should consider doing [Steps the practice or its patients may wish to take to protect themselves from potential harm.] How to reach us For follow-up questions, please contact [Foundry contact name, role, email, phone]. We will provide additional information required by 45 CFR § 164.410(c) as it becomes available, and will support your patient, HHS, and (where applicable) media notification obligations under 45 CFR §§ 164.404 and 164.406. Sincerely, [Name] Security & Privacy Officer Bioscope Foundry, LLC privacy@bioscopefoundry.com ## 12. Workforce training {#training} Foundry trains all workforce members on the policies and procedures relevant to PHI as necessary and appropriate for each member's role. Training covers how to identify a potential breach, how to report it through the channels in the [Incident Response](/docs/ir/) policy, and the prohibition on attempting to investigate or remediate independently of the SIRT. Training is delivered at onboarding and refreshed annually, with completion tracked. ## 13. Complaints, sanctions, non-retaliation {#complaints} **Complaints.** Foundry provides a process for individuals (including practice workforce, patients via their practice, and Foundry workforce members) to make complaints about Foundry's privacy practices or its compliance with those practices. Complaints can be sent to and are tracked in Linear. **Sanctions.** Foundry applies appropriate sanctions against workforce members, contractors, and subprocessors who fail to comply with this policy or with the relevant BAA, ranging from required retraining to termination of employment or engagement. **Non-retaliation and non-waiver.** Foundry does not intimidate, threaten, coerce, discriminate against, or take retaliatory action against any individual for exercising a privacy right or for filing a complaint, participating in an investigation, or opposing an act or practice that the individual believes in good faith violates HIPAA. Foundry does not require individuals to waive their privacy rights as a condition of any service. ## 14. Authority contacts {#contacts} These contacts are provided for reference. Foundry, as a business associate, does _not_ notify HHS, individuals, or the media on a practice's behalf unless the BAA expressly delegates that responsibility. The affected practice manages these communications. ### U.S. Department of Health and Human Services (HHS), Office for Civil Rights {#us-department-of-health-and-human-services-hhs-office-for-civil-rights} - Phone: 1-877-696-6775 - HHS Breach Portal: - Mailing Address: Centralized Case Management Operations, U.S. Department of Health and Human Services, 200 Independence Avenue, S.W., Room 509F HHH Bldg., Washington, D.C. 20201 ### Federal Trade Commission - Phone: 1-877-382-4357 - Website: ## 15. Roles & responsibilities {#roles} - **Security & Privacy Officer**: owns this policy, makes the breach determination, names the investigator, signs notifications to practices, and maintains the breach log. - **Investigator (per-incident)**: performs the risk assessment, coordinates internal teams, drafts the notification to the practice. - **Legal counsel**: supports breach analysis and any regulator or law-enforcement engagement. - **Affected practice (covered entity)**: receives Foundry's notification; conducts its own analysis; issues required notifications to patients, HHS, and (where applicable) media. - **Workforce members**: promptly report suspected breaches through any documented channel. ## 16. Review & revision {#review} This policy is reviewed at least annually and whenever business, technology, or regulatory change makes it stale (for example, an HHS rulemaking that alters the Breach Notification Rule). Material revisions are approved by the Security Officer in coordination with the Policy Management process. ## 17. Related policies {#related} - [Incident Response](/docs/ir/) - [Privacy](/docs/privacy/) - [Data management](/docs/data-mgmt/) - [Data protection](/docs/data-protection/) - [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/) - [Business Associate Agreement](/legal/business-associate-agreement/) --- _Policy · v2026.06 · Owner: Engineering Lead / Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Foundry standardizes and automates configuration through infrastructure-as-code (Terraform / Pulumi for the AWS environment, Nix flakes for the Rust agent runtime) and pull-request-driven change control through GitHub. Every production change, code, infrastructure, access, or feature-flag, is traceable, reviewed, tested, and reversible. This policy spells out how that happens. {{< /callout >}} ## 1. Purpose & scope {#purpose} This policy applies to every production change Bioscope Foundry makes, to the cloud environment that hosts `conductor` and Foundry's FHIR service, to the macOS launchd + Nix deployments that run `foundry-master-agent` and the Maverick OpenClaw, to the Cloudflare Workers deployments that serve the marketing surfaces, and to the access-control, feature-flag, and network configurations that surround them. The intent is to ensure every change is traceable, reviewed by someone other than the author, tested, and reversible. ## 2. Policy statements {#statements} Bioscope Foundry policy requires that: \(a\) All production changes, including software deployments, feature-flag enablement, infrastructure changes, network changes, and access-control updates, must go through an approved change-management process. \(b\) Each production change must maintain complete traceability documenting the request, the requester, the date and time, the actions taken, and the result. The system of record is Linear (the production-change tracker) and GitHub (the merging pull request). \(c\) Each production change must be tested before implementation. Testing includes, at minimum, usability, security, and impact testing appropriate to the change. \(d\) Each production change must include a rollback plan that the on-call operator can execute without further design work. \(e\) Each production change must be approved. - Approvers are determined by change type. PHI-adjacent changes require Security review. - Approvers must be someone other than the author or executor of the change. - Auto-approval is permitted only for pre-approved categories (e.g., routine dependency upgrades that pass the standard gate); each auto-approval rule is documented and signed off by the Security Officer in advance. \(f\) Configuration drift must be detectable. Infrastructure is managed as code; out-of-band changes are minimized and reconciled back into source promptly. ## 3. Configuration management processes {#config} 1. **Configuration is automated.** cloud infrastructure is managed with Terraform (or Pulumi in the repos where Pulumi has been adopted). The agent runtime is managed with Nix flakes; macOS launchd units are declared and reproducible. Cloudflare Workers deployments are driven by Wrangler configuration committed to source. 2. **All changes to production systems, networks, and security configurations are reviewed and approved by Security** when they touch PHI flow, authentication, authorization, firewall rules, IAM, encryption keys, or network perimeter controls. 3. **All production changes are tested before implementation**: at minimum via the `terraform plan`, `pulumi preview`, or `nix flake check --impure` output reviewed in the PR. For application code, the full CI gate (`pnpm check` / `cargo test --workspace`) must pass. 4. **Implementation is performed by authorized personnel.** The set of humans able to apply a change to production is documented in the [Access Policy](/docs/access/). 5. **Inventory is automated.** System inventories are generated from the source-of-truth IaC and from AWS / Cloudflare APIs: - Resources are categorized and labelled by environment (`dev`, `staging`, `prod`). - Resources are classified by the data they store or process per the Foundry data-classification model (see [Data Management](/docs/data-mgmt/)). - The Security function maintains automation that monitors all changes to production assets and produces inventory diffs for review. - Asset inventory drives the risk-assessment inputs in [Risk Management](/docs/risk-mgmt/). - Periodic manual audits reconcile the IaC inventory against the live cloud state. 6. **Baselines for hardening.** Foundry uses recognized baselines as the hardening reference: - cloud environments follow the CIS Cloud Foundation Benchmark. - Production container images are pinned to **explicit version tags** before promotion; pinning images to their content digest is a near-term roadmap item. Local development stacks may reference upstream tags for convenience but are not part of any PHI data plane. - The Nix flake-based runtime for `foundry-master-agent` provides reproducible system configuration by construction. 7. **Time synchronization.** Production hosts and managed endpoints sync to authoritative time sources (authoritative time servers, device vendor time servers). 8. **Separation of frontend and backend.** User-facing surfaces are deployed independently from data-handling services. The customer-facing `conductor` web app is separate from its services and from the FHIR service store. 9. **Full-scale testing before promotion.** Software and infrastructure changes complete the standard gate before being promoted to production. 10. **Code review.** Static analysis (`tsgo`, `oxlint --type-aware`, `knip`, `cargo`) and human review run on every PR, see [Secure SDLC](/docs/sdlc/) §3.2. ## 4. Configuration monitoring & auditing {#monitoring} Infrastructure and configuration state is captured continuously: - provider-side configuration and posture monitoring is being stood up as part of the security-tooling rollout; misconfigurations are alerted to Security and triaged into Linear. - Drift between Terraform / Pulumi state and live cloud resources is reconciled at every plan. Drift outside a planned change is investigated immediately. - Configuration auditing rules are defined against approved baselines; deviations (open ingress, public buckets, IAM expansions, encryption disabled) generate alerts. - The cloud audit log is the system of record for control-plane changes in AWS and is reviewed by Security weekly. PHI never appears in those logs. ## 5. Production systems provisioning {#provisioning} 1. Before provisioning a new production resource, a request must be opened in GitHub (PR against the IaC repo) and tracked in the production-change tracker. 2. Linear access is restricted to authenticated workforce; access is granted per [Access Control](/docs/access/). 3. The Security function must approve the provisioning request before the resource is created, unless a pre-approved automation path applies (e.g., a routine ephemeral worker in a sandboxed environment). 4. Once approved, the implementer configures the resource against the standard baseline for its role. Where the resource will store or process PHI, the encryption configuration is verified: provider-managed or customer-managed encryption keys (CMEK) at rest, TLS 1.2+ in transit. 5. Sensitive data in motion is always encrypted. 6. Once provisioned, a security analysis is performed: automated configuration / vulnerability scans or manual inspection by Security. Verifications include, without limitation: - removal of default credentials and provisioning users; - network configuration (no unintended public exposure); - encryption settings on data volumes and buckets; - monitoring agents installed where applicable; - IAM bindings minimized to least privilege. 7. Resources are fully promoted to production only after verification against Foundry's standards and the change request is approved. ## 6. Endpoint configuration controls {#endpoints} Workforce endpoints, primarily macOS (Apple Silicon), are configured either manually by IT or the owner, or automatically through the MDM platform. The following baseline applies at minimum: - full-disk encryption (FileVault) enabled; - unique user accounts with strong, passwordless authentication where available; - automatic OS and security patching enabled; - screen-lock timeout and password protection; - EDR / endpoint protection agent installed; - Foundry-approved configuration profile applied (firewall on, sharing off, remote management restricted). Endpoint configuration is inspected by Security via the MDM console, manually as needed, automatically via continuous compliance checks. See [Endpoint & MDM](/docs/mdm/) for the full standard. ## 7. Server & service hardening {#hardening} ### 7.1 provider-managed compute {#provider-managed-compute} Production workloads run primarily on provider-managed compute (Amazon ECS container services and Lambda functions, selection depends on the workload). Hardening derives from the CIS Cloud Foundation Benchmark plus Foundry-specific controls: - production container images pinned to explicit version tags before promotion, with content-digest pinning on the near-term roadmap; - workload identity used in preference to service-account keys; - service-to-service traffic mutually authenticated; - egress from the PHI-handling account restricted by network perimeter controls; - logging configured per [System Audits & Monitoring](/docs/system-audits/). ### 7.2 Nix + macOS launchd (agent runtime) {#nix-macos-launchd-agent-runtime} The Maverick OpenClaw deployment in `agents/` and parts of `foundry-master-agent` run on macOS Apple Silicon under launchd, configured by Nix + Home Manager. Hardening derives from the reproducibility of the Nix flake itself: the system configuration is checked into source, `nix flake check --impure` runs after every flake change, and any drift between declared and observed configuration is detectable and reversible. PHI-eligible mounts are gated by the agent's mount-security checks (Tier-4 Moltworkers cannot hold PHI by construction). ### 7.3 Windows {#windows} Foundry does not run Windows systems in its production environment or as standard workforce endpoints. Any future introduction of Windows would require a security review and the addition of a Windows-specific hardening standard to this policy. ## 8. Network controls {#network} Network controls on sensitive segments are configured such that: - vendor defaults are modified securely: default credentials rotated, default SNMP / management strings changed, default keys regenerated; - credentials and keys are rotated when a person with knowledge of them leaves or changes role; - traffic filtering and inspection (firewall rules, cloud-provider WAF and DDoS protections, VPC flow logs) are enabled; - an up-to-date network and data-flow diagram is maintained as part of Foundry's internal architecture documentation; - AWS network controls are implemented as VPCs, subnets, security groups, and firewall rules, all managed in source, all changes following the standard PR and change-management path. ## 9. cloud environment structure {#cloud} Foundry uses AWS Organizations with separate accounts for management and for workloads. PHI-handling workloads run in a dedicated production account behind network perimeter controls. Identity is federated through Foundry's identity provider; engineers assume IAM roles in target accounts through role bindings managed in IaC. Non-production accounts hold synthetic data only; production PHI is never copied to lower environments. Exact account layout is documented in an internal infrastructure runbook and is reviewed in the [Risk Management](/docs/risk-mgmt/) cycle. ## 10. Change management for deploys {#deploy} The continuous-delivery pipeline (GitHub Actions, pinned to commit SHAs) automates change-request creation and approval gating. Deploys follow a three-step process: 1. **Create change request.** When a deploy to a controlled environment is requested, the workflow opens (or updates) a Linear change-management ticket in the production-change tracker, populated from PR metadata and user input. 2. **Obtain approval.** Slack notifies potential approvers. Approvers review the ticket, summary, components, justification, rollback plan, links to the PR and Linear issue, and approve or reject. Approvers are someone other than the author or executor. 3. **Detect risky changes, deploy, close.** The workflow proceeds only against an approved ticket. - A `terraform plan` (or `pulumi preview`) runs first to surface risky changes. - Categories that count as "risky" include changes to IAM policies, KMS key policies, bucket policies, firewall and network perimeter rules, security groups, and any deletion in a production account. These categories require explicit Security approval. - On completion (success or failure), the Linear ticket is updated with the result and closed. ## 11. Patch management {#patch} ### 11.1 Workforce endpoints {#workforce-endpoints} Foundry requires automatic security patching to be enabled on all workforce endpoints. Patch state is inspected via the MDM console; endpoints out of compliance are remediated or removed from production access until they catch up. ### 11.2 Cloud workloads {#cloud-workloads} Foundry follows a cattle-not-pets approach in the cloud: - managed serverless compute and managed functions workloads are rebuilt and redeployed on every deploy and CI run; base images and dependencies are refreshed as part of each rebuild. - A scheduled rebuild cadence, to pick up upstream security patches in base layers between deploys, is being established. - Dependency updates run on a scheduled manual review cadence, with the Foundry 7-day cooldown (`minimumReleaseAge` / `--min-age 7`) honored to reduce exposure to short-lived malicious releases; automated dependency-update tooling is being rolled out. Patches that close Critical / High findings can override the cooldown with Security Officer approval. - provider-managed services (Foundry's FHIR service, a managed relational database, etc.) are patched by the cloud provider under the shared-responsibility model; Foundry monitors provider security bulletins and applies any required customer-side actions on the SLA in [Vulnerability Management](/docs/vuln-mgmt/). ### 11.3 Agent runtime {#agent-runtime} The Nix flake for `foundry-master-agent` pins all inputs. Patches arrive as flake-input bumps in PRs that run `nix flake check --impure` and the full Rust test suite before merge. Production hosts pull the new generation via the standard deploy path; the previous generation is preserved for rollback. ## 12. Production deploy / code promotion processes {#release} To promote changes to production, a valid and approved change request is required. The change request, typically a Linear ticket linked to a merged PR, captures, at minimum: - summary of the change; - impacted components; - justification; - rollback plan; - links to the relevant pull request(s) and Linear issue(s). For code deploys, additional fields are recorded: - build job name and run ID; - deploy action (plan / apply); - deploy branch; - target environment (e.g., `foundry-prod`, `conductor-services-prod`). At least one approval from someone other than the author is required for each change request, and required CI status checks must be green at the commit being promoted. Branch protection on `main` enforces this at the GitHub level. ## 13. Emergency change {#emergency} When an emergency arises, a zero-day affecting a production dependency, a live incident requiring immediate mitigation, a recovery from an outage, and the standard change-management path cannot be followed without unacceptable delay, the emergency-change process applies. - **Notification.** The Engineering Lead and Security Officer must be notified before the change by Slack, phone, or both. Depending on the nature of the emergency, executive leadership and/or affected practices may also be informed. - **Access & execution.** The change is made using one of the documented break-glass mechanisms in [Access Control](/docs/access/): support / troubleshooting access, root-account access where strictly necessary, or local system access. Every use of a break-glass mechanism is logged. - **Post-emergency documentation.** A production-change ticket must be created within 24 hours of the emergency change, capturing: - the reason for the emergency change; - the access mechanism used; - the steps taken and the change made; - the standard-process sign-offs that would have been required, recorded retroactively. - **Prevention & improvement.** Security and Engineering jointly review the emergency change and the conditions that necessitated it. Process improvements or preventive controls are recorded as Linear issues and tracked to completion. ## 14. Roles & responsibilities {#roles} - **Security Officer**: owns this policy, approves Security-sensitive changes and auto-approval rules, and chairs the emergency-change review. - **Engineering Lead**: owns the deploy pipeline, approves engineering-side changes, and assigns the on-call rotation. - **Repository / system owners**: approve changes within their domain and ensure rollback plans are realistic. - **All engineers**: open changes via PR; never apply changes to production outside the documented process unless the emergency-change path applies. ## 15. Review & revision {#review} This policy is reviewed at least annually and whenever business, technology, or regulatory change makes it stale, including changes to the cloud organization layout, to the IaC tooling, or to the auto-approval rule set. Material revisions are approved by the Security Officer in coordination with the [Policy Management](/docs/policy-management/) process. ## 16. Related policies {#related} - [Secure SDLC & Product Security](/docs/sdlc/) - [Vulnerability Management](/docs/vuln-mgmt/) - [Threat Detection & Prevention](/docs/threat/) - [Incident Response](/docs/ir/) - [Access Control](/docs/access/) - [Endpoint & MDM](/docs/mdm/) - [System Audits & Monitoring](/docs/system-audits/) - [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/) --- _Policy · v2026.06 · Owner: Security Officer / Privacy Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Bioscope Foundry, LLC ("Foundry") is a HIPAA **business associate** to the physician practices it supports. This policy governs how Foundry meets applicable statutory, regulatory, and contractual obligations; how internal and external audits are conducted against those obligations; and how Foundry communicates with customers, partners, regulators, researchers, and the public on compliance and security matters. Internal audit reports and penetration-test findings are Foundry-internal working documents and are not distributed externally; the summary posture published in this Trust Center, together with executed BAAs, the Subprocessors list, and the standard security questionnaire, is Foundry's external compliance evidence. {{< /callout >}} ## 1. Purpose & scope {#purpose} Foundry may, from time to time, be asked to share details of its compliance, privacy, and security program with an external entity: a member practice, a prospective customer, a partner, a regulator, the press, law enforcement, or an independent researcher. External communication beyond what is already published on this Trust Center must comply with the policies and procedures below. This policy applies to all Foundry workforce members (employees, contractors, and any agent operating under Foundry's authority) and to every external inquiry for compliance evidence, breach information, vulnerability disclosures, or related materials. ## 2. Policy statements {#statements} Foundry policy requires that: \(a\) Foundry operations comply with all applicable laws, regulations, security standards, and frameworks. External audits and assessments are conducted accordingly to each applicable compliance requirement. - **HIPAA / HITECH.** Foundry complies with the Health Insurance Portability and Accountability Act of 1996 and the Health Information Technology for Economic and Clinical Health (HITECH) Act in its role as a business associate. That includes the Privacy Rule (45 CFR Part 164 Subpart E), Security Rule (Subpart C), Breach Notification Rule (Subpart D), and the Enforcement Rule (Part 160 Subpart C–E). Foundry maintains a written BAA with each covered-entity practice it supports. - **Platform-wide secure-development review.** Foundry completed a platform-wide review against its secure-development standards on 2026-02-21. Findings from that review are binding for new web application code and tracked to remediation through Vulnerability Management. - **Credential baseline.** Foundry's credential and authentication baseline reflects current authentication best practice, with passwordless and phishing-resistant MFA for privileged access. 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](/frameworks/crosswalk/). \(b\) All external communications related to compliance, security, and customer or workforce privacy must follow pre-established procedures and be handled by approved personnel. This includes, but is not limited to, completed customer security questionnaires, incident disclosures, and breach notifications. Workforce members must not respond to external requests for compliance evidence outside the process described in [§4](#requests). \(c\) Internal audit reports, penetration-test reports, red-team findings, and Corrective Action Plans (CAPs) are Foundry-internal working documents. They are _not_ distributed externally, including to member practices, prospective customers, partners, or auditors acting on behalf of another party. Foundry's external compliance evidence consists of the summary posture in this Trust Center, executed BAAs, the [Subprocessors](/legal/subprocessors/) list, and Foundry's completed standard security questionnaire. \(d\) When a covered-entity practice requests information in support of its own HIPAA risk analysis or due diligence on Foundry, Foundry provides its published Trust Center materials, executed BAA, and completed standard security questionnaire under the terms of the BAA and applicable law. Requests for underlying audit reports or pentest reports are declined; Foundry provides an attestation of completion and summary posture instead. ## 3. Compliance program management {#program} Foundry management and the security team identify and regularly review all relevant statutory, regulatory, and contractual requirements applicable to the business and to PHI handled on practices' behalf. Requirements that emerge from new business lines, new geographies, new vendor relationships, or regulatory change are added to the compliance register and assigned an owner. This policy depends on and is reinforced by: - The [Vendor & Third-Party Risk](/docs/vendor/) policy, which specifies contractual requirements for partners, vendors, subcontractor business associates, and subprocessors, and the BAA flow-down where PHI is involved. - The [Policy Management](/docs/policy-management/) policy, which governs how this and every other Foundry policy is approved, communicated, and retired. - The [Risk Management](/docs/risk-mgmt/) policy, which governs the risk analysis required by 45 CFR §164.308(a)(1)(ii)(A). - The [System Audits & Monitoring](/docs/system-audits/) policy, which governs the logging and audit record retention referenced below. ## 4. External requests for compliance materials {#requests} Foundry's public compliance materials, this Trust Center, all published policies, the standard [Business Associate Agreement](/legal/business-associate-agreement/), and the [Subprocessors](/legal/subprocessors/) list, require no request and no NDA. They are the primary source of external compliance evidence about Foundry. For additional materials that are not published (for example, a completed standard security questionnaire, attestations of specific control implementations, or a scoped statement of a completed audit), the following process applies: 1. A request is sent by email to . The request should identify the requesting party, the materials sought, the intended use, and any required timelines. 2. The request is logged in Foundry's internal compliance request tracker. 3. The Foundry security team confirms whether a current NDA is in place. If not, Foundry sends its standard NDA for execution before any non-public material is shared. 4. The Security Officer or Privacy Officer approves or rejects the request. Requests for internal audit reports, penetration-test reports, red-team findings, or other Foundry-internal assessment artifacts are declined; a summary attestation may be provided in their place at Foundry's discretion. 5. If approved, Foundry transmits the requested materials through a secure channel and closes the request. Breach-related external communications are governed by the [Breach Notification](/docs/breach/) policy and follow the timelines required by 45 CFR §164.410 and the practice's BAA. ## 5. Independent audits and assessments {#external-audits} Prior to engaging an independent audit or assessment firm, whether for a HIPAA security risk analysis, a penetration test, an ISO readiness assessment, or any other independent review, Foundry shall: - Outline the audit scope, the auditor's responsibility, authority, and accountability, and the deliverables expected; - Select a firm independent of other organizational operations, with no conflict of interest with Foundry's IT or platform vendors; - Verify the technical competence of the firm's staff for the scope being assessed (HIPAA, cloud security, application security, AI/ML systems, etc.); - Require the firm's adherence to applicable codes of professional ethics (AICPA, ISACA, (ISC)², or equivalent); - Obtain a signed HIPAA Business Associate Agreement before the auditor may access PHI or systems that handle PHI; - Assign internal responsibility for supervising the engagement and reviewing the findings. Whenever possible, a third-party audit or assessment vendor should not also be providing Foundry IT or operational services for the systems in scope; vendors providing IT services should not audit their own services. This is a separation-of-duties requirement that follows from 45 CFR §164.308(a)(3). The output of an independent audit is reviewed by the Security Officer and tracked to remediation through the [Vulnerability Management](/docs/vuln-mgmt/) and [Risk Management](/docs/risk-mgmt/) processes. Findings affecting PHI safeguards are reported to affected practices to the extent required by the BAA; the underlying report is retained by Foundry and is not distributed. ## 6. Contacts for external communications {#contacts} Direct external communication requests to the contact below that matches the inquiry. Workforce members receiving an unsolicited external request that does not match one of these channels should forward it to the Security Officer rather than respond directly. - **Security disclosures, vulnerability reports, and incident reporting**: - **Privacy concerns, including reports of HIPAA Privacy Rule violations**: (see [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/)) - **Compliance materials, BAA requests, and completed security questionnaires**: - **Press and media inquiries**: - **Law enforcement requests**: routed to . Foundry responds to validly issued legal process consistent with HIPAA and its BAA obligations. The covered-entity practice is notified to the extent permitted by law. ## 7. Coordinated vulnerability disclosure {#disclosure} Foundry welcomes responsible security research against its public surfaces and authenticated platform. Researchers acting in good faith are protected under the [Researcher Safe Harbor](#safe-harbor) in Appendix A. - **Reporting channel.** Vulnerability reports are submitted to . Reports should include reproduction steps, affected components, and the researcher's preferred attribution. - **Acknowledgement target.** Foundry acknowledges receipt within 3 business days. - **Coordinated disclosure window.** Foundry follows a coordinated disclosure model with a 90-day default window from acknowledgement to public disclosure, extendable by mutual agreement where remediation requires upstream-vendor coordination. Vulnerabilities posing imminent risk to PHI may be disclosed to affected practices and regulators ahead of public disclosure consistent with the [Breach Notification](/docs/breach/) policy. - **Out of scope.** Testing must not exfiltrate or modify PHI, must not degrade availability for legitimate users, and must not target third-party subprocessors directly. Findings touching subprocessor surfaces are routed through Foundry to the subprocessor. ## 8. Continuous compliance monitoring {#monitoring} The status of Foundry's compliance posture is tracked internally through a combination of: - Cloud-provider security and compliance tooling (cloud security posture management, AWS CloudTrail, IAM access analysis, and provider access logging) configured for the environments that host PHI; - Static and dynamic application security testing in the CI pipeline (see [Secure SDLC](/docs/sdlc/)); - Dependency and supply-chain scanning, including the supply-chain pinning rules described in [Configuration & Change Management](/docs/ccm/): GitHub Actions pinned to commit SHAs, production container images pinned to explicit version tags (content-digest pinning is a near-term roadmap item), and a 7-day cooldown on new npm release adoption; - Continuous monitoring of subprocessors per [Vendor & Third-Party Risk](/docs/vendor/); - Quarterly internal control review against the HIPAA Security Rule. Material gaps are recorded on the internal compliance dashboard and routed into the [Risk Management](/docs/risk-mgmt/) process. Gaps that affect PHI safeguards are escalated to the Security Officer within 24 hours of detection. ## 9. Roles & responsibilities {#roles} - **Security Officer** (HIPAA Security Rule §164.308(a)(2)): owns this policy, approves or rejects requests for non-public compliance materials, supervises external audit engagements, and authorizes coordinated vulnerability disclosure timelines. - **Privacy Officer** (HIPAA Privacy Rule §164.530(a)(1)): co-approves requests touching privacy artifacts, handles external privacy inquiries, and coordinates with the Security Officer on breach-related external communications. - **Legal**: owns NDA execution, BAA execution, and the response to legal process and law-enforcement requests. - **Workforce members**: route external requests to the appropriate contact above; do not respond to external requests for compliance evidence outside this policy. ## 10. Review & revision {#review} This policy is reviewed at least annually and whenever business, technology, or regulatory change makes it stale, including changes to Foundry's role under HIPAA, adoption of a new compliance framework, or material change to subprocessor or audit-firm relationships. Material revisions are approved by the Security Officer in coordination with the [Policy Management](/docs/policy-management/) process and recorded in the policy changelog. ## 11. Related policies {#related} - [Security program overview](/docs/overview/) - [Vendor & Third-Party Risk](/docs/vendor/) - [Incident response](/docs/ir/) - [Breach notification](/docs/breach/) - [Vulnerability management](/docs/vuln-mgmt/) - [Risk management](/docs/risk-mgmt/) - [System audits & monitoring](/docs/system-audits/) - [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/) - [Subprocessors](/legal/subprocessors/) - [Business Associate Agreement](/legal/business-associate-agreement/) ## Appendix A: Researcher Safe Harbor {#safe-harbor} Bioscope Foundry values the work of independent security researchers. This Safe Harbor sets out the conditions under which good-faith security research against Foundry's public and authenticated surfaces will not be pursued as a policy violation, a contract breach, or an unlawful act by Foundry. ### A.1 Authorized activity {#a1-authorized-activity} Research is authorized when the researcher: - Acts in good faith to identify and report a security or privacy vulnerability in a Foundry-operated system; - Makes a good-faith effort to avoid privacy violations, degradation of service, and disruption to Foundry, its member practices, patients, or workforce; - Stops testing and reports the finding immediately upon encountering PHI or any other sensitive personal data; - Does not exfiltrate, retain, alter, or destroy PHI or any other data belonging to Foundry, a member practice, a patient, or a workforce member; - Does not publicly disclose the vulnerability before Foundry has had a reasonable opportunity to remediate it, consistent with the coordinated-disclosure window in §7; - Submits the finding to with sufficient detail for Foundry to reproduce and evaluate it. ### A.2 In-scope systems {#a2-in-scope-systems} - Public Foundry web properties operated under `bioscopefoundry.com` and its subdomains; - The authenticated Foundry operating platform (subject to A.3 rules of engagement); - Foundry-published mobile or desktop clients, where applicable; - Any Foundry-operated API whose documentation identifies it as public. ### A.3 Rules of engagement {#a3-rules-of-engagement} - **No PHI.** Do not attempt to access, modify, exfiltrate, or destroy PHI. If PHI is encountered, stop, do not save it, and report the finding. - **No degradation.** Do not perform automated high-volume testing, denial-of-service testing, resource-exhaustion tests, or social-engineering attacks against Foundry workforce, practices, patients, or subprocessors. - **No physical or supply-chain intrusion.** Physical intrusion, tailgating, dumpster diving, mail interception, and supply-chain compromise are out of scope. - **Use test accounts.** Where an authenticated surface is in scope, use accounts you own or accounts Foundry has provisioned to you. - **No third-party pivots.** Do not directly test Foundry's subprocessors or upstream vendors. Route findings that involve a subprocessor through . - **Local law.** Research must comply with all applicable laws in the researcher's jurisdiction and in the jurisdiction of the affected system. ### A.4 Foundry's commitments {#a4-foundrys-commitments} If a researcher's activity complies with this Safe Harbor, Foundry will: - **Not initiate legal action.** Foundry will not initiate or support civil or criminal legal action against the researcher for the authorized activity, including under the Computer Fraud and Abuse Act (18 U.S.C. § 1030), the Digital Millennium Copyright Act's anti-circumvention provisions (17 U.S.C. § 1201), state computer-crime statutes, or applicable non-U.S. equivalents. - **Consider the activity authorized.** Foundry considers the authorized activity to be conducted with Foundry's authorization for the purposes of any anti-circumvention or computer-access statute. - **Not report to law enforcement.** Foundry will not refer the researcher to law enforcement for authorized activity conducted under this Safe Harbor. - **Communicate.** Foundry will acknowledge receipt within 3 business days, provide status updates during triage, and credit the researcher in any public disclosure at the researcher's option. - **Advocate for good-faith research.** Where a third party (for example, a subprocessor whose surface was inadvertently touched during Foundry-scoped testing) considers action, Foundry will affirm to that party that the activity was authorized research and request that Safe Harbor be respected. ### A.5 What Safe Harbor does not cover {#a5-what-safe-harbor-does-not-cover} - Activity outside the scope and rules of engagement in A.2 and A.3; - Activity conducted after Foundry has, in writing, revoked authorization for the researcher; - Extortion, blackmail, or any demand for compensation as a condition of disclosure; - Retention, sale, or public disclosure of Foundry, practice, patient, or workforce data; - Activity that violates the law of a jurisdiction in which the researcher or the affected system is located; - Activity Foundry cannot lawfully authorize (for example, testing against a subprocessor's systems that Foundry does not own). ### A.6 Interpretation {#a6-interpretation} If a researcher is uncertain whether a specific activity is within scope, they may contact before conducting it. Foundry will interpret this Safe Harbor generously in favor of good-faith researchers. Nothing in this Safe Harbor waives obligations Foundry owes to member practices under its BAAs or to regulators under HIPAA and other applicable law; where a specific action would put Foundry in breach of those obligations, Foundry will notify the researcher and coordinate a path forward. --- _Policy · v2026.06 · Owner: Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} This policy sets the requirements and controls Bioscope Foundry uses to manage data across its lifecycle, creation or acquisition, classification, storage, backup, retention, and disposal. Protected health information (PHI) that Foundry handles for a physician practice lives only inside Foundry's clinical data plane: a Foundry-operated clinical workflow database (the source of truth for clinical workflow, appointments, tasks, encounter state, messaging) and a private FHIR R4 service that serves clinical resources. Both stores are Foundry-operated software running on Foundry's cloud infrastructure subprocessor under the Business Associate Agreement (BAA) between Foundry and the practice. Bioscope Foundry is a HIPAA **business associate**, not a covered entity; the practice remains the covered entity. {{< /callout >}} ## 1. Purpose & scope {#purpose} This policy outlines the requirements and controls Bioscope Foundry has implemented to manage the end-to-end data lifecycle, from creation or acquisition through retention and deletion, across the MSO operating platform, internal business systems, and the public marketing site. It also defines how Foundry creates and maintains retrievable exact copies of electronic PHI (ePHI) and other critical business data, so that information remains available for the physician practices we support and for Foundry's own operations in the event of a disruption. Data backup is part of Foundry's day-to-day operations. To protect the confidentiality, integrity, and availability of ePHI, and of customer and business data, Foundry runs scheduled backups so data remains available when needed and recoverable in case of a disaster. PHI backups are operated within HIPAA-eligible cloud provider services covered by Foundry's BAA with the provider. ## 2. Policy statements {#statements} Foundry policy requires that: \(a\) Data is classified at time of creation or acquisition according to the [Foundry data classification model](#classification) and labeled or tagged where the storage system supports it. \(b\) An up-to-date inventory and data-flow map is maintained for all critical data, including the flow of PHI into and out of Foundry's FHIR service. \(c\) Business data is stored or replicated in a company-controlled repository. Data on end-user computing devices is treated as transient and must be backed to an approved company repository (for example, the managed document store) for any business record. \(d\) Data is backed up according to its level in the Foundry data classification. \(e\) Data backups are validated for integrity. \(f\) Retention periods are defined, kept to the minimum required by business need, and aligned with regulatory and contractual obligations. In particular: - PHI handled on behalf of a physician practice is retained and disposed of as required under HIPAA and the practice's BAA, with a six-year minimum for required HIPAA documentation; - Data and records belonging to member practices are retained per the Master Services Agreement and any specific contractual addenda; - Workforce, financial, and tax records are retained per applicable Delaware and U.S. federal requirements. \(g\) By default, security documentation and audit trails are retained for a minimum of six years, unless the data classification, a specific regulation, or a contractual agreement requires a longer period. \(h\) PHI is never copied to local disk, agent worktrees, prompts, memory, generated documents, or logs. PHI lives only in Foundry's FHIR service (R4); audit records refer to PHI by FHIR resource identifier rather than by content. ## 3. Controls & procedures {#controls} ### 3.1 Data classification model {#classification} Foundry defines four classifications of data. Examples are illustrative, not exhaustive. #### PHI Protected Health Information that Foundry creates, receives, maintains, or transmits on behalf of a physician practice. Strictest controls apply. - Patient demographics, encounters, clinical notes, medications, lab orders and results, and related FHIR resources; - FHIR audit events that reference patient resources; - Communications metadata that ties an individual to a clinical encounter. PHI is stored and processed only within Foundry's FHIR service (R4). External disclosure is permitted only as authorized by the BAA, by the practice, or by law. #### Confidential Information that represents Foundry's or a practice's business secrets, or is otherwise of significant value to the company or its members. Unauthorized disclosure may disrupt operations and erode trust. Disclosure requires an NDA and management approval. - Physician contracts, MSAs, BAAs, and addenda (executed and in-flight); - Financial records, banking details, and payment-processor data; - Workforce / HR data and applicant data outside what Foundry's HRIS exposes; - Pre-announcement business plans, fundraising materials, and product strategy; - Non-production secrets, access keys, private certificates, and related material; - Non-production security audit logs, incident records, security architecture documents, and internal audit reports. #### Internal Non-sensitive business data used for day-to-day operations. Unauthorized disclosure may be undesirable but is not likely to cause material harm. Disclosure outside Foundry generally requires management approval; an NDA is usually required and may be waived case by case. - Internal documentation, runbooks, and standard operating procedures; - Policies and procedures (this Trust Center is the public-facing extract); - Product plans, design documents, and engineering specifications; - Most source code in Foundry's GitHub organization (`bioscope-foundry`). #### Public Information intended for public consumption. Public data is not confidential. Foundry protects its integrity and availability. - Content on [bioscopefoundry.com](https://bioscopefoundry.com) and other Foundry-owned marketing surfaces; - Post-announcement news, press, and brand assets; - Public product documentation; - This Trust Center. ### 3.2 Data handling requirements matrix {#handling} Requirements for data handling, encryption, retention, access, and recovery, are defined according to Foundry's data classifications. | Data | Labeling or tagging | Segregated storage | Endpoint storage | Encrypt at rest | Encrypt in transit | Encrypt in use | Controlled access | Monitoring | Destruction at disposal | Retention period | Backup & recovery | | ---------------- | ----------------------------- | ---------------------------------------------------------------------- | ----------------------------------------- | ----------------------------------------- | ------------------- | -------------- | ---------------------------------------------------------------------------------------------------- | ---------------------------------------------- | ------------------------------------------------------------------ | --------------------------------------------------------------------------------------------- | ----------------- | | **PHI** | Required (FHIR resource type) | Required (Foundry's clinical data plane, segregated cloud environment) | Prohibited | Required (AES-256; CMEK available on BAA) | Required (TLS 1.2+) | Required | Blocked by default; least-privilege, role-based, audit-logged access via the conductor platform only | Required (cloud audit logs; FHIR audit events) | Required (cryptographic erasure or BAA-defined return/destruction) | Six-year minimum for required HIPAA documentation; longer where the practice or law requires† | Required | | **Confidential** | Required | N/R | Allowed (encrypted endpoint, MDM-managed) | Required | Required | Required | Need-to-know | Required | Required | Six years for official documentation; otherwise per business or contractual need | Required | | **Internal** | Required | N/R | Allowed (encrypted endpoint, MDM-managed) | N/R | N/R | N/R | Workforce and contractors (read); data owners and authorized individuals (write) | N/R | N/R | Six years for official documentation; otherwise per business need | Optional | | **Public** | N/R | N/R | Allowed | N/R | N/R | N/R | Everyone (read); data owners and authorized individuals (write) | N/R | N/R | Per business need | Optional | N/R = Not required. † Practice-owned PHI is retained for as long as the practice remains a Foundry member, or as required by HIPAA and applicable state record-retention law, whichever is longer. On offboarding, PHI is returned or destroyed per the BAA. Symmetric encryption uses AES-256. Hashing for integrity uses SHA-256 or SHA-3 family algorithms. Password hashing, where applicable to Foundry-issued credentials, uses argon2id; Foundry is largely passwordless in practice (see [Access Control](/docs/access/)). ### 3.3 Data inventory and lifecycle management {#inventory} Foundry maintains a data inventory across its cloud-based infrastructure and core SaaS, including: - FHIR datasets and stores (PHI); - Amazon S3 object storage buckets, Amazon RDS datastores, and AWS Secrets Manager; - Cloudflare Workers and R2 storage (marketing surfaces); - GitHub source-code repositories in the `bioscope-foundry` organization; - the identity provider (Drive, Gmail, Calendar) for internal records; - Operational SaaS systems used by the back office (CRM, billing, e-signature, HRIS, ticketing). The inventory captures owner, classification, storage location, and data flows. PHI flows are tracked separately as part of the BAA evidence package and are referenced in the [HIPAA Security Rule mapping](/frameworks/hipaa/). #### Object lifecycle and storage classes For non-PHI bulk storage in the cloud managed object storage, Foundry uses object lifecycle policies to transition data between storage classes (Standard, Nearline, Coldline, Archive) based on age and access pattern. Lifecycle policies also age out backups and historical artifacts on a schedule consistent with the retention rules in this policy. PHI in the FHIR store is not subject to discretionary tiering by Foundry. Versioning and cloud audit logs preserve the change history that HIPAA requires. #### Other business data Internal and confidential business records, product plans, financial models, decisions, presentations, contracts, are stored in managed repositories, not on workforce laptops: - **Source code & reviews**: GitHub (`bioscope-foundry`); - **Tickets & planning**: Linear; - **Documents & spreadsheets**: the managed document store; - **HR & payroll**: the HRIS / payroll platform; - **Contracts & e-signature**: the e-signature system; - **Accounting & AP/AR**: the accounting / bill-pay platform. Confidential business documents are stored in encrypted form with access controlled on a need-to-know basis. #### Transient data Foundry does not use transient storage for PHI. Where transient processing is required for non-PHI workloads (for example, intermediate computation in a worker), the data is purged immediately after use and the worker tier is configured so it cannot persist outside its sandbox. ### 3.4 Backup and recovery {#backup} #### PHI and clinical platform data PHI is stored in Foundry's clinical data plane on Foundry's cloud infrastructure subprocessor: the clinical workflow database (a provider-managed relational service) and the private, Foundry-operated FHIR R4 service (running as a container workload on the provider's managed compute). Foundry relies on the provider's HIPAA-eligible managed services for durability and runs scheduled backups consistent with the BAA between Foundry and the provider. Data is replicated within the provider's regional infrastructure; backups are encrypted under the same customer-managed KMS keys as live data. Customer-managed encryption keys (CMEK) are available on request via the practice's BAA. Recovery is exercised on a defined cadence as part of the [BCDR program](/docs/bcdr/). Practices may export their FHIR data through the conductor platform; standard API usage applies. #### Source code Foundry source code lives in GitHub. Repositories in the `bioscope-foundry` organization are mirrored to a Foundry-controlled cloud project on a recurring schedule. In the event of catastrophic loss at GitHub, source can be restored from the mirror. Git's commit log preserves a full change history independent of the host. #### Business records and documents Each data owner is responsible for moving working files off their local device to the appropriate location in the managed document store (or the system of record above). Local backups of non-PHI personal productivity material are self-managed by the device owner, are restricted to encrypted, password-protected media, and may never include PHI or other Critical data. Confidential business records are stored in encrypted form with access controls on a need-to-know basis. ### 3.5 Data deletion and offboarding {#deletion} #### For member practices Foundry's Master Services Agreement supports a 90-day clean offboarding for member practices. On voluntary termination: - The practice may export its FHIR data through the conductor platform during a defined offboarding window; - At the practice's election in the BAA, Foundry returns the PHI to the practice or destroys it (cryptographic erasure of CMEK-protected data, or BAA-defined destruction for provider-managed key environments); - Non-PHI operational records (configurations, integrations, account metadata) are removed from active systems and aged out of backups on the standard backup schedule. If a practice's account is involuntarily suspended for non-payment or terms-of-service violations, there is a grace period during which the account is inaccessible but recoverable. After the grace period, the account is closed and data is deleted in line with the BAA, except where law requires retention. #### For Foundry workforce When a workforce member departs, their account is deactivated, devices are wiped through MDM, and access to PHI-bearing systems is revoked through identity provider workflows. Personal work product moves to a Foundry-controlled location before access is removed. See [HR & personnel security](/docs/hr-personnel-security/). #### Foundry's covered-entity status Foundry is **not a covered entity** and does not provide healthcare services directly to patients. If Foundry's posture were to change, this policy would be updated to incorporate the patient-record retention requirements that apply to providers, and the change would be communicated under [Policy management](/docs/policy-management/). ## 4. Roles & responsibilities {#roles} - **Security Officer**: owns this policy, the data classification model, and the lifecycle / retention defaults. - **Privacy Officer**: owns the BAA evidence package and the interface to member practices on PHI handling. - **Engineering leads**: implement classification, retention, and deletion in the platforms they own; review FHIR audit data and lifecycle policies. - **Data owners**: keep records inside Foundry-controlled repositories, tag confidential material, and request retention exceptions in writing. - **Workforce members**: follow handling requirements for the classifications above and never copy PHI to local disk, prompts, or generated documents. ## 5. Review & revision {#review} This policy is reviewed at least annually and whenever business, technology, or regulatory change makes it stale. Material revisions are approved by the Security Officer in coordination with the [Policy Management](/docs/policy-management/) process. ## 6. Related policies {#related} - [Data protection](/docs/data-protection/) - [Privacy](/docs/privacy/) - [Access control](/docs/access/) - [Business continuity & disaster recovery](/docs/bcdr/) - [System audits & monitoring](/docs/system-audits/) - [Vendor & third-party risk](/docs/vendor/) - [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/) - [Business Associate Agreement](/legal/business-associate-agreement/) --- _Policy · v2026.06 · Owner: Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Bioscope Foundry protects the confidentiality, integrity, and availability of the data it handles for member physician practices. As a HIPAA **business associate**, Foundry holds PHI only inside Foundry's clinical data plane, a Foundry-operated clinical workflow database and a private FHIR R4 service, both running on Amazon Web Services (Foundry's cloud infrastructure subprocessor). All PHI is encrypted in transit and at rest, accessed under least privilege, and audit-logged. This policy defines the controls that production systems must follow when they create, receive, store, or transmit data on Foundry's platform. {{< /callout >}} ## 1. Purpose & scope {#purpose} Bioscope Foundry takes the confidentiality and integrity of member-practice and patient data seriously. As stewards for our member practices, we protect data from unauthorized access and keep it available when needed. This policy defines the controls that drive Foundry's procedures and technical safeguards. It applies to **production systems** that create, receive, store, or transmit data on behalf of Foundry or its member practices, including the `conductor` platform (services + web + shared packages in the cloud), the `foundry-master-agent` orchestration spine, the Cloudflare-hosted marketing surfaces, and internal business systems handling Confidential data. ## 2. Policy statements {#statements} Foundry policy requires that: \(a\) Data is handled and protected according to its classification (see [Data Management: classification model](/docs/data-mgmt/#classification)) and using approved encryption standards. \(b\) Data of the same classification is stored together where possible; sensitive and non-sensitive data are not mixed in a shared repository. Security controls, authentication, authorization, encryption, and auditing, are applied at the highest classification present in each repository. \(c\) Workforce members do not have direct administrative access to production data, including PHI, during normal business operations. Time-bounded, audited break-glass access is permitted only for incident response, manual disaster recovery, or other emergency operations approved by the Security Officer. \(d\) All production systems disable services that are not required to achieve the business purpose of the system. \(e\) All access to production systems and to PHI is logged. PHI reads and writes are logged through AWS CloudTrail and FHIR audit events, retained for a minimum of six years, with records that reference resources by identifier rather than by PHI content. \(f\) Production systems have security monitoring enabled, including activity monitoring, file integrity monitoring where applicable, vulnerability scanning, and malware / posture detection through AWS HIPAA-eligible managed services. \(g\) PHI never leaves Foundry's FHIR service boundary except through approved, audited interfaces. PHI is not written to local disk, agent worktrees, prompts, memory, generated documents, or logs. ## 3. Controls & procedures {#controls} ### 3.1 Data protection implementation {#data-protection-implementation} Data is classified and handled according to the [Data Management](/docs/data-mgmt/) policy. Where storage systems support it, Critical and Confidential data is tagged at creation; classification may also be inferred from the repository (for example, FHIR resources inside Foundry's FHIR service perimeter are PHI by location; source code in `bioscope-foundry/*` is Internal by default). Critical and Confidential data is always stored and transmitted using approved encryption standards. Production systems that process or store sensitive data follow the provisioning, configuration, change management, and patching standards defined in [Configuration & Change Management](/docs/ccm/). ### 3.2 Customer / production data protection {#customer-production-data-protection} The Foundry platform is hosted primarily on Amazon Web Services, in a U.S. region (us-east-2, Ohio). Clinical workloads (the workflow database and the FHIR service) run in a segregated AWS account with restricted ingress and AWS KMS customer-managed keys; the marketing site and tooling surfaces run on Cloudflare Workers (Static Assets with SPA fallback) with no PHI reach. All Foundry workforce members, systems, and resources adhere to the following standards to reduce the risk of compromise of production data: 1. Implement and review controls designed to protect production data from improper alteration or destruction (versioning, write-ahead logs, and BAA-bound replication). 2. Ensure Confidential and PHI data is stored in a manner that supports access logging and automated monitoring for potential security incidents. 3. Ensure each member practice's data is logically segmented and accessible only to authorized workforce of that practice (and to Foundry workforce acting under the BAA). 4. Store all production data at rest on encrypted volumes using keys managed by AWS KMS or, where the practice elects under the BAA, customer-managed encryption keys (CMEK). 5. Protect volume encryption keys and the systems that generate them with access controls so that key material is only accessible by privileged service accounts; human access is brokered through identity-aware proxy and audit-logged. 6. Use approved cipher algorithms, key strengths, and key management processes as defined in [Encryption Key Management](#keys). #### Access Foundry workforce access to production is governed by an approval process and is disabled by default. Time-bounded access can be granted to a designated workforce member for a defined task; the grant is recorded, the session is logged, and access is automatically revoked at expiry. The Security Officer reviews each request individually. PHI reads and writes from within Foundry's operating platform are mediated by the `conductor` service tier and are always audit-logged through AWS CloudTrail and FHIR audit events. #### Separation Practice data is logically separated at the FHIR-store and datastore level using practice-scoped identifiers. Separation is enforced at the API layer: the client authenticates against a specific practice context, the practice identifier is included in the access token, and all FHIR / datastore queries are scoped to that identifier. Tier-4 sandboxed workers (Moltworkers) run on a separate sandboxed network and **cannot** hold PHI, practice-private data, or clinic-scoped memory. #### Backup and recovery Backup and recovery controls are defined in [Data Management: Backup and Recovery](/docs/data-mgmt/#backup). PHI is backed up within AWS HIPAA-eligible services and is encrypted under the same controls as live data. #### Monitoring Foundry uses logging, AWS CloudTrail, and monitoring provided by AWS to observe the platform. If a system alarm fires, on-call personnel are notified by chat and email and escalate per the [Incident Response](/docs/ir/) runbook. Foundry also operates a security agent that monitors workforce endpoints and platform services, generates alerts on suspicious activity, and reports vulnerability findings to a centralized console. ### 3.3 Protecting data at rest {#at-rest} #### Encryption of data at rest All databases, FHIR stores, object stores, and file systems containing sensitive Foundry data are encrypted using modern cryptographic standards: - **AES-256** symmetric encryption for all data at rest. - Separate encryption keys per storage type and environment. - Keys managed through AWS KMS with automatic rotation. - Annual automatic rotation for the AWS KMS keys; rotation cadence may be tightened by request via the BAA. - **Customer-managed encryption keys (CMEK)** available to member practices on request through the BAA for PHI workloads on Foundry's FHIR service. - **Cryptographic hashing** using SHA-256 or SHA-3 family algorithms for integrity. - **Argon2id** for password hashing where Foundry issues a password-style credential (Foundry is largely passwordless; see [Access Control](/docs/access/)). - Envelope encryption supported where an additional control layer is appropriate. #### Post-quantum cryptography readiness - Foundry monitors developments in post-quantum cryptography standards (NIST PQC standardization). - A migration plan for post-quantum resistant algorithms will be developed as standards mature and as AWS HIPAA-eligible services adopt them. #### Local disk / volume encryption {#local-disk-volume-encryption} Endpoint encryption follows defined practices for macOS (FileVault) and Linux. Workforce devices are MDM-managed, encrypted at rest, and configured so PHI cannot land on disk; see [Endpoint & MDM](/docs/mdm/). ### 3.4 Protecting data in transit {#in-transit} 1. All external data transmission is encrypted end-to-end. Public-facing TLS termination is managed by AWS Certificate Manager (on the AWS load balancer), Cloudflare-managed certificates (for marketing surfaces), and Let's Encrypt where appropriate. 2. Transmission encryption keys and the systems that generate them are protected by access controls; key material is accessible only to privileged service accounts. 3. Transmission encryption uses modern cryptographic standards: - **TLS 1.3** preferred, **TLS 1.2 minimum** for HTTPS connections. - **RSA 3072-bit minimum** or **ECDSA with P-256 or stronger** curves. - **AES-256-GCM** for symmetric encryption (AES-128-GCM minimum). - Forward secrecy (PFS) required on all TLS connections. - Certificate transparency logging for public certificates. 4. TLS certificates are managed with appropriate lifecycles: - Certificates renew automatically (typically 90-day validity for public certificates). - Private keys are rotated when certificates are renewed. - Certificates nearing expiration trigger automated alerts. - Revocation is performed immediately upon suspected compromise. 5. For all Foundry APIs, including the `conductor` services API, the Atlas API in `foundry-master-agent`, and internal service-to-service traffic, Foundry enforces authentication, authorization, and auditing: - API authentication uses OAuth 2.0 / OpenID Connect, federated to the workforce identity provider for workforce and physician access. - API keys and tokens transit only over TLS and are stored in AWS Secrets Manager. - Rate limiting and throttling protect APIs from abuse. - All API calls touching PHI are logged with request and response metadata (identifiers, not content). 6. System logs of production data transmissions are retained per [Data Management](/docs/data-mgmt/). #### Encryption of data in transit All internet connections to Foundry-controlled endpoints are encrypted and authenticated using modern protocols and ciphers: - **TLS 1.3** preferred, **TLS 1.2 minimum** with strong cipher suites. - Key exchange using **ECDHE** with **P-256** or stronger curves (P-384, P-521). - Symmetric encryption using **AES-256-GCM** (preferred) or AES-128-GCM minimum. - **TLS 1.0 and TLS 1.1 are prohibited.** - Forward secrecy (PFS) required. - Certificate validation enforced; pinning applied where it is the right control. ### 3.5 Protecting data in use {#in-use} "Data in use" refers to active data being processed by systems and applications, typically held non-persistently in RAM, CPU caches, or registers. Protection of data in use depends on application-layer controls and system access controls; see [Secure SDLC](/docs/sdlc/) and [Access Control](/docs/access/). Foundry applications implement logical practice-level data segregation to protect data in a multi-tenant deployment. The `foundry-master-agent` tiering model further enforces this in agentic workflows: - **Tier-3 clinical agents** are clinic-scoped and PHI-eligible; they operate inside the same authorization boundary as the `conductor` platform. - **Tier-4 sandboxed workers (Moltworkers)** run on a separate sandboxed_public network and **cannot** hold PHI, `:private` memory, or clinic-scoped data. - **Beacon Layer** redaction sits between PHI-bearing systems and physician-facing dashboards so that sanitized insights, not raw PHI, surface to humans. ### 3.6 Encryption key management {#keys} Foundry uses AWS KMS for encryption-key management. - KMS keys are unique to Foundry environments and services. - KMS keys rotate automatically on a defined schedule (annually by default; shorter intervals available on request via the BAA). - Customer-managed encryption keys (CMEK) are available to member practices for PHI workloads. CMEK enables practice-scoped cryptographic erasure on offboarding. - Secrets that grant access to PHI systems are stored in AWS Secrets Manager and GitHub Actions Secrets; plaintext credentials are never committed to source. ### 3.7 Certificate management {#certs} Foundry uses AWS Certificate Manager, Cloudflare-managed certificates, and Let's Encrypt for the surfaces each is responsible for. - Certificates renew automatically. - The Security team monitors certificates for expiration, potential compromise, and validity. Revocation is invoked when a certificate is no longer needed or when compromise is suspected. ### 3.8 Data integrity protection {#integrity} Where the storage system supports it, Foundry enables versioning and lifecycle controls so direct edits and deletes cannot silently overwrite or destroy data. This guards against accidental loss, malicious overwrite, and ransomware. On AWS, S3 Object Versioning and lifecycle policies preserve prior versions for a defined retention window; on the FHIR service, resource history is maintained per FHIR semantics: - All edits create a new version; prior versions are preserved for a lifecycle-defined period. - Deletes are tombstoned so objects can be recovered within the retention window before final removal. - Data is archived to a separate AWS account and / or region per BCDR requirements. All access to PHI is authenticated and audited through infrastructure, system, and application logs. FHIR audit events reference resources by identifier, not by content; see [System Audits & Monitoring](/docs/system-audits/). ## 4. Roles & responsibilities {#roles} - **Security Officer**: owns this policy and the encryption / key-management baseline. - **Privacy Officer**: owns the PHI protection posture under the BAA, including CMEK and key-rotation options. - **Engineering leads**: implement the at-rest, in-transit, and in-use controls in the systems they own. - **Workforce members**: follow the access and handling rules above; never copy PHI off the FHIR boundary. ## 5. Review & revision {#review} This policy is reviewed at least annually and whenever cryptographic standards, business needs, or regulatory expectations change materially. Material revisions are approved by the Security Officer in coordination with [Policy Management](/docs/policy-management/). ## 6. Related policies {#related} - [Data management](/docs/data-mgmt/) - [Privacy](/docs/privacy/) - [Access control](/docs/access/) - [Configuration & change management](/docs/ccm/) - [Secure SDLC](/docs/sdlc/) - [System audits & monitoring](/docs/system-audits/) - [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/) --- _Policy · v2026.06 · Owner: Head of Operations & Security Officer (joint) · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="warning" >}} **No PHI is stored or processed at any Foundry physical office.** Protected health information lives only in Foundry's FHIR service (R4), under HIPAA-eligible cloud infrastructure controls. Because no PHI is present at Foundry's premises, the HIPAA Security Rule's physical-safeguard requirements (45 CFR § 164.310) apply primarily to the cloud data centers operated by our cloud infrastructure providers, and, to a limited extent, to the workforce devices held at Foundry's Carmel coordination office. {{< /callout >}} ## 1. Purpose & scope {#purpose} This policy governs the physical security of Foundry's operating environments: the Carmel, Indiana coordination office; the cloud data centers operated by Foundry's HIPAA-eligible infrastructure providers; and the workforce home offices from which most of Foundry's work is performed. It addresses the HIPAA Security Rule's facility-access controls, workstation use, and workstation security standards (45 CFR § 164.310(a)–(c)). 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](/frameworks/crosswalk/). Foundry is a remote-first MSO. The Carmel office is a coordination and team space, not a clinical or production facility. PHI is stored and processed only in Foundry's FHIR service; physical safeguards therefore concentrate on the cloud providers' data centers and on workforce devices. ## 2. Policy statements {#statements} Foundry policy requires that: 1. No PHI or other Restricted data (per [Data Management](/docs/data-mgmt/)) is stored, printed, displayed on a fixed monitor in a public-visible way, or otherwise maintained at any Foundry physical office. 2. Physical office security at the Carmel office is provided by the building / co-tenancy facility manager in accordance with their published security procedures. Foundry complies with and supplements those procedures. 3. Physical security of production data centers is provided by Foundry's cloud-infrastructure subprocessor, Amazon Web Services (AWS), under its own independently attested controls and under the BAA Foundry holds with AWS. 4. Every workforce member is responsible for reporting physical security incidents, unauthorized access attempts, suspicious activity, lost or stolen devices, missing access cards, to Foundry Security. 5. Workstations are locked when unattended, taken home from the Carmel office at the end of the work day, and never left in vehicles or other publicly accessible spaces. 6. Building safety provisions, fire safety, emergency exits, evacuation procedures, at the Carmel office are maintained by the facility provider in accordance with applicable laws and regulations. Workforce members participate in announced drills. 7. Visitors at the Carmel office sign in through the facility's process and are escorted within Foundry's leased footprint by a workforce member. ## 3. Controls & procedures {#controls} ## 4. Carmel coordination office {#office} Foundry maintains a coordination office in Carmel, Indiana. The space is in a professionally managed office building. Physical access controls, building security, surveillance, and facility maintenance are managed by the building's property manager. The facility manager maintains controls including: - Building access control (key-card or equivalent badge access); - Surveillance and monitoring of common areas; - Building security staffing or after-hours monitoring per the facility's standard; - Fire safety and emergency-response systems; - Visitor management at the lobby. Foundry-specific controls inside Suite 125: - The suite door is locked outside of business hours and whenever no Foundry workforce member is on-site. - Access keys / cards to the suite are issued only to workforce members and tracked by the Head of Operations. - Guest access (vendors, candidates, visitors) is approved in advance, the visit is logged, and a workforce member escorts the guest while they are inside the suite. - Surveillance inside the suite, if any, is operated by the facility provider; Foundry does not store private spaces of recordings. - Where physical credentials or media are held on-site, they are kept in locked storage with access restricted to authorized workforce members. Workforce members at the Carmel office: - Comply with the facility manager's published security procedures; - Report any security concern or incident to Foundry Security; - Follow the facility's visitor-management procedure for any guest entering the lobby, and supplement it with the suite-level escort described above. ## 5. Cloud data centers {#datacenter} Foundry's production workloads run in: - **Amazon Web Services (AWS)**: Foundry's clinical data plane and platform infrastructure: the clinical workflow database (Amazon RDS for PostgreSQL), a private, Foundry-operated HAPI FHIR service (R4) running on Amazon ECS, object storage encrypted under AWS KMS customer-managed keys, the platform compute and messaging tiers, the managed secrets store, and the audit-logging surface. PHI lives only in the dedicated PHI account, behind network perimeter controls. AWS operates physical security at the data center level and publishes independent attestations: - 24×7 staffing and surveillance; - Multi-factor physical access (badge plus biometric); - Environmental controls (power, cooling, fire suppression) with redundancy; - HIPAA-eligibility attestations published by AWS, along with their independent third-party attestations. Foundry's BAA with AWS binds AWS to safeguard PHI consistent with HIPAA. AWS attestations are available under NDA on request and are reviewed in the annual [Vendor & Third-Party Risk](/docs/vendor/) cycle. ## 6. Workstation security {#workstation} All Foundry computing equipment is secured to protect confidential company information and credentials: - Workstations and laptops are accessed and used only by the authorized workforce member to whom they are assigned. - Workforce members monitor their devices and report any unauthorized access attempt to Security, in line with [Access Control](/docs/access/) and [Incident Response](/docs/ir/). - Workstations are locked (password / passkey protected) when unattended, automatically after no more than five minutes and manually whenever the workforce member steps away. - Laptops are not left unattended in public areas at the Carmel office or at any other location. Portable devices are taken home at the end of the work day or secured in a locked drawer in the suite. Laptops are not left in vehicles overnight. - Workstations are company property; they are issued through and returned through the workflows in [Asset Management](/docs/asset-mgmt/). - Lost or stolen devices are reported to IT and Security immediately, per [Incident Response](/docs/ir/). The device is remotely locked and wiped through MDM. ## 7. Clean desk {#clean-desk} Workforce members secure confidential information whenever they leave their workspace. **Electronic information:** - Workstations, laptops, and tablets are locked when unattended. - Portable devices are taken home or locked away at the end of the work day. - Removable storage (where it exists at all) is locked away when not in use. - Credentials are not written down, photographed, or stored physically. Recovery codes live in the workforce password manager. **Physical information:** - **PHI is never printed at the Carmel office, never stored at the Carmel office, never displayed on shared monitors at the Carmel office.** Any inadvertent printing of PHI is a reportable incident. - Confidential business documents (executed contracts, signed forms) are immediately collected from the printer. - Confidential printed materials are stored in a locked drawer or destroyed through cross-cut shredding when no longer needed. - Sensitive documents are not left on desks overnight or while away from the workspace. **Keys and access cards:** - Building or suite access cards are not left unattended. - Lost or stolen access cards are reported to the facility manager and to Foundry IT / Security on the same day. ## 8. Remote work environments {#remote} Foundry is remote-first; most workforce time is spent in home offices and, less often, in coworking spaces or travel locations. The physical-safeguard expectations on those environments are proportionate to their use: - **Display privacy.** Workforce members position their screens so that unauthorized observers cannot easily read confidential content. Use of a privacy filter is encouraged in public or shared spaces and required when working with PHI in any non-private setting. - **Audio privacy.** Calls discussing PHI or other confidential information are conducted in private space or with appropriate audio isolation (headphones, closed-door room). Calls discussing PHI are never recorded by the workforce member's own device without an explicit business reason and contract authority. - **Lock when stepping away.** The screen-lock requirement applies in home offices too. A laptop on a kitchen counter or in a coworking space is locked the moment the workforce member moves out of line of sight. - **Family / cohabitant access.** Other people in the workforce member's residence do not use the Foundry-issued laptop. The device is treated as an exclusively-assigned business tool. - **Travel.** Workforce members notify IT and Security before travel that takes them outside the United States; PHI access is suspended for the duration of the trip (per [Access Control §4](/docs/access/)). Devices are not stored in checked baggage. - **Network.** Workforce members use trusted networks where possible; on untrusted Wi-Fi, the device's DNS filter and the platform's TLS protect the session. Foundry does not maintain a workforce VPN as a primary control because production access requires federated SSO with MFA (WebAuthn where the target console supports it), and every session runs over TLS. ## 9. Incident reporting {#incident} Workforce members report physical security incidents to , including: - Unauthorized access or attempted access to the Carmel suite, a workforce member's home office, or any device; - Lost or stolen laptops, mobile devices, security keys, or access cards; - Suspicious activity at the Carmel office building or its parking; - Any concern about the physical security of a Foundry-issued device or credential. Incidents are handled per [Incident Response](/docs/ir/). Where there is any plausible exposure of PHI, which, given the FHIR-only PHI boundary, would itself indicate a separate failure, the matter is escalated to [Breach Notification](/docs/breach/) so the affected practice can be notified within the BAA's timeframes. ## 10. Roles & responsibilities {#roles} - **Head of Operations**: manages the Carmel office relationship with the facility provider, controls suite access, owns visitor procedures. - **Security Officer**: owns this policy, the workstation baseline, the lost-device workflow, and the incident-response intake. - **IT Lead**: administers MDM remote-lock and remote-wipe, replaces lost devices, reconciles the asset register. - **Workforce members**: lock devices, protect their workspaces, report incidents promptly. ## 11. Review & revision {#review} This policy is reviewed at least annually and whenever Foundry's facility footprint changes (new office, change of building, new coworking arrangement). Material revisions are approved by the Head of Operations and the Security Officer in coordination with the [Policy Management](/docs/policy-management/) process. ## 12. Related policies {#related} - [Asset management](/docs/asset-mgmt/) - [Endpoint & MDM](/docs/mdm/) - [Access control](/docs/access/) - [Data management](/docs/data-mgmt/) - [Incident response](/docs/ir/) - [Breach notification](/docs/breach/) - [Vendor & third-party risk](/docs/vendor/) --- _Policy · v2026.06 · Owner: Head of People & Security Officer (joint) · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Bioscope Foundry handles protected health information on behalf of physician practices as a HIPAA business associate. Every workforce member who can reach the Foundry platform, and especially those tagged for PHI access, passes through a screened, trained, and supervised lifecycle: background check before PHI access, signed confidentiality agreement at hire, annual HIPAA training, role-based access bounded by least privilege, and full access revocation within one business day of separation. {{< /callout >}} ## 1. Purpose & scope {#purpose} This policy governs the security and conduct expectations placed on Bioscope Foundry's workforce, employees, contractors, interns, and any other person acting on Foundry's behalf, from the time of offer through termination. It addresses the HIPAA Workforce Security and Information Access Management standards (45 CFR § 164.308(a)(3) and § 164.308(a)(4)). 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](/frameworks/crosswalk/). Foundry is a remote-first MSO. Workforce members work primarily from their homes; the Carmel office is a coordination space, not a PHI-bearing facility. Every workforce member supports independent physician practices that remain the covered entities for their own patients; the privacy expectations below sit on top of, not in place of, each practice's own conduct standards. ## 2. Policy statements {#statements} In addition to the cross-functional roles set out in [Roles, Responsibilities & Training](/docs/roles-responsibilities-training/), Foundry policy requires every workforce member to comply with the acceptable-use and HR-security expectations of this document and with the practice-supplied policies that bind their work for a specific covered entity. Foundry policy requires that: 1. Background verification is performed on every candidate for employment or contract engagement, in accordance with applicable U.S. federal and state law and proportional to the role's exposure to PHI, finances, and credentials. PHI-access roles require a satisfactory background check before access is granted. 2. Every employee, contractor, and third-party user signs the terms of their engagement, including a confidentiality agreement and Foundry's acceptable-use policy, before being provisioned. 3. Workforce members disclose outside activities and potential conflicts of interest in accordance with the Conflict of Interest process below. 4. Workforce members complete onboarding that introduces them to Foundry's environments, policies, security expectations, and HIPAA obligations as a business associate. Ongoing security and HIPAA awareness training is required and audited. 5. Offboarding reiterates any duties that survive termination (confidentiality, IP, non-disparagement), removes access, recovers company assets, and confirms the workforce member's last day in the HR system. 6. Foundry and its workforce take reasonable measures to ensure that PHI and other confidential data are not transmitted through unsanctioned channels (personal email, personal chat, social media, generative-AI services without a BAA). 7. Foundry maintains a list of prohibited activities (e.g. downloading PHI to personal devices, taking generative-AI screenshots of patient records, sharing credentials) and updates the list as the threat landscape evolves. 8. Suspected breaches of security or policy are investigated through a fair disciplinary process. Multiple factors, intent, prior history, role, harm, inform the response. Foundry reserves the right to terminate engagement for serious misconduct, and immediate termination is the default response to any deliberate violation of the PHI boundary. ## 3. Controls & procedures {#controls} ### 3.1 HR system of record {#hr-system-of-record} Foundry uses a dedicated HRIS platform as the system of record for workforce identity, role, employment status, training completion, and policy acknowledgments. The HRIS is the trigger source for downstream provisioning and termination workflows tracked in Linear. ### 3.2 Organization structure {#organization-structure} A reporting structure aligned to Foundry's lines of business is maintained in the HRIS and made visible to every workforce member. The organization chart shows reporting lines, role labels, and PHI-access tags. Updates flow through People Operations. ### 3.3 Job descriptions {#job-descriptions} Position descriptions are documented in the HRIS and updated as roles evolve. Each description identifies: - The expected skills and responsibilities; - The data classifications the role may reach (including whether the role is PHI-access); - Required certifications or background screens; and - The training catalog applicable to the role. ### 3.4 Performance reviews {#performance-reviews} Workforce members receive ongoing feedback from their manager and peers, with a formal annual review documented in the HRIS. Reviews capture both performance outcomes and conduct, including adherence to security and HIPAA obligations. ## 4. Acceptable use of end-user computing {#acceptable-use} Foundry requires every workforce member to comply with the following acceptable-use rules: 1. Workforce members are considered remote users at all times and follow the remote-access controls in [Access Control](/docs/access/) regardless of physical location. 2. Use of Foundry computing systems is subject to monitoring by IT and Security, consistent with applicable law and any notice given at hire. 3. Computing devices used for business purpose, including company-issued laptops, mobile phones, and any approved peripheral, may not be left unattended in public spaces. 4. Workforce members take Foundry-issued laptops with them when leaving the Carmel office or any travel location; devices are not stored overnight in shared offices or vehicles. 5. Full-disk encryption (FileVault on macOS) is enforced through MDM. Mobile devices accessing Foundry data have device encryption enabled and meet the device-baseline controls in [Endpoint & MDM](/docs/mdm/). 6. Only approved software with a valid license is installed on Foundry devices. Personal software is not installed on Foundry devices, and Foundry-licensed software is not used for personal purposes. 7. Sensitive or confidential content sent by email is sent through Foundry's tenanted the identity provider and, when content would otherwise be exposed, is protected by the identity provider's confidential mode or an equivalent control. PHI is not sent by email under any circumstances; it stays inside the platform. 8. Workforce members do not post sensitive or confidential content (including PHI, customer identifiers, credentials, or internal strategy) in public forums, third-party chat tools, or generative-AI products that do not have a Foundry-executed BAA or equivalent contract. If a public post is necessary for technical support, content is sanitized before posting and reviewed by Security. 9. EDR or anti-malware protection is installed and actively running on every endpoint that can be affected. 10. Storage media (USB drives, external SSDs, removable backups) are managed under the data-classification scheme in [Data Management](/docs/data-mgmt/). Use of removable media for confidential data is prohibited absent a Security-approved exception. 11. **It is strictly forbidden to download or store any PHI on end-user computing devices.** PHI is reached only through the Foundry platform's audited APIs and UIs and remains inside the FHIR service environment. Screenshots, copy/paste, file exports, and AI-tool ingestion of PHI are all prohibited. 12. Mobile devices are not used to connect directly to production environments. The standard production-access path uses a managed laptop authenticating through the workforce identity provider with MFA. 13. Workforce members do not use personal email, personal cloud storage, or personal generative-AI accounts to process Foundry or member-practice data. ## 5. Screening & onboarding {#screening} ### 5.1 Pre-employment screening {#pre-employment-screening} Background verification is performed before the start date of any employment or contract engagement. Verification is scaled to the role: - **All workforce roles:** identity verification, right-to-work check, criminal background check consistent with applicable U.S. federal, state, and local law, and employment / education verification. - **PHI-access roles:** the above plus an OIG/SAM exclusion check against the U.S. Department of Health & Human Services Office of Inspector General List of Excluded Individuals/Entities and the General Services Administration's System for Award Management. - **Finance- or credential-bearing roles:** add a credit history check where permitted by law. Screening is performed by an approved third-party vendor under contract. Results are stored in the HRIS subject to access controls. A workforce member may not be granted PHI access, production-cloud access, or repository-admin access until screening clears. ### 5.2 Onboarding {#onboarding} People Operations creates an onboarding record in the HRIS for every new workforce member and opens a corresponding onboarding ticket in Linear. The onboarding workflow has three required pillars before any access is provisioned beyond the standard bundle: 1. **Training and policy acceptance.** - The new workforce member completes Foundry's core training: security policy walkthrough, acceptable-use policy, HIPAA business-associate awareness, the PHI boundary, the Conflict of Interest process, and an overview of the platform's audit logging. - The workforce member signs the confidentiality agreement, the acceptable-use policy acknowledgment, and the conflict-of-interest disclosure form. - Records are kept in the HRIS. - Training and signed acknowledgments must be completed within **30 days** of start. Access to PHI-bearing systems is not provisioned until the HIPAA portion is complete. 2. **Access provisioning.** - The standard bundle for the workforce member's role is provisioned per the workflow in [Access Control](/docs/access/). - Any access beyond the standard bundle is requested separately, with a business justification, and is approved by the Security Officer. - PHI-access group membership is granted only after the workforce member has completed HIPAA training and signed the acknowledgment, and only when the role requires it. 3. **Device configuration.** - The workforce member's MacBook is shipped from inventory or handed off in person, enrolled in MDM, configured to the endpoint baseline (FileVault, host firewall, EDR, automatic lock under 5 minutes), and audited as enrolled before first-day sign-in. - Engineering workforce who self-configure follow a documented baseline; their devices are enrolled in MDM and audited just like default devices. ### 5.3 PHI-access onboarding gates {#phi-access-onboarding-gates} Workforce members tagged as PHI-access pass additional gates before being added to the PHI-access group in the identity provider: - Background check cleared, including OIG/SAM check. - HIPAA business-associate training completed and acknowledged. - PHI handling walkthrough with a Security or Clinical Operations lead, covering minimum necessary, audit logging, the PHI boundary, and the consequences of any download or off-platform exfiltration. - Phishing-resistant MFA factor (WebAuthn security key preferred, platform passkey acceptable) issued and registered where the target console supports it; a strong TOTP factor where WebAuthn is not yet supported by the surface. - Confidentiality agreement signed (or re-signed with the PHI-access addendum). These gates are tracked as checklist items on the onboarding Linear ticket. Each item is signed off by a designated owner. ## 6. Training & awareness {#training} - **HIPAA awareness training** is required at hire and annually thereafter for every workforce member, regardless of PHI-access status, because every workforce member could plausibly encounter PHI in a routed message or a misdirected ticket. - **Role-specific training** is layered on top: engineering completes secure-coding refreshers, Clinical Operations and Practice Success complete an additional clinical-workflow training, IT and Security complete vendor-specific platform training. - Annual training completion is tracked in the HRIS; non-completion within 30 days of the due date results in suspension of access until the requirement is met. - Just-in-time training is delivered after a security event, a policy update, or the introduction of a new system. Acceptance is recorded. - Continuous-education budgets are available for conferences, courses, and certifications relevant to the workforce member's role. ## 7. Termination & offboarding {#termination} People Operations maintains the master offboarding checklist in the HRIS. The checklist is the same whether the separation is voluntary, involuntary, or end-of-contract; the only variable is the timing. 1. People Operations (or the workforce member's manager) opens an offboarding ticket in Linear and notifies Security on the day the decision is final. For involuntary separations affecting a PHI-access workforce member, the notification is given before the conversation with the workforce member. 2. HR or the manager notifies Security to terminate access whenever there is evidence or reason to believe that: - A workforce member has been using their access inappropriately; - A workforce member's credentials have been compromised; - An unauthorized individual is using a workforce member's identity. (In any of these cases an incident report is also filed; see [Incident Response](/docs/ir/).) 3. Security disables the workforce member's identity-provider account, which cascades through SSO to revoke application access. MFA credentials, MDM enrollment, repository organizations, time-bound access grants, and any unfederated SaaS administrator role are reconciled the same business day. 4. For any workforce member who has held PHI access, all revocations are completed **the same business day** as separation. For all other workforce members, revocation is completed within one business day. 5. The workforce member returns the company-issued laptop, security keys, and any other equipment. Devices are wiped through MDM and re-imaged before reissue. 6. Security audits workforce identities at least quarterly and removes accounts that have not authenticated for an extended period (defaulting to 90 days), accelerated review when the role has touched PHI. ## 8. Issue escalation & whistleblowing {#escalation} ### 8.1 Escalation {#escalation-1} Workforce members escalate issues through the procedures published in the employee handbook. Issues that reach the Escalation Team are assigned a designated owner. The membership of the Escalation Team is maintained by the CEO or delegate. Security incidents, particularly those involving PHI, are handled per [Incident Response](/docs/ir/). Where an incident involves a breach of PHI, the Security Officer manages the response per [Breach Notification](/docs/breach/), which covers the BA-to-covered-entity reporting obligation Foundry owes to the affected practice. If a workforce member is unsure whether something is a security incident, the default is to contact Security immediately; over-reporting is welcomed. The incident owner: 1. Creates a Linear issue in the Security Issues tracker (or, for incidents touching PHI, the dedicated Incidents tracker). 2. Investigates and documents the issue, moving it to Review when a conclusion or remediation is reached. 3. Has the issue reviewed by another member of the Escalation Team. If rejected, the issue is re-investigated. 4. On approval, marks the issue Done with any pertinent notes. 5. Notifies the workforce member who originated the report of the outcome. ### 8.2 Whistleblower process {#whistleblower-process} Foundry requires every workforce member to observe high standards of business and personal ethics. Each workforce member is encouraged to report serious concerns so they can be addressed, including questionable accounting matters, violations of company policy or ethics, and suspected violations of laws or regulations. 1. **Acting in good faith.** Reports must be made in good faith with reasonable grounds. Allegations made maliciously or known to be false are themselves serious disciplinary offenses. 2. **Confidentiality.** The confidentiality of a reporter is maintained to the extent possible. Identity may be disclosed where required to conduct a thorough investigation, to comply with the law, or to afford the accused their legal right of defense. 3. **No retaliation.** Workforce members who report concerns in good faith are not subject to retaliation. Retaliation is itself a sanctionable offense, up to and including termination. 4. **Reporting.** Concerns may be filed directly with the CEO, the Security Officer, or the Privacy Officer. Anonymous reporting is supported by an anonymous reporting channel. Additional reporting paths are documented in the employee handbook. ## 9. Conflicts of interest {#conflicts} Workforce members make decisions on Foundry's behalf every day. Those decisions must be made in Foundry's interest and independent of outside influences. Where personal or outside interests could influence judgment, the appearance of a conflict can be as harmful as the conflict itself. The default in any case of doubt is disclosure. 1. **What is a conflict of interest?** A conflict arises when a workforce member's personal or outside interests conflict with Foundry's. Examples include outside employment with a competitor, customer, or vendor (including advisory or board roles); engaging in other work during Foundry working hours; investments that could influence judgment; personal relationships with another workforce member who can influence pay, performance rating, or promotion; use of Foundry's name, logo, or property for personal purposes; and any activity that could lead to disclosure of confidential information or PHI. 2. **Policy requirements.** Outside activity must not interfere with the workforce member's Foundry duties, must not compete with Foundry's products or services, must not violate Foundry's compliance obligations (including BAAs and the conduct expectations of member practices), and must not lead to disclosure of confidential information. Where in doubt, the workforce member raises the activity to their manager and to People Operations in advance. 3. **Disclosure responsibility.** Every workforce member completes the Conflict of Interest Disclosure Form at hire and whenever a relevant change occurs. The form is filed in the HRIS. Where a conflict is confirmed, Foundry and the workforce member agree mitigations; in some cases the workforce member may need to step back from a specific decision or recuse themselves from a specific account. 4. **Resolution.** Conflicts are resolved fairly and as early as possible. Final decisions on contested conflicts rest with senior leadership. ## 10. Non-compliance & sanctions {#sanctions} Workforce members report suspected non-compliance with this or any Foundry policy to the Security Officer or to their manager. Reports made in good faith are not subject to retaliation. 1. The Security Officer facilitates a prompt investigation, with assistance from other personnel as needed. The investigation: - Builds an audit trail covering the violation and the sequence of events; - Interviews workforce members with relevant knowledge; - Gives the workforce members suspected of non-compliance an opportunity to explain their actions; - Is documented contemporaneously, including the names of every person involved. 2. Violation of any security policy or procedure by a workforce member may result in corrective disciplinary action up to and including termination. Violation by a business associate's subcontractor, vendor, or customer may result in termination of the relationship and may carry civil or criminal penalties under applicable law. - A fair disciplinary process is followed. Factors considered include prior history, intent, the workforce member's training, the harm caused, and contractual obligations. - Foundry reserves the right to terminate workforce members for serious misconduct. - **A violation that results in unauthorized disclosure of PHI, an integrity loss to PHI, or an availability loss preventing authorized users from reaching PHI is grounds for immediate termination of the workforce member.** 3. The Security Officer facilitates steps to prevent recurrence, additional training, control changes, policy clarification, where feasible. 4. Where an insider threat is suspected, the Security Officer and the Privacy Officer convene a small team to investigate and mitigate. Workforce members are encouraged to come forward, including anonymously. 5. The Security Officer maintains documentation of the investigation, sanctions, and remediation for at least **seven years** after the conclusion of the matter. 6. When a formal sanction process is opened, the appropriate manager or supervisor is notified within 24 hours. The notification identifies the individual, the reason for the sanction, and the specific procedures for service or account restriction or revocation. ### 10.1 Clean desk {#clean-desk} Workforce members secure all sensitive or confidential information in their workspace at the end of the work day and whenever the workspace is unattended. This includes: - Computers, laptops, and tablets: locked (screen lock active) when unattended; taken home from the Carmel office after the workday. - Removable storage (the rare USB drive, an external SSD): locked in a drawer when not in use; never used for PHI. - Printed material: Foundry does not generate printed PHI; for the small set of permitted printed material (e.g. signed contracts), output is collected from the printer immediately and stored in a locked drawer when not in use. - Passwords are never written down or stored physically. Recovery codes are stored in the workforce password manager. - Office keys and access cards (Carmel office) are not left unattended. ## 11. Roles & responsibilities {#roles} - **Head of People / People Operations**: owns the HRIS, the onboarding/offboarding checklists, performance reviews, and the conflict-of-interest register. - **Security Officer**: co-owns this policy, approves PHI-access onboarding completion, runs the sanctions process, owns annual HIPAA training delivery. - **Hiring managers**: write accurate job descriptions, sponsor access requests, sign off on a new workforce member's onboarding checklist completion. - **Privacy Officer**: receives whistleblower reports related to privacy and PHI; coordinates investigations with the Security Officer. - **Every workforce member**: completes training on time, signs and abides by policy acknowledgments, discloses conflicts as they arise, reports suspected violations. ## 12. Review & revision {#review} This policy is reviewed at least annually and whenever business, technology, or regulatory change makes it stale. Material revisions are approved jointly by the Head of People and the Security Officer in coordination with the [Policy Management](/docs/policy-management/) process. ## 13. Related policies {#related} - [Access control](/docs/access/) - [Roles, responsibilities & training](/docs/roles-responsibilities-training/) - [Endpoint & MDM](/docs/mdm/) - [Incident response](/docs/ir/) - [Breach notification](/docs/breach/) - [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/) --- _Policy · v2026.06 · Owner: Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Bioscope Foundry runs a documented incident response process to detect, contain, eradicate, and recover from security incidents that affect the operating platform, the agent fleet, or any system that touches protected health information ("PHI"). Bioscope Foundry is a HIPAA **business associate**: when an incident affects PHI we handle on a practice's behalf, our obligation is to report to the affected practice (the covered entity) without unreasonable delay and to provide the information the practice needs to meet its own notification obligations. {{< /callout >}} ## 1. Purpose & scope {#purpose} This policy establishes how Bioscope Foundry detects, responds to, and reports information-security incidents to minimize loss and destruction, contain the blast radius, mitigate exploited weaknesses, and restore service. It applies to every Foundry workforce member, every system Foundry operates (the `conductor` platform in the cloud, the `foundry-master-agent` control plane, all Forge Agents and Tier-4 Moltworkers, Foundry-managed workstations, and Foundry-owned SaaS tenants), and to subprocessors handling PHI on Foundry's behalf. The process covers: - Continuous monitoring through intrusion detection, audit log analysis, and anomaly alerts; - A standing Security Incident Response Team (SIRT) and on-call rotation; - Procedures for media inquiries and external communications; - Clear procedures for identifying, responding to, assessing, analyzing, and following up on incidents; - Workforce training, education, and awareness; and - Communication with internal stakeholders, member practices (covered entities), and external authorities as required. The procedural backbone is adapted from the HIPAA Collaborative of Wisconsin Security Networking Group and the SANS incident-handling lifecycle, then layered with controls specific to an MSO operating an agentic platform over FHIR-resident PHI. ## 2. Policy statements {#statements} Bioscope Foundry policy requires that: \(a\) All computing environments and systems are monitored in accordance with Foundry's Auditing, System Access, and Endpoint & MDM policies. \(b\) All alerts are reviewed to identify security incidents. Investigation tickets are stored in the Linear **Investigations** team; finalized investigation reports are filed in an access-controlled internal repository. \(c\) Incident response procedures are invoked upon discovery of a valid security incident. \(d\) When an incident affects PHI we handle on a practice's behalf, the Security Officer or designee notifies the affected practice (the covered entity) without unreasonable delay, in line with the Business Associate Agreement (BAA) and HIPAA's Breach Notification Rule. See the [Breach Notification](/docs/breach/) policy. \(e\) The incident response team and management comply with additional requests by law enforcement in the event of a criminal investigation or national-security matter, including warranted data requests, subpoenas, and breach notifications. ## 3. Security Incident Response Team (SIRT) {#sirt} The Security Incident Response Team (SIRT) is responsible for: - Reviewing, analyzing, and logging all received reports and tracking their statuses; - Performing investigations, creating and executing action plans, and post-incident activities; - Collaborating with law enforcement agencies as appropriate. The SIRT operates under defined roles for each incident: - **Incident Commander (IC).** Single decision-maker for the incident. Drives tempo, declares severity, makes containment calls, and approves communications. Rotates from the on-call schedule. - **Communications Lead.** Owns internal updates, practice/customer notifications, and any external communications. Maintains the comms log. - **Investigator(s).** Perform technical analysis, evidence collection, and root-cause work. - **Scribe.** Maintains the running timeline in the Linear ticket so the investigation is reconstructable after the fact. Standing SIRT membership: - Security & Privacy Officer - Engineering Lead - Platform / SRE on-call - Agent Platform on-call (covers `foundry-master-agent`, Atlas, Forge Agents, and Tier-4 workers) - Legal counsel (engaged for breach analysis and BAA notifications) ## 4. Incident management process {#process} Foundry's incident response follows the SANS incident-handling lifecycle. The process distinguishes events from incidents and includes a separate workflow for confirmed PHI exposure. ### Definitions - **Event.** Any observable security-related occurrence in a system or network with a potential negative consequence. Examples: hardware failure causing an outage; software error causing an outage; general network or system instability; alerts from authentication, antivirus, or WAF systems; modified system files or unusual accesses; antivirus alerts; unusual network traffic to unexpected geographies. - **Incident with no impact.** An event that resulted in degraded performance, SIRT activity, or follow-up tickets but did not affect customer-facing utility. Examples: brute-force attempts that resulted in extra authentication filters; missing endpoint protection agents that resulted in remediation; critical vulnerabilities requiring triage and patching; misconfigurations deployed to production that required redeploy. - **Incident with impact.** A confirmed attack or indicator of compromise, often resulting in data loss or service degradation. Examples: a denial-of-service attack making a critical service unreachable; unauthorized changes resulting in production downtime or data loss; malicious software discovered on endpoints requiring eradication; compromised cloud credentials used outside intended scope and containment procedures. - **Breach.** A confirmed event that resulted in PHI being exposed, altered, or destroyed in a manner not permitted under HIPAA. Examples: an exfiltration from Foundry's FHIR service; an authorized export of FHIR data to an unauthorized destination; unauthorized change or destruction of PHI in the FHIR store; loss of a Foundry-managed workstation that, contrary to policy, contained PHI; an agent-runaway scenario where a Tier-3 clinical agent exposed PHI to a destination that was not its policy-allowed sink; Beacon Layer redaction failure resulting in raw PHI surfacing on a sanitized physician channel. Foundry workforce members must report any unauthorized or suspicious activity seen on production systems or associated communication systems (such as Slack, email, or the agent control plane) as soon as it is discovered. "When in doubt, report" is the rule. ### I: Identification and triage {#i-identification-and-triage} 1. Immediately upon observation, Foundry members report suspected and known events, precursors, indications, and incidents through one of: 1. Direct report to management, the Security Officer, or the Privacy Officer; 2. Email to ; 3. Phone call to the on-call rotation; 4. Submission via the Foundry internal incident channel in Slack; 5. Anonymous submission through the channel of the reporter's choice. 2. The individual receiving the report facilitates collection of additional information and notifies the Security Officer if not already done. 3. The Security Officer determines whether the issue is an event, precursor, indication, or incident. 1. If non-security or low-severity event: route to the appropriate resource for resolution. A ticket is filed in Linear and tracked to closure. 2. If a security incident: activate the SIRT and notify senior leadership by email or Slack. 1. If a non-technical incident, the SIRT completes the investigation, implements preventative measures, and resolves the incident. Proceed to Phase V. 2. If a technical incident, proceed to Phase II (Containment). Each SIRT member and technical responder documents all measures taken, including start and end times. 3. The Incident Commander opens an Incident ticket in the Linear **Investigations** team; the ticket summarizes events, efforts, and conclusions for each phase. Detail follows the SANS Security Incident Forms templates. 4. If PHI is or may be implicated, the Security Officer notifies the affected practice (covered entity) per the BAA and the [Breach Notification](/docs/breach/) policy. The notification to the practice happens without unreasonable delay and in no event later than **thirty (30) calendar days** from discovery, well within the HIPAA-mandated 60-calendar-day outer limit for BA-to-CE notification at 45 CFR § 164.410(b). Where a Practice's negotiated BAA sets a shorter window, that BAA controls. 5. If a threat is identified, the Security Officer forms a team to investigate and engages any necessary external resources. ### II: Containment (technical) {#ii-containment-technical} In the containment phase, Foundry engineering and security work to limit the blast radius. Detailed notes are taken throughout so evidence is usable in a subsequent investigation or, if applicable, prosecution. 1. Review any information collected so far by Security or other investigators. 2. Secure the blast radius (e.g., revoke credentials, isolate the affected service, restrict a VPC perimeter, freeze an agent worker, or place the platform into Read-Only Mode, see §7). 3. Perform documented forensic analysis, following the relevant playbook. 4. Document containment in the Incident ticket using a SANS IH Containment Form-style structure. 5. Continuously update senior management. 6. Continue notifying affected practices/customers with relevant updates as needed. ### III: Eradication (technical) {#iii-eradication-technical} The SIRT removes the cause and resulting security exposures. 1. Determine symptoms and cause for each affected system. 2. Strengthen defenses surrounding affected systems, including network perimeter, system monitoring, and remediation of the underlying defect ("fixing" misconfigurations, removing unused services, applying host hardening). 3. Conduct a detailed vulnerability assessment to confirm exploitable gaps are addressed; if additional issues are found, take appropriate preventative measures. 4. Update the Incident ticket with eradication details (SANS IH Eradication Form-style). 5. Update documentation with what was learned: cause, symptoms, and the fix. 6. Update senior management; continue updates to affected practices/customers. 7. Proceed to Phase IV. ### IV: Recovery (technical) {#iv-recovery-technical} The SIRT restores affected systems to operation. 1. Determine whether affected systems were changed. 1. If changed, restore to last known good (intended functioning). 2. Validate that the system functions as intended; involve owning teams where needed. 3. If operation was interrupted (system taken offline, dropped from network), restart and monitor. 4. If the system was not changed but was taken offline, restart and monitor. 5. Update documentation with details from this phase. 6. Update senior management; continue updates to affected practices/customers. 7. Proceed to Phase V. ### V: Post-incident analysis (technical and non-technical) {#v-post-incident-analysis-technical-and-non-technical} The follow-up phase reviews the incident for lessons learned and improvements. Incident reviews occur shortly after resolution; timelines may extend one to two weeks post-incident. 1. Responders (SIRT and technical resource) meet to review documentation collected during the incident. 2. A blameless post-mortem is produced and filed in an access-controlled internal repository, linked from the Linear ticket. Post-mortem authorship rests with the technical lead, with input from key personnel. 3. All incident-related information is recorded and retained per Foundry's Auditing and Data Management standards. 4. The incident is closed. ### Periodic evaluation The incident response process is reviewed and evaluated for effectiveness at least annually and after each SEV-1/SEV-2 incident. Training for responders and for the broader workforce is updated based on lessons learned. The plan is tested annually via tabletop or simulation (see §8). ## 5. Severity levels & classification {#severity} An incident is assigned a category and a severity level as soon as enough information is available; both can change as the investigation progresses. The audit trail captures every change. ### Categories Categories are based on the ENISA Incident Taxonomy: - **Abusive Content**: spam, harassment, illegal sexual or violent content. - **Malicious Code**: virus, worm, trojan, spyware. - **Information Gathering**: scanning, sniffing, social engineering. - **Intrusions and Intrusion Attempts**: brute force, zero-day exploitation, account compromise. - **Availability Attack**: DoS, DDoS, sabotage. - **Change Management**: unauthorized changes to production, misconfiguration deployments. - **Vulnerable**: reported vulnerabilities. - **Fraud**: unauthorized use of resources, copyright, masquerade. - **Agent / AI**: Forge Agent runaway, policy violation, Beacon Layer redaction failure, Moltworker boundary breach attempt. - **Other**: anything that doesn't fit the above. ### Severity matrix | Severity | Definition | Examples | Response target | | --------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | | **SEV-1** | Confirmed or highly suspected breach of PHI, or a critical service outage that prevents a practice from operating. Engages executive leadership. | Confirmed PHI exfiltration; ransomware on a PHI-handling system; complete loss of the `conductor` platform. | IC paged within 15 minutes; SIRT engaged immediately; practice notification per BAA timing; status updates at least hourly. | | **SEV-2** | Major incident with immediate business-operations impact but no immediate PHI exposure. Substantial degradation. | Production downtime in a non-PHI service; DoS on the public website; credential compromise contained before PHI was reached. | IC paged within 30 minutes; SIRT engaged; status updates every 2 hours. | | **SEV-3** | Confirmed incident with limited impact. May affect a subset of users or an internal-only system. | Single-host compromise on a non-PHI system; phishing landing that was caught at MFA; misconfiguration that was rolled back before customer impact. | IC assigned within business hours; daily status updates until resolved. | | **SEV-4** | Low-impact incident; informational; "no impact" events that still warrant tracking. | Brute-force attempts blocked by rate limiting; critical vulnerability awaiting scheduled patching; a single endpoint missing an agent that was reinstalled. | Tracked in Linear; reviewed at the weekly security stand-up. | ## 6. Special cases {#special} ### 6.1 PHI / ePHI {#phi-ephi} When an incident involves unsecured PHI: - "Unsecured PHI" means PHI not rendered unusable, unreadable, or indecipherable to unauthorized persons through encryption or destruction per HHS guidance. PHI encrypted to NIST specification while at rest in the FHIR store and in transit over TLS 1.2+ is presumptively _secured_. - The Security Officer activates the breach workflow in the [Breach Notification](/docs/breach/) policy. - Foundry notifies the affected practice (covered entity) without unreasonable delay and in no event later than **thirty (30) calendar days** from discovery, well within the HIPAA 60-day outer limit at 45 CFR § 164.410(b). Where a Practice's negotiated BAA sets a shorter window, that BAA controls. Discovery is the first day the breach is known or, with reasonable diligence, would have been known to any Foundry workforce member or partner (other than the person committing the breach). - Foundry provides the practice with the information it needs to meet its own obligations: notification to affected individuals, HHS, and (for breaches of 500+ individuals in a single state or jurisdiction) prominent media outlets. - Foundry does not notify individuals, HHS, or media directly on behalf of the practice unless the BAA delegates that obligation in writing. ### 6.2 Criminal activities {#criminal-activities} If an incident involves suspected criminal activity, the SIRT and management notify law enforcement. The Security Officer coordinates the law-enforcement engagement, including evidence preservation requirements and any delays to notification authorized under HIPAA §164.412. ### 6.3 Insider threat {#insider-threat} The cross-discipline insider-threat response team includes: - Security & Privacy Officer; - The Operations Lead; and - Engineering Lead, as appropriate. Insider-threat investigations require dual-control review and explicit Security Officer authorization before any audit log lookups touch personally-identifiable activity. ### 6.4 Agent and AI runaway {#agent-and-ai-runaway} Because Foundry runs an agentic platform (Atlas + Forge Agents), the IR plan covers AI-specific failure modes: - **Compromised Tier-4 worker (Moltworker).** A Moltworker runs on a `sandboxed_public` host and, by design, cannot reach PHI, `:private` memory, or clinic-scoped data. A compromise is contained to that host. Response: freeze the worker, snapshot for forensics, rotate any credentials issued to that worker, audit the Atlas placement decisions that ran the worker. - **Tier-3 clinical agent policy violation.** A clinic-scoped agent attempts (or appears to attempt) to send PHI to a sink outside its policy. Response: revoke the agent's session, audit the decision chain in Atlas / `foundry-policy`, replay the policy evaluation against the recorded inputs, file a finding against the policy crate, and report to the affected practice if PHI left Foundry's boundary. - **Beacon Layer redaction failure.** Sanitized physician-facing output surfaced raw PHI or peer `:private` memory. Treat as a confirmed PHI exposure; activate §6.1 immediately. - **Atlas control-plane compromise.** The Tier-0 orchestrator is compromised. Treat as SEV-1 by default; place the operating platform in Read-Only Mode (§7) and consider System Offline Mode if exfiltration is suspected. Forensic artifacts for agent incidents include the relevant Atlas decision logs, Forge Agent audit codes, mount-watcher events, and any `memory_events` entries (which never contain raw PHI bodies, only machine-readable codes). ## 7. Emergency operations modes {#emergency} If an incident constitutes an emergency, for example, an ongoing campaign exfiltrating data, Foundry can place the operating platform into one of two emergency operations modes. Activation requires approval by the Security Officer or a higher executive. In emergency operations mode, temporary access may be granted to security and/or engineering personnel to access production environments for forensics, root-cause analysis, eradication, or recovery activities. All such access is logged to cloud audit logs and reviewed post-incident. ### Read-Only Mode Read-Only Mode pauses all write activity against the operating platform. Practices and patients can still _read_ their data, but no further edits can be made. Implemented via deny-write IAM policies on the AWS account hosting the FHIR service and application-tier feature flags in `conductor`. Example: a threat actor is writing continuous bursts of data at scale, driving cost and instability. We enter Read-Only Mode while we investigate and eradicate. ### System Offline Mode System Offline Mode completely isolates the production system from external networks via a combination of IAM and network perimeter controls policies. Practices and patients cannot access their data during this period. Example: a threat actor has compromised production credentials and is exfiltrating large volumes of data. ## 8. Tabletop exercises {#tabletop} At least once per year, Foundry security and engineering jointly run a tabletop exercise or red-team drill that simulates one or more SEV-1 incidents. Depending on the type of exercise, duration ranges from a 2–4 hour tabletop to a multi-week red-team engagement. Each exercise follows a cyberattack playbook. Exercises may be run entirely with internal resources or with an external security consulting firm. Senior leadership may participate in the drill or receive a readout. Goals: - Confirm responders can execute the documented procedures in real conditions; - Validate that the on-call rotation, paging, and comms paths work; - Identify gaps ahead of a real event; - For agent scenarios: validate that Atlas containment levers (Read-Only Mode, agent freeze, credential rotation) behave as designed. Findings are tracked to closure as Linear tickets and reviewed at the annual policy review. ## 9. Incident tracking and records {#tracking} A Linear ticket in the **Investigations** team is created for every reported incident. Each ticket captures: - Summary; - Description; - Impact; - Priority / urgency; - Category and severity; - Timeline (analysis notes and comments); - Cause / determination; - Outcome / resolution; - Lessons learned. Where a more detailed post-mortem is appropriate, Security or Engineering produces the write-up and files it in an access-controlled internal repository, linked from the Linear ticket. Incident records and supporting materials are retained for at least **six years** in line with HIPAA recordkeeping requirements. ## 10. Roles & responsibilities {#roles} - **Security & Privacy Officer**: owns this policy, declares incidents, authorizes emergency operations modes, and is the named contact for practice / regulator communications about Foundry security incidents. - **Incident Commander (per-incident role)**: single decision-maker during an active incident. - **Communications Lead (per-incident role)**: owns practice and customer notification. - **SIRT members**: investigate, contain, eradicate, and recover. - **On-call engineers**: first responders for platform and agent incidents. - **Workforce members**: report suspected incidents promptly through any documented channel. - **Legal counsel**: supports breach analysis, regulator interaction, and law-enforcement engagement. ## 11. Review & revision {#review} This policy is reviewed at least annually and whenever a significant incident, regulatory change, or platform change makes it stale. The plan is also exercised annually (§8). Material revisions are approved by the Security Officer in coordination with the Policy Management process. ## 12. Related policies {#related} - [Breach Notification](/docs/breach/) - [Business Continuity & Disaster Recovery](/docs/bcdr/) - [System Audits & Monitoring](/docs/system-audits/) - [Threat Management](/docs/threat/) - [AI Governance](/docs/ai-governance/) - [Access Control](/docs/access/) - [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/) --- _Policy · v2026.06 · Owner: IT Lead · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Every workforce device that can reach Bioscope Foundry's platform is centrally managed: Apple Silicon macOS as the standard, enrolled in MDM, with FileVault, the host firewall, EDR, and a five-minute screen-lock enforced. Foundry does not store PHI on endpoints, in removable media, or on backup tapes; PHI lives only in Foundry's FHIR service. The few media-handling cases that remain (e.g. occasional encrypted transfer of non-PHI confidential data) follow the controls in this policy. {{< /callout >}} ## 1. Purpose & scope {#purpose} This policy governs Foundry's workforce endpoints (laptops and mobile devices), the mobile-device-management (MDM) configuration applied to them, and the handling of storage media. It addresses the HIPAA Security Rule device-and-media controls (45 CFR § 164.310(d)). It applies to every device that authenticates to a Foundry-managed system or that holds Foundry-confidential data. 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](/frameworks/crosswalk/). Foundry's architecture keeps PHI inside Foundry's FHIR service (R4); endpoints never read or write PHI to local storage. Customer-managed FHIR data is therefore not present on Foundry laptops, on backup tapes, or on removable media. This policy's mobile-and-media controls exist to make that boundary enforceable and to govern the small set of legitimate use cases that remain. ## 2. Policy statements {#statements} Foundry policy requires that: 1. All Foundry-issued media that may hold company data must be encrypted at rest; encryption is enforced by MDM and verified continuously. 2. Critical data, including PHI and any data classified _Restricted_ in [Data Management](/docs/data-mgmt/), must not be stored on mobile devices, removable media, or backup tapes held by Foundry. The platform's FHIR-only PHI boundary makes the PHI case a structural prohibition, not just a procedural one. 3. Any destruction or disposal of media that may have held PHI is performed in accordance with federal and state law and with Foundry's retention schedule: - Records that have satisfied their retention period are destroyed or disposed of in an appropriate manner. - Records involved in any open investigation, audit, or litigation are not destroyed until the matter is concluded. 4. Where any media could plausibly have held PHI, the media is rendered forensically inaccessible prior to reuse or disposal. 5. Mobile devices used in support of business operations are managed and auditable by Foundry IT and Security. 6. Where Foundry or a workforce member believes that customer data (including PHI) has been moved, copied, or transferred onto a personal device, the workforce member: - Notifies Foundry Security immediately; - Surrenders the device to Foundry Security for confirmation; - Permits Security to securely remove the data, including a wipe or factory restore if required; - Deletes any backup of that data, including encrypted and cloud-hosted backups, on confirmation. Any such event is opened as an incident under [Incident Response](/docs/ir/). ## 3. Controls & procedures {#controls} ### 3.1 Approved devices {#approved-devices} - **Standard workforce device:** Apple Silicon MacBook on a currently supported macOS release. - **Engineering exception:** Linux laptops (Ubuntu LTS or equivalent) on Foundry-provisioned hardware, enrolled in MDM and brought under the EDR baseline. - **Mobile devices:** Foundry-issued iPhones running a currently supported iOS release for workforce members whose role requires a managed mobile device. Personal mobile devices are not enrolled. ## 4. Endpoint baseline {#baseline} The Foundry endpoint baseline applies to every managed laptop: 1. **Disk encryption.** FileVault (macOS) or LUKS (Linux) is enforced by MDM. The recovery key is escrowed in MDM and accessible only to IT and the Security Officer through a dual-control workflow. 2. **Host firewall.** The macOS firewall is enabled with stealth mode; all inbound connections are blocked by default. Linux endpoints run an equivalent configuration (e.g. `nftables` baseline). 3. **Endpoint Detection and Response (EDR).** The EDR agent is installed and running. Detections feed the centralized log platform; tamper-resistance is enabled and audited. 4. **Screen-lock requirements.** Automatic lock after no more than 5 minutes of inactivity; the lock requires authentication (passkey or password). 5. **Password / passkey.** The local account uses a strong password meeting the credential baseline in [Access Control](/docs/access/), supplemented by Touch ID where the hardware supports it. 6. **Automatic OS & security updates.** Critical updates install automatically; major OS upgrades are coordinated by IT within a published cadence (typically within 30 days of stable release). 7. **Browser baseline.** Managed browser (Chrome or Safari) with enterprise policies that restrict installation of unknown extensions, enforce safe-browsing, and require sign-in to the managed workforce browser profile. 8. **DNS & outbound filtering.** Workforce DNS is routed through the workforce DNS filter to block known-malicious destinations. 9. **Software inventory.** Installed applications are inventoried through MDM. Only approved software with a valid license is installed. 10. **Time sync.** NTP is enforced from a trusted source to keep audit timestamps coherent across the fleet. 11. **Lock screen content.** Notifications on the lock screen do not expose message bodies. Notifications never carry PHI by design. ## 5. MDM enforcement {#mdm} Foundry uses a dedicated MDM platform as the source of truth for endpoint configuration. The MDM: - Enrolls every Foundry-issued device automatically through Apple Business Manager (or equivalent for Linux); - Pushes the baseline configurations above and continuously asserts compliance; - Reports drift back to the Security team via the SIEM; - Supports remote lock and remote wipe for lost or stolen devices; - Escrows FileVault recovery keys; - Records last-check-in time, OS version, applied profile version, and EDR status for each device. The Security team reviews fleet compliance weekly. Devices that fall out of compliance (missed check-in, EDR offline, OS unpatched beyond the window) are escalated; access is suspended for chronically out-of-compliance devices until they are remediated. ## 6. Mobile devices {#mobile} Foundry-issued mobile devices are configured to a minimum baseline: - Device passcode required, with biometric unlock supplementing it; - Device encryption enabled by default (the iOS / Android standard); - MDM enrollment with separation between the work profile and any personal content; - Remote lock and remote wipe available to IT; - OS at a currently supported major version; - Sideloaded applications prohibited; - Conditional access: only enrolled, compliant mobile devices can authenticate to the workforce the identity provider tenant. Mobile devices are not used to connect directly to production environments. PHI is not viewed, transmitted, or stored on mobile devices; any workflow that would require this is routed through the desktop platform instead. ## 7. Storage media & removable devices {#media} Foundry uses cloud storage for production data; workforce members do not routinely use removable media. The policy on USB drives, external SSDs, and similar media is therefore restrictive: - **PHI:** never on removable media, under any circumstance. - **Other Restricted / Confidential data (per [Data Management](/docs/data-mgmt/)):** permitted on removable media only as a documented exception, on Security-approved hardware-encrypted devices. - Removable-media use requires a Linear ticket approved by IT and Security, identifying the workforce member, the data being transferred, the destination, and the expected duration. - On completion of the transfer, the device is securely wiped and returned to the IT Lead, who verifies the wipe and re-checks the device into inventory. - USB devices that are not hardware-encrypted Foundry-approved devices are blocked by the EDR's device-control policy. ## 8. Media disposal {#disposal} IT and Security ensure that media which may have held critical or sensitive data is disposed of securely: - Methods of destruction, disposal, and reuse are reassessed periodically against current technology, accepted practice, and cost-effectiveness. Methods may include: - Cryptographic erasure: destruction of the encryption key for media encrypted under a strong algorithm (AES-256); - Secure overwrite using NIST SP 800-88 Rev. 1-compliant patterns where the media supports it; - Physical destruction (shredding, degaussing) where overwrite or key-destruction is not adequate. - For Foundry-issued laptops, end-of-life follows the asset-management retirement workflow in [Asset Management](/docs/asset-mgmt/): MDM-driven wipe, cryptographic erasure of FileVault, and inventory closeout. - If records are requested in a judicial or administrative hearing, a qualified protective order is obtained to ensure their return or proper disposal by the requesting party. - Subcontractors (per [Vendor & Third-Party Risk](/docs/vendor/)) are contractually required to return or destroy Foundry data on contract termination. Where return or destruction is infeasible, the contract limits the use and disclosure of the data to the purposes that prevent its return or destruction. - For a member practice terminating its engagement with Foundry, data return or disposal follows the BAA and the published offboarding procedure. After return, the practice is solely responsible for ongoing safeguards on the data; Foundry retains only the audit records and any data the BAA expressly requires it to keep. ## 9. BYOD posture {#byod} Foundry provides workforce members with company-issued laptops and, where applicable, mobile devices. BYOD (Bring Your Own Device) for workforce work on Foundry systems is **not supported**. Personal devices do not enroll in MDM and are not allowed to access PHI-bearing surfaces or to install Foundry-licensed software. Where engineering self-configures a Foundry-issued laptop: - The workforce member follows a documented configuration baseline maintained by IT and Security; - The device is still enrolled in MDM, runs EDR, and is audited daily for baseline compliance; - Configurations that diverge from the baseline are flagged and remediated. ## 10. Roles & responsibilities {#roles} - **IT Lead**: owns the MDM, the endpoint baseline, the asset register tie-in, and the disposal workflow. - **Security Officer**: owns the EDR program, the SIEM tie-in, exception approvals, and the device-control policy. - **Workforce members**: keep their devices in compliance (no jailbreaking, no disabling EDR, no installing unapproved software), report loss or theft immediately, and surrender devices to Security on request. ## 11. Review & revision {#review} This policy is reviewed at least annually and whenever the endpoint stack, MDM vendor, or OS baseline changes materially. Material revisions are approved by the IT Lead and the Security Officer in coordination with the [Policy Management](/docs/policy-management/) process. ## 12. Related policies {#related} - [Access control](/docs/access/) - [Asset management](/docs/asset-mgmt/) - [Data protection](/docs/data-protection/) - [Data management & classification](/docs/data-mgmt/) - [Facility & physical security](/docs/facility/) - [Incident response](/docs/ir/) - [Vendor & third-party risk](/docs/vendor/) --- _Policy · v2026.06 · Owner: Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Bioscope Foundry is a Delaware management services organization (MSO) supporting independent U.S. physician practices. We are a HIPAA **business associate**; each member practice is the covered entity. This document summarizes how the security program is scoped, governed, and measured. The protected health information (PHI) we handle on a practice's behalf lives only in Foundry's clinical data plane, a Foundry-operated clinical workflow database and a private FHIR R4 service, both running on Amazon Web Services (Foundry's cloud infrastructure subprocessor) under an executed BAA, never on local disk, in logs, in prompts, or in generated documents. {{< /callout >}} ## 1. Purpose & scope {#purpose} 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 {#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 {#compliance} 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. | Framework | Status | What it means here | | ------------------------------------------------------ | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | HIPAA Privacy, Security, and Breach Notification Rules | In effect | Governs our obligations; we operate as a business associate under written BAAs with each member practice and with subprocessors that may handle PHI. | 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](/frameworks/crosswalk/). To request the current state of any compliance activity, attestation, or audit summary, see the [Compliance, audits & external communications](/docs/compliance-audits/) policy. ## 4. Program coverage {#program} 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 {#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](/docs/policy-management/) policy. Items that require confirmation by Foundry leadership have been resolved in this draft. ## 6. Review & reporting {#review} 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 {#related} - [Policy management](/docs/policy-management/) - [Roles, responsibilities & training](/docs/roles-responsibilities-training/) - [Risk management](/docs/risk-mgmt/) - [Security architecture & operating model](/docs/security-architecture/) - [AI governance](/docs/ai-governance/) - [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/) --- _Policy · v2026.06 · Owner: Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Bioscope Foundry maintains a versioned set of security and privacy policies as a HIPAA business associate. The Security Officer and Privacy Officer are accountable for keeping policies current, approved, communicated, and accessible to every workforce member. Previous versions are retained so that the state of any policy at any historical date is recoverable. {{< /callout >}} ## 1. Purpose & scope {#purpose} This policy governs how Foundry creates, approves, communicates, retains, and retires the policies in its security and privacy program. It applies to every Foundry policy document published in this Trust Center and to any internal procedure that implements one of them. It binds every workforce member who proposes, reviews, approves, or operates against a Foundry policy. Foundry's policies exist to maintain compliance, protect PHI handled on member practices' behalf, and to make safe behavior the easy behavior for the workforce. This policy is the policy about policies. ## 2. Policy statements {#statements} Foundry policy requires that: **(a)** Foundry policies are developed and maintained to meet all applicable compliance requirements, including HIPAA, and to adhere to recognized security best practices. Mapping of Foundry's policies to non-HIPAA frameworks is maintained in the [framework crosswalk](/frameworks/crosswalk/). **(b)** All policies are reviewed at least annually and whenever a material change to Foundry's business, technology, regulatory environment, or risk posture makes a policy stale. **(c)** All policy changes are approved by the Foundry Security Officer. In addition: - Major changes, changes that materially expand, contract, or alter Foundry's commitments to member practices or workforce, require approval by the Foundry CEO or designee. - Changes to policies governing product development (Secure SDLC, Vulnerability Management, Configuration & Change Management, AI Governance) require approval by the engineering lead. - Changes to policies governing privacy and the use of PHI require concurrence from the Privacy Officer. **(d)** All policy documents are maintained under version control. Previous versions are retained for a minimum of seven years from the date a version is superseded or retired. **(e)** Policy exceptions are handled case by case (see [§6](#exceptions)). Each exception is documented with the business justification, the residual risk, the compensating controls, an expiration no later than one year from approval, and named approvers. **(f)** Policies are accessible to every workforce member. Material changes are communicated to all workforce members through pre-established internal channels. ## 3. Document structure {#structure} Each Foundry policy is a standalone document covering a specific domain of concern. Documents share a consistent structure so that workforce members and external reviewers can find the same information in the same place across the library: - **Header**: eyebrow, title, owner, effective date, last reviewed date, next review date, and version number. - **Summary callout**: a one-paragraph plain-English statement of what the policy commits Foundry to. - **Purpose & scope**. - **Policy statements**: lettered `(a)`, `(b)`, `(c)`… commitments. - **Controls & procedures**: numbered, with H3 sub-headings where the source policy is long. - **Roles & responsibilities**. - **Review & revision**. - **Related policies**. ## 4. Versioning & numbering {#versioning} ### 4.1 Version numbers {#version-numbers} Each Foundry policy carries a version number in the format `YYYY.MM`, the year and month of the most recent material publication (for example, `2026.06`). The version is incremented with each material change. A material change is one that adds, removes, or alters a policy statement, a control, a role, or a retention commitment. A policy may also carry an optional revision suffix, `rev.N`, to denote minor, non-material changes such as formatting, typo fixes, or link updates that do not change the substance of the policy. ### 4.2 Section numbering {#section-numbering} Where sequencing numbers appear in policy headings, they are stable references. A policy or policy statement may be cited internally as, for example, `policy-management §2(c)`. To maintain cross-reference integrity: - Existing sequence numbers are not reordered or renumbered between versions. - Additions are appended: new policy statements are added at the end of an existing list rather than inserted between existing items. - Retired statements are marked _deprecated_ in place rather than deleted, so that historical citations remain resolvable. ## 5. Policy lifecycle {#lifecycle} ### 5.1 Storage and source of truth {#storage-and-source-of-truth} Policies are stored as source-controlled artifacts in the Foundry Trust Center repository a version-controlled repository. Updates flow through pull requests in the same manner as application source code. The version of a policy published on the Trust Center website is the version on the `main` branch of that repository. ### 5.2 Initiating a policy change {#initiating-a-policy-change} Any workforce member may propose a policy change at any time. The process is: 1. The proposer opens an Issue in the Foundry Security project in Linear the policy-change tracker describing the proposed change and the motivation. The Issue may include a draft pull request against the Trust Center repository. 2. The Security Officer (or the Privacy Officer, where the change is privacy-led) is assigned to review the request. 3. If the change touches a domain owned by another role (e.g., engineering for SDLC, BCDR for operations), that role is added as a reviewer. 4. The reviewer either approves the change or returns it with feedback for further iteration. 5. If the change requires technical changes to production systems, those follow the [Configuration & Change Management](/docs/ccm/) process. ### 5.3 Drafts, archives, and merges {#drafts-archives-and-merges} Material changes are prepared on a draft branch, not on `main`. Multiple authors collaborating on a change may use additional branches and stacked pull requests before consolidating into the draft branch. Before a material change is merged to `main`: - The current version of the affected policy document is archived under its existing version number (for example, `archive/policy-management/2026.06.html`). - The Security Officer's approval is recorded on the pull request. The Privacy Officer's concurrence is recorded for privacy-impacting changes. - Engineering reviewers are included for product-development policies. PR approvals serve as records of awareness and training for development staff. Minor revisions (`rev.N`) may be merged without archiving, since the substance of the policy has not changed. ### 5.4 Communication and training {#communication-and-training} Policy changes are communicated to the workforce through: - An automated notification to the Foundry Slack policy-changes channel a dedicated policy channel when a pull request affecting a policy is merged. - An email from the Security Officer to all workforce members for material changes, including a plain-language summary appropriate to the audience. - An item on the next company-wide meeting agenda when the change affects day-to-day workforce behavior. - Updates to the security-awareness curriculum when the change introduces new workforce expectations. Policy update communication and training for non-engineering staff is conducted separately by the Security team when the engineering pull-request channel is not appropriate for the audience. ### 5.5 Publication {#publication} The current set of approved Foundry policies is published at [the Foundry Trust Center](https://bioscopefoundry.com). Every workforce member has access to the current set without needing to request it. ## 6. Exceptions {#exceptions} Where business need or technical constraint requires temporary deviation from a Foundry policy, the deviation is handled as an exception rather than as a policy change. Exceptions are managed by the Security Officer. Each exception record contains: - The policy and specific statement(s) being excepted; - The business purpose and the reason the policy as written cannot be met; - The scope: which systems, accounts, environments, or workforce members are covered; - The residual risk and any compensating controls; - An expiration date no later than one year from the date of approval; - Named approvers: the Security Officer plus an additional approver appropriate to the domain (by default, the Engineering Lead). Open exceptions are reviewed at each scheduled program review. An exception that has expired without renewal is closed and the underlying gap is either remediated or re-opened for a fresh exception, not silently extended. Exceptions are **never** granted against: - The PHI boundary: PHI may not move outside Foundry's FHIR service by exception. - The encryption-at-rest and in-transit requirements for PHI systems. - The phishing-resistant MFA requirement for workforce access to PHI systems. - HIPAA Breach Notification timelines. ## 7. Retention & backup {#retention} Foundry policies and their associated documentation are retained for a minimum of seven years from the date of creation or from the date the version was last in effect, whichever is later. The retention chain is: - Version history is maintained in Git in the Trust Center repository. - Archived prior versions live in `archive/` under their version number. - Backup copies of the repository are held in an access-controlled document store for redundancy. - The HIPAA-relevant subset (any policy that touches PHI handling, BAA obligations, or breach response) is preserved for at least six years from the latest effective date, in line with 45 CFR § 164.530(j) as it applies to a business associate. ## 8. Review & revision {#review} The Security Officer initiates a structured review of every Foundry policy at least annually, or after a significant change to Foundry's organizational environment. The review process is: 1. The Security Officer opens an Issue or pull request in the Trust Center repository covering the policies due for review. 2. The Security and Privacy Officers, plus additional reviewers appropriate to the domain, are notified. 3. Reviewers comment on the pull request or leave findings in the Issue. Where changes are needed, those follow the lifecycle in [§5](#lifecycle). 4. Once review is complete, the Security Officer approves and closes the Issue, or merges the pull request, recording any pertinent notes. 5. Review status is tracked using Linear or GitHub reporting to assess compliance with this policy. ## 9. Related policies {#related} - [Security program overview](/docs/overview/) - [Roles, responsibilities & training](/docs/roles-responsibilities-training/) - [Configuration & change management](/docs/ccm/) - [Compliance, audits & external communications](/docs/compliance-audits/) --- _Policy · v2026.06 · Owner: Privacy Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Bioscope Foundry is committed to protecting the privacy of the people we deal with as an MSO, visitors to [bioscopefoundry.com](https://bioscopefoundry.com), physicians who apply or join, and the workforce of member practices. This is the program-level privacy policy. The public-facing privacy notice lives at [/legal/privacy-policy.html](/legal/privacy-policy/). PHI handled on behalf of a member practice is governed by the Business Associate Agreement and described in the [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/), not by this policy. {{< /callout >}} ## 1. Purpose & scope {#purpose} This policy sets Foundry's program-level requirements for privacy and consent across the MSO. It covers the information Foundry collects about visitors, applicants, physician members, and member-practice staff in the course of operating the business. This policy is **about Foundry-as-MSO information collection**. Patient health information (PHI) that Foundry handles for a physician practice is not governed here; it is governed by the Business Associate Agreement (BAA) between Foundry and the practice and described in the [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/). Patient rights flow through the practice's own Notice of Privacy Practices, not through Foundry. ## 2. Policy statements {#statements} Foundry policy requires that: \(a\) A privacy notice is published and kept current so visitors, applicants, and member practices can understand how Foundry collects, uses, secures, and shares information. \(b\) Valid consent is obtained for information collected from a person where consent is the lawful basis, and the purposes for which the information will be used are disclosed. Where applicable, the person is offered a meaningful opt-in or opt-out. Material changes to processing trigger a refreshed disclosure and, where required, re-consent. \(c\) Foundry does **not** sell personal information and does **not** share personal information for cross-context behavioral advertising. \(d\) AI-assisted processing is disclosed at the point of collection. AI processing that touches PHI occurs only through HIPAA-eligible services covered by a BAA, with human-in-the-loop review for material decisions. \(e\) Individual rights requests (access, correction, deletion, portability, opt-out) are routed, verified, and responded to within statutory timelines, with refusals limited to legally permitted grounds and an internal appeal path. ## 3. Controls & procedures {#controls} ### 3.1 Privacy notice {#notice} Foundry's current public-facing privacy notice is published at [/legal/privacy-policy.html](/legal/privacy-policy/) and at [bioscopefoundry.com](https://bioscopefoundry.com) under the standard footer link. The notice describes: - Who Foundry is (a Delaware MSO supporting independent U.S. physician practices); - The two distinct environments, the marketing site and the authenticated operating platform, and the privacy practices for each; - What information Foundry collects from visitors, applicants, and member-practice users; - How Foundry uses that information, including AI-assisted processing; - Categories of recipients (service providers under contract, parties acting on a person's direction, legal and safety disclosures, business-transfer recipients); - Retention defaults and the relationship to the [Data Management](/docs/data-mgmt/) policy; - How individuals exercise their rights and how Foundry handles requests; - Contact information for the Privacy Officer and how to escalate. The notice is reviewed at least annually and whenever a material change to processing, vendors, or applicable law warrants it. Material changes trigger an updated "Last updated" date and, where required, prominent notification before the change takes effect. ### 3.2 Consent and choice {#consent} Foundry distinguishes between information that is necessary to provide a service and information collected on a consent basis. - **Required for service.** Information needed to evaluate an application, sign a contract, provision an account, run payroll for a member practice, or operate the platform is collected as part of performing the agreement. Refusal means Foundry cannot provide that service. - **Consent-based.** Optional processing is offered with a clear opt-in. The most consequential example is the voice-first onboarding interview: Foundry tells the applicant before recording begins, captures consent, explains how the audio and transcripts will be used and retained, and permits withdrawal at any time. - **Marketing communications.** Marketing email is opt-in for non-customers and includes an unsubscribe mechanism. Transactional communications about an existing account are sent on the contractual basis and not subject to opt-out. - **Cookies and analytics.** The marketing site uses cookies and may use analytics; the operating platform uses only strictly necessary cookies for security and authentication. The notice provides cookie-control guidance. Consent records are retained alongside the corresponding account or application so Foundry can demonstrate, on request, when and how consent was obtained. ### 3.3 Notice of Privacy Practices (not applicable) {#nopp} Foundry is **not** a HIPAA covered entity and does not provide healthcare services directly to patients. Foundry therefore does not issue a patient-facing Notice of Privacy Practices. Each member practice issues its own NPP to its patients; patient rights regarding PHI are exercised through the practice. The [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/) explains Foundry's role as a business associate. ### 3.4 Platform use terms and consent {#platform} Terms of use for Foundry's operating platform are hosted at [/legal/terms-of-service.html](/legal/terms-of-service/) and surfaced in-product at first sign-in. Material changes require an updated acceptance step before continued use, except for non-material updates which are notified by email and by in-product banner. Service-specific consents (for example, the onboarding interview recording, agreement signatures, or specific authorizations from member-practice administrators) are captured in-flow, time-stamped, and stored with the corresponding account. ### 3.5 AI-assisted processing {#ai} AI assistance is part of how Foundry's services work. Examples include the voice-first onboarding interview, summarization and triage of communications, and analyst support for back-office workflows. The privacy notice describes AI processing at the level a reasonable visitor or applicant needs to understand it. Foundry policy: - AI outputs **augment, not replace**, human judgment. A person reviews material decisions, including membership, compliance, and clinical-policy determinations. - AI processing of PHI occurs only through HIPAA-eligible services covered by a BAA. The `foundry-master-agent` tiering model enforces this: clinical-tier agents are PHI-eligible inside the conductor authorization boundary; sandboxed worker tiers (Moltworkers) cannot hold PHI or clinic-scoped data. - The Beacon Layer redacts PHI before sanitized insights surface to physician-facing dashboards or external reports. - De-identified or aggregated information may be used to improve services, consistent with HIPAA's de-identification standard and other applicable law. - Individuals may ask the Privacy Officer about AI processing that affects them, including the categories of inputs, the role of human review, and the option to request a re-review where a decision was based on automated processing. Foundry's alignment with non-HIPAA frameworks (including AI-management and information-security standards) is described in the [framework crosswalk](/frameworks/crosswalk/). ### 3.6 Individual rights handling {#rights} Depending on residency, individuals may have the right to access, correct, delete, port, or restrict the processing of their personal information, and to opt out of processing covered by applicable law. Foundry handles those requests through a single intake at . 1. **Intake.** Requests are logged with date, requester, scope, and applicable jurisdiction. 2. **Identity verification.** Foundry verifies identity proportionate to the sensitivity of the request before disclosing or modifying information. 3. **Triage.** Requests that concern _patient health information_ are redirected to the relevant physician practice (the covered entity) and the requester is informed of the routing. 4. **Response.** Foundry responds within the statutory window for the applicable jurisdiction (for example, 45 days under most U.S. state privacy laws, extendable once where the law permits). 5. **Refusal & appeal.** If a request is refused, Foundry states the basis in writing and offers an internal appeal path; some jurisdictions also provide a regulator escalation path, which Foundry references in the response. ### 3.7 Sharing and sale of personal information {#sharing} Foundry does **not** sell personal information and does **not** share personal information for cross-context behavioral advertising. Personal information is shared only: - With service providers acting on Foundry's behalf under contract, including BAAs where the provider may handle PHI; - With parties at the individual's direction (for example, vendors engaged to stand up a practice); - To comply with law, subpoena, or legal process; to enforce agreements; or to protect the rights, safety, and property of Foundry, its members, or others; - In connection with a merger, acquisition, financing, or asset sale, where Foundry will seek assurances that the recipient honors this policy. ## 4. Roles & responsibilities {#roles} - **Privacy Officer**: owns this policy, the public-facing privacy notice, and the rights-request intake; coordinates with the Security Officer on PHI-adjacent matters. - **Security Officer**: owns the safeguards that this policy relies on (see [Data Protection](/docs/data-protection/)). - **Legal**: owns the Terms of Service, BAA template, MSA, and the interface to regulators when an escalation is needed. - **Engineering leads**: implement consent capture, preference management, and right-to-delete workflows in the systems they own; preserve PHI boundary controls. - **Workforce members**: collect only what is needed, route rights requests to the Privacy Officer, and never write PHI to local files, prompts, or generated documents. ## 5. Review & revision {#review} This policy is reviewed at least annually and whenever a material change in business activity, vendors, AI tooling, or applicable law warrants it. Material revisions are approved by the Privacy Officer in coordination with Legal and the Security Officer, and processed through [Policy Management](/docs/policy-management/). ## 6. Related policies {#related} - [Data management](/docs/data-mgmt/) - [Data protection](/docs/data-protection/) - [AI governance](/docs/ai-governance/) - [Breach notification](/docs/breach/) - [Vendor & third-party risk](/docs/vendor/) - [Privacy Policy (public-facing)](/legal/privacy-policy/) - [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/) - [Business Associate Agreement](/legal/business-associate-agreement/) --- _Policy · v2026.06 · Owner: Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Bioscope Foundry operates a continuous risk-management process modeled on NIST SP 800-30 and the HIPAA Security Rule risk-analysis and risk-management implementation specifications. The process protects the confidentiality, integrity, and availability of PHI that Foundry handles on member practices' behalf, supports Foundry's mission as an MSO, and underwrites the controls described elsewhere in this Trust Center. PHI itself does not leave Foundry's FHIR service as part of the risk-management process. {{< /callout >}} ## 1. Purpose & scope {#purpose} This policy establishes the scope, objectives, and procedures of Foundry's information security risk-management process. The process is intended to support and protect the organization and its ability to fulfill its mission, supporting independent physician practices, while safeguarding PHI handled on their behalf as a HIPAA business associate. The policy covers risks to Foundry's information assets, including the Conductor platform (which mediates all access to Foundry's FHIR service), the foundry-master-agent control plane (Atlas plus the tiered Forge Agents), workforce endpoints, identity and SaaS surface, the marketing and customer-site infrastructure, and the supply chain that supports all of these. ## 2. Policy statements {#statements} Foundry policy requires that: **(a)** A thorough risk assessment is conducted to evaluate the potential threats and vulnerabilities to the confidentiality, integrity, and availability of electronic protected health information (ePHI), and other confidential or proprietary electronic information, that Foundry stores, transmits, or processes on behalf of member practices. **(b)** Risk assessments are performed with any major change to Foundry's business or technical operations, with any change to supporting infrastructure that materially affects the ePHI risk envelope, and on no less than an annual cadence. **(c)** Strategies are developed to mitigate or accept the risks identified during the risk-assessment process. Mitigation strategies are tracked to closure in the risk register. **(d)** Documentation of all risk assessment, risk management, and risk-mitigation efforts is maintained for a minimum of seven years. **(e)** AI-specific risks, bias, fairness, model drift, prompt injection, and risks unique to the multi-tier agent architecture, are incorporated into the same risk-management process and tracked in the same registry, with cross-references to the [AI Governance](/docs/ai-governance/) policy. **(f)** The PHI boundary is treated as a control that cannot be relaxed: any proposed change that could allow PHI to land outside Foundry's FHIR service is identified as a high-risk change and undergoes risk assessment before implementation, with the Security Officer's explicit approval. Such changes are not approved through routine change management. ## 3. Risk management process {#process} Risk analysis and risk management are recognized components of Foundry's compliance and information security program, in accordance with the Risk Analysis and Risk Management implementation specifications within the HIPAA Security Management Standard and the evaluation standards set out in 45 CFR § 164.308(a)(1)(ii)(A), § 164.308(a)(1)(ii)(B), § 164.308(a)(1)(i), and § 164.308(a)(8). The process is also informed by NIST SP 800-30 and NIST SP 800-39. Risk assessments are conducted throughout the product lifecycle: - Before the integration of new system technologies and before changes are made to Foundry's physical and technical safeguards. Routine updates to existing systems, deployments of new instances built from previously assessed configurations, onboarding of additional member practices, and routine application releases do not, by themselves, trigger a fresh full risk assessment; - When changes are made to Foundry's facilities or to equipment hosting Foundry workloads that introduce new, untested configurations; - In response to changes in the threat environment that materially affect the security of ePHI, for example, a notable new attack pattern against the clinical data plane, a new class of LLM threat, or an incident at a subprocessor. Foundry performs periodic technical and non-technical assessments of the Security Rule requirements, as well as in response to environmental or operational changes affecting the security of ePHI. Foundry implements security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to: 1. Ensure the confidentiality, integrity, and availability of all ePHI Foundry receives, maintains, processes, or transmits on behalf of member practices; 2. Protect against any reasonably anticipated threats or hazards to the security or integrity of practice ePHI; 3. Protect against any reasonably anticipated uses or disclosures of practice ePHI that are not permitted by the BAA or required by law; and 4. Ensure compliance by all workforce members. In addition to the policy statements in [§2](#statements), Foundry's risk-management process requires that: 1. Any residual risk, risk remaining after risk controls have been applied, is signed off by senior management and the Security Officer. 2. All workforce members are expected to fully cooperate with persons performing risk-management work, including contractors and audit personnel. Workforce members who violate this expectation are subject to discipline as outlined in [HR & Personnel Security](/docs/hr-personnel-security/). 3. Implementation, execution, and maintenance of the risk-analysis and risk-management process is the responsibility of the Security Officer (or other designated workforce member) and the identified Risk Management Team. 4. All risk-management efforts, including decisions on controls implemented and controls explicitly not implemented, are documented and the documentation is maintained for at least seven years. 5. The risk-management procedure is tracked in Linear in the risk register as follows: 1. The Security Officer or Privacy Officer initiates a risk-management activity by creating an Issue in the Risk Register project. 2. The Security Officer or Privacy Officer is assigned to carry out the risk-management procedure. 3. All findings are documented and linked to the Issue. 4. Once the assessment steps and corresponding documentation are complete, the Security Officer approves or rejects the Issue. Rejected Issues return for further review and documentation. 5. Approved Issues are marked Done with any pertinent notes recorded. 6. The risk-management procedure is monitored on a quarterly basis using Linear reporting to assess compliance with this policy. Third-party risk management, procurement, and systems acquisition are covered in [Vendor & Third-Party Risk](/docs/vendor/). ## 4. Risk management schedule {#schedule} The two principal components of the risk-management process, assessment and mitigation, are executed on the following schedule to ensure the continued adequacy and continuous improvement of Foundry's security program: - **Scheduled basis.** An organization-wide risk assessment of Foundry's information-system infrastructure is conducted annually. The assessment is completed in time for mitigation priorities to be reflected in the corporate budgeting cycle. - **Throughout the development lifecycle.** From the time a need for a new, untested information system or application is identified through to its retirement, ongoing assessments of potential threats and vulnerabilities are undertaken as part of normal system maintenance and design. - **As needed.** The Security Officer (or other designated workforce member) or the Risk Management Team may call for a full or partial risk assessment in response to changes in business strategy, technology, information sensitivity, threats, legal liabilities, or other significant factors affecting Foundry's platform. ## 5. Risk assessment & analysis {#assessment} The intent of a risk assessment is to identify potential threats and vulnerabilities and to estimate the likelihood and impact of their occurrence. The output helps identify appropriate controls for reducing or eliminating risk. ### 5.1 Step 1: System characterization {#step-1-system-characterization} Define the scope. Identify where ePHI is received, maintained, processed, or transmitted. Identify the boundaries of the Foundry platform: the FHIR service environment, the Conductor services that mediate access, the agent control plane, the workforce identity surface, and the supporting CI/CD pipeline. _Output:_ a characterization of the system in scope, a clear picture of its environment, and a delineation of platform boundaries. ### 5.2 Step 2: Threat identification {#step-2-threat-identification} Identify and document potential threat-sources, the potential for a threat-source to successfully exercise a specific vulnerability. Threat-sources are identified from historical incidents, industry intelligence (including Health-ISAC where Foundry is a member), government advisories, and Foundry's own incident history. _Output:_ a threat list of threat-sources that could exploit platform vulnerabilities. ### 5.3 Step 3: Vulnerability identification {#step-3-vulnerability-identification} Develop a list of technical and non-technical platform vulnerabilities that could be exploited or triggered by potential threat-sources. Vulnerabilities range from incomplete or conflicting policies through insufficient safeguards on the facilities that house computer equipment to software, hardware, identity, or supply-chain weaknesses. _Output:_ a list of platform vulnerabilities that could be exercised by potential threat-sources. ### 5.4 Step 4: Control analysis {#step-4-control-analysis} Document and assess the effectiveness of the technical and non-technical controls that have been or will be implemented by Foundry to minimize or eliminate the likelihood of a threat-source exploiting a platform vulnerability. _Output:_ a list of current or planned controls (policies, procedures, training, technical mechanisms, insurance, etc.) used to mitigate the likelihood of a vulnerability being exercised and to reduce the impact of such an adverse event. ### 5.5 Step 5: Likelihood determination {#step-5-likelihood-determination} Determine the likelihood that a vulnerability could be exploited by a threat-source given existing or planned controls. Likelihood is rated low (0.1), medium (0.5), or high (1.0), per NIST SP 800-30 definitions. ### 5.6 Step 6: Impact analysis {#step-6-impact-analysis} Determine the adverse impact that would result from a threat successfully exploiting a vulnerability. Factors include importance to Foundry's mission, sensitivity and criticality of the data and systems, and the loss of confidentiality, integrity, and availability. Impact is rated low (10), medium (50), or high (100). Impacts involving PHI are weighted toward the upper end of the scale by default. ### 5.7 Step 7: Risk determination {#step-7-risk-determination} Multiply likelihood and impact to produce a risk level: low (1–10), medium (\>10–50), or high (\>50–100). The risk rating presents the actions senior management must take at each level. ### 5.8 Step 8: Control recommendations {#step-8-control-recommendations} Identify controls that could reduce or eliminate the identified risks at an acceptable level. Factors considered include effectiveness of the recommended options, regulatory requirements, organizational policy, operational impact, and safety and reliability. Control recommendations feed the mitigation process. ### 5.9 Step 9: Results documentation {#step-9-results-documentation} Risk-assessment results are documented in an official report and provided to senior management to inform policy, procedure, budget, and platform operational and management decisions. The report describes threats and vulnerabilities, measures risk, and recommends controls. ## 6. Risk mitigation & monitoring {#mitigation} Risk mitigation involves prioritizing, evaluating, and implementing the risk-reducing controls recommended by the risk assessment to ensure the confidentiality, integrity, and availability of practice ePHI. Determination of appropriate controls depends on Foundry's risk tolerance, which is conservative for any risk involving PHI. ### 6.1 Step 1: Prioritize actions {#step-1-prioritize-actions} Sort threat/vulnerability pairs by risk level in descending order. Pairs at the top of the list receive immediate attention and priority in resource allocation. ### 6.2 Step 2: Evaluate recommended control options {#step-2-evaluate-recommended-control-options} Review the recommended controls and alternatives for reasonableness and appropriateness, assessing feasibility (compatibility, user acceptance) and effectiveness (degree of protection, level of risk mitigation). Select the most appropriate control option for each pair. ### 6.3 Step 3: Cost-benefit analysis {#step-3-cost-benefit-analysis} Determine the extent to which each control is cost-effective. Compare the benefit (risk reduction) of applying a control with its cost of implementation and operation. Cost considerations include direct expenditure, complexity introduced, ongoing operational burden, and the impact on the workforce experience. ### 6.4 Step 4: Select controls {#step-4-select-controls} Taking into account previous-step information, Foundry's mission, and other important criteria, the Risk Management Team determines the best controls for reducing risks to the information systems and to the confidentiality, integrity, and availability of ePHI. Controls may consist of a mix of administrative, physical, and technical safeguards. ### 6.5 Step 5: Assign responsibility {#step-5-assign-responsibility} Identify the workforce members with the skills necessary to implement each control and assign their responsibilities. Identify the equipment, training, and other resources needed for successful implementation. ### 6.6 Step 6: Safeguard implementation plan {#step-6-safeguard-implementation-plan} Develop an implementation or action plan. The plan contains, for each risk pair: - Risk level and ranked priority; - Recommended feasible control(s); - Resources required for implementation; - The team member responsible for implementation; - Start date for implementation; - Target completion date; - Ongoing maintenance requirements. Status against the plan, along with key metrics and indicators, is reported to Foundry senior management at the regular cadence. ### 6.7 Step 7: Implement and monitor {#step-7-implement-and-monitor} As controls are implemented, monitor the affected systems to verify that the controls continue to meet expectations. Elimination of all risk is not practical; depending on the situation, implemented controls may lower a risk level but not completely eliminate the risk. Expectations are continually and consistently communicated to the Risk Management Team, senior management, and other key stakeholders. Additional monitoring is especially crucial during periods of major environmental, organizational, or facility change. If risk reduction expectations are not met, the relevant portion of the risk-management process is repeated. _Output:_ residual-risk documentation. ## 7. Risk register {#registry} The Security team maintains a registry of risks, captured and kept up to date in the Linear Risk Register project and/or in the security operations tool of record the security operations tool of record. The risk register includes all risks and threats identified during the annual risk assessment and all interim reviews. Each entry contains a unique identifier, a description, the affected assets, the threat and vulnerability pair, the likelihood and impact ratings, the resulting risk level, the chosen treatment (mitigate, transfer, accept, avoid), the owner, the target date, and the current status. ## 8. Cyber liability insurance {#insurance} Foundry holds cyber liability insurance with coverage commensurate with the organization's risk profile. Coverage is reviewed annually as part of the risk-management process and adjusted in line with the size of the workforce, the number of practices supported, and the volume of PHI handled. ## 9. Fraud risks {#fraud} Foundry considers its fraud-related risk to be low given its transparent culture, small team, written separation of duties, controls spanning the organization, continuous monitoring and auditing, and external accounting relationship supporting financial controls. Fraud risk is re-evaluated as part of the annual risk assessment. The assessment considers the classical fraud-triangle factors: pressures and incentives, opportunities, and rationalizations. Financial-related fraud assessment is led by the operations/finance lead. IT-related fraud assessment is led by the Security Officer. | Fraud Risk | Likelihood | In-place controls / monitors | | ----------------------------------------- | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------------- | | Fraudulent financial reporting | Low | Monthly executive review of plan and revenue; external accounting firm review. | | Misappropriation of assets | Low | Expense reporting, corporate-card controls, and asset tracking. | | Regulatory and legal misconduct | Low | Audit and compliance policies and processes, including whistleblower channels; outside counsel reviews legal conduct. | | Payroll fraud | Low | Payroll reviewed by at least two people internally plus the external accounting firm. | | Kickbacks / conflict of interest | Low | Team-based vendor review and selection process; conflict-of-interest disclosures. | | Misuse of cloud resources | Low | Continuous resource monitoring across cloud accounts and regions, plus expense monitoring with thresholds. | | Other IT fraud | Low | IT asset and resource tracking; least-privilege access; audit logging. | | Agent / AI-tool misuse (Foundry-specific) | Low–medium | Agent tier boundaries, Beacon Layer redaction, AI-tool guardrails per [AI Governance](/docs/ai-governance/), audit logs for orchestrator actions. | ## 10. Anti-money laundering & antitrust {#aml} ### 10.1 Anti-money laundering {#anti-money-laundering} It is the policy of Bioscope Foundry to prohibit and actively prevent money laundering and any activity that facilitates money laundering or the funding of terrorist or criminal activities. - Foundry does not accept any customers or transactions involved with money laundering. - Foundry encourages suspicious-activity reporting and implements applicable measures to detect such activity. - Workforce members complete training that includes recognition and reporting of suspicious financial behavior. ### 10.2 Antitrust compliance {#antitrust-compliance} All workforce members must comply strictly and in good faith with the letter and spirit of all antitrust laws applicable in any jurisdiction in which Foundry transacts business. Antitrust laws protect and promote free and open competition, a posture Foundry believes is in the best interest of the company, its competitors, suppliers, member practices, and the patients those practices serve. ## 11. Review & revision {#review} This policy is reviewed at least annually and after any material change to Foundry's business or technical operations, regulatory environment, or risk posture. Material revisions are approved by the Security Officer in coordination with the Privacy Officer and the [Policy Management](/docs/policy-management/) process. ## 12. Related policies {#related} - [Security program overview](/docs/overview/) - [Security architecture & operating model](/docs/security-architecture/) - [AI governance](/docs/ai-governance/) - [Vendor & third-party risk](/docs/vendor/) - [Vulnerability management](/docs/vuln-mgmt/) - [Incident response](/docs/ir/) - [Business continuity & disaster recovery](/docs/bcdr/) --- _Policy · v2026.06 · Owner: Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Security and compliance are everyone's responsibility at Bioscope Foundry. This policy names the roles accountable for the security program, the Security Officer and the Privacy Officer, defines what every workforce member is required to do, and sets the cadence and substance of security and HIPAA training. As a HIPAA business associate, Foundry's workforce safeguards apply to anyone who creates, receives, maintains, or transmits PHI on a member practice's behalf. {{< /callout >}} ## 1. Purpose & scope {#purpose} This policy assigns accountability for Foundry's security and privacy programs and establishes the training that every workforce member completes. Most cybersecurity incidents begin with the compromise of an end-user computing device, social engineering, human error, or insider misuse. The workforce is therefore both the first line of defense and the most common point of failure, and training is essential. In this and all related policies the term **workforce member** includes full-time and part-time employees in all job roles, founders, temporary staff, contractors, subcontractors, volunteers, interns, advisors, managers, and executives at Bioscope Foundry. Where HIPAA uses the term "workforce" we use the same meaning here. ## 2. Policy statements {#statements} Foundry policy requires that: **(a)** A Security Officer and a Privacy Officer (45 CFR § 164.308(a)(2) and § 164.530(a)(1)) are appointed to lead the maintenance and enforcement of safeguards for the confidentiality, integrity, and availability of PHI. The Security Officer's responsibilities focus on the HIPAA Security Rule; the Privacy Officer's focus on the HIPAA Privacy Rule and the Breach Notification Rule. **(b)** Security and compliance are the responsibility of every workforce member. Every workforce member is required to: - Complete all required security trainings, including HIPAA awareness on hire and annually thereafter, and any additional training required by job role; - Follow all security requirements set out in Foundry's policies and procedures, including access control, acceptable use, the PHI boundary, and the AI-tool use rules; - See something, say something: follow the incident reporting procedure to report all suspicious activities to the Security Officer. **(c)** Workforce members are required to report non-compliance with Foundry policies to the Security Officer or designee. Individuals who report concerns in good faith are protected against intimidation, threats, coercion, discrimination, or any other retaliatory action. **(d)** Workforce members are required to cooperate with federal, state, and local law-enforcement activities and legal investigations. Interfering with such an investigation through willful misrepresentation, omission, or threats is strictly prohibited. **(e)** Workforce members who violate Foundry policies are subject to sanctions in proportion to the severity of the violation, up to and including termination, as detailed in the [HR & Personnel Security](/docs/hr-personnel-security/) policy. **(f)** Segregation of duties is maintained where applicable to ensure proper checks and balances, minimize conflict of interest, reduce the opportunity for fraud and insider misuse, and eliminate single points of compromise in critical systems. **(g)** Workforce safeguards apply not only to Foundry-employed individuals but also to any contractor or third party acting on Foundry's behalf with access to Foundry systems or PHI. Contractor agreements include the same confidentiality and security obligations. ## 3. Security & Privacy Officers {#officers} ### 3.1 Appointment {#appointment} The Security Officer and the Privacy Officer are appointed by, and report to, the Foundry CEO and, where established, the Board of Directors. At these two roles may be held by one individual; whenever a single individual holds both roles, that fact is recorded and the dual-control safeguards in [§6](#segregation) are reinforced. Foundry has formally designated a Security Officer and a Privacy Officer; current assignments are recorded in internal governance records. ### 3.2 Security Officer responsibilities {#security-officer-responsibilities} The Security Officer is accountable for the Foundry information security program. The Security Officer or designee: - Builds and maintains the security program to satisfy regulatory and contractual requirements (HIPAA and the frameworks tracked in the [framework crosswalk](/frameworks/crosswalk/)); - Establishes, documents, distributes, and updates security policies, standards, and procedures; - Oversees, enforces, and documents the activities necessary to maintain compliance, including verifying that those activities are in alignment with the program; - Monitors, analyzes, distributes, and escalates security alerts and information from internal and external sources; - Develops and maintains the security incident response and escalation procedures; - Administers user accounts, additions, deletions, and modifications, in coordination with HR and engineering; - Monitors and controls access to critical systems and data, including PHI and ePHI; - Performs risk assessment, remediation, and ongoing risk management (see [Risk Management](/docs/risk-mgmt/)); - Delivers regular security awareness and compliance training, plus periodic updates and reminder communications; - Maintains a program that incentivizes the right behaviors, supports timely and proper reporting and investigation of violations, implements effective mitigation, and applies fair sanctions when necessary; - Assists in the administration and oversight of Business Associate Agreements (BAAs) with member practices and with subprocessors; - Facilitates audits and external assessments to validate compliance efforts; - Works with the finance lead to ensure that security objectives receive appropriate consideration in the budgeting process. ### 3.3 Privacy Officer responsibilities {#privacy-officer-responsibilities} The Privacy Officer is accountable for the Foundry privacy program and for Foundry's obligations under the HIPAA Privacy Rule and Breach Notification Rule as a business associate. The Privacy Officer or designee: - Maintains Foundry's HIPAA business-associate posture, including the standard BAA and any practice-specific addenda; - Reviews uses and disclosures of PHI by Foundry and its subprocessors against the BAA and the minimum-necessary standard; - Coordinates support to member practices when patients exercise individual rights under HIPAA: access, amendment, accounting of disclosures, restriction requests, confidential communications; - Owns the breach risk assessment and the notification timeline to affected practices in the event of a breach of unsecured PHI (see [Breach Notification](/docs/breach/)); - Leads privacy training content for the workforce and for role-based curricula; - Maintains the subprocessor list and the BAAs that bind PHI-handling subprocessors; - Acts as the contact for member practices on privacy questions and for regulators on Foundry's privacy practices. ## 4. Security Committee {#committee} The Security Committee is chaired by the Security Officer and includes the Privacy Officer plus designated representatives from engineering, operations, and administration. At the committee membership is: - Security Officer: chair; - Privacy Officer; - The Engineering Lead; - The Operations Lead. The committee meets at least quarterly and is responsible for reviewing the security scorecard, the risk register, open exceptions, significant incidents, and the schedule of policy reviews. The committee is the standing forum for cross-functional decisions affecting the security program. Decisions are recorded in the meeting notes in internal governance records. ## 5. Workforce supervision {#workforce} The Security Officer oversees the security program but does not personally supervise every workforce member's daily activity. Supervision of users of Foundry's systems, applications, servers, workstations, and data is a shared responsibility: 1. Team leads and supervisors monitor their teams' use of Foundry systems for unauthorized use, tampering, and theft, and report non-compliance to the Security Officer in line with the [Incident Response](/docs/ir/) policy. 2. Team leads assist the Security and Privacy Officers in ensuring that role-based access is appropriate for each individual on their team. 3. Team leads take all reasonable steps to hire, retain, and promote workforce members who comply with the Security Rule and Foundry's policies, and to grant access only to users who do so. 4. Co-workers are expected to report observed non-compliance through the same channels. ## 6. Segregation of duties {#segregation} Foundry assigns the security and compliance job function to dedicated personnel. Segregation of duties is achieved through a combination of role assignment and automated enforcement of software-defined processes, including: - Production deployments require pull-request review by an engineer other than the author; - Changes to PHI-handling systems require concurrence from the Security Officer in addition to engineering approval; - Financial transactions over an established threshold require dual approval; - Access reviews are performed by someone other than the access grantor; - Audit-log integrity controls are owned by a role other than the one administering the systems whose logs they collect. Where the team is too small to fully separate two functions, the Security Officer documents the gap in the risk register and applies compensating controls (for example, additional automated alerting or external review). ## 7. Training program {#training} ### 7.1 Cadence {#cadence} The Security and Privacy Officers, with HR support, facilitate the training of all workforce members: 1. New workforce members complete onboarding training within their first 30 days of employment or engagement. 2. Existing workforce members complete annual refresher training. 3. Workforce members whose functions are affected by a material change in policies or procedures complete supplemental training within one month after the change takes effect. 4. The Security Officer may require additional training in response to changes in Foundry's security and risk posture (for example, after a notable incident or after the introduction of a new agent tier or new subprocessor). Training session materials, attendance, and completion records are retained for a minimum of seven years. ### 7.2 Subjects covered {#subjects-covered} Training covers, but is not limited to, the following subjects defined in Foundry's security and privacy policies: 1. HIPAA Privacy, Security, and Breach Notification Rules as they apply to Foundry as a business associate; 2. Risk management procedures and how workforce members contribute to them; 3. Auditing: Foundry may monitor access and activities of all users of its systems; 4. Acceptable use: workstations and Foundry accounts are used only to perform assigned job responsibilities; 5. Reporting obligations: malicious software, unauthorized attempts, uses, or theft of Foundry systems or workstations, unauthorized access to facilities, suspicious log-in events, and suspected security incidents are reported to the Security Officer immediately; 6. The PHI boundary: PHI lives only in Foundry's FHIR service. Workforce members must never copy, export, or paste PHI into local files, logs, prompts, third-party AI tools, or generated documents; 7. Use of AI tools: the AI-tool guardrails in the [AI Governance](/docs/ai-governance/) policy, including the prohibition on entering PHI into third-party AI tools; 8. The contingency plan: what to do during a service degradation or disaster; 9. Credential hygiene: passwordless authentication, phishing-resistant MFA, no credential sharing under any circumstance; 10. Automatic session timeout on applications that access PHI; 11. Supervisor responsibilities: reporting terminations and role changes promptly so that access can be adjusted; 12. Backup, hardware-disposal, and media-handling procedures for any device that has been provisioned to access Foundry systems; 13. Secrets management: keys, tokens, and credentials are stored only in the approved secret broker, never in source code, chat, or local files. ## 8. Ongoing awareness {#awareness} Foundry delivers periodic security-awareness content to all workforce members throughout the year, not only at the annual refresh. Awareness content is tailored to actual Foundry use cases and current security risks, for example, real-world social-engineering scenarios, threat-intelligence updates relevant to healthcare, and practical guidance on identifying and responding to phishing, prompt-injection, vishing, and similar threats. Progress is tracked by workforce member and required topic. HIPAA-specific awareness training is required within 30 days of onboarding and annually thereafter. The training record is captured in HR and/or in the learning management system. Role-based supplemental training is required for: | Role | Additional training | | ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Engineering & data | Secure SDLC, Foundry's secure-development standards, threat modeling, secure use of LLM APIs and Foundry's FHIR service, key management. | | Clinical / practice ops | HIPAA Privacy Rule applied to BA workflows, minimum necessary, communication discipline (no PHI in SMS or email body), patient-rights routing back to the practice. | | Operations & IT | Identity administration, MDM operations, audit-log review, incident-response runbooks, BCDR drills. | | Workforce members operating agent tooling | Agent operating-model boundaries (Atlas, Forge Agents, Moltworkers, Beacon Layer), prompt-injection awareness, AI-tool use limits. | | All workforce members | HIPAA awareness, acceptable use, AI-tool guardrails, incident reporting. | ## 9. Internal communications {#comms} ### 9.1 Company-wide updates {#company-wide-updates} Foundry holds a company-wide roundtable on a regular cadence (at least quarterly) to communicate updates across business operations, performance, and objectives. Senior management sends additional company-wide announcements through pre-established internal channels, primarily email and the Foundry Slack workspace (`#general` and topic-specific channels). ### 9.2 Team-level updates {#team-level-updates} Regular performance and status updates are communicated by each department, functional team, or designated individual through pre-established channels. Engineering project teams maintain their own committed cadence and channel, for example, daily standups or weekly team meetings. ### 9.3 Security-specific communications {#security-specific-communications} Security-relevant updates, policy changes, incidents, awareness reminders, and the quarterly scorecard summary, are communicated by the Security Officer through a dedicated security channel and, for material items, by email to all workforce members. ## 10. Review & revision {#review} This policy is reviewed at least annually and whenever a change in organizational structure, workforce composition, regulatory environment, or risk posture makes a section stale. Material revisions are approved by the Security Officer with concurrence from the Privacy Officer, in coordination with the [Policy Management](/docs/policy-management/) process. ## 11. Related policies {#related} - [Security program overview](/docs/overview/) - [Policy management](/docs/policy-management/) - [HR & personnel security](/docs/hr-personnel-security/) - [Access control](/docs/access/) - [AI governance](/docs/ai-governance/) - [Incident response](/docs/ir/) - [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/) --- _Policy · v2026.06 · Owner: Engineering Lead / Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Bioscope Foundry's engineering team writes software that handles PHI on behalf of physician practices. Because Bioscope Foundry is a HIPAA **business associate**, every change to that software has to be safe to ship: secure by design, secure by default, reviewed by a human other than the author, tested against Foundry's secure-development standards, and produced by a toolchain that never lets PHI leave Foundry's FHIR service. This policy describes how we get there. {{< /callout >}} ## 1. Purpose & scope {#purpose} This policy applies to every Bioscope Foundry product surface, primarily the `conductor` TypeScript monorepo (the MSO platform running on Foundry's FHIR service), the `foundry-master-agent` Rust workspace (Atlas orchestrator and the Forge Agent tiers), the customer-facing web properties (`marketing-website`, `pureethosmed-website`), and the supporting CLIs and tooling repos. It governs how software is designed, written, reviewed, tested, and deployed, and how vulnerabilities discovered along the way are tracked to closure. Security is integrated into all phases of Foundry's product development lifecycle: - **Secure design**: application risk classification, RFC-driven design review, threat modeling, data-flow analysis. - **Secure development & testing**: secure coding standards, peer review, linting with security rules (`oxlint --type-aware`), dead-code detection (`knip`), open-source security analysis, static and dynamic application security testing, periodic penetration testing, a responsible-disclosure inbox. - **Remediation**: every finding tracked through the [Vulnerability Management](/docs/vuln-mgmt/) process; no Critical or High finding ships to production unexcepted. Detailed architectural and security documentation is maintained in Foundry's internal architecture documentation. ## 2. Policy statements {#statements} Bioscope Foundry policy requires that: \(a\) Software engineering and product development must follow security best practices. Products must be "Secure by Design" and "Secure by Default." \(b\) Quality assurance activities must be performed, including: - Peer code reviews prior to merging into the protected `main` branch; and - Thorough product testing before release (unit tests with `vitest`, end-to-end tests with `playwright` for web surfaces, `cargo test --workspace` for Rust, and `nix flake check --impure` after every flake change). \(c\) Risk assessment (threat modeling) must be performed for new products and major changes to existing products that touch PHI, authentication, authorization, or production infrastructure. \(d\) Security requirements must be defined, tracked, and implemented as part of the work item in Linear. \(e\) Security analysis must be performed for any open-source or third-party components introduced into Foundry software. \(f\) Static application security testing (SAST), including type-checking via `tsgo --noEmit`, lint with security rules via `oxlint --type-aware`, and dependency scanning, must be performed throughout development and before each release. \(g\) Dynamic application security testing (DAST) must be performed before each release for customer-facing web surfaces. \(h\) All Critical or High severity security findings must be remediated prior to release. \(i\) All Critical or High severity vulnerabilities discovered post-release must be remediated within the SLAs defined in the [Vulnerability Management Policy](/docs/vuln-mgmt/). \(j\) Any exception to remediation must be documented and approved by the Security Officer. \(k\) PHI must never leave Foundry's FHIR service (R4) boundary. PHI must not appear in source code, test fixtures, logs, prompts, agent memory, generated documentation, or commit history. Test fixtures use placeholder strings. ## 3. Development process {#process} ### 3.1 Overview {#overview} Foundry follows a release strategy that gives every production change a traceable lineage. Features, enhancements, and defects are tracked as Linear issues in the relevant project. An engineer proposes the change in a feature branch, opens a GitHub pull request, and continuous integration (GitHub Actions, pinned to commit SHAs) runs the full check suite. Once review and CI pass, changes merge into `main` and promote through environments under the [Configuration & Change Management](/docs/ccm/) process. Foundry practices continuous delivery through development, staging, and production environments. Infrastructure is written as code (Terraform / Pulumi under `infra/` in `conductor`, Nix flakes for `foundry-master-agent`) and managed in source control alongside the application. Lower environments use synthetic, placeholder data; PHI is never copied out of production. Production deployments are gated by a Linear change-management ticket that records sign-offs from engineering, security, and product as appropriate. Roll-outs happen continuously, without service impact; if a deploy degrades production, it is rolled back and the offending change is reverted from source before the proposal cycle restarts. Feature toggles allow code to land in production ahead of customer-visible enablement (dark launching); enablement of a toggle is itself a change-managed event. ### 3.2 Secure development standards {#secure-development-standards} Traceability of code changes lets Foundry's software remain a living system. Linear is the system of record for change context. Every commit and pull request should reference a Linear issue ID that explains why the change is necessary; the resulting commit history lets us trace the lineage of any line of production code. All Foundry `git` repositories are hosted in Foundry's GitHub organization and share a baseline configuration. Repos are `internal` by default. The standard can be relaxed with documented justification; exceptions are socialized to the Security Officer. Developers must document, in the change itself, any new or altered functions, ports, protocols, services, environment variables, and third-party dependencies introduced. **Branch strategy and code review process:** 1. All development happens on feature branches cut from `main`. Changes for a single feature or fix live on a single branch. - Changes must be covered by a unit test (`vitest` / `cargo test`) where feasible, or by an integration / end-to-end test (`playwright`) where unit coverage cannot exercise the behavior. - Integration tests are _required_ when unit tests cannot reliably exercise all facets of the change. 2. Developers follow conventional commit style. Commit messages are written in the present tense and start with the relevant Linear issue ID where applicable. Per Foundry organizational convention, commits do **not** include `Co-Authored-By` trailers, "Generated with Claude Code" footers, or other tool-marketing metadata. 3. Once the feature and tests are complete, a pull request is opened in GitHub. The PR description names the Linear issue, summarizes the change, and calls out anything reviewers should look for. 4. Code review happens through the PR mechanism. - Reviewers note potential issues; the author addresses them or explains why they are not applicable. - New commits to a PR reset stale approvals. - Each reviewer approves explicitly, after which the author merges into `main`. - A PR can only merge with at least one approval from someone other than the author. 5. If the change interacts with PHI (FHIR resources in `conductor`, memory events / mount security in `foundry-master-agent`), controls access to data that may contain PHI, or alters production infrastructure, security review is required before the PR can be marked complete. - The reviewer performs a secure-development review against Foundry's standards. Foundry completed a platform-wide review on 2026-02-21; its findings are binding for new web app code. - The reviewer verifies that authenticated user actions generate appropriate audit log entries: codes only, never free-text PHI. ### 3.3 Release strategy {#release-strategy} Releases follow continuous delivery into production through development, staging, and production environments. Infrastructure-as-code (Terraform / Pulumi for the AWS environment, Nix for the Rust workspace) is managed under source control, and every infrastructure change follows the same review and change-management path as application code. Detailed code-promotion and production-release procedures are covered in [Configuration & Change Management](/docs/ccm/). ## 4. Source code management {#scm} Foundry uses GitHub for source control. A designated Security Officer owns cross-cutting security concerns. Access and configuration standards include: - All developers authenticate to GitHub per the [Access Policy](/docs/access/): - SSO via the workforce identity provider, with phishing-resistant MFA enforced at the IdP. - SSH key access permitted for `git` CLI; keys are rotated and inventoried. - Every repo: - has a named owner; - is `internal` by default; public visibility requires explicit Security review; - uses the standard `CODEOWNERS` pattern for security-sensitive paths. - Branch protection on `main`: - `main` cannot be rebased; - direct pushes to `main` are blocked; - history rewrites of `main` are blocked; - deletion of `main` is blocked; - force-push is blocked. - Pull request requirements before merge: - at least one approving review from a non-author; - required status checks must pass: at minimum `pnpm check` (which runs `pnpm fmt`, `pnpm lint`, `pnpm typecheck`, `pnpm knip`, and the test suite) for TypeScript repos and `cargo test --workspace` + `nix flake check --impure` for Rust + Nix repos; - Foundry conventions forbid committing credentials, API keys, private keys, or cleartext password material of any kind. CI secret scanning and workflow linting enforce the rule, additional static analysis of workflows runs locally, and every PR is human-reviewed against it. - **Third-party GitHub Actions are pinned to immutable commit SHAs.** Floating tags (`@v3`, `@main`) are forbidden, a well-known supply-chain footgun. Workflow linting runs in CI to catch violations, with additional static analysis of workflows performed locally. Production container images are pinned to explicit version tags; content-digest pinning is a near-term roadmap item. ## 5. High-level application security requirements {#appsec} All Foundry software must include the following application security principles. Web applications must defend against the common web vulnerability classes called out in Foundry's secure-development standards and the findings of the 2026-02-21 platform review. 1. Protect sensitive data: PHI, PII, credentials, and patient-identifying tokens. PHI in transit is encrypted with TLS 1.2 or higher; PHI at rest lives only in Foundry's FHIR service and is encrypted with provider-managed or customer-managed keys (CMEK on request). 2. Provision strong access control. Identity, authentication, authorization, and accounting are enforced before any request reaches the FHIR store. Each workforce console enforces the strongest MFA factor it supports; a WebAuthn / FIDO2 passkey is enforced today on the AWS root account, with hardware security keys planned. SMS one-time codes are prohibited for workforce use, per Foundry's credential baseline. 3. Log every transaction and access: who, when, which records, the outcome. Audit log rows record machine-readable codes, never free-text PHI bodies. 4. Implement client-side security at application endpoints: CSP, SRI, secure cookies, sandboxed iframes where embedded content is unavoidable. 5. Communicate securely between services. Service-to-service traffic inside the production environment is mutually authenticated; egress from the PHI-handling account is restricted. 6. Use secure defaults. Deny by default in authorization; explicit allow lists. 7. Maintain the security of all third-party and open-source dependencies. Upgrades run on a scheduled manual review cadence, published advisories are triaged by Security, and license scanning is part of the same gate; automated dependency-update tooling is being rolled out. 8. Validate every data input. Encode every output appropriate to its context (HTML, attribute, URL, JS, SQL). Schema validation at API boundaries. 9. Deploy and configure applications securely. Terraform / Pulumi for the AWS environment, Nix for the agent runtime; secrets supplied through the managed secrets store and never embedded in code or images. 10. Perform regular vulnerability analysis and apply patches promptly, on the timelines in [Vulnerability Management](/docs/vuln-mgmt/). 11. Secure privileged access to production. Break-glass paths are logged and reviewed; standing production access is minimized. All software must complete the SAST/DAST/dependency-scan gate before reaching production. Findings flow to the [Vulnerability Management](/docs/vuln-mgmt/) process. ## 6. Secure design and application threat modeling {#design} The Foundry Security function, in collaboration with the engineering team, performs application threat modeling and risk assessment on a per-application basis. The approach blends industry-standard methods (STRIDE-style decomposition, attack-tree thinking, application-security verification checklists) with Foundry-specific concerns, most notably the PHI boundary and the agent-tier model defined in `foundry-master-agent` (Atlas at Tier 0, executives at Tier 1, Foundry ops at Tier 2, clinic-scoped clinical agents at Tier 3, sandboxed Moltworkers at Tier 4). Major changes are captured via an **RFC** process. The RFC template requires a **Security Considerations** section documenting: - identified risks, - attack vectors, - mitigating controls. Each RFC captures sufficient detail of the feature or component to be developed, including: - authentication and authorization mechanisms; - network communications and service boundaries; - data encryption in transit and at rest; - the AWS services used and whether they are HIPAA-eligible under the BAA; - logging and audit code coverage; - data-flow diagrams and PHI boundary annotations; - edge cases, drawbacks, and considered alternatives. RFCs must be approved before implementation. Security is included as a required reviewer on RFC PRs that touch PHI flow, authentication, authorization, or production infrastructure. ### 6.1 Platform design details {#platform-design-details} Architectural specifications are maintained in Foundry's internal architecture documentation, covering the system overview, the FHIR data model, and security and compliance. For the agent platform, internal documentation captures roughly twenty HIPAA-aware invariants that must hold before any change merges. ## 7. Dependencies & supply chain {#supply} Foundry treats the supply chain as part of the attack surface. - **GitHub Actions pinned to immutable commit SHAs.** Floating tags (`@v4`, `@main`) are not permitted. CI workflow linting catches violations. - **Production container images are pinned to explicit version tags.** Pinning images to their content digest is a near-term roadmap item. - **npm dependency upgrades honor a 7-day cooldown** (`minimumReleaseAge` / `--min-age 7`) where the tooling supports it. This window is intended to reduce exposure to typosquats and short-lived malicious releases. - **Inventory and scanning.** Published security advisories are triaged by Security, and dependency upgrades run on a scheduled manual review cadence; automated dependency-update tooling is being rolled out. Manual review and license scanning happen on dependency introductions. - **License hygiene.** New dependencies are reviewed for license compatibility before adoption. - **Secret hygiene.** Committing credentials is prohibited by Foundry's contributor guides, which call out the credential patterns to reject on sight: messaging-platform bot tokens, AI-provider API keys, private keys, cleartext password material, and cloud access keys. GitHub secret scanning is enabled fleet-wide and blocks pushes of high-confidence patterns. Test fixtures use placeholder strings, never real credentials. Secrets that must live in a repository are stored only in encrypted form; one-way password hashes are safe to commit because they cannot be reversed. ## 8. SAST, DAST & penetration testing {#testing} ### 8.1 Static application security testing {#static-application-security-testing} SAST runs on every PR through the standard `pnpm check` pipeline for TypeScript repos and `cargo test --workspace` + `nix flake check --impure` for Rust + Nix repos. Specifically: - **Type-check** with `tsgo --noEmit` (TypeScript-go native), not `tsc`. Type errors are a release blocker. - **Lint** with `oxlint --type-aware` (Oxidation Compiler), not ESLint. Security rules are enabled. - **Format** with `oxfmt`, not Prettier. Format drift is a release blocker. - **Dead-code detection** with `knip`. Removing unused exports reduces the attack surface. - **Manual code review** by Security on PRs that touch PHI, authentication, authorization, or production infrastructure (see §3.2). - **Periodic deep review** by Security as part of the weekly security cadence and by request via a Linear ticket on the Security project. ### 8.2 Dynamic application security testing {#dynamic-application-security-testing} DAST is run against staging instances of the customer-facing web surfaces (`marketing-website`, `pureethosmed-website`, and the `conductor` web app) before each release that materially changes attack surface. Dedicated DAST tooling is being added to the pipeline; baseline scans are also available on request to the Security function. ### 8.3 Penetration testing {#penetration-testing} Foundry commissions an external penetration test of the operating platform from a qualified independent security firm at least once per year; the first external engagement is being scheduled. The Security function also performs internal white-box penetration testing of the platform on a documented cadence. The platform-wide OWASP Top 10 review was completed on 2026-02-21. External pen-test reports are held by the Security Officer and findings are tracked in Linear under the Security project. ## 9. Responsible disclosure {#disclosure} All software contains defects, including security defects. Foundry maintains a responsible-disclosure inbox at . Researchers acting in good faith are welcomed; we commit to acknowledging reports within a reasonable timeframe, triaging and remediating in accordance with our [Vulnerability Management](/docs/vuln-mgmt/) SLAs, and crediting reporters where they wish to be credited. ## 10. Outsourced software development {#outsourced} Where Foundry engages outside developers or contracting firms to build software on its behalf, the engagement must follow the same rigor and process as internal engineering. Outsourced developers must: - develop in Foundry's secure environment (Foundry-managed laptop posture or sanctioned Codespaces), accept Foundry's security policies, and follow the same secure coding standards; - receive secure-coding training equivalent to Foundry's internal training program; - follow Foundry's source-control, code-review, and security-scanning processes; - run an endpoint-compliance agent that verifies disk encryption, patching, screen-lock, firewall, and antimalware posture. The contracting firm must demonstrate appropriate background-check practices during their own hiring process. Any outsourced engagement that may touch PHI flows is also subject to a Business Associate Agreement with the contracting firm. ## 11. HIPAA best practices for software development {#hipaa} ### 11.1 Use only HIPAA-eligible services in the cloud (and any other cloud) {#use-only-hipaa-eligible-services-in-the-cloud-and-any-other-cloud} Foundry's production environment for PHI is the **Foundry-operated FHIR service (R4)**. Amazon Web Services (AWS) is a Foundry subprocessor and operates under a Business Associate Agreement covering its HIPAA-eligible services. PHI must only flow through HIPAA-eligible services covered by that BAA. Non-eligible services may be used in support of the production environment so long as they do not have access to PHI. Where additional cloud services are introduced (for example, additional AI inference providers or analytics platforms), they may only be used to process PHI under a BAA and only via their HIPAA-eligible service offerings. References: - [AWS HIPAA-eligible services reference](https://aws.amazon.com/compliance/hipaa-eligible-services-reference/) - the Foundry-operated FHIR service (HAPI FHIR running on AWS) ### 11.2 Separate access and data between production and non-production {#separate-access-and-data-between-production-and-non-production} Separation of duties between production and non-production environments is a HIPAA compliance requirement and a Foundry policy. Production PHI is never copied to development, staging, or local environments. Non-production data sets are synthetic or thoroughly de-identified. ### 11.3 Never log PHI {#never-log-phi} It is both a security best practice and a contractual obligation under the AWS BAA to keep PHI out of application logs, prompts, agent memory, and generated documents. Logs record machine-readable identifiers and audit codes; PHI bodies stay inside Foundry's FHIR service on AWS. The `foundry-master-agent` mount-security and Beacon Layer redaction controls are designed to enforce this at the agent runtime: Moltworkers (Tier-4 sandboxed workers) cannot hold PHI by construction. ### 11.4 Include the right language in notices {#include-the-right-language-in-notices} Specific HIPAA language must be included in patient-facing terms, consents, and communications. Because Foundry acts as a business associate, patient-facing language belongs to the practice's Notice of Privacy Practices. Where Foundry communicates with patients on a practice's behalf (for example, appointment reminders), the practice's notice and identifying information are surfaced, not Foundry's. See [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/). ### 11.5 Data protection {#data-protection} Follow the requirements set out in: - [Data Management](/docs/data-mgmt/): classification model and handling matrix; - [Data Protection](/docs/data-protection/): encryption, key management, redaction; - [Business Continuity & Disaster Recovery](/docs/bcdr/): backup and recovery for PHI-containing systems. ## 12. Production system monitoring and paging {#monitoring} Production software and infrastructure are monitored continuously for health and for security-relevant events. The on-call rotation is paged via the on-call paging service when an error or anomaly is detected; secondary notifications route to Slack and email. See [Incident Response](/docs/ir/) for the response playbook and [System Audits & Monitoring](/docs/system-audits/) for monitoring controls and log retention. ## 13. Roles & responsibilities {#roles} - **Security Officer**: owns this policy, approves exceptions, owns the platform-wide secure-development review cadence and external penetration test engagement. - **Engineering Lead**: owns adherence to the development process across the fleet; resolves disputes between speed and rigor in favor of rigor where PHI or production infrastructure is involved. - **Repository owners**: named on each repo; responsible for keeping branch protection, CODEOWNERS, and required checks current. - **All engineers**: responsible for following secure coding standards, writing tests, requesting security review where required, and refusing to merge code that fails the gate. ## 14. Review & revision {#review} This policy is reviewed at least annually and whenever business, technology, or regulatory change makes it stale. Material revisions are approved by the Security Officer in coordination with the [Policy Management](/docs/policy-management/) process. Notable triggers for off-cycle review: a material update to Foundry's secure-development standards, a material change to the Foundry toolchain (e.g., a move off `oxlint`/`oxfmt`/`tsgo`), or a finding from penetration testing that exposes a process gap. ## 15. Related policies {#related} - [Vulnerability Management](/docs/vuln-mgmt/) - [Threat Detection & Prevention](/docs/threat/) - [Configuration & Change Management](/docs/ccm/) - [Access Control](/docs/access/) - [Data Protection](/docs/data-protection/) - [AI Governance](/docs/ai-governance/) - [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/) - [Framework crosswalk](/frameworks/crosswalk/) --- _Policy · v2026.06 · Owner: Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Bioscope Foundry takes a zero-trust, minimal-infrastructure, data-centric approach to security. PHI is constrained to Foundry's clinical data plane, a Foundry-operated clinical workflow database and a private FHIR R4 service running on Amazon Web Services (the cloud infrastructure subprocessor), by design and by code, never by convention alone. Non-PHI workloads (the marketing site, CI/CD, developer tooling) run on Cloudflare Workers and the identity provider under separate trust boundaries. This document describes the principles and the building blocks of the operating model. {{< /callout >}} ## 1. Purpose & scope {#purpose} In the digital age, cyber attacks against healthcare-adjacent infrastructure are inevitable. Foundry's architecture starts from that premise. This document describes the guiding principles and the building blocks of the security model, the boundary that defines PHI handling, and the operating-model controls that keep that boundary intact. The architecture covers all Foundry-operated infrastructure: the Conductor platform, the foundry-master-agent control plane, supporting SaaS, workforce endpoints, and the marketing and customer-site surface. ## 2. Policy statements {#statements} Foundry policy requires that: **(a)** Foundry's security program and operations are designed and implemented with the following objectives: - Data-centric, cloud-first; - Assume compromise: never trust, always verify; - Apply controls using least-privilege and defense-in-depth principles; - Avoid single points of compromise; - Automate wherever possible: the simpler the better, less is more; - Encourage self-management and reward good behavior. **(b)** Security remains a top priority across Foundry's business operations and product development. New features and infrastructure changes that would weaken the architecture are rejected or re-designed. **(c)** The PHI boundary is absolute: PHI may exist only inside Foundry's clinical data plane (the clinical workflow database and the FHIR R4 service, both Foundry-operated on AWS). It does not exist on local disk, in object storage outside that perimeter, in non-Foundry SaaS, in LLM prompts or completions, in agent memory, in generated documents, or in audit logs. Audit-log entries describe PHI access using machine-readable codes, not PHI content. **(d)** Production access is never available by default. Privileged access is short-lived and audited; each console enforces the strongest MFA factor available (phishing-resistant WebAuthn passkeys are the preferred factor and are enforced today on the AWS root account). SMS one-time passcodes are prohibited as an MFA method for workforce. **(e)** Architectural changes that affect PHI handling, the agent operating model, or the trust boundaries between tiers require a documented review against this policy and the [Risk Management](/docs/risk-mgmt/) policy before implementation. ## 3. Security principles {#principles} ### 3.1 Data-centric, zero-trust architecture {#data-centric-zero-trust-architecture} Zero trust is a data-centric design that places micro-perimeters around specific data assets so that granular rules can be enforced. It rejects the perimeter-centric assumption that the inside of a network is implicitly safer than the outside. The guiding principle is "never trust, always verify." At Foundry there is no implicit trust for any entity, users, devices, applications, or packets, regardless of network location. Verifying that authorized entities are doing only what they are allowed to do is mandatory. - No internal network. 100% cloud. - Fully segregated workloads with granular policy enforcement. - Individually secured devices. No production access by default. ### 3.2 Minimal infrastructure & short-lived processes {#minimal-infrastructure-short-lived-processes} Foundry extends zero trust with a minimal-infrastructure posture. Where reasonable, we use managed services rather than self-hosted infrastructure, both to use the security investment of cloud providers and to integrate via APIs that make security operations programmable. Reducing always-on infrastructure reduces the attack surface; services that are not used are turned off rather than left idle. - No direct administrative or broad network connectivity into production. - Compute is short-lived where possible: serverless functions, ephemeral containers, just-in-time sessions. - Minimal persistent attack surface. ### 3.3 Least-privilege, temporary access {#least-privilege-temporary-access} Foundry security operations assume that compromise can happen at any time, to any device, with little or no warning. When designing operations, we identify potential single points of compromise and avoid having "keys to the kingdom." Compromise of any single system, user, or credential should not lead to broad or full compromise of the entire infrastructure or operations. - Need-based access control for both workforce members and computing services. - Access to critical systems and PHI is closed by default and granted on demand. - Phishing-resistant multi-factor authentication for privileged access. - No single points of compromise. - Secrets (API keys, signing keys, SSH keys) must remain secret at all times and are stored in the approved secret broker, never in source code. ### 3.4 Immutable builds and deploys {#immutable-builds-and-deploys} The Foundry platform is composed of independently built and deployed components. Before deployment to production, changes are validated in lower environments that are isolated from production. Once an immutable build has been validated in lower environments, it is promoted to production with the same artifact, no rebuilds. Infrastructure changes, databases, storage, load balancers, DNS, and IAM, are also expressed as source code and deployed through the same mechanisms as applications. Infrastructure as code is a prerequisite for fully automated deployments with minimal human touch. - Infrastructure as code with active protection. - Automated security scans and full traceability from commit to production. - Hands-free deployment ensures each build is free from human error or malicious contamination. ### 3.5 End-to-end data protection and privacy {#end-to-end-data-protection-and-privacy} Foundry is committed to the confidentiality, integrity, and availability of practice and patient data we handle as a business associate. Data is protected with end-to-end encryption, strong access control, and disciplined key management; internal workforce members do not access PHI directly in production for non-operational purposes; access for support requires a documented break-glass procedure that is logged and reviewed. - Data is encrypted at rest (AES-256) and in transit (TLS 1.2+). - Customer-managed encryption keys (CMEK) are available where a member practice's BAA so requires. - Workforce members do not access practice PHI in production for any purpose not permitted by the BAA. ### 3.6 Strong yet flexible user access {#strong-yet-flexible-user-access} Access control matters too much to get wrong. Doctor onboarding uses email magic links with short-lived, HttpOnly sessions. The production workforce identity provider is being selected under _ADR-011_ (a signature-verifying OIDC IdP with MFA); until it lands, each console enforces MFA locally with the strongest factor it supports. Patients interact with practice-issued surfaces; where Foundry-operated patient-facing surfaces exist, they use email or SMS one-time passcodes. (SMS OTPs are **not** used as an MFA method for workforce.) - OAuth 2.0 / OpenID Connect will be the federated identity fabric once the workforce IdP is wired; - Phishing-resistant WebAuthn passkeys are the preferred MFA factor across every surface that supports it and are enforced today on the AWS root account per the account-setup runbook; dedicated hardware security keys are planned as sealed break-glass authenticators; - A cloud identity broker fronts access to non-PHI cloud workloads; - Short idle and absolute session timeouts on PHI-handling applications. ### 3.7 Watch everything, even the watchers {#watch-everything-even-the-watchers} You can't protect what you can't see. Foundry inventories its assets, documents its operations, identifies its weaknesses, and instruments its systems and data flows. This includes risk analysis, threat modeling, vulnerability assessment, application scanning, and periodic penetration testing. Where manual effort is unsustainable, security operations are automated so that monitoring scales with operational complexity. Foundry consumes threat intelligence from community feeds and from healthcare-specific information-sharing organizations such as Health-ISAC (membership being established) to stay current on attacker activity and methodology. - All environments are monitored; all events are logged; all alerts are analyzed; all assets are tracked. - No privileged access without prior approval or full auditing. - Monitoring redundancy is deployed to watch the watchers: the integrity of the audit pipeline is itself monitored. ### 3.8 Centralized and automated operations {#centralized-and-automated-operations} Wherever possible, Foundry translates policy and compliance requirements into reusable code, enabling fast and scalable enforcement rather than reliance on written policy alone. Endpoint posture is enforced by an MDM agent. Access-control policies for production are expressed as IAM bindings and applied via infrastructure as code. Audit-log routing is configured rather than hand-curated. Automation makes it possible to centralize security operations: event aggregation and correlation, the orchestration and management of previously siloed security controls, and remediation. - API-driven, cloud-native security fabric that centrally monitors security events, visualizes risk, automates compliance audits, and orchestrates near-real-time remediation; - Policy as code wherever feasible. ### 3.9 Usable security {#usable-security} Security benefits from transparency and should operate as an open book within the organization. Foundry's security standards and practices are available to all workforce members for feedback prior to adoption, in the same manner as code review and pull requests in engineering. Usability and practicality matter. A security control that is not used is not effective, no matter how strong it appears on paper. Impractical security generates noise, a false sense of safety, and unnecessary cost. - All workforce members receive security-awareness training (see [Roles, responsibilities & training](/docs/roles-responsibilities-training/)); - Simple policies, processes, and procedures; - No shadow IT: tools that handle Foundry data must be approved and inventoried; - DevSecOps with shared goals and an integrated team; - Processes encourage self-management and reward good behavior. ### 3.10 Compliant and verified {#compliant-and-verified} Security and compliance are different things; we cannot have one without the other. - HIPAA-compliant as a business associate; - Foundry's secure-development standards apply to all new web application code, refreshed by periodic platform-wide review (most recent: February 2026); - Credential baseline aligned with current authentication best practice applied; - Subject to periodic external assessment; findings are tracked to remediation in the risk register. 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](/frameworks/crosswalk/). ## 4. Security architecture {#architecture} ### 4.1 Three operating environments {#three-operating-environments} Foundry's architecture rests on three operating environments, each with its own trust boundary and controls: | Environment | What runs here | Provider / location | | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | **PHI cloud** | The Foundry's FHIR service instance (FHIR R4), the Conductor backend services that mediate FHIR access, the practice-scoped audit log, and the encryption key material that protects PHI at rest. | Amazon Web Services, isolated account, US region (us-east-2, Ohio). | | **Non-PHI cloud** | The marketing and customer-site surface, the CI/CD pipeline, the static asset hosting, the Conductor frontend serving non-PHI bundles, and the foundry-master-agent control plane for non-PHI workloads. | Cloudflare Workers (Static Assets); AWS for selected workloads, build, and storage. | | **Workforce / collaboration** | Identity, email, calendaring, documents, source code, ticketing, Slack, and the AI tooling allowed for non-PHI use. | the identity provider, GitHub, Linear, Slack, and the AI tools approved by the AI Governance policy. | Data does not flow between these environments except through documented, audited paths. PHI does not leave the PHI cloud. ### 4.2 Architecture diagrams {#architecture-diagrams} Detailed architecture diagrams of the in-scope networks, endpoints, applications, and security operations are developed and maintained by the security team. Network and trust-boundary diagrams are updated at least every six months and after any material change. ### 4.3 Cloud architecture {#cloud-architecture} Foundry's cloud architecture is cloud-native by design: - Designed for the cloud using true multi-tenant architecture where each member practice's data is logically segregated within the FHIR store and access-controlled per practice; - Auto-scaling across multiple regional zones to support availability targets; - Foundry services deployed inside private subnets of a Virtual Private Cloud (VPC) with explicit egress controls; - Use of provider compliance posture (AWS HIPAA-eligible services) under executed BAAs; - Ongoing security testing by the provider plus Foundry's own scanning and assessment. The practice benefits from this posture by gaining: - Infrastructure tailored to the practice's clinical and operational patterns; - The economic benefit of shared infrastructure without sharing data; - Near-unbounded compute and storage capacity; - Automatic backup and recovery (see [BCDR](/docs/bcdr/)); - Continuous improvement under the change-management process; - Faster adoption of new clinical and operational technology. ### 4.4 Evolution of compute {#evolution-of-compute} Foundry favors abstractions higher up the cloud stack where the security trade-offs are favorable: 1. **Bare metal:** a computer in someone else's data center. 2. **Virtual machine:** a portion of a computer in someone else's data center; created from an image. 3. **Container:** application libraries and code packaged independently of the host OS. Simpler to scale; no duplication of core OS processes. 4. **Function:** application code that runs in a managed container. Foundry uses functions and managed containers as primary building blocks for the platform because they deploy quickly, scale automatically based on incoming requests, and are short-lived, which minimizes attack surface compared to long-running servers. ## 5. Tiered agent operating model {#agents} Foundry's AI-enabled back office is operated through a tiered agent operating model implemented in foundry-master-agent. The tiers exist to make trust boundaries explicit between agents that may handle PHI and agents that cannot. This is a defining feature of Foundry's architecture and is referenced throughout the rest of the program (see [AI Governance](/docs/ai-governance/) for the controls applied to each tier). | Tier | Name & purpose | PHI eligibility | | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------- | | Tier 0 | **Atlas**: the master orchestrator and control plane. Routes work, enforces policy, owns the deterministic placement and migration logic. | Mediates PHI access; never holds raw PHI itself. | | Tier 1 | **Executive assistants: Goose, Maverick.** Workforce-facing assistants that operate over org communications, scheduling, and meta-work. | Constrained to non-PHI surfaces; do not retrieve patient records. | | Tier 2 | **Foundry operations and specialist agents.** Compliance, ops, knowledge curation. | Non-PHI by default; PHI-eligible agents at this tier are explicit, named, and per-task. | | Tier 3 | **Clinic-scoped clinical agents.** Practice-specific agents that operate over a single practice's data on its behalf. | PHI-eligible within the scope of one practice and one task, under that practice's BAA. | | Tier 4 | **Moltworkers: sandboxed workers on `sandboxed_public` hosts.** Run untrusted or experimental tasks (e.g., scraping a public website, executing a new tool). | **Cannot** hold PHI by construction. Cannot reach the PHI cloud. Cannot read `:private` or clinic-scoped memory. | The **Beacon Layer** is the redaction surface that turns clinic-scoped data into sanitized physician-facing insights. The Beacon Layer never exposes raw PHI or peer-practice `:private` memory across the boundary. Anything that goes to a Tier-1 executive assistant or to a workforce member outside the practice has passed through Beacon Layer redaction. The orchestrator's deterministic placement and migration planner is referred to internally as the **Vector Engine**. (This is a deterministic, scored router; it is not vector search.) ## 6. Metrics & continuous monitoring {#metrics} A defined set of metrics and KPIs is used to measure, report on, and optimize the security program and its controls. A security scorecard is produced each business quarter with updates to the key metrics, PHI access patterns, endpoint compliance, identity hygiene, vulnerability remediation against SLA, change-management adherence, and open incidents, to measure the program's adoption and effectiveness. The scorecard is owned by the Security Officer and reviewed at the quarterly Security Committee meeting. Key metrics are summarized for senior leadership; the underlying data is available to Security Committee members on request. ## 7. Quality of service {#qos} Foundry strives to provide a high quality of service to member practices, accomplished through a security architecture that encompasses operations end-to-end and supports availability, integrity, and confidentiality together. An overview of Foundry's architecture is available above. Foundry uses a highly scalable cloud architecture to provide system quality. All systems are monitored and measured in real time as described in [BCDR](/docs/bcdr/) and [System audits & monitoring](/docs/system-audits/). Foundry uses a DevSecOps methodology as described in the [Secure SDLC](/docs/sdlc/) policy to ensure a smooth delivery process for all systems and applications. Service status for external customer-facing surfaces is published at delivered in-platform and by email to designated contacts. ## 8. Review & revision {#review} This policy is reviewed at least annually and whenever a material change to the platform architecture, the agent operating model, or the PHI boundary requires reassessment. Material revisions are approved by the Security Officer and reviewed at the Security Committee, in coordination with the [Policy Management](/docs/policy-management/) process. ## 9. Related policies {#related} - [Security program overview](/docs/overview/) - [Risk management](/docs/risk-mgmt/) - [AI governance](/docs/ai-governance/) - [Access control](/docs/access/) - [Data protection](/docs/data-protection/) - [Configuration & change management](/docs/ccm/) - [Business continuity & disaster recovery](/docs/bcdr/) - [System audits & monitoring](/docs/system-audits/) --- _Policy · v2026.06 · Owner: Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Bioscope Foundry audits, monitors, and assesses access and activity across the systems that process or store production data and PHI. The aim is to ensure controls work in practice, to detect compromise early, and to generate the evidence HIPAA requires Foundry to keep as a business associate. Audit records covering PHI reads and writes are retained for at least **six years**. {{< /callout >}} ## 1. Purpose & scope {#purpose} This policy governs how Bioscope Foundry audits, monitors, and assesses the access and activity of systems and applications that process or store production data and protected health information (PHI). It applies to every Foundry-operated system in scope of the HIPAA Security Rule, including the `conductor` operating platform, Foundry's FHIR service (R4) data store, the `foundry-master-agent` control plane, the Forge Agent fleet (including Tier-4 Moltworkers), Foundry-managed workstations, the workforce identity provider, source control (GitHub), and continuous-integration systems. HIPAA Security Rule reference: this policy supports § 164.308(a)(1)(ii)(D) (information system activity review) and § 164.312(b) (audit controls). The HIPAA Security Rule requires that healthcare organizations and their business associates implement reasonable hardware, software, and procedural mechanisms that record and examine activity in systems that contain or use PHI. Foundry makes good-faith efforts to safeguard the privacy and security of information through an auditing approach consistent with available resources. It is Foundry's policy to safeguard the confidentiality, integrity, and availability of applications, systems, and networks. To ensure that appropriate safeguards are in place and effective, Foundry audits access and activity to detect, report, and guard against: - Network vulnerabilities and intrusions; - Breaches of confidentiality and security of PHI; - Performance problems and flaws in applications; - Improper alteration or destruction of PHI; - Out-of-date software and software known to have vulnerabilities; - Policy violations by Forge Agents or workforce members. ## 2. Policy statements {#statements} Bioscope Foundry policy requires that: \(a\) All critical computing systems and software, both virtual and physical, enable audit logging. \(b\) Audit logs include sufficient information to identify _who did what, when, where_, and with what outcome. \(c\) Audit logs covering PHI access and security-relevant events are retained for at least six years. \(d\) An annual audit of Foundry security controls is conducted, either by a designated internal audit team or a qualified external audit firm. \(e\) Access reviews are performed quarterly for general access and monthly for privileged access; unused or invalid access is removed as a result of each review. \(f\) Audit logs never contain PHI bodies. Logs record machine-readable identifiers and event codes; PHI content does not appear in log lines, including in agent `memory_events`. ## 3. Types of system audits {#types} Foundry's auditing processes fall into three categories. ### 3.1 Configuration and activity monitoring {#configuration-and-activity-monitoring} Logging, monitoring, scanning, and alerting on a system, account, or environment. This is performed _continuously_ as part of Foundry operations. Examples include: - **User.** User and account-level audit trails monitor commands directly initiated by the user, identification and authentication attempts, and data and services accessed. - **Application.** Application-level audit trails monitor user activities, including data accessed and modified and specific actions performed. - **System.** System-level audit trails monitor user activity, applications accessed, file integrity, and other system-defined actions. - **Network.** Network-level scans or audit trails monitor what is operating, identify vulnerabilities, and run penetration probes. - **Traffic.** Inbound and outbound traffic to production and restricted environments, for example, firewall logs and AWS VPC Flow Logs around the account that hosts Foundry's FHIR service. - **Data.** All successful and failed attempts at production data access and editing, including FHIR resource reads, writes, and exports through Foundry's FHIR service. Audit events are routed to AWS CloudTrail (management and data events). - **Agent.** Forge Agent decisions, policy evaluations, mount events, and Beacon Layer redaction outcomes, recorded as machine-readable audit codes in `memory_events`, never raw PHI content. Each event records, at minimum: origin, destination, action performed, timestamp, and any other relevant detail available. ### 3.2 Access reviews {#access-reviews} Review of all user and service accounts and permissions across Foundry operational environments, including AWS accounts, the identity provider, GitHub, and Linear. - Foundry uses a Cloud Security Posture Management (CSPM) tool to automatically pull configurations from cloud environments, including: - AWS IAM policies and roles; - AWS VPC, security group, and network configuration; - Foundry's FHIR service access bindings; - the identity provider users, groups, and application access; - Network access via VPC Flow Logs. - Data is collected on demand, on a scheduled cadence, or in response to environment changes detected by the CSPM. - The CSPM aggregates and analyzes user and application access. - Access to systems not covered by the CSPM is reviewed manually via the SIEM (see §10). - Foundry Security completes access reviews **monthly for privileged access** and **quarterly for general access**, including workforce accounts. Privileged access includes any role that can read, write, export, or change permissions on the PHI store; any AWS account administrator or organization owner; any GitHub Org Owner; and any the identity provider Super Admin. - Unused or invalid access is removed as a result of each review. ### 3.3 Compliance and controls audit {#compliance-and-controls-audit} An audit performed against the technical, administrative, and physical controls defined in Foundry policies and procedures, to measure adoption and effectiveness. Performed by a designated internal audit team or an external audit firm at defined intervals or triggered by a specific event. Potential trigger events include: - Scheduled compliance audit or assessment (e.g., annual HIPAA assessment, ISO surveillance audit when in scope); - High-risk or problem-prone incidents or post-incident review; - Practice or partner complaints, including BAA-related complaints; - Identification of significant security vulnerabilities; - Atypical patterns of activity; - Failed authentication attempts above the alerting threshold; - Remote access patterns or activity post termination; - Random audits. ## 4. Security event analysis {#events} Security logs, events, and audit trails are reviewed by the Security team with the assistance of automated systems and processes. - Audit logs are automatically analyzed and correlated by the monitoring solutions and a centralized SIEM / log platform (see §10). - Rules and policies identify suspicious activity, vulnerabilities, and misconfigurations. - Alerts are triggered upon identification of an issue and routed to responsible staff via email, Slack, or the monitoring dashboard. - Analysis is prioritized by alert severity. High-severity alerts are reviewed within 24 hours; SEV-1/SEV-2 alerts page the on-call rotation immediately per [Incident Response](/docs/ir/). - The incident-response process is followed as needed. - Patches and updates are applied in a timely manner per [Vulnerability Management](/docs/vuln-mgmt/). ## 5. Internal and manual auditing {#manual} Additional manual reviews, for example, user account and access auditing, may be necessary from time to time. These can be triggered by the events listed in §3.3. Responsibility for audit activity is assigned to Foundry's Security Officer. The Security Officer: - Assigns the task of generating reports for audit activities to the workforce member responsible for the application, system, or network; - Assigns the task of reviewing audit reports to the responsible workforce member, the Privacy Officer, or another individual deemed appropriate; - Organizes and oversees a team structure for audit compliance activities (parameters, frequency, sample sizes, report formats, evaluation, follow-up); - Reviews all connections to Foundry-controlled networks for appropriate restrictions to services, ports, and destinations. Exceptions are reviewed annually. The manual review process defines and includes: - A description of the activity and a rationale for performing the audit; - Identification of personnel to perform the review (workforce members do not review audit logs that pertain to their own system activity); - Frequency of the audit; - Determination of significant events requiring further review and follow-up; - Identification of appropriate reporting channels for audit results and required follow-up. Manual audits and review activities are tracked in Linear. Audits may be carried out internally or by an external third-party vendor. Where possible, the external auditing vendor does not also provide Foundry's IT services, to maintain separation of duties. ## 6. Audit requests {#requests} 1. An audit for a specific cause may be requested by, among others, the Privacy Officer, Security Officer, a practice (covered entity), a partner, or an application owner. 2. A request must include time frame, frequency, and nature of the request. 3. A request must be reviewed and approved by the Privacy Officer and/or Security Officer before proceeding. Under no circumstances is detailed audit information shared with parties without proper permissions and access. - If the audit discloses that a workforce member has accessed PHI inappropriately, the minimum-necessary information is shared with the Security Officer to determine appropriate sanctions or corrective action. - Only de-identified information is shared with practices or partners regarding the results of an investigative audit, communicated by the Privacy Officer or designee. Prior to communicating with practices or partners, Foundry consults legal counsel and risk management as appropriate. ## 7. Review and reporting of audit findings {#reporting} 1. Audit information that is routinely gathered is reviewed in a timely manner, at least monthly, by the responsible workforce members. Additional reviews are performed as needed to confirm proper data is being captured and retained. 2. The reporting process supports meaningful communication of audit findings to relevant workforce members, practices, or partners. - Significant findings are reported immediately in writing. The Foundry incident-response form may be used to report a single event. - Routine findings are reported to the sponsoring leadership structure in a written report format. 3. Audit results are limited to internal use on a minimum-necessary, need-to-know basis. Audit results are not disclosed externally without administrative or legal counsel approval. 4. Security audits are a confidential, internal monitoring practice that may be included in Foundry's performance-improvement activities. Audit results are disclosed only to administrative-level oversight structures, and information that may further expose organizational risk is shared with extreme caution. Generic security audit information may be included in organizational reports; individually identifiable information is not. 5. Where evaluation and reporting indicate that corrective action is required, the action is undertaken, documented, and shared with the responsible workforce members, practices, or partners. ## 8. Remediation of control deficiencies {#remediation} Most controls are continuously monitored and reported via automation. Control deficiencies identified by an internal or external system audit are documented and reviewed with management. Security works with the corresponding control owner to prioritize and mitigate the deficiency, including corrective actions, additional controls, or adjustments to existing controls. Remediations are tracked to closure in Linear and reflected in the next control-audit cycle. ## 9. Audit trails and application security events logging standard {#trails} Foundry logging standards require application and system logs to contain sufficient information to determine **who did what, when, where** and record security and audit events and generate evidence for unauthorized activity. All systems and software built at Foundry have the following security-event logging enabled in addition to standard application logging. 1. All security log events have the following attributes at minimum: - Timestamp of the event (synchronized to an approved time source); - Identifier of the principal performing the action (such as user ID or service account); - Location, including both origin (such as hostname or IP) and target (such as host, service, or resource); - Activity or action (such as log in, log out, create, read, update, delete of a resource). The action may be logged as and determined by the HTTP request method and the API endpoint; - Event description and additional details may be logged depending on the system or application. 2. The following types of security events are logged at minimum: - User and group administration activities (user or group added, updated, deleted; access granted or revoked); - All login attempts, successful and unsuccessful, including the source IP address; - All interactive logoffs; - Privileged actions (configuration changes, application shutdown or restart, software update); - Major application events (application failure, start and restart, shutdown); - Any and all actions performed on critical resources, including reads, writes, and exports against Foundry's FHIR service FHIR store; - Forge Agent decisions and policy evaluations, recorded as audit codes in `memory_events`. 3. All application and system logs do not include (removed or masked): - Any sensitive information, PHI, or personally identifiable information (PII); - except for IP addresses; - usernames and logins may be logged as part of authentication logging; - for user-action auditing, opaque IDs are used in place of usernames or logins wherever possible. - Authentication and session tokens, user credentials. 4. Security events and audit logs are: - Always accessible to the monitoring system and team; - Protected from any changes (append-only where supported); - Monitored with alerting in place, including alerts when expected log events stop arriving for a defined period. 5. All Foundry IT infrastructure has system clocks synchronized. Examples of recommended application events for logging and their auditing purpose: | Event | Purpose | | ------------------------------------------------------------ | ----------------------------------------------------------------- | | Client requests and server responses | Forensics and debugging; detail level defined by the application. | | Successful and unsuccessful login attempts | Authentication. | | Successful and failed access to application resources | Authorization, escalation of privileges. | | Excessive amount of requests from a client | Brute force, malicious bots, denial-of-service. | | Emails sent by the application | Spamming, social engineering. | | Foundry's FHIR service admin activity and data-access events | PHI access auditing. | | Forge Agent policy evaluations | AI accountability and post-incident reconstruction. | Logging configuration is documented in: - AWS CloudTrail and service logs (management and data events) on the accounts hosting `conductor` and the FHIR service; - GitHub organization audit log (code, CI, branch protection, access events); - the identity provider audit log (identity, admin, drive, login events); - Linear (issue, comment, and admin events). ## 10. Audit trail integrity, retention, and SIEM {#retention} 1. Audit logs are protected from unauthorized access or modification; their content is made available only when needed to evaluate a security incident or for routine audit activities outlined in this policy. 2. All audit logs are encrypted in transit and at rest. 3. Where possible, audit logs are stored on a system separate from the audited application to minimize the impact of auditing on the audited system and to apply separation of duties, protecting audit trails from system administrators of the audited system. - Logs from AWS CloudTrail, GitHub, and the identity provider are aggregated into the centralized log platform for analysis and long-term retention. 4. Reports summarizing audit activities are retained for at least **six years**, consistent with HIPAA recordkeeping requirements at 45 CFR § 164.530(j). 5. Raw event data is retained locally in the source environment for a defined window (typically 30 days), then encrypted and moved to long-term storage and retained for at least the HIPAA-required period for PHI-related logs. Other security-relevant logs are retained for a minimum of one year unless a longer retention is required by a specific use case (litigation hold, incident investigation). 6. Raw event data may be summarized into aggregated audit reports after the initial retention window, provided the aggregated reports retain the detail required to satisfy HIPAA audit-control obligations. ## 11. Access reviews {#access-reviews} Access reviews are a specific subset of activity monitoring focused on identity: - **Quarterly**: general workforce access reviewed across the identity provider, GitHub organizations, Linear, the AWS organization, and Foundry-owned SaaS. Inactive accounts are removed; group memberships are validated against current role. - **Monthly**: privileged access reviewed (AWS account admin / organization owner; Foundry's FHIR service admin/editor roles; GitHub Org Owner; the identity provider Super Admin; Atlas / control-plane admins; any role with break-glass capability). Each privileged grant is justified or revoked. - **On change**: access reviewed at workforce role change, internal transfer, or contract change. - **On departure**: all access removed within the timeframe set by the [HR & personnel security](/docs/hr-personnel-security/) policy. Departures of privileged users are audited end-to-end within 24 hours. Each access review produces a record retained in line with §10. ## 12. Auditing practice and partner activity {#partners} 1. Periodic monitoring of practice (covered entity) and partner activity is performed to ensure access and activity are appropriate for the privileges granted and necessary to the arrangement between Foundry and the third party. Foundry takes care that practices and partners do not gain access to data outside their own environments. 2. If a practice or partner has exceeded the scope of access privileges, Foundry management and security remediate the problem immediately and notify the practice. 3. If a practice or partner has violated the terms of the BAA or any HIPAA requirement, Foundry takes immediate action to remediate the situation. Continued violations may result in suspension or termination of the engagement. ## 13. Auditing and assessment tools {#tools} Foundry's Security Officer is authorized to select and use assessment tools designed to detect vulnerabilities and intrusions. Use of such tools against Foundry systems and environments by others, including practices and partners, is prohibited without the explicit authorization of the Security Officer. Tools may include: - Scanning tools and devices; - Password-cracking utilities; - Network sniffers; - Security agents installed locally on servers and endpoints (and on workstations via MDM); - Passive and active intrusion-detection systems; - Penetration testing tools. Vulnerability testing software is used to probe the network to identify what is running, whether publicly known vulnerabilities have been corrected, and whether the system can withstand attacks aimed at circumventing security controls. Penetration testing of Foundry production systems is authorized only in writing by the Security Officer; agreements with third-party testers include a written rules-of-engagement document. ## 14. Training, education, awareness {#training} Foundry workforce members are provided training, education, and awareness on safeguarding the privacy and security of business and patient data. Foundry's commitment to auditing access and activity is communicated through onboarding, ongoing training opportunities, and the applicable policies in this Trust Center. Workforce members are made aware of their responsibilities with respect to privacy and security, and of the sanctions that follow if auditing detects a workforce member's failure to comply with organizational policies. Foundry's member practices are provided with the necessary information to understand Foundry's auditing capabilities. Practices remain responsible for logging, auditing, and retention of any application hosted outside Foundry environments, even if that application integrates with the Foundry platform. ## 15. Roles & responsibilities {#roles} - **Security Officer**: owns this policy; selects and authorizes assessment tools; reviews and approves audit requests; ensures access reviews are completed on cadence. - **Privacy Officer**: co-approves audit requests touching PHI access; reviews audit results before any external disclosure. - **Security Engineering**: operates the SIEM, CSPM, and detection rules; investigates alerts. - **Platform Engineering**: ensures all systems and services emit the required audit events. - **Workforce members**: refrain from reviewing audit logs that pertain to their own activity; cooperate with audits; report suspected misuse. - **External auditors**: perform the annual control audit under written engagement, with separation of duties from Foundry IT service provision. ## 16. Review & revision {#review} This policy is reviewed at least annually and whenever business, technology, or regulatory change makes it stale. Material revisions are approved by the Security Officer in coordination with the Policy Management process. ## 17. Related policies {#related} - [Incident Response](/docs/ir/) - [Breach Notification](/docs/breach/) - [Business Continuity & Disaster Recovery](/docs/bcdr/) - [Access Control](/docs/access/) - [Vulnerability Management](/docs/vuln-mgmt/) - [HR & Personnel Security](/docs/hr-personnel-security/) - [Vendor & Third-Party Risk](/docs/vendor/) - [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/) --- _Policy · v2026.06 · Owner: Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} To preserve the confidentiality, integrity, and availability of the PHI Foundry stores, processes, and transmits on behalf of physician practices, Foundry runs layered threat detection and prevention controls, across endpoints, networks, the AWS control plane, and the application surface, and subscribes to the threat intelligence feeds that warn us before something hits. {{< /callout >}} ## 1. Purpose & scope {#purpose} This policy applies to every system that participates in delivering Foundry's services to physician practices: workforce endpoints (laptops, mobile devices), the AWS production environment (the clinical workflow database, Foundry's FHIR service, supporting services, and the workloads running on top of them), the customer-facing web surfaces, and the multi-tier agent runtime. It defines the threat-detection and prevention controls Foundry operates, the signals they generate, and how those signals flow into Incident Response. ## 2. Policy statements {#statements} Bioscope Foundry policy requires that: \(a\) All critical systems, assets, and environments, including the AWS production environment, workforce endpoints, and the agent runtime, must implement real-time threat detection or prevention controls appropriate to their tier. \(b\) Detection signals must aggregate to a central monitoring and alerting surface that the Security function reviews continuously; high-severity alerts page the on-call engineer. \(c\) Foundry monitors threat-intelligence sources relevant to its dependency surface and operating environment, and triages relevant advisories through the [Vulnerability Management](/docs/vuln-mgmt/) process. ## 3. Endpoint malware protection {#malware} 1. All workforce endpoints (laptops, desktops) must run endpoint protection. - Endpoint detection and response (EDR): the EDR agent provides behavior-based threat detection and quarantine. - Hosts are scanned continuously for malicious binaries in critical paths and on file events; additional scheduled scans run at reboot and on a recurring cadence. - Signature and behavior models are kept current through automatic vendor updates. - Logs of scans and detections are retained per [System Audits & Monitoring](/docs/system-audits/). 2. Detected malware is evaluated and contained following the [Incident Response](/docs/ir/) process. Endpoints suspected of compromise are isolated from Foundry's networks until cleared. 3. Foundry endpoints are issued for Foundry business use. Personal use is restricted per [HR & Personnel Security](/docs/hr-personnel-security/). ## 4. Firewall & network controls {#firewall} Firewall protection is implemented at three layers: - **Network**: VPC security-group and firewall rules scope ingress and egress to and from the healthcare data account; edge WAF and DDoS protections are being finalized as part of the network-hardening rollout. The healthcare data account sits behind network perimeter controls to limit exfiltration paths. - **Host**: local firewalls are enabled on managed workforce endpoints; production workloads run inside the AWS network perimeter and accept only mTLS-authenticated service-to-service traffic. - **Application**: a web application firewall protects customer-facing web surfaces against common web attacks (XSS, injection, scraping, DoS). Marketing-tier surfaces (`marketing-website`, `pureethosmed-website`) run on Cloudflare Workers Static Assets behind Cloudflare's standard protections. ## 5. Network intrusion detection {#nids} ### 5.1 Detection in the AWS production environment {#detection-in-the-aws-production-environment} Foundry's PHI-handling production environment runs in AWS. Real-time detection in that environment is built from: - **AWS CloudTrail** from the healthcare data account is ingested by cloud-native threat-detection tooling for anomaly and threat detection; VPC flow-log coverage is being finalized as part of the network-hardening rollout. - **Edge protection** for internet-facing endpoints via cloud-provider WAF and DDoS services, being finalized as part of the network-hardening rollout. - **network perimeter controls** restrict data movement out of the healthcare data account. Alerts fire on perimeter violations. - **Foundry's FHIR service access logs** are monitored for unusual patterns: bulk reads, off-hours access, access by service accounts outside their declared scope. ### 5.2 Detection in office and home networks {#detection-in-office-and-home-networks} Foundry is a remote-first organization without a managed office network. Workforce members connect from home networks and trusted public networks. Endpoint posture (EDR + MDM) and federated identity compensate for the absence of an office firewall; access to production is mediated by identity, not network position. ## 6. Host intrusion detection {#hids} Host-based detection is provided by the EDR agent on workforce endpoints and by container/host runtime monitoring on provider-managed compute. Behavioral detections that match known attack techniques (e.g., suspicious child processes, credential dumping, persistence implants) are alerted to Security in real time. ## 7. Web application protection {#waf} Customer-facing web surfaces are protected against common attacks (SQL injection, XSS, CSRF, DoS/DDoS) by their hosting platform's WAF: - **`conductor` application**: edge protection on the load balancer in front of the application services, being finalized as part of the network-hardening rollout. - **Marketing surfaces** (`marketing-website`, `pureethosmed-website`), Cloudflare Workers Static Assets with Cloudflare's standard managed rule set and rate limiting. The application layer also implements defense-in-depth against common web vulnerability classes per Foundry's secure-development standards and the 2026-02-21 platform review (see [Secure SDLC](/docs/sdlc/) §5). ## 8. Agent-runtime threat controls {#agents} The `foundry-master-agent` runtime introduces threat-detection considerations distinct from a traditional web application: the system is multi-tier (Atlas at Tier 0; executives, ops, clinical agents, and sandboxed workers across Tiers 1–4) and operates on behalf of human principals over PHI-eligible mounts. The runtime's HIPAA-aware invariants (documented in Foundry's internal engineering guides) are themselves a class of detection: any code path that would let a Tier-4 Moltworker hold PHI, that would let a clinic-scoped Tier-3 agent reach another clinic's data, or that would let free-text PHI escape into audit logs, fails the test suite. Specifically: - **Mount-security checks** enforce the tier-to-mount contract: Moltworkers cannot mount PHI-eligible volumes. - **Beacon Layer redaction** separates sanitized physician-facing insight surfaces from raw PHI; the Beacon Layer never exposes raw PHI or peer-private memory. - **PHI-event routing** in the agent runtime sends PHI-relevant events through a dedicated audit-event channel rather than the general object registry, with audit codes (not free-text content) emitted to the audit log. - **Atlas Vector Engine** placement and migration decisions are deterministic and auditable; placement violations are detectable in post-hoc audit. - **`nix flake check --impure`** runs after every flake change and is part of the gate before any agent build is promoted to production. ## 9. Centralized SIEM & correlation {#siem} Security events and alerts from endpoint EDR, AWS detection, WAF, Foundry's FHIR service access logs, and application audit logs are aggregated to a central detection surface, the centralized log platform (rollout in progress). Correlation rules surface multi-source anomalies (e.g., an unusual workforce login followed by an out-of-scope FHIR query). High-severity alerts page the Security on-call engineer; lower-severity alerts are reviewed in the routine security cadence. Retention of security-relevant logs follows the schedule defined in [System Audits & Monitoring](/docs/system-audits/); PHI never appears in those logs by design. ## 10. Threat intelligence monitoring {#ti} Foundry monitors a tailored set of threat-intelligence sources to anticipate threats relevant to its stack: - **CISA advisories**: Known Exploited Vulnerabilities catalog and emergency directives. - **provider security bulletins**: including AWS advisories for ECS, RDS, Lambda, IAM, and CI/CD tooling. - **AI provider security disclosures**: Anthropic and OpenAI security bulletins and model-card security notes (relevant because the agent platform consumes their APIs). - **Upstream maintainer advisories** for the dependencies of `conductor` (TypeScript / Node ecosystem, Vite, React, Hono, FHIR client libraries) and `foundry-master-agent` (Rust crates, Nix flake inputs). - **Health-sector ISAC feeds**: Foundry is establishing participation in healthcare threat-intelligence sharing communities for healthcare-specific threat sharing. - **Vendor intelligence**: feeds bundled with the endpoint EDR and WAF products feed automatically into their detection engines. - **Regulatory monitoring**: the Security and Privacy Officer monitors HIPAA, OCR, and state breach-notification law changes; updates to other frameworks tracked in the [framework crosswalk](/frameworks/crosswalk/); and updates to Foundry's secure-development standards. Relevant advisories are triaged into Linear under the Security project and dispositioned via the [Vulnerability Management](/docs/vuln-mgmt/) process. ## 11. Roles & responsibilities {#roles} - **Security Officer**: owns this policy, the detection-tool inventory, and the threat-intelligence subscription list. Reviews high-severity alerts and tunes detection rules. - **Security on-call**: receives high-severity pages and triggers the [Incident Response](/docs/ir/) process. - **Engineering Lead**: owns the engineering response to confirmed detections that require code or configuration changes. - **All personnel**: report suspected security events to immediately. ## 12. Review & revision {#review} This policy is reviewed at least annually and whenever business, technology, or regulatory change makes it stale, including changes to the detection-tool inventory, the AWS control surface, or the threat-intelligence feed list. Material revisions are approved by the Security Officer in coordination with the [Policy Management](/docs/policy-management/) process. ## 13. Related policies {#related} - [Incident Response](/docs/ir/) - [Vulnerability Management](/docs/vuln-mgmt/) - [System Audits & Monitoring](/docs/system-audits/) - [Endpoint & MDM](/docs/mdm/) - [AI Governance](/docs/ai-governance/) - [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/) --- _Policy · v2026.06 · Owner: Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Bioscope Foundry, LLC ("Foundry") makes every reasonable effort to ensure that the third parties supporting its MSO operations do not compromise the integrity, security, or privacy of PHI handled on member practices' behalf, or of any other Foundry, customer, or workforce data. As a HIPAA **business associate**, Foundry executes Business Associate Agreements with subcontractors that may handle PHI, on terms at least as protective as Foundry's BAA with the practice. Third parties in scope of this policy include vendors, customers, partners, subcontractor business associates, subprocessors, and contracted developers. {{< /callout >}} ## 1. Purpose & scope {#purpose} 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 {#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](#monitoring)). \(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](#tiering)). 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](/docs/hr-personnel-security/). \(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](#subsub). \(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](#intel)). \(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](/docs/policy-management/). ## 3. Vendor technology risk review {#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 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 {#tiering} 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 | Tier | Definition | BAA required? | Examples | | -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Tier 1: PHI processor** | Vendor may create, receive, maintain, or transmit PHI on Foundry's behalf. Subcontractor business associate under 45 CFR §160.103. | **Yes, required before any access.** | Amazon Web Services (hosts the clinical data plane, the clinical workflow database and the Foundry-operated HAPI FHIR service), Anthropic / OpenAI where PHI is in scope, EHR or lab integration partners | | **Tier 2: Business-critical, non-PHI** | Vendor supports Foundry's daily operations but does not handle PHI. Loss of the vendor would materially disrupt the business. | Not required (no PHI). DPA where applicable. | GitHub, Slack, the identity provider, identity provider, observability and logging tooling | | **Tier 3: Non-critical** | Vendor provides convenience or quality-of-life functionality. Loss would be a nuisance, not an operational issue. No PHI, no PII at scale, no production integration. | Not required. | Marketing analytics, low-risk SaaS, contract management, design tools | ### Required evidence by tier | Evidence | Tier 1 | Tier 2 | Tier 3 | | -------------------------------------------------------------- | :------: | :-------------: | :------: | | Business justification & cost in onboarding ticket | ✓ | ✓ | ✓ | | VTR questionnaire | ✓ (full) | ✓ (lightweight) | optional | | Independent third-party security attestation (where available) | ✓ | ✓ | N/A | | Executed BAA (where PHI may touch the vendor) | ✓ | N/A | N/A | | Executed DPA (where non-US data subjects are involved) | ✓ | as applicable | N/A | | Sub-subprocessor disclosure list | ✓ | as applicable | N/A | | Named relationship owner inside Foundry | ✓ | ✓ | N/A | ### Approval matrix | Tier | Required approvers | Target SLA | | ------ | ------------------------------------------------ | ------------------- | | Tier 1 | Security Officer + Legal + Executive sponsor | 10–20 business days | | Tier 2 | Security Officer | 3–7 business days | | Tier 3 | Requester's manager (Security CC for visibility) | Best effort | 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 {#contracts} ### HIPAA / Business Associate Agreement {#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](/docs/bcdr/). ### 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 {#subsub} 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](/legal/subprocessors/) page. ## 7. Monitoring vendor risks {#monitoring} ### 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](#genai)); - 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](/docs/ir/). ## 8. Supplier threat intelligence {#intel} 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](#monitoring). ## 9. AI / LLM vendor track {#genai} 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](/docs/sdlc/) and [AI Governance](/docs/ai-governance/) policies. Public consumer AI tools (ChatGPT, Claude.ai, Microsoft Copilot, Google Gemini consumer tier, etc.) are subject to the [AI Governance policy](/docs/ai-governance/) 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} 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](/docs/hr-personnel-security/). 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](/docs/access/), 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 {#shadow} 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](/docs/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 {#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](/legal/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 {#evidence} 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 {#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](#tiering). 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 {#notice} Foundry provides member practices with notice of changes to its subprocessor list. Notice is delivered through the public [Subprocessors](/legal/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 {#roles} - **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 {#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](/docs/ccm/). Material revisions are approved by the Security Officer in coordination with the [Policy Management](/docs/policy-management/) process and recorded in the policy changelog. ## 18. Related policies {#related} - [Security program overview](/docs/overview/) - [Compliance, audits & external communications](/docs/compliance-audits/) - [AI governance](/docs/ai-governance/) - [HR & personnel security](/docs/hr-personnel-security/) - [Access control](/docs/access/) - [Configuration & change management](/docs/ccm/) - [Incident response](/docs/ir/) - [Breach notification](/docs/breach/) - [BCDR](/docs/bcdr/) - [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/) - [Business Associate Agreement](/legal/business-associate-agreement/) - [Subprocessors](/legal/subprocessors/) --- _Policy · v2026.06 · Owner: Security Officer · Effective: 2026-06-30 · Reviewed: 2026-06-30 · Next review: 2027-06-30_ {{< callout type="info" >}} Foundry runs software that touches PHI on behalf of physician practices. A vulnerability in that software is a risk to patients, providers, and Foundry's status as a HIPAA business associate. This policy defines how vulnerabilities are discovered, tracked, prioritized, and closed, and the timelines that bind us to fixing them. {{< /callout >}} ## 1. Purpose & scope {#purpose} This policy governs how Bioscope Foundry discovers, tracks, prioritizes, and remediates security vulnerabilities across its production systems and supporting infrastructure, including the `conductor` TypeScript platform, the `foundry-master-agent` Rust workspace, the Maverick OpenClaw deployment in `agents/`, customer-facing web surfaces, and the development tooling and CLIs maintained in Foundry's GitHub organization. It also covers vulnerabilities reported to Foundry through the responsible-disclosure inbox and findings produced by penetration testing. ## 2. Policy statements {#statements} Bioscope Foundry policy requires that: 1. All product systems must be scanned for vulnerabilities on a continuous basis (via CI security checks and published-advisory triage) and reviewed at least quarterly and with each material release. 2. All vulnerability findings must be reported and tracked to resolution in Linear under the Security project. Records of findings are retained for at least six years to align with HIPAA's documentation retention requirement. 3. All personnel performing internal security testing shall: - be a Foundry Security function member, or otherwise specifically authorized by the Security Officer for a given test scope and duration; - have appropriate training or experience with the tools and techniques used; - maintain currency of knowledge through training, conferences, and continuing professional education. 4. Critical and High severity findings affecting production must be remediated within the SLAs defined in [§5](#sla). No release ships to production with an unresolved Critical or High finding unless an approved Exception is in place. 5. Exceptions to remediation must be documented, reviewed, and approved by the Security Officer and the impacted asset owner. ## 3. Vulnerability discovery {#discovery} Foundry uses a layered approach to discover vulnerabilities across the software supply chain and runtime environment. 1. **Software composition analysis (SCA).** Dependency upgrades run on a 7-day release-age cooldown (`minimumReleaseAge`) and a scheduled manual review cadence; published advisories affecting Foundry dependencies are triaged into Linear with severity, exploitability, and reachability annotations. Automated dependency-update tooling is being rolled out. 2. **Static analysis in CI.** Every pull request runs the standard check suite: type-checking with `tsgo --noEmit`, security linting with `oxlint --type-aware`, dead-code analysis with `knip`, and the Rust + Nix equivalents (`cargo test --workspace`, `cargo audit`, `nix flake check --impure`). Findings produced by these tools are surfaced on the PR itself. 3. **Secret scanning.** GitHub secret scanning with push-protection is enabled fleet-wide, blocking known-secret patterns before they land in a remote branch. Foundry contributor guides prohibit committing credential material of any kind, messaging-platform bot tokens, AI-provider API keys, private keys, cleartext password material, and cloud access keys, and PR review enforces the rule. One-way password hashes are safe to commit; cleartext is not. 4. **Cloud security posture monitoring.** Cloud posture and misconfiguration monitoring is being stood up as part of the security-tooling rollout. Findings flow to the same Linear pipeline as software findings. 5. **Threat intelligence and advisory monitoring.** The Security function monitors CISA advisories, AWS and Foundry FHIR-service security bulletins, Anthropic and OpenAI security disclosures (for AI dependencies), and upstream advisories from the maintainers of Foundry's software dependencies. See [Threat Detection & Prevention](/docs/threat/). 6. **Manual security review.** Security reviews PRs that touch PHI, authentication, authorization, or production infrastructure (see [Secure SDLC](/docs/sdlc/) §3.2). Periodic deep reviews are performed as part of the weekly security cadence. 7. **Penetration testing.** At least one annual external engagement plus internal white-box tests (see [§8](#pentest)). 8. **Responsible disclosure.** External reports arrive at ; each report is acknowledged and triaged into the same Linear queue. 9. **Platform-wide secure-development review.** Foundry performs periodic platform-wide reviews against its secure-development standards; the most recent completed **2026-02-21**. Its findings are binding for new web app code and tracked to remediation under this policy. ## 4. Reporting, tracking & remediation {#tracking} Foundry tracks vulnerabilities in Linear under the Security project. Records of findings are retained for at least six years. ### 4.1 Reporting a finding {#reporting-a-finding} - Upon identification of a vulnerability (in software, system, or process), a Linear issue is created in the Security project. - The issue captures the following structured fields where applicable: - **Source of finding** (SCA / SAST / DAST / manual review / pen test / external disclosure / threat intel). - **In production** (yes / no / N/A). - **Affected component** (repo name, package, service, or infrastructure resource). - **Severity rating** (see [§5](#sla)). - **Reachability / exploitability** assessment. - The **title** of the finding follows the format "\[Sev\] {short description}" (e.g., "\[High\] Outdated `jsonwebtoken` dependency in conductor services"). - The **description** contains technical details with no PHI and no confidential customer information, plus a link to the source advisory or finding. - The **priority** on the Linear ticket matches the severity rating. ## 5. Severity ratings & SLAs {#sla} Severity reflects the realistic worst-case impact of the vulnerability in Foundry's environment, weighted by exploitability and whether the affected surface processes PHI. SLAs drive remediation timelines from the point the finding is created. Findings that are actively being exploited in the wild are treated as Critical regardless of base score. | Severity | Priority | SLA | Definition | Examples | | ------------ | -------- | ------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | **Critical** | P0 | **24 hours** (in-the-wild) / **3 days** otherwise | Vulnerabilities enabling privilege escalation from unprivileged to admin, remote code execution, unauthorized access to or extraction of PHI, or compromise of the FHIR boundary. | Authentication bypass to FHIR data, RCE, SSRF reaching the PHI-handling account, SQL injection, XXE, secrets exposure that grants production access. | | **High** | P1 | **7 days** | Vulnerabilities that materially affect the security of the platform or the processes it supports, including lateral-movement risks. | Lateral authentication bypass, stored XSS in authenticated surfaces, missing authorization on a sensitive route, audit log evasion. | | **Medium** | P2 | **30 days** | Vulnerabilities that affect multiple users and require little or no interaction to trigger, or significant misconfigurations. | Reflected XSS, IDOR with limited blast radius, open redirect on an authenticated surface, some CSRF cases. | | **Low** | P3 | **Next patch cycle** (typically 180 days) | Issues that affect singular users, require significant prerequisites, or have negligible impact. | Verbose error messages, mixed-content warnings, low-impact information disclosure, defense-in-depth hardening items. | If a severity rating is changed after creation, the SLA adjusts as follows: - **Severity upgrade**: the SLA resets from the time of escalation. - **Severity downgrade**: the SLA time remains based on the original creation date of the finding. ## 6. Resolving & closing findings {#resolve} - The finding is assigned to the owner responsible for the affected system, repo, or package. `CODEOWNERS` drives routing where ambiguous. - All findings are addressed against the applicable SLA. Findings approaching or breaching SLA are surfaced to the Security Officer and the Engineering Lead in the weekly security review. - No release ships to production with an unresolved Critical or High finding unless an approved Exception is in place (see [§7](#exceptions)). - A finding may be resolved by: 1. providing a valid fix or mitigation that addresses the root cause; 2. determining the finding to be a false positive, with rationale recorded in the issue; or 3. documenting an approved Exception with a compensating control. ### 6.1 Closing a finding {#closing-a-finding} - The assignee records the resolution (fix PR link, mitigation description, or Exception link) as a comment on the Linear issue. - The finding is re-assigned to the reporter or to a member of the Security function for validation. - Upon validation, the finding is marked Done (closed). - **A finding may only be closed once the fix has been deployed to development / staging and a targeted production-release date is noted on the ticket.** Findings remain open until the fix lands in production. ## 7. Exceptions {#exceptions} - An Exception may be requested when a direct fix is not available, for example, a fixed version of a dependency is not yet released, is incompatible with the current runtime, or has not yet cleared the 7-day npm cooldown (`minimumReleaseAge` / `--min-age 7`) Foundry applies to dependency upgrades to reduce supply-chain risk. - A compensating control must be in place, technical (WAF rule, network restriction, configuration change), procedural (heightened monitoring, additional human review), or a combination, such that the residual risk is acceptable. - The Exception is opened as a Linear issue and linked to the original finding. - Each Exception is reviewed and approved by the Security Officer and the impacted asset owner. - All Exceptions are reviewed every six months to re-assess validity, and immediately when an upstream fix becomes available. ## 8. Penetration testing {#pentest} - **External penetration testing** is commissioned at least once per year from a qualified independent security firm; the first external engagement is being scheduled. The platform-wide OWASP Top 10 review was completed 2026-02-21. Pen-test reports are held by the Security Officer and findings are tracked in Linear under this policy. - **Internal white-box penetration testing** is performed periodically by the Security function with engineering collaboration. Scope, timing, and rules of engagement are documented in advance. - **Responsible disclosure** is continuously open at . A formal bug-bounty program is not currently offered. - All testing performed against Foundry production systems requires explicit authorization in writing from the Security Officer. Internal testers are bound by the same access-control and minimum-necessary requirements as production engineers. ## 9. Records retention {#retention} Vulnerability findings, pen-test reports, exception records, and the related audit trail are retained for at least six years to align with HIPAA's documentation retention requirement at 45 CFR § 164.316(b)(2). Records are stored in Linear and the Foundry document repository; access is restricted to the Security function and the relevant asset owners. ## 10. Roles & responsibilities {#roles} - **Security Officer**: owns this policy, the severity scale, exception approvals, and the external pen-test engagement. - **Engineering Lead**: owns remediation throughput against SLA; arbitrates competing priorities in favor of security where Critical or High findings are open. - **Repository / system owners**: receive findings via routing rules and are responsible for delivering fixes within SLA. - **All engineers**: report suspected vulnerabilities through the Security project in Linear; never close a finding before the fix is in production. ## 11. Review & revision {#review} This policy is reviewed at least annually and whenever business, technology, or regulatory change makes it stale. Material revisions are approved by the Security Officer in coordination with the [Policy Management](/docs/policy-management/) process. ## 12. Related policies {#related} - [Secure SDLC & Product Security](/docs/sdlc/) - [Threat Detection & Prevention](/docs/threat/) - [Configuration & Change Management](/docs/ccm/) - [Incident Response](/docs/ir/) - [Vendor & Third-Party Risk](/docs/vendor/) - [HIPAA Notice & Business Associate Statement](/legal/hipaa-notice/) - [Framework crosswalk](/frameworks/crosswalk/) ---