What happens to student data in SLPDesk

Every third party that can process data on our behalf is listed below. If a vendor is not on this list, it does not receive your data. Several entries are optional and only apply if your district enables that feature.

Subprocessor-change notice: changes to this list are recorded in the dated change log at the bottom of this page, and this page is versioned. Districts with a signed agreement that requires advance notice of subprocessor changes should say so in that agreement; email security@slpdesk.com to be added to the notification list.

This is usually the first question, so here is the precise answer. AI drafting is opt-in per action — nothing is sent to Anthropic unless a therapist presses a draft button.

The prompt sent to Anthropic is assembled from the fields the therapist's session has open, rendered through fixed templates in our codebase. Depending on the drafting action those templates accept, and therefore transmit:

• a student name field — the app sends the student's display name as shown in the therapist's UI, or the literal placeholder “the student” when no name is supplied;
• grade level;
• the clinical content the therapist is drafting from: goal text, session observations, data-point summaries, service area;
• the note format requested (SOAP, DAP, BIRP) and the report type.

Nothing else from the student record is included. Date of birth, address, guardian contact details, identifiers, IEP documents, uploaded files and audio recordings are not sent to Anthropic by any drafting path.

If your district's policy is that no student name may leave the system: tell us. The templates accept a placeholder and the name field is supplied by the client, so a name-free mode is a configuration change, not a redesign. It is not currently an enforced org-level setting, and we will not claim it is.

The application server, the PostgreSQL database and the Redis cache all run on a single virtual private server hosted by OVH Hosting, Inc. The IP allocation for that server is registered in ARIN to OVH Hosting, Inc. with country CA (Canada).

Stated plainly because it is material to procurement: we do not currently represent that primary application data is stored in the United States. If your district requires US-only residency as a contractual term, raise it before signing — that is a hosting change we can scope, not something this page will paper over. The registry country above is what we can evidence; we are not asserting a specific datacenter facility on this page.

Optional Amazon S3 storage, when a district enables it, defaults to the us-east-1 region in the United States. That means uploaded documents and the primary database can sit in different jurisdictions. S3 is off by default.

Anthropic and Resend process data in the United States. Browser push and SSO providers process data per their own regions.

In transit

All traffic to slpdesk.com is served over HTTPS. TLS is terminated at nginx using certificates issued by Let's Encrypt. Our nginx configuration does not pin a minimum version above the server default, which means TLS 1.2 and TLS 1.3 are both accepted. We say “TLS 1.2 and 1.3” rather than “TLS 1.3” so that what you find when you run an external SSL scan matches what this page says.

At rest

Tenant isolation

Every record carrying user data has an organization_id foreign key, and service-layer queries filter on the organization taken from the authenticated user's token. There is no cross-organization read path in the application. Shared library content (system activities, goal templates) is the deliberate exception: it has a null organization and contains no student data.

Authentication

JWT access tokens with a 15-minute lifetime, plus refresh tokens with a 7-day lifetime that are stored server-side and can be revoked individually or in bulk.

Passwords

Hashed with bcrypt via passlib. Plaintext passwords are never stored or logged.

Roles

Six roles — SLP, SLPA, district admin, school admin, parent, student — enforced at the route level by a role dependency, not only in the UI. A request from the wrong role is rejected by the API regardless of what the client renders.

Rate limiting

Applied at the API edge. Account registration is limited to 10 attempts per hour per source, and login and token refresh to 10 per minute, with a 200-per-minute default across the API.

Single sign-on

Google and Microsoft SSO are available and optional. Clever and ClassLink are not available — those endpoints return 501.

Logging

Application logs run at INFO level in production and do not carry student PHI.

Access to and modification of student data writes an audit event recording: the organization, the acting user, the action, the entity type and id, the before and after state of the record, the source IP address, the user agent, a timestamp, and a SHA-256 checksum. Administrators can read their organization's audit trail, filter it by student, and call a verification endpoint that recomputes the checksum for a given event and reports whether it still matches.

Two honest limits, because a reviewer will ask:

• Insert-only is an application-level convention, not a database grant. Our code never updates or deletes audit rows, but the database role the application uses is not restricted from doing so by a REVOKE or a trigger. An attacker holding the application's database credential could therefore alter the log. We describe this as a tamper-evident log, not a tamper-proof one.
• The checksum is per-row, not chained. It is a SHA-256 over the event's timestamp, actor, action, entity type and entity id. It detects modification of a retained row. It does not detect deletion of a row, and it does not cryptographically link a row to its predecessor, so it will not by itself prove the log is complete.

