Originally published at theculprit.ai/blog/hipaa-checklist-for-alert-pipelines.

The compliance review for a healthtech SaaS usually treats the alert pipeline as a footnote.

The product is HIPAA-ready, the database is encrypted, the BAAs are signed, the access controls are documented. Then someone runs grep on a week of monitoring logs and finds patient IDs, member emails, and the occasional plaintext SSN sitting in alert payloads — copies of which were forwarded to a third-party log aggregator (without a BAA), surfaced to an LLM-based incident-analysis tool (also without a BAA), and rendered in plaintext inside a Slack channel that a contractor was a member of last month.

The product wasn't the leak. The alert pipeline was. And alert pipelines are a near-universal blind spot because the engineering team that built the application isn't the same team that wired up the alerting, and the alerting tools don't advertise themselves as PHI-handling systems.

This post is the checklist a healthtech engineering team can hand a HIPAA auditor and say "here's how the alert path is treated like the rest of the data path." Eight controls, mapped to the HIPAA Security Rule's Technical Safeguards (45 CFR 164.312), with concrete pointers to what each one looks like in code.

Where PHI gets into alert payloads

Before the controls, the threat model. A few common paths PHI takes into a monitoring alert:

1. Stack traces from production exceptions. A NullReferenceException in a patient-record handler captures the request URL, often containing patient identifiers. A failed insert captures the row being inserted, often containing PHI fields. Your error-tracking vendor will happily forward these verbatim to whichever notification channels you've configured — usually without a redaction step in between.
2. Webhook payloads from third-party services. A claims-clearing house's status webhook may include the member identifier in the body. A pharmacy benefit manager's notification includes the prescription. The alert that fires when the webhook 500s contains the full payload.
3. Database query timeouts. Slow-query log lines often include the bound parameters of the query — patient IDs, dates of birth, diagnosis codes. The alert that fires on "slow query" forwards the line.
4. Application logs surfaced into alerts. A log line emitted by your code with logger.warn({ user, request }) becomes the body of an alert when an aggregator's threshold fires. The full user object — email, phone, SSN-last-4 — rides along.
5. Health-check failure responses. A health-check endpoint that returns the failing patient-record's ID in its error body propagates that ID into the uptime monitor's alert.

In each case, PHI lands somewhere outside the application's authorized data path: a log aggregator, a notification channel, an incident-analysis tool, an on-call engineer's phone screen. Most of those somewheres are vendors who have not signed a BAA with you.

What HIPAA's Technical Safeguards actually require

The relevant subsection of the Security Rule (45 CFR 164.312) names five Technical Safeguards. Five sound like a lot; the load-bearing ones for an alert pipeline are:

• § 164.312(a)(1) Access control — only authorized personnel can decrypt PHI; the system enforces this in code, not by trust.
• § 164.312(b) Audit controls — every access to PHI is recorded; the audit trail itself is tamper-evident.
• § 164.312(c)(1) Integrity — PHI cannot be altered or destroyed by unauthorized parties; this includes side-channel destruction (e.g. a forgotten log retention deletes the only audit trail of a breach).
• § 164.312(d) Person or entity authentication — every PHI-accessing actor is authenticated with traceable identity, not "the on-call account."
• § 164.312(e)(1) Transmission security — PHI is encrypted in transit; this includes intra-system hops, not just the user-facing TLS layer.

The piece that catches most alert pipelines isn't any single safeguard — it's that the alert path is not treated as a PHI path, so none of these safeguards are applied to it specifically. The Notice of Privacy Practices doesn't mention monitoring alerts. The internal access-control matrix lists the application's data store but not the log aggregator. The audit log captures application-level reads but not "the on-call engineer saw the alert payload."

The checklist below addresses each gap.

The 8-item checklist

1. Tokenize PHI at ingest, before any storage

The first system that receives an alert payload (your ingestion edge) replaces every PHI value with an opaque token before writing the payload to any backing store. Concretely: a regex pass over the raw payload identifies high-confidence PHI shapes (emails, IPs, SSNs, common ID formats), each match gets replaced with <EMAIL_a3f9> / <SSN_b8c4> / <IP_2c1e>, the token-to-real mapping is encrypted with the customer's per-tenant key and stored in a vault separate from the alert event row.

After this step, the alert row in the operational store contains tokens only. Every downstream stage (correlation, LLM analysis, notification fan-out, log retention) operates on the tokenized form. The vault is read only by code paths that pass an authorization check.

What this earns: the alert pipeline now satisfies §164.312(a)(1) and §164.312(e)(1) for everything past the ingest edge — there is no PHI to access without going through the vault, and there is no PHI in transit to any downstream system.

2. Encrypt the vault at rest with customer-controlled keys

