Security you can check, not a badge you have to trust.
Here is how BFLOW® protects patient data, where it lives, who can see it and what we will never do with it. Every line on this page is something we can show you.
How PHI is protected
A contract first, then code that enforces it.
A signed Business Associate Agreement
Every customer gets a signed BAA. It limits how we use and disclose PHI, requires safeguards, and commits us to tell you about a suspected breach within 24 hours. Read the BAA ›
PHI reaches an AI model only under a BAA
Protected health information reaches a model only under a signed BAA. Our production report engine runs on OpenAI under that agreement. A provider without a BAA sees de-identified data only, enforced in code, not by configuration.
Minimum necessary
Under the BAA we request, use and disclose only the minimum PHI needed for the job. Our subcontractors agree in writing to the same restrictions.
Where your data lives
Managed infrastructure from providers that publish their own audits.
Database on Supabase
Application data lives in managed Postgres on Supabase. Supabase states that all customer data is encrypted at rest with AES-256 and in transit with TLS.
Web app on Vercel
The BFLOW® web application is served from Vercel. Traffic between your browser and BFLOW uses HTTPS.
Providers with their own SOC 2 Type II reports
BFLOW is hosted on infrastructure whose providers maintain SOC 2 Type II reports. Those reports cover Supabase and Vercel. They do not cover BFLOW.
Who can see what
Access is decided by the database, your company and your role.
Row-level security in the database
Row-level security is enabled in the database. Each query is limited to your company's records by the database itself, not only by the screen.
Role-based access
What a user can see and change depends on their role. BFLOW's own support access runs through a designated administrator role the database checks.
Two-factor sign-in
Users can turn on two-factor verification by text message or an authenticator app. An administrator can require it for every user in the company.
Idle sign-out
Sessions sign out after a period of inactivity your company sets. A warning appears two minutes before, so it is never a surprise.
What we never do
Rules written into the system, not into a policy binder.
We never delete billing data
Database triggers refuse every delete on subscription and invoice records from any client, including our own service role. Correction is an update with an audit row, never a wipe.
We never let AI act alone
Every AI output is reviewable in the screen it affects. Holds, exceptions and proposals wait for a human decision. A refusal is the guard working, never an error to tune away.
We never loosen a guardrail quietly
These rules are enforced by sentinel remarks in the code and lock tests that fail the build on drift. Changing one is a named decision by our founder, not a side effect of a fix.
We never sell your data
We do not sell personal information. PHI is used only to deliver the service, as the BAA allows.
What we don't have yet
A straight answer to the first question on every vendor review.
BFLOW has not completed a SOC 2 audit of its own.
We would rather say so than show a badge that belongs to our hosting providers. If your review needs more than this page, ask us. We will send our answers to your security questionnaire and the Business Associate Agreement, and walk your team through how the controls above work.
Bring your security review.
Send your questionnaire. We answer it in writing and show you the controls in the live product.
We use cookies to enhance your browsing experience, serve personalized content, and analyze our traffic. By clicking "Accept All", you consent to our use of cookies.Learn more about our Cookie Policy