HIPAA E-Signature (2026)

2. Security Rule — required technical safeguards

The Security Rule (45 CFR §164.302–318) lists five technical safeguard categories that apply to electronic PHI (ePHI), including any signed document containing PHI. (1) Access control — unique user identification, automatic logoff, encryption/decryption (the latter is 'addressable' but functionally required). (2) Audit controls — record and examine activity in systems containing ePHI. (3) Integrity — protect ePHI from improper alteration. (4) Person-or-entity authentication — verify the signer is who they claim. (5) Transmission security — encryption in transit. A compliant e-signature stack maps each of these to a specific control: Formfy implements TLS 1.2+ in transit, AES-256 at rest, per-signature audit logs, hash-based document integrity, and email/SMS-based signer verification.

Source: https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html

3. Business Associate Agreement (BAA) — the contractual gate

Under 45 CFR §164.504(e), a Covered Entity (provider, health plan, clearinghouse) MUST execute a written BAA with any vendor that creates, receives, maintains, or transmits PHI on its behalf. The BAA assigns Security Rule obligations to the vendor and enables HHS enforcement against the vendor directly. An e-signature platform that handles signed documents containing PHI is a Business Associate. If your vendor does not offer a BAA, you cannot legally send PHI through their platform regardless of their other security claims. Formfy does not currently offer a BAA — operators with HIPAA-covered workflows should review this restriction before deploying.

Source: https://www.hhs.gov/hipaa/for-professionals/covered-entities/sample-business-associate-agreement-provisions/index.html

4. Audit trail — what must be captured for e-signatures on PHI

The Security Rule's audit-control specification (45 CFR §164.312(b)) requires hardware, software, or procedural mechanisms to record and examine activity in systems with ePHI. For an e-signature, this means at minimum: server-side timestamp (not the signer's local clock), source IP address, user agent / device signal, identity verification method used, and the document hash before + after signing. Formfy generates a per-signature certificate of completion that includes timestamp, IP, browser fingerprint, and a document SHA-256, downloadable as a PDF. Operators should retain audit logs for at least 6 years per the Privacy Rule retention requirement (45 CFR §164.530(j)).

5. Risk analysis — operator obligation before deployment

Before using ANY e-signature platform for PHI workflows, the Covered Entity must conduct a Security Rule risk analysis (45 CFR §164.308(a)(1)(ii)(A)). This is a documented assessment of vulnerabilities, threats, and impact across the entire workflow — not just the e-signature step. The analysis covers: who can access the platform, how authentication works, what happens if a signed document is intercepted, retention and destruction policies, and incident-response procedures. Vendor security claims (including HIPAA certification claims) are inputs to your risk analysis, not substitutes for it.

Source: https://www.hhs.gov/hipaa/for-professionals/security/guidance/guidance-risk-analysis/index.html

6. Patient access and amendment rights

Under 45 CFR §164.524 and §164.526, patients have the right to access, copy, and request amendment of their PHI — including PHI captured in signed forms. Your e-signature platform should support exporting a patient's signed documents on demand (typically within 30 days, extendable once by 30 days under the Privacy Rule) and either incorporating amendments or recording an amendment denial in the audit log. Workflows that lock signed documents into a vendor without a portable export path are problematic — a vendor exit becomes a Privacy Rule violation. Verify portable export (PDF + structured-data download) is documented in your BAA before signing.

7. Breach notification — the 60-day clock

Under the Breach Notification Rule (45 CFR §164.400–414, expanded by HITECH Act 2009), Covered Entities must notify affected individuals within 60 days of discovering a PHI breach. Business Associates must notify the Covered Entity, who then has 60 days from THAT notification — not from the original incident date. For breaches affecting 500+ individuals, the Covered Entity must also notify HHS and prominent media outlets in the affected state. This makes vendor selection critical: an e-signature platform with weak audit logs may not even be ABLE to determine the scope of a breach, which is itself a violation. Verify your vendor supports timely breach forensics.

Source: https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html

8. State law overlay — CMIA, NY SHIELD, Texas HB 300

HIPAA is a federal floor, not a ceiling. Several states impose stricter requirements that apply alongside HIPAA. California's Confidentiality of Medical Information Act (CMIA) defines 'medical information' more broadly than HIPAA defines PHI, and applies to non-HIPAA-covered entities like fitness apps. New York's SHIELD Act adds breach-notification requirements for any business holding NY-resident health data. Texas HB 300 expands the definition of Covered Entity to anyone who 'obtains, assembles, collects, analyzes, evaluates, stores, or transmits PHI,' which can pull non-clinical SaaS vendors into Texas's HIPAA-equivalent framework. For practices operating in multiple states, your most-restrictive applicable law sets the bar — not HIPAA alone.

9. Risk-analysis documentation — what HHS auditors look for

When HHS Office for Civil Rights (OCR) opens a HIPAA investigation, the first document they ask for is your written Security Risk Analysis. Per HHS guidance and audit case law (St. Joseph Health $2.14M settlement 2016, University of Texas MD Anderson Cancer Center $4.3M penalty 2018, multiple HHS Resolution Agreements), a deficient or missing risk analysis is one of the most-cited compliance failures. The analysis must cover: scope (what ePHI exists, where it flows), threat identification (technical, environmental, human), vulnerability assessment, likelihood-and-impact rating, current controls inventory, residual risk determination, and a risk management plan that addresses identified gaps. The analysis must be PERIODIC (typically annually) and event-driven (new vendor, system change, breach). Most operators dramatically underestimate the depth required — a one-page checklist does not satisfy 45 CFR §164.308(a)(1)(ii)(A).

10. Practical onboarding checklist for HIPAA-covered e-signature workflows

Before sending the first PHI-bearing form through any e-signature platform: (1) confirm the practice qualifies as a Covered Entity (or is a Business Associate of one); (2) execute the BAA with the e-signature vendor — verify the BAA template addresses all 45 CFR §164.504(e)(2) required elements; (3) complete a Security Risk Analysis covering the new workflow; (4) document workforce HIPAA training on the new platform (45 CFR §164.530(b)); (5) configure unique user accounts with role-based access (no shared credentials); (6) test the audit-log export and retention policy; (7) document an incident-response plan for the platform (who to call, what to preserve, how to notify); (8) calendar the annual risk-analysis refresh. Cutting any step is a finding waiting to happen if HHS audits you later.