Trust

Security & Compliance

Last updated October 16, 2026. We'll keep this page current as our posture matures.

ClearReport stores legally sensitive incident reports for licensed California assisted living facilities. We treat security as a product requirement, not a checkbox. This page describes how we protect your data today and where we're heading.

At a glance

  • Encryption in transit (TLS 1.2+) and at rest (AES-256)
  • Identity managed by Clerk; MFA available to all users
  • Role-based access scoped to facility (org_admin, facility_admin, worker)
  • Per-mutation audit log retained for 7 years
  • Daily Supabase backups with 7-day point-in-time recovery
  • All subprocessors located in the United States
  • We do not currently offer a Business Associate Agreement — see HIPAA posture below
  • AI vendors receive report text only as described on our subprocessor page: Anthropic receives the report under review; Voyage AI receives administrator policy text and pattern-redacted narrative text for retrieval.

Data protection

Encryption

  • In transit: TLS 1.2 or higher for every connection between your browser, our application, and our subprocessors. HSTS (two-year max-age, includeSubDomains) sent on every response.
  • At rest: AES-256 disk encryption on our Supabase Postgres instance.
  • Secret handling: API keys and service credentials are stored in Infisical and injected at build/deploy time. No secrets live in source control.

Database isolation

Customer data is logically separated by the Clerk organization ID (org_id). Isolation is enforced in the application's server-side authorization layer: the caller's organization is resolved from their authenticated session, and every query is scoped to it — the organization ID is never trusted from the client. We do not have a feature that lets one customer see another customer's data.

Sensitive fields

  • SOC 341 (suspected abuse) reports store only the last four digits of victim social security numbers, never the full SSN.
  • Payment card numbers are never stored on our servers — Stripe holds them, we store only Stripe customer/subscription IDs.
  • Resident date-of-birth and admission-date fields are required by the regulatory forms; we treat them as protected fields and surface them only inside role-appropriate views.

Access control

User authentication

  • Sign-in is handled by Clerk. We do not store passwords ourselves.
  • Multi-factor authentication with an authenticator app (TOTP) plus one-time backup codes is available to every user. SMS codes and passkeys are not offered today. We encourage every administrator and reviewer to turn it on.
  • Sessions expire 7 days after sign-in. There is no separate inactivity timeout today.

Role-based access

  • Organization admin: every facility, resident and report in the organization, plus billing and team.
  • Facility admin: the reports, residents, team and compliance for the facilities they administer.
  • Caregiver (worker): only the reports they wrote. A SOC 341 abuse report is never visible to any caregiver other than the person who wrote it.
  • Permission checks happen on every server-action call, not just in the UI.

Skdaddle staff access

  • Skdaddle staff access to customer data is restricted to a small group of identified employees and is logged in a separate audit trail.
  • Skdaddle staff can reach customer data only through the audited staff portal. Every staff view of an organization's data, and every staff change, is written to a separate staff audit log. SOC 341 report details are not shown in the staff portal. There is no in-app “log in as this customer” impersonation feature.
  • Staff access requires an email address on our corporate domain, verified by our identity provider, plus an explicit membership record that an administrator can revoke independently of the account itself.

Audit logging

Every meaningful mutation in the application — report creation, editing, voiding, draft deletion, AI review run, approval, agency notification, role assignment, settings change, billing change — is written to an audit_logs table with the actor's identity, target resource, and a timestamp.

  • Filed reports are never deleted in the app: they can only be voided with a reason, and a voided report is kept and marked voided. SOC 341 reports cannot be deleted or voided in the app. Unsubmitted drafts can be deleted, and even those are soft-deleted (a deleted_at timestamp is set), so the audit trail remains complete.
  • Audit logs are retained for 7 years to support customer defense in regulatory and civil proceedings.
  • Org admins and facility admins can view their organization's audit log directly in the application.

