Compliance

HIPAA Compliance for Lead Routing

Lead Router is architected for the HIPAA Security Rule. AES-256-GCM at rest, TLS 1.2 plus in transit, row-level tenant isolation, audit logs on every access. Business Associate Agreement available on request. Formal HIPAA attestation in progress.

AES-256-GCM

Encryption at rest

Row-level

Tenant isolation

Audit logged

Access trail

The Basics

What HIPAA requires

HIPAA governs Protected Health Information. If you route leads for healthcare services, you likely process PHI and the rules apply to you.

Protected Health Information (PHI)

PHI is any individually identifiable health information held or transmitted by a covered entity or its business associate. Names, phone numbers, emails, addresses, dates of birth, and any condition or service interest tied to a person all count when the context is healthcare. A lead for Medicare, health insurance, dental, mental health, telehealth, or medical devices carries PHI the moment the prospect is associated with a healthcare service. Partial identifiers combined with health context also qualify. A zip code plus a date of service plus an ailment is PHI even if the name is removed.

Covered entities and business associates

Covered entities are health plans, clearinghouses, and healthcare providers. A business associate is anyone that creates, receives, maintains, or transmits PHI on their behalf. A lead routing platform that processes PHI is a business associate, and the relationship must be formalized through a Business Associate Agreement (BAA) before PHI changes hands. Subcontractors of a business associate need BAAs with the business associate, which means the chain runs all the way down.

Security Rule

The Security Rule covers electronic PHI. It requires technical safeguards (encryption, access control, audit logs, integrity checks), administrative safeguards (workforce training, access management, incident response), and physical safeguards (facility access, device control). Each safeguard has required and addressable implementation specifications.

Privacy Rule

The Privacy Rule covers who can see PHI and for what purpose. The core principle is minimum necessary: disclose the least amount of PHI needed for the task at hand, and no more. It also covers individual rights, including the right to request access, request amendment, and receive an accounting of disclosures. Marketing and sales use of PHI requires explicit patient authorization. A generic opt-in checkbox on a lead form does not satisfy the rule on its own.

Breach Notification

The Breach Notification Rule requires notice to affected individuals, HHS, and in some cases the media when unsecured PHI is compromised. Notice deadlines are 60 days from discovery for individual and HHS notification, with annual summary reporting for smaller breaches.

Penalties

Civil penalties range from about $100 to $50,000 per violation depending on culpability tier, with an annual cap of $1.5M per identical violation type. Willful neglect with no correction sits at the top of the tier schedule. Criminal penalties apply when PHI is obtained or disclosed with intent to sell or cause harm.

How Lead Router Is Built

How Lead Router is architected for HIPAA

Six architectural controls that map to the HIPAA Security Rule. Each one is enforced in code, not left to operator discipline.

Encryption at rest

All lead records, contact fields, custom fields, sale records, call records, and audit logs are encrypted at rest using AES-256-GCM. Key material is held in separate key-management infrastructure from the application database, so a stolen database dump does not hand over readable PHI. Encryption keys rotate on a scheduled cadence, and backups are encrypted with the same standard. Database snapshots and point-in-time recovery images carry the same encryption as live storage.

Encryption in transit

All API endpoints, admin, buyer, and partner portals require TLS 1.2 or higher. Plaintext HTTP is rejected at the edge with a redirect, never served. Outbound webhook deliveries to buyer endpoints also require TLS, and delivery will fail closed if the buyer endpoint rejects a modern cipher. Internal service-to-service traffic runs over authenticated TLS. There are no unencrypted paths for PHI to travel on the platform.

Access controls

Role-based access controls enforce who sees what. Admins are scoped to their tenant. Buyers see only leads matched to their contracts. Partners see only their own campaign data. Admin accounts require 2FA, with Passkey and WebAuthn supported for phishing-resistant sign-in. Row-level tenant isolation is enforced on every database query through a central helper, not ad-hoc per route, which removes the class of bug where one forgotten WHERE clause leaks across tenants.

Audit logging

Every authenticated action writes an audit record with actor, timestamp, target entity, and request IP. Reads on lead records, PHI field access, and admin actions are captured. Audit logs are retained for 90 days at minimum for standard accounts and longer under HIPAA mode. The log itself is append-only and tenant-scoped, so a compromised tenant admin cannot erase their tracks. Audit exports are available on request for incident review.

Minimum necessary

Buyers see only the leads they won through matching contracts, plus the specific fields their contract is licensed for. Partners see only their own campaign and lead data, never another partner's. Admin access is tenant-bounded. No global view of PHI exists outside a narrow superadmin role used for Lead Router support, and that role is itself audit-logged. Field-level access controls allow you to hide sensitive fields from specific roles within a tenant as well.

Breach readiness

