> ## Documentation Index
> Fetch the complete documentation index at: https://docs.platform.embeddables.com/llms.txt
> Use this file to discover all available pages before exploring further.

# HIPAA compliance

> How Embeddables handles field classifications, protected data access, permissions, and audit logging on HIPAA-sensitive projects

## Overview

Embeddables gives you three tools to run HIPAA-sensitive projects safely:

1. **Field classifications** — mark which form fields collect sensitive data (PII or PHI), so Embeddables knows how to treat them.
2. **Protected data access** — view individual responses only after an explicit permission has been granted to your account.
3. **Audit trail** — every time someone reads protected data or changes a governance setting, that action is recorded automatically. Nothing goes through without a log entry.

## Managing HIPAA settings

HIPAA settings for your project can be managed through the **Embeddables Dashboard**, the **Embeddables MCP**, or by **reaching out to the Embeddables team**. This page focuses on how those controls work so you can plan integrations and access policies — not on a specific management UI.

## Permissions

Not everyone on your team can access sensitive data by default — that's intentional. Two project permissions govern HIPAA-related work:

| Permission | What it allows |
| - | - |
| `data.full.read` | Read identified data — individual email addresses, full answer breakdowns |
| `data.governance.manage` | Set field classifications (which fields are PHI/PII) |

Standard analytics (funnel counts, page views, results summaries) are aggregate and don't require either permission.

<Warning>
  Neither `data.full.read` nor `data.governance.manage` is granted automatically — not even to
  project admins. An Embeddables administrator must grant the first access on a project. After that,
  a member with `team.permissions.edit` can extend either permission to others only when they
  already hold it themselves (no privilege escalation).
</Warning>

## Field classifications

A field classification tells Embeddables what kind of sensitive data a form field collects. Classifications are set per field, per form. Available values:

| Label | Meaning |
| - | - |
| `PHI` | Protected Health Information |
| `PII` | Personally Identifiable Information |
| `none` | Explicitly not sensitive |
| `undefined` | Not yet classified |

When you update classifications, only the fields you specify change — everything else stays as it is. Re-applying the same classification for a field is safe and has no extra side effects.

## Protected data vs aggregate analytics

Some reporting surfaces return **identified** respondent data. Access requires `data.full.read`. If your account doesn't have it, the request is denied and the attempt is logged.

Examples of protected reads:

* **Captured emails** — individual email addresses tied to respondents in a date range.
* **Answer breakdown by field** — counts per distinct answer for a specific form field (for example, date of birth), which can reveal identifiable values when cardinality is low.

**Aggregate analytics** — funnel overviews, step counts, page traffic, and results summaries — never include individual user data. They only require `analytics.read` and work without additional HIPAA permissions.

## Audit trail

Every sensitive action — reading protected data, changing a field classification, updating who has access — is logged automatically **before** the action happens. If the log can't be written for any reason, the action is blocked entirely.

What gets logged:

| Action | When it's logged |
| - | - |
| Reading captured emails | On every successful or failed attempt |
| Reading answer breakdowns | On every successful or failed attempt |
| Updating field classifications | On every write |
| Changing a member's permissions | On every write |
| Inviting a member to the project | On every invite |
| Removing or disabling a member | On every removal |
| Disabling or re-enabling a project | On every status change |

Each log entry records who took the action, what they did, whether it was allowed or denied, and why it was denied if applicable. **Log entries never contain email addresses, names, form answers, tokens, or any personal data.**

To review the audit log for your project, use the Embeddables Dashboard when available, your Embeddables MCP connection if you have one, or contact the Embeddables team.