Skip to main content

Security and compliance, in plain language.

Michigan AFC operators store some of the most sensitive records a small business can hold — Social Security numbers, behavioral-health diagnoses, medication regimens. Here is how we protect them.

  • HIPAA-aligned

    AES-256-GCM SSN encryption via GCP KMS · audit logs immutable for 6 years · RLS tenant isolation enforced at the database layer.

  • BAAs with every PHI subprocessor

    Signed Business Associate Agreements with GCP, Google Workspace, and on-file with Supabase + Postmark before any production PHI flows.

  • Built for Michigan AFC operators

    LARA / BCHS / BCAL / MDHHS / DWIHN / CMS regulator clusters supported out of the box. State-specific licensing format validation.

What we do, how we prove it.

SSN encryption at rest

Every Social Security number is encrypted with AES-256-GCM before it touches the database. Keys live in GCP KMS in a separate key ring; the application service account holds encrypt/decrypt only — never key-management.

KMS keyring: afc-phi-keyring · key: ssn-encryption-key · 90-day rotation

Tenant isolation by row

Every facility's data lives in the same Postgres database, but is fenced off by row-level security policies that the runtime application role cannot bypass. The afc_app role runs with NOBYPASSRLS. A second admin role exists for migrations only and never accepts traffic.

Postgres role: afc_app NOBYPASSRLS · 39 RLS policies verified by verify_rls_coverage.py

Audit log, append-only

Every read and write of resident data writes a row to an append-only audit log. Log rows are immutable for 6 years (HIPAA requirement). Triggers refuse UPDATE and DELETE on the audit table.

audit_logs table: append-only triggers · 6-yr retention

HIPAA-grade email

Notifications never include resident health information in the email body or subject line. Operators get a portal link only — every detail lives behind authentication.

Postmark Pro tier · BAA on file · zero-PHI invariant verified by 14-template audit

No PHI in analytics

Vercel Analytics and our privacy-first secondary analytics never receive a resident name, license number, or facility identifier. Marketing-page traffic only.

(marketing) route group only · no PHI event payloads

No PHI to LLM providers

Our AI assistant reads the LARA AFC Manual and our own form-field schemas — never resident records. Prompt construction is structurally prevented from including PHI.

RAG pipeline: manual chunks + field names only · no resident context

Subprocessors that touch PHI.

Every vendor below has a signed Business Associate Agreement on file before any production PHI flows. Synthetic-data and pre-paying-customer environments do not require BAAs.
SubprocessorPurposeBAA status (as of 2026-05-07)
Google Cloud PlatformHosting (Cloud Run, KMS, Logging, Storage, Secret Manager, Cloud Armor, IAP)Signed (umbrella, 2026-05-04)
Google WorkspaceOperator email + calendarSigned (2026-05-04)
SupabasePostgres + Auth + Storage + pgvectorPending — signs at first paying customer onboarding
PostmarkTransactional emailPending — signs at first paying customer onboarding
DocuSealSelf-hosted e-signature service (Cloud Run in same project)No external BAA — self-hosted in ggdc-afc-prod

Last reviewed: 2026-05-07. See ~/Business/docs/compliance/BAA_TRACKER.md (operator-only) for live status.

Run the audit. See what an inspector would see.

Run your free LARA Readiness Audit