Security & Compliance

• 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

Encryption

• In transit: TLS 1.2 or higher for every connection between your browser, our application, and our subprocessors. HSTS enforced at the edge.
• At rest: AES-256 disk encryption on our Supabase Postgres instance and on cloud-provider storage.
• 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.

User authentication

• Sign-in is handled by Clerk. We do not store passwords ourselves.
• Multi-factor authentication (TOTP, SMS, or passkey) is available to every user and we encourage organization administrators to require it.
• Session timeout follows Clerk's defaults for the application.

Role-based access

• Org admin: full access to all facilities, residents, reports, billing, and team management within their organization.
• Facility admin: full access to reports, residents, team, and compliance within the facilities they administer.
• Worker: can create and view their own reports for their assigned facility, plus reports approved for facility visibility.
• 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.
• Staff view customer data only through the audited staff portal; there is no in-app “log in as this customer” impersonation feature. Every staff access is recorded in a separate staff audit log.
• 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.

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

• Reports are soft-deleted (a deleted_at timestamp is set) rather than purged, 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.

• Database backups: daily snapshots and 7-day point-in-time recovery, managed by Supabase.
• Recovery point objective (RPO): ≤ 24 hours.
• Recovery time objective (RTO): ≤ 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); we verify restore procedures as part of release testing.

We rely on the following subprocessors to operate ClearReport. The full list with purpose and location is published in our Privacy Policy. All have signed data-processing terms with us.

• Clerk — identity, authentication, organization management
• Supabase — primary database and storage
• Anthropic — Claude API for AI report review and the Ace advisor. Anthropic does not train on our customers' data.
• Voyage AI — vector embeddings of administrator-entered reporting standards / policy text (incident narratives are not sent pending a BAA)
• Resend — transactional email for compliance-deadline digests (deadline metadata only, no report narratives)
• Stripe — billing, subscriptions, payment processing. PCI DSS Level 1 certified.
• AWS Amplify — application hosting and CDN
• Infisical — secrets management for our infrastructure
• Sentry — application error monitoring

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

RCFEs are generally not HIPAA “covered entities,” but we recognize that some of our customers operate skilled-nursing or adjacent businesses that are. We will sign a Business Associate Agreement with any covered entity customer on request. Email contact@skdaddle.com.

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.

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@skdaddle.com. We commit to acknowledging receipt within two business days. We do not currently run a paid bug-bounty program.

• 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)

Security questions, vulnerability reports, or BAA requests: contact@skdaddle.com