Legal
Security
The safeguards protecting protected health information in Od Suite, and an honest account of where our program stands today.
Last updated August 15, 2026 · BrainBit LLC
1. Our position
BrainBit LLC is a Business Associate under HIPAA. We sign a Business Associate Agreement with every customer before their account is enabled for protected health information (“PHI”), and we implement administrative, physical, and technical safeguards under the HIPAA Security Rule.
The controls below are the ones actually in place today. We would rather describe them precisely than claim more than we can support.
2. Encryption
- In transit. Every connection to Od Suite is encrypted with current TLS. Unencrypted requests are redirected, and browsers are instructed to use encrypted connections only. Connections to EHR systems and to our providers are encrypted as well.
- At rest. EHR access tokens and multi-factor authentication secrets are individually encrypted using authenticated encryption, with keys held only in the deployment environment and never in source control. Stored data is encrypted at rest by our hosting provider.
- Passwords are protected with a salted, deliberately slow, industry-standard password hashing function. They are never stored, logged, or recoverable in plain text — not even by us.
3. Authentication and access control
- Multi-factor authentication is mandatory on every account, enrolled at first sign-in. There is no opt-out.
- Passwords must be at least 12 characters with uppercase, lowercase, numeric, and symbol characters.
- Sessions expire after 30 minutes. Session cookies are HttpOnly, Secure, and SameSite-restricted.
- Access is role-based, and each clinic's data is isolated from every other clinic's.
- Sign-in across the suite uses standards-based single sign-on with cryptographically signed, short-lived tokens, single-use authorization codes, and back-channel logout, so signing out of one product signs you out of all of them.
- Support access to a customer account is time-limited to 30 minutes, displayed in a banner while it is active, and written to the audit log.
4. Least-privilege EHR access
- We request read-only access, scoped to only the data a product actually needs. Od Suite never writes to the medical record.
- Each clinic's connection is separate, with its own credentials and tokens.
- Production connections require our explicit review and approval before they are enabled.
- Private signing keys live only in the deployment environment. Only the corresponding public keys are ever published.
5. Application hardening
- Cross-site request forgery protection on session-authenticated forms.
- Strict rate limiting on sign-in, multi-factor verification, and password reset, to blunt credential stuffing and brute-force attempts.
- Browser security headers on every response, blocking content-type sniffing, embedding of our pages in other sites, and referrer leakage.
- Server-to-server interfaces authenticate with per-client secrets rather than session cookies.
- Production refuses to start if any required secret or signing key is missing, so a misconfigured deploy fails closed instead of running unprotected.
- Dependencies are kept current, and we monitor for security advisories affecting the components we run.
6. Audit logging
Every security-relevant action — sign-in, administrative change, EHR approval, support impersonation, entitlement change — is recorded with the actor, clinic, originating application, IP address, user agent, and timestamp.
Audit records are hash-chained: each entry cryptographically commits to the one before it, so altering or removing a record breaks the chain and is detectable. We can verify the chain end to end on demand. Records are retained for seven years, and clinic administrators can review their own clinic's activity at any time.
7. Infrastructure and subprocessors
Od Suite runs on managed cloud infrastructure located in the United States. We deliberately keep the number of providers small, and each one operates under contract and, where PHI is involved, a signed Business Associate Agreement. They cover:
- Application and database hosting.
- Transactional email. We do not send PHI by email.
- Language model processing, as described below.
Production access is limited to the personnel who need it. We identify our current subprocessors to customers and prospective customers on request, under a non-disclosure agreement, rather than publishing the list.
8. How we handle AI
Where a feature sends PHI to a model provider, we use enterprise offerings under a signed BAA with zero data retention, and the provider is contractually barred from training on that content. Model output is always a draft for a qualified person to review.
9. Incident response and breach notification
We investigate suspected incidents on discovery, contain and remediate them, and preserve audit evidence. If a breach of unsecured PHI occurs, we notify the affected customer without unreasonable delay and no later than 60 calendar days after discovery, with the detail HIPAA requires so they can meet their own notification obligations.
10. Where we stand today
Stated plainly
We do not currently hold a SOC 2 Type II report or HITRUST certification. Everything on this page describes controls we have implemented, not controls a third party has attested to.
We are glad to complete security questionnaires, walk through our architecture, and share additional detail under NDA. Ask at support@brainbit.ai.
11. Reporting a vulnerability
If you believe you have found a security issue, email support@brainbit.ai with enough detail for us to reproduce it. Please do not access or modify data that is not yours, degrade the Services, or disclose the issue publicly before we have had a reasonable chance to fix it. We will not pursue legal action for good-faith research that follows those guidelines, and we will keep you updated as we remediate.
Contact
Questions about this page?
Write to support@brainbit.ai. We answer privacy requests, security questionnaires, and Business Associate Agreement requests at the same address.