Information Security Policy

Document Control

This document is the property of BrilLiquid LLC and is classified CONFIDENTIAL. Distribution is limited to authorized personnel, partners under mutual NDA, regulators conducting lawful review, and third parties conducting due diligence at our invitation.

0. Maturity Note (Read First)

BRILL.health is an early-stage platform built by a small team. This policy describes our security principles, our architecture and technical controls as deployed today, and our roadmap for formalized operational practices. We distinguish clearly between what is in place today, what is implemented but not yet formally documented, and what remains on the roadmap.

Partners conducting due diligence are encouraged to ask specific questions about the current state of any control. We prefer candor to checklist theater: we will say "we are establishing X" rather than "we do X" when the latter would overstate our current operational maturity.

Our security posture is strengthened by the architectural choice to hold as little sensitive data as possible (see §2.1). Many controls that would be critical for a large data-holding platform are less load-bearing for us because we are a relay, not a repository.

1. Purpose and Scope

This policy establishes the information-security framework governing BRILL.health — BrilLiquid LLC's patient-facing health platform — including its infrastructure, personnel, and authorized service providers.

BRILL.health transmits, and incidentally handles, Protected Health Information (PHI) as defined under 45 CFR § 160.103. Its architecture and policies are designed to minimize what Brilliquid itself holds in persistent form; the platform is operated as a standards-based secure relay rather than as a records repository.

This policy is aligned with:

• HIPAA — Privacy Rule (45 CFR §§ 164.500–164.534), Security Rule (§§ 164.302–164.318), and Breach Notification Rule (§§ 164.400–164.414)
• 21st Century Cures Act Final Rule — ONC Information Blocking provisions (45 CFR Part 171) and CMS Interoperability requirements (CMS-9115-F, CMS-0057-F)
• Washington My Health My Data Act (RCW 19.373)
• California Consumer Privacy Act / California Privacy Rights Act
• State breach-notification statutes in the jurisdictions where we serve residents
• NIST Cybersecurity Framework (Identify, Protect, Detect, Respond, Recover) as a design reference

Brilliquid operates principally as a Business Associate to the Covered Entities with which its users interact. Our specific obligations flow from each Business Associate Agreement in force.

2. Security Philosophy

2.1 Decentralized by design

BRILL.health is decentralized by design. Clinical records live on patient devices and with the Covered Entities that originated them — not in a central Brilliquid repository. Where we retain data, we retain the minimum necessary for routing, auditing, and regulatory compliance — and nothing more. Non-aggregation is enforced as a design constraint, not a post-hoc commitment.

2.2 Patient-held clinical data

Clinical records are held on the patient's device and on the Covered Entities that originate them. BRILL.health does not hold a canonical copy. Our target architecture uses device-held cryptographic keys such that message content is end-to-end encrypted and our servers cannot decrypt what passes through them. The current implementation provides HIPAA-acceptable encryption at rest using server-held keys; the transition to patient-held keys is on the roadmap.

2.3 Defense in depth

We assume that any single control may fail. Controls are layered so that a compromise of any one does not result in data exposure. Layers include perimeter network controls, transport encryption, application-level authentication and authorization, field-level encryption for persisted identifiers, audit logging, vendor contractual protections, and physical security of development environments.

3. Data Classification

Data handled by BRILL.health is categorized as follows. Classification drives encryption, access control, retention, and logging requirements.

Data minimization is the rule at every layer. Where a field is optional for operation, it is not collected. Where a field is required briefly (e.g., a photo of an identity document), it is handled, acted upon, and purged in the shortest practical window.

4. Access Controls

4.1 Authentication

• All access to the platform requires authentication.
• Patient accounts use email-based identification. Multi-factor authentication is mandatory. Passkeys (WebAuthn, device-bound biometric) are the preferred factor; TOTP authenticator apps are supported as a fallback.
• Administrative access requires multi-factor authentication without exception.
• Account credentials are never transmitted or logged in plaintext.
• Each human has an attributable identity; account sharing is not permitted.

4.2 Authorization

• Role-based access with least privilege. Roles include Patient (self-service), scoped Professional Users (e.g., genetic counselors, care coordinators, partner operational staff, with information, action, and tenancy scopes), Operations Staff (program administration), and Administrator (platform governance). Authority-delegated users (e.g., HIPAA Personal Representatives, Records-Access Proxies, expeditors) act under cryptographically-sealed legal instruments per our envelope model.
• A patient has access to their own records exclusively. Staff roles do not have patient-record access except in narrowly-defined support contexts, which are logged for review.

4.3 Session Management

• Sessions expire on browser close and after a configured period of inactivity.
• Session identifiers are transmitted only over encrypted channels.

4.4 Account Lifecycle

• Onboarding produces an attributable identity through identity verification appropriate to the service tier requested (see §7.1).
• On offboarding (patient-initiated, staff termination, or contract end) access is deactivated and retained records are reduced to the minimum legally required.

5. Cryptographic Controls

5.1 Data in Transit

All data crossing a network boundary is protected by modern transport-layer encryption (TLS 1.2 or greater). HTTP Strict Transport Security is enforced at the application layer. Legacy protocols are not supported.

5.2 Data at Rest

Persistent data is encrypted at rest. Cryptographic keys are managed by a managed key-management service (AWS KMS). Field-level encryption is applied to categories of data whose sensitivity warrants a tighter blast radius than database-level encryption alone.

5.3 End-to-End (Roadmap)

The platform's target architecture encrypts message content to keys held on the patient's device, derived via standard WebAuthn ceremonies and backed by device secure-hardware where available. Under this target, the server role is reduced to ciphertext relay and metadata retention. Implementation is in progress. The current phase uses server-held keys at rest; milestones for the transition are tracked in our internal Security Roadmap.