Backups and disaster recovery

  • Database backups: daily snapshots and 7-day point-in-time recovery, managed by Supabase.
  • Recovery point objective (RPO): target ≤ 24 hours.
  • Recovery time objective (RTO): target ≤ 4 hours for the application; database restoration depends on Supabase's recovery process.
  • Backups are managed by Supabase (point-in-time recovery on our plan).

Subprocessors

We rely on the following subprocessors to operate ClearReport. The full list with purpose, data and location is published on our subprocessor list. Each is engaged under data-processing terms incorporated in its service agreement.

  • Clerk — Authentication and organization management
  • Supabase — Primary database (Postgres) and storage
  • Anthropic (Claude API) — AI wording review and the Ace advisor
  • Voyage AI — Vector embeddings of administrator-entered reporting standards and of your organization's own approved reports, after a pattern-based redaction pass (not HIPAA safe-harbor de-identification)
  • Resend — Transactional email (deadline reminders and review-loop notices: staff names, facility, form type, dates and a report link; no resident names or narratives)
  • Stripe — Billing, subscriptions and payment processing
  • AWS Amplify — Application hosting and CDN
  • Infisical — Secrets management for our infrastructure
  • Sentry — Application error monitoring

Regulatory posture

California (CCPA / CPRA)

We operate as a “service provider” under the California Consumer Privacy Act when processing personal information on behalf of customer facilities. We do not sell or share personal information for advertising purposes. Consumer rights requests are addressed in our Privacy Policy.

HIPAA

We do not currently offer a Business Associate Agreement (BAA). ClearReport does not sign BAAs today and does not hold itself out as a HIPAA Business Associate. California RCFEs are generally not HIPAA covered entities, so most customers do not need one. If your organization is a covered entity (for example, you also operate a skilled-nursing facility), email contact@useclearreport.com before purchasing and we will tell you honestly whether ClearReport fits your requirements.

California confidentiality law (CMIA and Title 22)

HIPAA is not the only law that applies. California's Confidentiality of Medical Information Act (Civil Code § 56 et seq.) may apply to a licensed RCFE and to the medical information in its records, and Title 22 (22 CCR § 87506 and related sections) requires residents' records to be kept confidential and retained. Reports of suspected abuse (SOC 341) are confidential under Welfare and Institutions Code § 15633.

ClearReport handles report content as confidential medical and resident information on your behalf: access is limited by role and facility, SOC 341 reports are never shown to other caregivers, and we disclose report content only to provide the service, as you direct, or as the law requires.

22 CCR § 87211

The California regulation that mandates LIC 624, LIC 624A, and SOC 341 reports is built into the application — the AI review and the Ace advisor reference the regulation text directly. The deadlines we compute and the agencies we suggest reflect § 87211 and the accompanying SOC 341 / LIC 624A guidance.

SOC 2

We are not currently SOC 2 certified. We will pursue a Type I attestation when we cross the customer threshold that warrants the investment (typically 25+ paying customers or one customer with a contractual requirement). Until then, we're happy to walk through any specific control with a customer's IT or compliance team.

Incident response

If we confirm unauthorized access to customer data, we will:

  • Notify affected customers in writing within 72 hours of confirmation.
  • Provide what we know about the scope, the data accessed, and the corrective steps we are taking.
  • Cooperate with customers' own regulatory notification obligations.
  • Conduct a post-incident review and publish a summary to customers within 30 days.

Suspect a vulnerability? Email contact@useclearreport.com. We commit to acknowledging receipt within two business days. We do not currently run a paid bug-bounty program.

What we’re working on next

  • SSO / SAML support for enterprise customers
  • Enforced multi-factor authentication for Skdaddle staff access
  • Customer-configurable session timeout and MFA requirements
  • SOC 2 Type I attestation
  • Customer-side data-export tooling that covers every report field, not just PDFs
  • Field-level encryption for the most sensitive fields (e.g. SOC 341 perpetrator information)

Contact

Security questions, vulnerability reports, or HIPAA questions: contact@useclearreport.com