Company / Security
What we hold, and what protects it.
This page is written for the person whose job is to check rather than to be reassured, which is why the controls we are missing are on it too.
Last reviewed August 13, 2026.
What Bip holds
Provider records. Not patient records.
Bip holds sensitive information about clinicians. It holds no charts, no encounters, no claims and no diagnoses, because credentialing never needs them.
- Provider identity
- Legal name, date of birth, contact details, home and practice addresses, NPI, and the government identifiers a payer or facility requires to enroll a clinician.
- Credentials
- State licenses, DEA and state controlled-substance registrations, board certifications, education and training, work history, malpractice coverage, CME and immunizations.
- Evidence
- The documents that support each credential — certificates, insurance policies, CVs, board responses and signed forms — attached to the credential they evidence.
- Disclosures and attestations
- The provider’s answers to the professional disclosure questions, each with an explanation where one is required, and the dated attestations confirming the record.
- Operational records
- Credentialing and enrollment workflow state, correspondence exchanged with providers, and the change history behind all of it.
That boundary is enforced in code, not by policy. Anything Bip’s models are about to return is checked first, and any output resembling patient information — an identifier, a medical record number, a diagnosis or procedure code — is discarded rather than sent.
The check is deliberately over-sensitive and it does not attempt a rewrite. A false positive costs one response. A false negative costs a disclosure.
Access and isolation
One organization cannot see another’s file.
Isolation is enforced in the application on every request rather than delegated to a single database mechanism, because a control with one layer has one failure.
- Tenant scoping
- Every request is scoped to one organization, enforced in the application on every API call, with Postgres row-level security beneath it as a second layer.
- Roles
- Five roles — owner, admin, manager, staff and viewer — over an explicit permission matrix covering provider data, documents, reports, audit, team and billing. Individual permissions can be granted or denied on top of a role.
- Network restriction
- An organization can restrict access to its own IP ranges. It is enforced at the edge before a request reaches application code, and it fails closed: an error denies rather than admits.
- Two-factor authentication
- Available to every user through an authenticator app.
- Request integrity
- Headers that could be used to impersonate an internal caller are stripped from every external request before any handler sees them.
- Rate limiting
- Applied at the API layer and held in the database, so limits survive across serverless instances rather than resetting per process.
- Provider-controlled sharing
- The provider decides which organization sees which part of their record. A facility receives what was shared with it, not the whole file by default.
How it is protected
Encryption, headers, and the supply chain.
Nothing here is unusual. It is listed because a security questionnaire asks for it line by line, and you should not have to email us to get it.
In transit
- TLS on every connection, with HTTP Strict Transport Security set to two years, applied to subdomains and submitted to the browser preload list.
- Framing refused outright, content-type sniffing disabled, and referrers trimmed to the origin when they cross one.
At rest
- AES-256 encryption on the database and on document storage.
- The buckets holding credential evidence are private. A document is reached through an authenticated, scoped request, never a public URL.
Credentials Bip holds for you
- Payer portal passwords, mailbox authorization tokens and API keys are encrypted with AES-256-GCM at the application layer, above the storage encryption, each with its own salt and initialization vector.
- A payer portal password is released only through a single audited endpoint.
In the codebase
- Dependencies are scanned weekly, and on every manifest change, against the Open Source Vulnerability database.
- Every pull request is reviewed for security issues by an automated AI reviewer (Anthropic’s claude-code-security-review). Dependency and code-security scans run in CI, not a human’s memory.
The audit record
The record keeps its own history.
Every change to a provider record writes the complete state of the row before the change and after it, with the time it happened.
Recorded change events across licenses, documents, work history, education, coverage, enrollments, affiliations and the rest of the credentialing record.
The audit tables are append-only by design. The application exposes no path that updates or deletes an entry, and the credentialing request log goes further than design: each event carries a SHA-256 hash computed in the database over its own contents and the hash of the event before it, and the database refuses updates and deletes outright. Editing a past event breaks every hash after it.
Signatures carry their own evidence. Each one records a SHA-256 fingerprint of the original document, the signed document and the signature image, alongside the version of the consent text shown, the signer’s address and browser, and the time — the record ESIGN and UETA expect you to be able to produce years later.
On the provider’s side the device has no write path into its own audit trail at all. A provider can read their history and cannot author it, so the subject of a record is never its author.
We describe these tables as append-only rather than immutable. The distinction is real, and a reviewer who has read a vendor questionnaire knows which word was chosen carefully.
Compliance posture
Two of these are standards. One is not a badge.
HIPAA
Bip operates as a business associate and its controls are designed against the Security Rule. We do not call ourselves HIPAA certified, because there is no such certification — the phrase is a reliable tell about the vendor using it. A business associate agreement is available.
NCQA
NCQA credentials organizations, not software, so no software vendor can hold it. What Bip does is structural: the disclosure model follows NCQA’s 26 professional disclosure questions across 11 categories, and recredentialing intervals default to the cycles the standards assume — roughly 36 months for payers, 24 for hospital reappointment.
Primary source
State licenses are verified with the issuing board, and exclusions are screened monthly against the OIG exclusion list. Every other credential is labeled provider-supplied on its own row. The file never calls a certificate a primary source check.
Incident and breach notification
You hear it from us, in writing.
As a business associate, Bip’s notification duties run to you rather than to your patients. The Breach Notification Rule requires a business associate to report a breach of unsecured protected health information to the covered entity without unreasonable delay and no later than sixty days after discovery, with the individuals affected and the facts known at the time.
Your business associate agreement governs the specifics, and where its terms are tighter than the rule, its terms are what we work to.
Reach a person who can answer.
Vulnerability reports, questionnaires and architecture reviews all go to the same place, and a human reads them.
Report a vulnerability
Tell us what you found and how to reproduce it. We will confirm receipt and tell you what we are doing about it.
Security questionnaire
Send yours. We answer the document you use rather than returning our own summary of it.
Architecture review
Under an NDA we will walk the data model, the isolation boundary and the identity method in full, including the parts this page withholds.