How D3rx Handles Your Compliance Data — Honestly

Our operating principle is restraint. We build a deterministic, source-grounded administrative documentation aid — not a certification, not a guarantee, and not a substitute for your counsel or qualified security professional. AI may decorate deterministic output; AI does not author compliance prose. Every claim on this page traces to something that either ships in this repository or runs in our production database.

We use Supabase managed Postgres for the application database, Vercel for hosting and delivery, and Stripe for billing. Account email is delivered through Resend; AI inference is provided by Anthropic and, in some flows, OpenAI. The full third-party processor list is enumerated in our Privacy Policy.

The application database is provisioned in the us-west-2 region. Supabase offers a HIPAA add-on with a Business Associate Agreement on its Team plan and higher; we have not yet enabled that add-on or signed a BAA with our infrastructure providers. See the roadmap section below.

Tenant-owned compliance and SRA records are scoped at the database layer using Postgres Row-Level Security: most tenant-owned tables carry a policy of the shape `practice_id = auth.uid()`, and child rows are gated by related-record ownership checks. Authenticated application queries cannot read or mutate another practice's rows. Service-role and provider-level access (Supabase staff, AWS operators) remain outside that boundary; the BAA chain in the roadmap below is what governs those.

As of 2026-05-22, the production database has 332 active Row-Level Security policies across the public schema. This count is verified against the production database before each commit to this page, not pulled from a marketing tagline.

Most compliance-tool marketing leaks claims that an honest product cannot back. D3rx writes its forbidden list down and tests every export, AI prose block, and marketing page against it. The list below is enforced in code (`src/lib/compliance-sra/claims.ts`) and mirrored from our internal forbidden-claims spec:

• We are not a HIPAA certification. Neither HHS nor OCR recognizes private HIPAA certifications. No badge, seal, or cover-page verdict on any export implies one.
• We do not offer an audit-protection guarantee. We do not have lawyers on retainer; we will not promise to handle your audit for you.
• We do not author compliance policies via AI. AI may decorate deterministic output; AI does not author the policy or risk prose that goes into your binder.
• We do not provide legal advice and are not a substitute for your own counsel or a qualified security professional. The practice remains responsible for reviewing, adopting, and maintaining its compliance program.
• We do not perform penetration testing, vulnerability scanning, or phishing simulation. We describe a practice's security posture; we do not test or improve it.
• We are not an integration platform. We do not pull controls from Google Workspace, Microsoft 365, EHR systems, or cloud admin consoles. Users enter their inventory and evidence, and D3rx organizes it.
• We do not upload your ERA remittances. The in-browser ERA explainer at /era parses your 835 or PDF remittance entirely in your browser; the denial data in it, including the patient account number, is never sent to our servers. Saving to this device is off by default, and a one-click Clear-all wipes anything you chose to keep.

Every mutation to a compliance or SRA record flows through an append-only `compliance_audit_events` table, scoped by `practice_id = auth.uid()`. The audit log is queryable by the practice owner; binder-export generation is itself recorded as an audit event.

The audit log action labels in scope today are tracked by the regression guard in `src/lib/compliance/__tests__/audit-actions.test.ts` and grouped below. Live `logAuditEvent` call sites may emit additional labels under the same naming convention; the regression list is updated as new label families are pinned.

• document.upload, document.download, document.delete
• report.unlock, report.create
• assessment.create, assessment.update, assessment.complete
• vendor.create, vendor.update, vendor.delete
• training.create, training.delete
• risk.update
• reminder.create, reminder.update, reminder.delete
• subscription.checkout, subscription.activated, report.unlock_checkout
• sra_one_time_unlock.checkout, sra_one_time_unlock.activated
• sra_remediation.regenerate, sra_remediation.update, sra_remediation.delete
• sra_policy_review.create, sra_policy_review.update, sra_policy_review.delete
• sra_section_approval.upsert
• sra_export.record, sra_export.generate, sra_export.scan_failed, sra_export.locked_denied, sra_export.readiness_blocked

These are items customers and resellers commonly ask about. We refuse to list them under "what we have" until they are true. They live here so the buyer can decide whether to wait, push us for a date, or pick a different vendor.

• SOC 2 Type 1: not yet. We have not committed to an audit date and we will not pretend otherwise. We will update this section the moment a scoped engagement is signed.
• Annual third-party penetration test: not yet. We do not currently engage an outside firm for an annual application or infrastructure pentest. When that changes, we will name the firm and the cadence.
• HIPAA Business Associate Agreement with our infrastructure providers: not yet. Supabase offers a BAA on its Team plan; enabling it requires the HIPAA add-on, signed BAA, and project-level controls described in Supabase's documentation. Until we complete that step, do not treat D3rx as a BAA-ready destination for protected health information. Our Privacy Policy says the same.
• Customer-facing BAA: not yet. We expect to evaluate customer-facing BAAs once the upstream BAA chain above is in place.

D3rx is built and operated by D3rx Inc, a small US company. We are deliberately a small team and we will not pretend to be a larger one. We do not list staff biographies on this page because we will not fabricate them — when an individual is named here, that person will be identifiable and accountable.

What this means in practice: product code changes ship through a single repository; schema changes ship through migration files in that repository; and claims on this page are intended to trace back to code or production data. There is no separate marketing surface that contradicts the engineering work.

Security and trust contact runs through [email protected]. Security questions, suspected vulnerabilities, and trust-page corrections all reach the same address. If you need a named human on the other end of an email, request one and we will identify ourselves directly — we just refuse to dress up that exchange as a fabricated roster on a static page.

Security questions, suspected vulnerabilities, and trust-page corrections go to [email protected]. We do not currently operate a bug bounty or formal vulnerability-disclosure program, but we review reports sent there and ask reporters to include reproducible details before any public disclosure.