How we keep student records safe. The controls below run today, not on a roadmap. This page is meant to give procurement and IT what they need without an NDA.
Three fully isolated environments: development on a local SQLite file, staging on a separate Turso database with throwaway credentials, and production on a dedicated Turso database with credentials that never leave Vercel. Production secrets are never pulled to a developer machine.
All traffic is served over TLS. Data at rest in Turso is encrypted using libSQL's underlying SQLite encryption with keys managed by Turso. Authentication tokens are issued as JWTs in httpOnly secure cookies so they cannot be read by client-side JavaScript.
Every API route requires a valid session and checks the caller's role before reading or mutating data. Roles are scoped to a single organization for program directors and instructors. Students see only their own records. Super-admin access is restricted to Wealth in Motion PT LLC personnel and is logged.
Passwords are hashed with bcrypt at 10 salt rounds. Plaintext passwords are never logged, stored, or transmitted to subprocessors. SSO logins via WorkOS or Google bypass passwords entirely.
Sensitive actions write to an append-only audit log with the actor, action, target, and timestamp. Universities can request an export of audit entries scoped to their organization for compliance review.
Login attempts are rate-limited per IP. AI-feature calls are rate-limited per user. Both run on Upstash Redis with an in-memory fallback so a Redis outage does not disable protection.
Production databases are backed up by Turso on their managed schedule. Backups are retained on rolling 90-day windows and aged out automatically. Backup data inherits the same encryption posture as the live database.
Every subprocessor is listed publicly with what they do and where they sit. We notify program directors at least 30 days before adding a new subprocessor that touches student records. See the full list and subscribe to change notifications on the Subprocessors page.
We commit to notifying your institution's primary contact within 72 hours of confirming any breach involving student data. Notifications include the nature of the incident, categories of data affected, estimated number of records, containment steps, and recommended actions. See the FERPA page for the full breach SLA.
| Framework | Status | Notes |
|---|---|---|
| FERPA | Active | Operate as school official under 34 CFR § 99.31(a)(1)(i)(B) |
| California CCPA / CPRA | Active | California-resident rights honored on request |
| Illinois SOPPA | Active | Public subprocessor list maintained per § 110/27(b) |
| New York Ed Law 2-d | On request | State-specific exhibit available for NY institutions |
| HECVAT Full | In progress | Pre-filled response in development; available on request |
| SOC 2 Type II | Planned | Targeted for completion as enterprise pipeline justifies |
| Cyber liability insurance | Available | Coverage bound on contract execution |
If you have discovered a security issue in our platform, please report it to security@thehomehealthpro.com. We will acknowledge receipt within two business days and provide a remediation timeline within ten business days.
We ask that you do not test against live student data, do not attempt to access accounts that are not your own, and give us a reasonable window to remediate before public disclosure. We will not pursue legal action against good-faith researchers who follow these guidelines.
Last updated: May 6, 2026