The vault that holds the token-to-real mapping is encrypted at rest with a customer-specific symmetric key. Postgres's pgcrypto extension gives you pgp_sym_encrypt() for this — the encrypted bytes go into a bytea column, and only the application's authorized code paths know the key.

Two decisions that matter:

• Key per tenant, not key per row. Per-row keys are a key-management nightmare and don't add real security. Per-tenant keys mean a key rotation only requires re-encrypting one tenant's vault.
• The key never enters the alert row's storage system. Keys live in your secret store (1Password / AWS Secrets Manager / Cloudflare Workers' bindings) and are pulled into the application process at startup. A snapshot of the database without the keys is not a PHI breach.

What this earns: §164.312(c)(1) integrity (the vault is tamper-evident — modifying ciphertext without the key produces decryption failure) and one half of §164.312(e)(1) (encrypted at rest).

3. Use SECURITY DEFINER functions for vault access, not direct SELECTs

Application code never SELECTs from the vault directly. Instead, it calls a SQL function defined as SECURITY DEFINER (in Postgres) that:

• Verifies the caller is authorized to decrypt this specific record (the tenant matches, the actor has the right role, the access is being made in the context of an active incident, etc.)
• Decrypts the requested tokens using the tenant's key
• Writes an audit row capturing who decrypted what, when
• Returns the plaintext to the caller

Wrapping decryption in a function gives you a single chokepoint to enforce all the access-control and audit-logging rules. Without it, every code path that wants to display PHI has to remember to do those checks, and the checks will drift.

What this earns: §164.312(a)(1) access control (the function is the access enforcement) plus §164.312(b) audit controls (the function writes the audit row).

4. Send only tokens to LLM analysis, never raw PHI

Any LLM-driven analysis (root-cause inference, correlation, summarization) operates on the tokenized payload. The model sees <EMAIL_a3f9> instead of alice@example.com. The model's output, similarly, contains tokens — your UI rehydrates them into plaintext only on display, only for authenticated users with the right access.

Why this matters even with a BAA-covered LLM vendor: the model's training data, the model's prompt cache, the model's logs, the inference platform's debug surfaces, the conversation context an engineer might paste into a developer console — all of these are surfaces where the prompt could end up being retained or visible. Sending tokens means none of those surfaces ever holds PHI.