A documented incident-response runbook covers detection, triage, containment, customer notification, and HHS notification under the Breach Notification Rule. Tabletop exercises are run on the runbook. Data-subject deletion requests are handled via a dedicated DSR flow with 30-day turnaround. PHI purge is verified across primary tables, derived tables, audit logs, and backups within the retention window, with a signed-off verification record.

Business Associate Agreement

How to get a BAA

A BAA is the contract that formalizes the business-associate relationship. It must be executed before PHI is processed on a HIPAA-covered workload.

Lead Router offers a mutual BAA to customers processing PHI. The process is short. Customer requests a BAA through support or their account contact. Lead Router sends the standard BAA for review. Both parties execute, and the agreement covers all lead data processed through the tenant going forward.

The BAA defines permitted uses and disclosures, safeguards, subcontractor terms, breach notification timelines, and termination. Service-level commitments around uptime, backup, and retention are documented separately in the Terms of Service and referenced in the BAA.

If you are running a healthcare vertical today on a non-BAA account, request the BAA before onboarding PHI. Account staff can flip the tenant into HIPAA mode as part of the BAA execution, which turns on the full set of controls described above including stricter audit-log retention and tighter backup windows.

Subprocessors are disclosed as part of the BAA. The current list includes the database provider, the object-storage provider, the transactional email provider, and the call-tracking provider. Each of these signs a BAA with Lead Router, and any addition to the list is communicated to customers on HIPAA mode before it takes effect.

Honest Scope

What is covered and what is not

A BAA covers the data Lead Router processes on your behalf. It does not cover data outside the platform.

Covered

  • Lead records you post or receive through Lead Router, including names, contact info, and custom fields
  • Sale records, distribution logs, and posting logs tied to routed leads
  • Audit trails of who accessed PHI inside the tenant
  • Call records and recordings generated by live transfer inside Lead Router

Not covered

  • !PHI stored in your own systems before it enters Lead Router, such as landing-page databases and marketing tools
  • !Data you export from Lead Router into your own CRM, warehouse, or spreadsheets
  • !Data processed by third-party buyers after delivery. They become the responsible party on their side
  • !Data you send to subprocessors Lead Router does not control on your behalf

Where We Are

Audit status

Architecture shipped. Formal attestations in progress. BAA available today based on architecture review.

SOC 2 Type II audit is in progress. HIPAA attestation is in progress. The platform architecture is aligned with the HIPAA Security Rule, and formal attestation is expected in 2026. BAA is currently offered on the basis of that architecture review and the controls described on this page.

When attestations complete, this page will be updated with the reporting period, the auditor, and a link to request the report under NDA. Until then, we are explicit: the controls are live and enforced, the formal third-party sign-off is in flight, not yet issued.

Frequently Asked

FAQ

The questions healthcare lead-gen operators ask before onboarding.

Is Lead Router HIPAA compliant?

Lead Router is architected for HIPAA and offers a Business Associate Agreement on request. Formal HIPAA attestation is in progress. The technical controls required by the Security Rule are in place today: AES-256-GCM encryption at rest, TLS 1.2 plus in transit, role-based access with row-level tenant isolation, audit logging on every authenticated action, 2FA and Passkey support on admin accounts, and a documented incident-response runbook.

How do I get a BAA?

Contact support or your account contact to request a BAA. Lead Router sends the standard mutual BAA for review. Both parties sign, and the agreement covers all lead data processed through your tenant from that point forward. HIPAA mode is enabled on the tenant as part of BAA execution, which activates stricter audit-log retention and other controls.

What encryption does Lead Router use?

AES-256-GCM for data at rest on lead records, contact fields, custom fields, sale records, call records, and audit logs. Key material is held in separate key-management infrastructure from the application database. TLS 1.2 or higher is required on every API endpoint and portal. Plaintext HTTP is rejected at the edge. Outbound webhook deliveries to buyer endpoints also require TLS.

Who can access PHI inside Lead Router?

Access is role-based. Tenant admins see only their tenant. Buyers see only leads matched to their own contracts, and only the fields licensed to that contract. Partners see only their own campaigns and leads. A narrow superadmin role exists for Lead Router support and is itself audit-logged. Every authenticated action that touches a lead writes an audit record with actor, timestamp, entity, and request IP.

What happens on a data subject deletion request?

A Data Subject Request is filed through the DSR flow at /dsr. Turnaround is 30 days. PHI is purged from primary tables, derived tables, call records, and audit logs within the platform's retention window. Verification is logged so the customer has a record of completion. Deletion from third-party buyer systems is the responsibility of those buyers and is documented separately in their own DSR processes.

Healthcare-Ready

Route leads for healthcare verticals with HIPAA architecture

Medicare, health insurance, dental, mental health, telehealth, medical devices. Encrypted at rest, TLS in transit, audit trail on every access, BAA available on request.

Request a BAA through support. Formal attestation in progress.