HIPAA-aligned by architecture —
because nothing has to leave
Blabb runs speech recognition and the cleanup model entirely on your Windows PC. There is no cloud path for your audio or your text.
What this page is — and what it isn't
This is a factual description of Blabb's architecture and the technical safeguards it ships with, written to help a covered entity's compliance team do their own assessment. It is not legal advice, and Blabb is not described here as "HIPAA compliant." Only the U.S. Department of Health & Human Services Office for Civil Rights (OCR) can determine whether an entity is compliant with HIPAA, and the FTC has warned that loose "HIPAA compliant" or "HIPAA secure" marketing claims can be deceptive. Blabb has not been through an external HIPAA, SOC 2, or HITRUST audit. If your organization is subject to HIPAA, have your compliance officer and counsel make the final determination before using Blabb in a regulated context.
What's true about how Blabb handles data
On-device, end to end
Speech-to-text and the cleanup language model both run on your PC. Audio is held in memory during transcription and is not written to disk; only the resulting text is stored.
Encrypted at rest
Transcription history is encrypted row-by-row with AES-256-GCM; secrets and keys use Windows DPAPI with HMAC-SHA256 integrity. Keys are tied to your Windows user account.
Tamper-evident audit log
An integrity-chained audit log (HMAC hash chain) records security-relevant actions and is retained for about seven years — longer than HIPAA's six-year documentation minimum.
PHI-masked logs
Every file-log event passes through a PHI-masking filter before it is written to disk, replacing
common identifiers with [MASKED-PHI] tokens.
Crash reporting off by default
The only cloud egress is optional Sentry crash reporting — opt-in, off by default, and PHI-scrubbed. Leave it off and there is no cloud path at all.
Generally not a Business Associate
Because PHI never reaches us, Blabb meets none of the four tests that define a HIPAA Business Associate. No BAA is offered.
The full picture — one machine, your machine
When you dictate, audio is captured to memory, transcribed on-device, optionally cleaned by the on-device
language model, and typed into the window you're working in. The audio itself is not saved as a file. The
resulting text — original and cleaned — is stored in a local SQLite database at
%LocalAppData%\Blabb\history.db, encrypted row-by-row. Settings sit in an unencrypted
config.json (no clinical content); secrets sit in a DPAPI-encrypted
secrets.dat. Nothing in this flow is uploaded.
How Blabb maps to 45 CFR §164.312
The HIPAA Security Rule's technical safeguards sit at 45 CFR §164.312. Here is what Blabb actually does for each one — and, honestly, where the boundary falls. (Under the current rule, most of these are "addressable" rather than "required" — meaning a covered entity may implement them or document an equivalent alternative. A proposed 2025 update would make several mandatory; it is not yet final.)
Access control — §164.312(a)
All encrypted data is bound to your Windows user account through DPAPI (CurrentUser
scope): it cannot be decrypted by another user on the machine, or by anyone off the machine.
Audit controls — §164.312(b)
A dedicated integrity audit log records security-relevant events — history access, item and bulk deletion, export, and data wipe — as a tamper-evident HMAC-SHA256 hash chain with sequence numbering, so altered, removed or truncated entries are detected on verification. The log is local, so it is evidence of tampering rather than a guarantee against it. Logs are retained roughly seven years (about 2,555 days), beyond HIPAA's six-year documentation minimum. Personal-data fields are masked.
Integrity — §164.312(c)
Two independent integrity mechanisms: secrets are sealed with Encrypt-then-HMAC (HMAC verified before decryption, constant-time comparison), and every history row carries an AES-GCM authentication tag bound to its row id — so swapping or tampering with a blob fails verification.
Person/entity authentication — §164.312(d)
Access to encrypted data is gated by Windows user authentication (the DPAPI key is only recoverable within your Windows logon session). The covered entity's own workstation sign-in, screen-lock, and device policies are the authentication controls that apply in practice.
Transmission security — §164.312(e)
Blabb transmits no ePHI over any network — speech and text processing are local. The only network paths are an optional model download if you switch from the bundled defaults, a licence check with our payment provider, and optional crash reports, none of which carry transcription content. No ePHI in transit is the strongest available transmission-security posture.
Encryption — §164.312(a)(2)(iv)
History uses AES-256-GCM (a NIST-approved authenticated mode recommended for ePHI at rest); secrets use DPAPI plus HMAC-SHA256. The secrets-store integrity key rotates automatically every 90 days, following NIST SP 800-57.
Every network path — and what each carries
AI model downloads
When you fetch additional models, Blabb makes a plain HTTPS GET to the model host
(e.g., HuggingFace) and verifies a pinned SHA-256 before trusting the file. The request carries no
voice, transcript, or account data — only your IP address is exposed to the host. One-time; cacheable;
avoidable by using the bundled models.
Subscription licence
Blabb is distributed through the Microsoft Store and billed through Polar, a merchant of record. The app sends only your licence key and a device identifier to check whether an active subscription entitlement is present on the device. No purchase data and no dictation content are transmitted by Blabb.
Optional crash reports (Sentry)
Off by default and opt-in. When on, it sends unhandled-exception details only — SendDefaultPii
off, no user identity, no performance monitoring — and a PHI-scrubbing filter (fail-closed) runs before
anything is sent. For sensitive environments, simply leave it off.
That is the entire list. None of these paths transmits your audio, your transcriptions, or other clinical content.
Is Blabb a Business Associate?
Under HIPAA, a "Business Associate" is an entity that creates, receives, maintains, or transmits PHI on behalf of a covered entity (45 CFR §160.103). HHS is explicit that "the mere selling or providing of software to a covered entity does not give rise to a business associate relationship if the vendor does not have access to the protected health information." Because Blabb runs entirely on the customer's own machine and the vendor never receives, stores, transmits, or accesses PHI, Blabb meets none of the four tests — the same legal category as shrink-wrapped desktop software such as Microsoft Word or Adobe Acrobat, which covered entities use to author PHI-containing documents without a BAA.
So a BAA is not legally required on the merits, and we do not offer one. Some covered entities have a procurement policy that asks every vendor for a signed BAA regardless. If yours does, Blabb will not satisfy it, and you should treat that as a reason to assess the product against your own obligations before deploying it.
On the encryption safe harbor
HHS guidance says ePHI encrypted to the specified standard is not "unsecured," so its loss does not trigger
the HIPAA Breach Notification Rule. Blabb's history is encrypted with AES-256-GCM, a NIST-approved
authenticated mode consistent with that guidance. Two honest caveats a reviewer should weigh. First, the guidance expects the decryption key to be kept separate
from the data; Blabb instead stores the DPAPI-wrapped database key on the same machine and folder as the
database. The safe-harbor argument is therefore strongest when the device itself is protected — Windows
user-account security plus full-disk encryption such as BitLocker, which is a covered-entity workstation
control. Second, the database key is tied to the Windows account: the data wipe deletes
db_key.dat, rendering the history unrecoverable — an effective cryptographic-erasure path if
you ever need it.
What the covered entity is responsible for
A local-only tool shifts most of the technical surface onto the customer's own environment, which also means the covered entity owns those controls. At minimum, expect to provide:
- A documented HIPAA risk analysis and risk-management process
- Workforce training
- Physical, device, and workstation controls (full-disk encryption, screen lock, access reviews)
- An incident-response and breach-notification plan
- A retention configuration
Blabb exposes configurable history retention (auto-delete, default one week; selectable up to "keep until I delete") and a full data wipe. These complement — they do not replace — your organization's Security Rule program. HIPAA is also a federal floor: states such as California (CMIA), Texas (HB 300), and Washington (My Health My Data Act) can impose stricter health-privacy duties, so apply the most protective standard that governs your location and patients.
Where Blabb's protection has limits
A trust page that hides its gaps isn't trustworthy. These are the boundaries a reviewer should know about:
PHI masking is best-effort, not a guarantee
The log and crash-reporting masking uses pattern matching (SSNs, MRNs, dates, phone numbers, emails, medical terms, and more). It reduces PHI in logs but cannot catch every instance of free-form dictated text. Do not treat masking as a license to enable verbose logging in sensitive environments.
Access control relies on the OS account
The effective access boundary is your Windows user account and session lock, not an in-app lock.
Wipe covers the named stores
The data wipe clears history (including SQLite WAL sidecars), secrets, settings, glossary, logs, and the database key, and retains audit logs (a legal-retention choice). The retention/auto-delete path deletes rows by SQL, which can leave write-ahead-log residue until the next checkpoint; for assured sanitization use the full wipe, which removes the database key and renders history cryptographically unrecoverable.
Not externally audited
Blabb has not undergone SOC 2, HITRUST, or an external HIPAA assessment. The statements on this page describe the shipped architecture; they are not a third-party attestation.
HIPAA FAQ
Is Blabb "HIPAA compliant"?
We don't claim that. Only OCR can determine HIPAA compliance, and the FTC has cautioned that "HIPAA compliant" marketing claims can be deceptive. The accurate description is that Blabb's architecture is HIPAA-aligned and local-only; whether it fits your program is your compliance team's call.
Do you sign a BAA?
No. A BAA is not legally required because we never receive or maintain PHI, and we do not offer one. If your procurement policy requires a signed BAA from every vendor, Blabb will not meet it.
Is my audio or transcription ever uploaded?
No. Speech recognition and the cleanup model run on your device. Audio stays in memory and is not saved to disk; only the resulting text is stored, encrypted, on your machine.
Can crash reporting be turned off?
It is off by default. It only turns on if you explicitly opt in, and it can be switched off at any time in Settings. With it off, there is no cloud egress path for crash data.
Where are encryption keys kept?
On your machine, DPAPI-wrapped and tied to your Windows user account. They cannot be used by another user or decrypted off the machine. The trade-off is that protecting the device (full-disk encryption, strong Windows sign-in) is what protects the keys.
Can I verify these claims against the code?
The safeguards described here correspond to named services in the application — the secure-storage service, the integrity audit log, the per-row AES-GCM history cipher, the PHI-masking log sink, and the crash-reporting service. We're glad to walk a security reviewer through the specifics; contact support@blabb.io.
Where these references come from
HHS & the HIPAA Rules
Security Rule technical safeguards (45 CFR §164.312), the Business Associate definition (§160.103), the
Breach Notification Rule (§164.400–414), and the encryption safe-harbor guidance.
HHS — Security Rule ·
HHS — Is a software vendor a Business Associate? ·
HHS — Breach Notification Rule ·
HHS — Breach Safe Harbor
FTC
Why "HIPAA compliant" marketing claims can be deceptive — only HHS OCR determines compliance.
FTC — Protecting health privacy (2023)
NIST & the rule text
The HIPAA Security Rule implementation guide, storage-encryption standards, and the eCFR rule text. The
2025 Security Rule update is proposed, not final (final action projected July 2027).
NIST SP 800-66 Rev. 2 — Implementing the HIPAA Security Rule ·
45 CFR Part 164 (eCFR)
Private by design. Honest about the limits.
Local-only speech and language models, encrypted storage, tamper-evident audit — and no BAA, because none is required and we do not offer one.
QUESTIONS? SUPPORT@BLABB.IO · NOT LEGAL ADVICE