See what a self-serve BAA covers, and what it doesn’t.

[!TLDR]

• A BAA template has four required terms under §164.504(e); verify scope covers logs, dashboards, and support tools, not just the primary data path.
• HHS names NIST SP 800-111 (at rest) and TLS 1.2 minimum (in transit) as the encryption safe harbor; encrypted PHI with an uncompromised key does not trigger breach notification.
• Operational logs inherit HIPAA requirements whenever they hold PHI; ask whether recipient identifiers and error echoes are scrubbed before write.
• Audit log integrity requires a tamper-evident mechanism, not just retention; the six-year floor at §164.316(b)(2)(i) applies to Security Rule documentation, not fax content.
• §164.410(b) caps business associate breach notification at 60 calendar days after discovery; the BAA should name the notification method, not leave it to a status page.

How to evaluate a HIPAA-compliant fax API

You handle protected health information, and part of the workflow moves over fax. Discharge summaries to a downstream clinic. Lab results to a referring provider. Prior authorization forms between a specialty pharmacy and a payer. The vendors on your shortlist all publish a HIPAA page. At that level they look interchangeable.

The generic engineering tests for a fax API are covered in the sibling note, How to choose a fax API: idempotency keys, signed webhooks, real retries, structured errors, a self-serve BAA, and public per-page pricing. HIPAA adds a separate failure axis on top of those. A vendor that passes the generic six can still leak PHI in an operational log, sign a BAA whose scope excludes the data the vendor actually holds, or maintain an audit trail with no integrity mechanism. The six tests below cover the added axis. Read them as a pre-integration audit of the vendor’s BAA template, security documentation, and dashboard.

The six added tests

1. BAA scope

The Business Associate Agreement is not the yes-or-no signal most vendor pages present it as. 45 CFR §164.502(e) and §164.308(b) require a BAA before a covered entity can disclose PHI to a business associate. §164.504(e) specifies what the contract has to contain. Reading the template against those required contents is the actual test.

Four contract terms carry most of the weight. §164.504(e)(2)(ii)(B) binds the vendor to appropriate safeguards under Subpart C. §164.504(e)(2)(ii)(C) requires the vendor to report any use or disclosure not permitted by the contract, including breaches of unsecured PHI. §164.504(e)(2)(ii)(D) requires the vendor to flow the same restrictions down to any subcontractor that touches PHI. §164.504(e)(2)(ii)(J) requires return or destruction of PHI at contract termination, or extended contractual protection if return or destruction is not feasible. §164.314(a)(2)(i)(C) adds the security-incident reporting requirement.

What to check: Does the vendor publish or share the BAA template before signup? Do the four required terms above appear verbatim or by clear equivalent? Does the scope cover every place PHI can reach in the vendor’s system (submission, storage, logs, dashboards, support tools) rather than a subset of those? Is subcontractor flow-down explicit?

2. Encryption in transit and at rest, with named standards

§164.312(a)(2)(iv) covers encryption of stored ePHI. §164.312(e)(2)(ii) covers encryption of transmitted ePHI. Both are Addressable specifications. Addressable does not mean optional. Per §164.306(d)(3), the covered entity must implement the specification, implement an equivalent alternative and document why it meets the standard, or document why the specification is not reasonable and appropriate in the entity’s environment (with an alternative measure in place).

The named-standards floor comes from HHS. Under §164.402, “unsecured” PHI is PHI not rendered unusable, unreadable, or indecipherable through a technology or methodology specified by the Secretary. The HHS guidance for that safe harbor names NIST SP 800-111 for data at rest, and FIPS 140-2 (with reference to NIST SP 800-52 for TLS) for data in motion. Encrypted PHI whose key was not also compromised does not trigger breach notification.

NIST SP 800-52 Revision 2 (August 2019) sets TLS 1.2 as the minimum and required support for TLS 1.3 by 1 January 2024. TLS 1.0 and SSL 2/3 are prohibited on government-only servers, and TLS 1.1 is discouraged.

What to check: Does the vendor name a TLS version floor at TLS 1.2 or higher? Does the at-rest description name AES with a specific key size, and reference NIST SP 800-111 or a FIPS-validated equivalent? Is there a statement of key ownership, key rotation frequency, and separation of key material from the ciphertext?

3. PHI-in-logs discipline

