Compliance, Audits & External Communications

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

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.

1. Purpose & scope

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

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.

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

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

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 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 policy, which governs how this and every other Foundry policy is approved, communicated, and retired.
The Risk Management policy, which governs the risk analysis required by 45 CFR §164.308(a)(1)(ii)(A).
The System Audits & Monitoring policy, which governs the logging and audit record retention referenced below.

4. External requests for compliance materials

Foundry’s public compliance materials, this Trust Center, all published policies, the standard Business Associate Agreement, and the 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:

A request is sent by email to legal@bioscopefoundry.com. The request should identify the requesting party, the materials sought, the intended use, and any required timelines.
The request is logged in Foundry’s internal compliance request tracker.
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.
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.
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 policy and follow the timelines required by 45 CFR §164.410 and the practice’s BAA.

5. Independent audits and assessments

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 and Risk Management 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

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: security@bioscopefoundry.com
Privacy concerns, including reports of HIPAA Privacy Rule violations: privacy@bioscopefoundry.com (see HIPAA Notice & Business Associate Statement)
Compliance materials, BAA requests, and completed security questionnaires: legal@bioscopefoundry.com
Press and media inquiries: press@bioscopefoundry.com
Law enforcement requests: routed to legal@bioscopefoundry.com. 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

Foundry welcomes responsible security research against its public surfaces and authenticated platform. Researchers acting in good faith are protected under the Researcher Safe Harbor in Appendix A.

Reporting channel. Vulnerability reports are submitted to security@bioscopefoundry.com. 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 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

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);
Dependency and supply-chain scanning, including the supply-chain pinning rules described in Configuration & Change Management: 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;
Quarterly internal control review against the HIPAA Security Rule.

Material gaps are recorded on the internal compliance dashboard and routed into the Risk Management process. Gaps that affect PHI safeguards are escalated to the Security Officer within 24 hours of detection.

9. Roles & responsibilities

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

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 process and recorded in the policy changelog.

11. Related policies

Appendix A: Researcher 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

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 security@bioscopefoundry.com with sufficient detail for Foundry to reproduce and evaluate it.

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

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 security@bioscopefoundry.com.
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

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

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

If a researcher is uncertain whether a specific activity is within scope, they may contact security@bioscopefoundry.com 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.

System Audits, Monitoring and Assessments Vendor & Third-Party Risk