5.4 Key Management

• Keys are segregated by function; the same key is not reused across authentication, data classes, or signing (except where a standardized protocol requires it).
• Keys rotate on compromise and, for long-lived keys, on a planned basis.
• Cryptographic material is not stored in source code or on unprotected developer workstations.

6. Infrastructure and Network Security

6.1 Hosting

The platform runs on Amazon Web Services in United States regions. PHI is not processed or stored outside the United States. Infrastructure is defined as code; builds are reproducible.

6.2 Isolation

Production environments are logically separated from development and test environments. No production PHI is used in non-production environments.

6.3 Perimeter Controls

Inbound network access is restricted by default. Only the ports required for public service are exposed. Administrative access to infrastructure requires key-based authentication.

6.4 Monitoring

System activity is logged. Authentication events, access to sensitive resources, and administrative actions receive enhanced logging. Log-review practice is being formalized; interim review is performed at the administrative level on a needs-triggered basis.

7. Identity Verification, Messaging, and Third-Party Services

7.1 Identity Verification

Patient identity verification is performed in two tiers aligned with platform capability:

• Tier 0 — platform onboarding. Identity verification for general platform access is performed by Plaid, Inc. under a standard service agreement. Plaid handles identity attributes only (name, date of birth, address, government-ID images, biometric selfie) — no Protected Health Information is transmitted. Plaid operates as a general identity-verification service, not as a healthcare Business Associate.
• Tier 1 — Direct Secure Messaging activation (optional). NIST SP 800-63-3 Identity Assurance Level 2 (IAL2) identity proofing, as required by the DirectTrust Certificate Policy for Patient Certificate issuance, is performed by an accredited Credential Service Provider. The structured attribute outputs are retained in encrypted form; the underlying photographic captures are not retained on the platform after verification completes. See our Privacy Policy §12 for the full Registering Agent disclosure.

BrilLiquid LLC is a DirectTrust Registering Agent under our Health Information Service Provider's certification authority; identity-verification artifacts required by the DirectTrust Certificate Policy §4(iii) are retained accordingly.

7.2 Messaging

Secure clinical messaging is operated through an accredited DirectTrust Health Information Service Provider (HISP) — MaxMD, Inc. — under a Business Associate Agreement. The HISP is responsible for trust-bundle management, message signing, and delivery auditing.

7.3 Business Associate Agreements

We execute Business Associate Agreements with service providers that may encounter PHI in the course of rendering service to us. Agreements include confidentiality, use limitation, subcontractor flow-down, breach notification, and return-or-destroy obligations consistent with 45 CFR § 164.504(e).

7.4 Sub-Processors

A current list of service providers handling data on our behalf is maintained as an appendix to our Privacy Policy. Material additions are disclosed in advance of effect.

8. Incident Response and Breach Notification

We maintain interim incident-response procedures, including defined decision authority, containment steps, forensic preservation, and notification templates. A formal Incident Response Plan is in preparation and will be maintained as a living document thereafter.

Notification obligations are governed by the applicable law in each case:

• To affected individuals: without unreasonable delay and within the statutory deadline for the affected jurisdiction.
• To the Secretary of HHS: in accordance with 45 CFR § 164.408 where applicable.
• To state attorneys general and media outlets: where required by jurisdiction and scale.

Material incidents are followed by a written post-incident review and corrective actions.

9. Personnel and Physical Security

9.1 Personnel

Personnel with access to production systems have signed confidentiality obligations. Security-awareness practices are being formalized; interim expectations are conveyed directly to each person with access.

9.2 Workstations and Devices

Development and administrative workstations require full-disk encryption, automatic lock-on-idle, and modern endpoint protection. Removable media is discouraged; where used for cold-storage of cryptographic key material, hardware-encrypted devices with onboard PIN enforcement are employed.

9.3 Physical Security

Infrastructure is hosted in AWS data centers whose physical security is audited under SOC 2, ISO 27001, and HIPAA attestations. Brilliquid's development environment uses commercial-grade premises security.

10. Vendor Management

Third-party service providers are assessed before engagement, considering financial standing, track record, security posture (including available certifications), and data-handling practices. Vendor relationships are reviewed when material platform changes or new integrations create a change in the scope of vendor access.

11. Business Continuity and Recovery

Critical system components use encrypted backups separated from production. A Business Continuity Plan covering prolonged outages, key-person events, and vendor failures is in preparation. Recovery-time and recovery-point objectives are defined for each critical component.

12. Privacy by Design

Features that collect or share new categories of data, or that introduce new sub-processors, undergo review before implementation and are reflected in the Privacy Policy before release.

13. Policy Governance

This policy is reviewed on material changes to the platform, on changes to applicable law, and at least once per year. Substantive changes are versioned and recorded in the Document Control table.

14. Contact

Questions about this policy, or reports of suspected security issues, are directed to:

BrilLiquid LLC — Information Security
Andrew MacInnes, Managing Member
406 Sun Valley Way, Florham Park, NJ 07932
security@brilliquid.com

Security researchers reporting potential vulnerabilities in good faith, and in accordance with industry-standard responsible-disclosure practices, will not be subject to legal action by Brilliquid.

Specific technical implementations — cryptographic algorithm choices, key-rotation intervals, and system-specific defenses — are documented in internal standards made available to authorized auditors under appropriate confidentiality. That level of detail is intentionally omitted from this document to avoid providing a roadmap to potential adversaries.

Partners conducting due diligence are invited to request specific evidence of any control described here; where a control is described as "in preparation" or "being formalized," we will candidly describe what is in place today and what the timeline is for formalization.