An operational log is one of the quietest failure modes in a HIPAA evaluation. It is invisible on the product page, and often not addressed in the security overview. §164.312(a)(1) requires technical policies and procedures that “allow access only to those persons or software programs that have been granted access rights.” §164.312(b) requires mechanisms that “record and examine activity in information systems that contain or use electronic protected health information.” Both attach to any system that holds ePHI. When a request log contains a recipient identifier, or an error log echoes a cover-page body, that log inherits both requirements.

What to check: Ask the vendor for its operational logging documentation. What do the request logs, error logs, metric labels, and support tools retain? Are PHI-carrying fields (recipient identifiers, cover-page contents, uploaded file names, URLs that embed identifiers) scrubbed before write? What happens to log data sent to third-party aggregation services, and are those services signed under subcontractor BAAs per §164.504(e)(2)(ii)(D)? Can support staff read customer content, and does that access generate a corresponding audit event on the customer’s own audit stream?

4. Audit log coverage, integrity, and export path

§164.312(b) requires audit controls on any system that contains or uses ePHI. §164.312(c)(1) requires policies and procedures to protect ePHI from improper alteration or destruction. §164.312(c)(2) makes an electronic mechanism to corroborate that ePHI has not been altered or destroyed an Addressable specification. §164.308(a)(1)(ii)(D) adds an information-system-activity review requirement: audit logs, access reports, and security-incident tracking reports must be reviewed on a regular basis. §164.316(b)(2)(i) requires Security Rule documentation to be retained for six years from creation or from the date it was last in effect, whichever is later. Vendors that publish six-year audit-log retention trace the figure to that documentation floor.

What to check: Is there a per-account audit endpoint that returns the events (send, receive, delete, access, export, key change) with actor identity, timestamp, and event type? Is there an integrity mechanism on those records (hash chain, signed batches, tamper-evident storage), so a tampered record can be detected? Can the account export the full audit stream in a machine-readable format? Is the retention window at least six years, or does the covered entity have to bring its own?

5. Retention configurability and disposal on demand

HIPAA does not mandate a specific retention duration for the ePHI content itself. Retention is a covered-entity decision, driven by the covered entity’s own record-retention policy and by applicable state law. The Security Rule’s six-year floor at §164.316(b)(2)(i) applies to the required documentation, not to the content in a fax record.

§164.310(d)(2)(i) makes “Disposal” a Required implementation specification: policies and procedures for the final disposition of ePHI and the media on which it is stored. §164.310(d)(2)(ii) makes “Media re-use” Required: removal of ePHI from electronic media before the media are made available for re-use. §164.504(e)(2)(ii)(J) then requires the BAA to return or destroy PHI at contract termination, or extend the contractual protection if return or destruction is not feasible.

What to check: Is the default content retention window stated, and is it a customer-configurable knob (both down from the default and up to a longer window)? Is there a per-record deletion endpoint that removes the content everywhere it has been written (live tier, backup, archival tier, log aggregation), or only the visible record? Is the contract-end path executable rather than a support ticket?

6. Breach and security-incident notification path

§164.402 defines a breach as an acquisition, access, use, or disclosure of PHI not permitted under Subpart E that compromises security or privacy, subject to three exceptions (unintentional workforce acquisition, inadvertent disclosure between authorized persons at the same entity, and disclosure where the recipient could not reasonably retain the information). The same section defines “unsecured” PHI, which anchors the safe harbor from Criterion 2.

§164.410(b) requires a business associate to notify the covered entity of a breach “without unreasonable delay and in no case later than 60 calendar days after discovery.” §164.410(c) requires that notice to identify each affected individual (or those reasonably believed affected), and to furnish any other available information the covered entity needs for its own §164.404(c) notice. Below the breach threshold, §164.308(a)(6) requires the vendor to identify, respond to, mitigate, and document security incidents. §164.314(a)(2)(i)(C) requires the BAA to require the vendor to report those security incidents to the covered entity.

What to check: Does the BAA specify the notification method (email to a named security contact, dashboard notice, both) rather than leaving the covered entity to poll a status page? Is the 60-day figure treated as a ceiling or as a target? Does the vendor’s public documentation distinguish a security incident from a breach, so the reader knows what will be reported when?

If you want to see how mintfax operates under a BAA against these six added tests, the HIPAA compliance page describes the BAA path and the underlying controls, the pricing page confirms the same compliance features at every paid tier, and the developer docs cover the audit log API, the PHI boundary, and the retention defaults in reference detail.