What this earns: closes the most common HIPAA-blast-radius gap in modern alert pipelines (LLM analysis was a 2023 addition for many teams, and the controls didn't get updated).

5. Audit every PHI rehydration

Every time a token is decrypted to plaintext (a UI that shows the original value, an export to PDF, a customer-support tool that surfaces the data), an audit row is written. The audit row captures: who (authenticated user ID), what (which tokens), when (timestamp), in what context (incident ID, ticket ID, support session ID).

The audit table is append-only — no updates, no deletes from the application — and is itself protected (separate access control, separate retention).

What this earns: §164.312(b) audit controls. A HIPAA auditor's standard test is "show me a record of every time PHI for patient X was accessed in the last 90 days." If you can produce that report from one audit table, you pass; if you have to assemble it from log files across five vendors, you fail.

6. Default-deny on outbound notifications

Every channel the alert pipeline can fan out to (PagerDuty, Slack, email, webhook) receives the tokenized payload by default. To send plaintext, the channel configuration must explicitly opt in — and the opt-in is logged + reviewed quarterly.

The default matters because new channels get added regularly ("can we send these to the new on-call rotation in the platform team?"), and the safe default is "yes, with tokens." If the default were "yes, with plaintext," every new channel introduces a fresh BAA conversation that's likely to be skipped under deadline pressure.

What this earns: §164.312(e)(1) transmission security (PHI doesn't leave the system in plaintext); also a major reduction in BAA scope (you only need BAAs with vendors that actually receive plaintext, which is a much smaller set).

7. Auto-resolve quiet alerts to limit retention

The HIPAA Security Rule doesn't specify a retention period for alerts, but the principle behind §164.312(c)(1) is that PHI shouldn't sit indefinitely in places where it's not actively serving a clinical or operational purpose.

A practical control: incidents that have been quiet for 30 minutes and don't have an active investigation get auto-resolved. Auto-resolve doesn't delete the underlying tokenized payloads (you may need them for a future investigation), but it moves the incident out of the on-call queue and out of the active dashboard. The vault retention policy (separately) governs how long the encrypted plaintext is kept; a defensible default is "as long as the corresponding incident is needed for audit, then deleted via a periodic sweep."

What this earns: bounded retention of accessible PHI, which limits both the §164.312(c)(1) integrity surface and the volume that has to be re-reviewed during a periodic access audit.

8. Tenant-isolation at the database, not at the application

Multi-tenant SaaS architectures often enforce tenant isolation in application code ("the application only queries rows where tenant_id matches the authenticated session"). For HIPAA, this is too weak — a single bug in any code path that omits the predicate is a cross-tenant breach.

The control: enforce tenant isolation at the database level via Row-Level Security (Postgres's RLS), where every row in every PHI-adjacent table has a tenant_id column and the database itself rejects queries that don't match the active session's tenant. Application code can still construct the query without the predicate; the database refuses to return cross-tenant data.

What this earns: §164.312(a)(1) access control, with the enforcement layer being the database (not the application). A bug in application code can no longer cause a cross-tenant PHI leak — the bug would have to be in the RLS policy itself, which is much smaller surface area to review.

What this looks like in practice

Three concrete patterns from a production alert pipeline that ships with these controls:

Edge tokenization in TypeScript:

// Conceptual; production code wraps this in vault writes + key resolution.
const sanitized = payload.replace(EMAIL_REGEX, (match) => {
  const token = `<EMAIL_${hmac(match, salt).slice(0, 4)}>`;
  vault.set(token, encrypt(match, tenantKey));
  return token;
});

The hmac slice keeps tokens deterministic per-value within a tenant — the same email always produces the same token, so correlation across alerts works.

SECURITY DEFINER decryption in Postgres:

CREATE FUNCTION token_decrypt(p_incident_id uuid, p_tokens text[])
RETURNS TABLE(token text, plaintext text)
SECURITY DEFINER
LANGUAGE plpgsql
AS $$
BEGIN
  -- Authorization: caller must have read access to this incident's tenant.
  IF NOT EXISTS (
    SELECT 1 FROM tenant_members
    WHERE tenant_id = (SELECT tenant_id FROM incidents WHERE id = p_incident_id)
      AND user_id = auth.uid()
  ) THEN RAISE EXCEPTION 'forbidden'; END IF;

  -- Audit the decryption.
  INSERT INTO token_decrypt_audit (incident_id, actor_id, token_count)
  VALUES (p_incident_id, auth.uid(), array_length(p_tokens, 1));

  -- Decrypt + return.
  RETURN QUERY
    SELECT v.token, pgp_sym_decrypt(v.encrypted_value, key())::text
    FROM vault v WHERE v.token = ANY(p_tokens);
END;
$$;

This is the only path application code uses to see plaintext. Direct SELECT FROM vault is rejected by RLS; token_decrypt is the chokepoint.

Token-only LLM prompt:

const prompt = `Analyze the following sanitized incident events:
${sanitizedEvents.join('\n')}
The events contain placeholder tokens like <EMAIL_x> for redacted PII.
Do not attempt to infer the actual values; reason about the patterns.`;

The LLM never sees plaintext. Its output cites the tokens; the UI rehydrates them via token_decrypt only when an authorized user clicks "show plaintext."

What you sign up for

These controls aren't free. Three honest tradeoffs:

• Cluster quality drops slightly when the LLM can't see literal values. Two alerts that both reference alice@example.com cluster trivially when the LLM sees the email; with tokens, the cluster has to come from the surrounding context. Mitigations exist (deterministic tokens that produce the same placeholder for the same value, so co-occurrence is preserved) but don't fully close the gap.
• The audit table grows. Every rehydration writes a row. At healthcare-SaaS scale (thousands of incidents per month per tenant) the table grows into the millions of rows per year. Plan for this with partitioning + a separate retention policy.
• The on-call experience adds one click. Engineers who used to see the patient ID inline now see <EMAIL_a3f9> and click "show plaintext." For most incidents the click is unnecessary (the tokens are enough to triage); for the 10% where it matters, the extra click is the cost of the audit trail.

The alternative is the status quo: PHI in alerts, scattered across vendors, audit trails that don't exist, and the cheerful assumption that nobody on the security team will think to look at the alert pipeline during the next audit. That assumption holds until it doesn't.

Where this generalizes

The controls above are written for HIPAA but apply with minor edits to any compliance regime that requires (a) data classification, (b) access control, and (c) audit logging on a sensitive-data path. SOC 2's Common Criteria 6 (Logical and Physical Access Controls) maps to controls 1, 3, 5, 8. ISO 27001's Annex A.9 (Access Control) maps to controls 3, 5, 8. GDPR's Article 32 (Security of Processing) maps to controls 1, 2, 4, 6.

The pattern is universal: treat the alert pipeline as a sensitive-data path, not as a footnote. Every piece of PHI / PII / PCI that flows through the alert path should be tokenized, encrypted, audited, and tenant-isolated by the same primitives that protect the application's data store. Once those primitives exist (controls 1-3 are the foundation), the rest follows.

This is the architecture behind Culprit's edge tokenization model — every alert payload arrives, gets tokenized, gets stored encrypted, and downstream tools see only tokens. The /security page documents the specific control mapping if your security team wants to review the architecture during a vendor review.