Default retention

2,555 days (7 years) of clinical records, configurable per organization to match your state's records-retention schedule.

Automated purge

A scheduled job runs monthly (1st of the month, 04:00 UTC) and permanently deletes audit events, sessions and progress data points past the organization's retention cutoff. The purge itself writes an audit event recording what was removed.

Inactive-student archiving

A separate monthly job (1st, 03:00 UTC) soft-archives students with no sessions for a configurable period (365 days by default). This is opt-in per organization and off unless enabled. Archiving is a status change, not a deletion.

Right to erasure (users)

A “forget user” operation anonymizes a user's personal fields — email, name, avatar, preferences — revokes every refresh token they hold, and deactivates the account. It deliberately preserves the audit trail, because deleting the record of who accessed a student's data would defeat the audit obligation it exists to serve. It returns a summary of exactly which fields were anonymized.

Soft deletes

Clinical records are deactivated rather than hard-deleted during normal operation, so that an accidental deletion is recoverable within the retention window.

Termination

On contract termination we will provide an export of your organization's data and delete it on request. The export format, the deletion deadline and the deletion confirmation are contract terms, not product features — they are negotiated in your agreement rather than asserted here. Email security@slpdesk.com to have them written into your contract before you sign.

If we confirm a security incident affecting your organization's data, we commit to notifying your designated district contact within 72 hours of confirmation, with what we know at that point: what happened, which data categories were involved, what we have done to contain it, and what we are still investigating. We will follow up as the investigation develops rather than waiting for a complete picture.

Where your state's student-privacy law sets a shorter notification deadline than 72 hours, that deadline governs and we will meet it.

What we do not claim: we do not operate a 24/7 staffed security operations centre, and we do not claim continuous third-party threat monitoring. This is a small engineering team. The commitment above is a contractual notification commitment, and it is one we can keep; the ones we cannot keep are not on this page.

• Student data privacy agreements. We review and sign district and state DPAs on request, including SDPC/NDPA-form agreements and state-specific templates (for example New York Ed Law 2-d addenda or California SOPIPA terms). Send your district's template to security@slpdesk.com. We are not currently listed on a state SDPC alliance registry.
• HIPAA BAAs. School-based speech services delivered under IDEA are generally governed by FERPA rather than HIPAA. We do not offer a BAA by default, because a BAA carries flow-down obligations onto every subprocessor that touches PHI and we will not sign one we cannot fully honour. If your district genuinely operates under HIPAA for these services, contact us and we will scope it honestly rather than signing to close a deal.
• FERPA school official. We operate as a school official with a legitimate educational interest under the district's direct control, and we use student data only to provide the service to your district — never to build advertising profiles, and never to train third-party AI models. Our AI subprocessor is used through its API for inference on your prompts only.

SLPDesk has not completed a SOC 2 Type I or Type II audit. We do not hold ISO 27001, HITRUST or StateRAMP authorization, and we have not undergone a third-party penetration test. We are stating this here so that nobody has to discover it three weeks into a procurement cycle. Nowhere on this site do we soften that with hedging language implying a certification is in progress or nearly held — those phrasings mean nothing to a reviewer, and we do not use them.

What we offer instead is this page: specific, checkable statements about what the system actually does, including the parts that are weaker than we would like. If a SOC 2 report is a hard requirement for your district, we are not the right vendor today and we would rather tell you now.

Security reports, procurement questionnaires, DPA requests and subprocessor-notice signups all go to security@slpdesk.com, which is monitored.

Vulnerability disclosure. If you believe you have found a vulnerability, email that address with enough detail to reproduce it. We will acknowledge receipt within 3 business days and keep you updated until it is resolved. We will not pursue legal action against a researcher who reports a vulnerability in good faith, stops at the point of proof, does not access or exfiltrate data belonging to other users, and gives us a reasonable window to remediate before publishing. We do not currently run a paid bug bounty.

Also relevant: our privacy policy and terms of service. Both are undergoing legal review; where they and this page differ on a factual matter about how the system works, this page is the more current statement.

Districts diff this page at renewal. Every material change is recorded here.

v1.0 — August 7, 2026

Initial publication. Subprocessor list established. Corrected the at-rest encryption and TLS-version claims carried on the compliance feature page. Disclosed that primary hosting is registered in Canada. Documented that audit-log immutability is enforced in application code rather than by database grant, and that the audit checksum is per-row rather than chained. Stated that no SOC 2, ISO 27001, HITRUST or StateRAMP certification is held.