Data Protection

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

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.

1. Purpose & scope

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

Foundry policy requires that:

(a) Data is handled and protected according to its classification (see Data Management: classification model) 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

3.1 Data protection implementation

Data is classified and handled according to the Data Management 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.

3.2 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:

Implement and review controls designed to protect production data from improper alteration or destruction (versioning, write-ahead logs, and BAA-bound replication).
Ensure Confidential and PHI data is stored in a manner that supports access logging and automated monitoring for potential security incidents.
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).
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).
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.
Use approved cipher algorithms, key strengths, and key management processes as defined in Encryption Key Management.

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. 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 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

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).
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

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.

3.4 Protecting data in transit

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.
Transmission encryption keys and the systems that generate them are protected by access controls; key material is accessible only to privileged service accounts.
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.
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.
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).
System logs of production data transmissions are retained per Data Management.

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

“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 and Access Control.

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

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

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

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.

4. Roles & responsibilities

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

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.

6. Related policies

Data Management Privacy & Consent