HIPAA one-pager

Posture summary

SpiderLabs operates as a business associate to the covered businesses we serve. The table below is the whole posture; the sections after it explain each line.

The PHI boundary is enforced in code

Every outbound network request in our integration layer that could carry patient data must pass a PHI boundary check before it executes. The check verifies the destination is an approved endpoint for that kind of data. This is not a policy document: an automated test suite scans the integration code and fails the build if any outbound call skips the check.

Access to patient content is audited

Reading a call transcript or playing back a recording writes an audit event recording which account, which person, and when. The audit trail is designed so a practice owner or a reviewer can answer the question “who saw this patient’s content, and when” without inference.

Data minimization is the default

We call the customer-facing posture Mirror Mode: your team works in a clean SpiderLabs dashboard while heavier artifacts stay upstream. By default we do not keep bulk copies of raw transcripts or recordings. What we store is operational: identifiers, timestamps, event types, appointment and callback status, and safe metadata. When a teammate opens a call, the content is retrieved on demand through our own servers, the access is audited, and enabling any broader raw storage is an explicit, deliberate platform change rather than a default.

Access control and isolation

Dashboard access is role-based (owner, admin, member, viewer; see Team and roles), so each teammate sees only what their role allows. Each business’s data is isolated to its own account: one account cannot read another’s calls, patients, or appointments. We do not use your patients’ data to train shared models.

The BAA and our subprocessors

We sign a business associate agreement with each covered business as part of onboarding, and an executed BAA is a launch requirement. The agreement text is public on the HIPAA and BAA page. Underneath us, an executed BAA with our data-platform provider is on file today, and business associate agreements with the remaining covered subprocessors in the voice and hosting stack are executed or in progress. We do not name subprocessors on customer surfaces, and we treat vendor coverage as a per-customer launch check: before live patient data flows for a new account, the coverage for that account’s stack is verified and evidenced.

The live-PHI activation gate

For a new customer, live patient traffic is not switched on until two things are true: the BAA is executed and on file, and the compliant data environment for that account is active and verified during onboarding. Until both hold, a business launches in callback-first mode under the minimum-necessary posture above. The gate is not optional, and we hold launches on it.

What we do not claim

• We do not claim certifications we do not hold. If a specific attestation (for example SOC 2) matters to your review, ask us directly rather than reading between lines.
• We do not claim that HIPAA compliance is a product feature you can buy. It is a shared posture: our controls above, your BAA, and your own staff practices together.
• We do not claim every subprocessor agreement is filed until it is. The honest current state is always available from us on request.

Verify it yourself

The fastest check is to ask. Security questions, vendor status requests, and vulnerability reports all reach a monitored mailbox, and breach-notification terms are covered in the BAA.

For the narrative version of this posture, read Security and compliance. For the agreement text, read the HIPAA and BAA page. For how data flows in practice, read Booking modes and Analytics and reporting.