Security for school-based OT work

Security controls for student records and school-based OT work.

The School OT puts access checks, encrypted fields, supervision decisions, and traceable record history inside the same workflow used to plan services and document care.

Request a security review Review the controls

PII-ready foundation. This is not a compliance claim or production approval. Authorized workspace members can use student names in clinical views; production release still depends on every applicable gate below.

Security controls

Security controls protect records after you sign in.

A school OT moves between service plans, schedules, session notes, supervision, and progress reporting. The School OT checks who is acting, which workspace they belong to, which students they are assigned, and whether the record can still be changed at each of those points.

Release gate: MFA enforcement before production use
4 roles: Owner, supervisor OTR, OTR, and COTA
2 checks: Workspace scope and student assignment
Name first: Encrypted names shown after authorization

Application security

How we protect accounts, student data, care records, and activity history.

No single control carries the whole burden. The application combines identity verification, least-privilege access, field encryption, tamper-evident history, record lifecycles, and restrictive browser behavior.

Account security

Use an individual account and optional authenticator.

Team members are invited into individual accounts instead of sharing credentials. Passwords are hashed with Argon2id, email is verified before access, and a time-based authenticator can be enabled from account settings.

Passwords require at least 12 characters, including upper- and lowercase letters and a number.
One-time recovery codes are stored as password hashes and audited when used.
Failed password and MFA attempts are limited; pending MFA challenges expire after five minutes.
Password or MFA changes invalidate existing signed-in sessions.
The supplied configuration expires inactive sessions after 30 minutes and all sessions after 12 hours.

Access control

Student assignments limit which records each person can open.

Every protected query stays inside the signed-in user’s workspace. Treating OTRs and COTAs must also have an active assignment to the student; workspace owners and supervisor OTRs retain oversight.

Owners manage the workspace and team.
Supervisor OTRs manage clinical records, schedules, reviews, and exports.
OTRs work with assigned students and can review sessions within their permitted scope.
COTAs see assigned work and submit documentation through the configured review policy.
Aggregate views, schedules, session lists, reports, imports, and exports use the same authorization boundary.

Data protection

Student identity and care details are encrypted before storage.

Selected sensitive values use AES-256-GCM field encryption. Each encrypted value receives a unique nonce and authenticated context so ciphertext cannot be moved to a different record or field and still decrypt successfully.

Student names, local IDs, school, grade, teacher, classroom, guardian, and eligibility fields.
Service details, goals, observations, consultations, session notes, participant responses, and review comments.
MFA secrets, import-validation snapshots, privacy-request details, and demo-request details.
Versioned encryption keys and a dry-run-first rotation utility are included in the build.
Production key custody, backup-key separation, and recovery evidence must be approved before identified data is enabled.

Accountability

Security-sensitive actions are recorded without student details.

Audit events record the actor, workspace, action, object, request, time, and limited operational metadata. Student names, note bodies, goal narratives, and review comments are not written into the audit metadata.

Sign-ins, failed authentication, password and MFA changes, and recovery-code use.
Student, service-plan, schedule, session, supervision, report, import, export, privacy, and settings actions.
Network addresses are HMAC-hashed instead of stored directly in audit rows.
Each event is chained to the prior event so deletion, reordering, or alteration can be detected.
Off-host immutable retention, alerting, and review ownership remain production release requirements.

Record integrity

Earlier plans, schedules, and reports cannot be overwritten.

Security also means being able to reconstruct which service plan, schedule, note, or report was in effect when a decision was made.

Service plans and schedules are versioned; schedule optimization stays in draft until an authorized user accepts it.
Accepted schedule versions can be restored without erasing prior versions.
COTA documentation can require OTR review before minutes become final.
Finalized progress reports cannot be edited in place.
Session corrections create a reasoned correction record instead of silently replacing history.

Browser and request protection

The app checks and limits every browser request.

Server-side protections are applied to public and signed-in pages. Staging and production refuse to start when secure cookies, MFA, HTTPS configuration, key material, or an approved database configuration are missing.

CSRF tokens on state-changing forms and session renewal after authentication.
A restrictive Content Security Policy, frame denial, content-type protection, and limited browser permissions.
Secure, HTTP-only session cookies outside local development and no-store cache behavior.
An allowed-host check and HTTPS-only application URL for staging and production.
Size and row limits, one-time validation snapshots, and spreadsheet-formula rejection for imports and exports.

Protected records

Security controls apply when you sign in, view records, edit care, and export data.

Work surface	Application boundary	Finished outcome
Student profile	Encrypted identity fields plus workspace, role, and assignment checks	The right clinician can identify the student without exposing the whole caseload.
Service plan	Versioned plan and requirements with activation audit event	The team can see which plan and service requirement applied on a service date.
Schedule	Draft, constraint check, authorized acceptance, and restorable version history	No generated week becomes the working schedule without a person accepting it.
Session note	Encrypted shared note and participant responses with configurable OTR review	Only eligible, finalized minutes reach the service ledger.
Progress report	Source dates preserved, encrypted narrative, immutable final version	The clinician can explain what evidence supported the finished report.
Exports and imports	Permission checks, rate limits, audit events, validation limits, and formula-safe files	Moving records is deliberate, attributable, and easier to review.

Production approval

Production use requires security review in addition to application controls.

The School OT will not enable identified student information because a feature list looks complete. The environment, vendors, operating procedures, recovery process, and customer approval must be reviewed as a system.

In this build

Controls tested in the application

Role and student-assignment authorization
MFA, recovery codes, session expiry, and sign-in limits
AES-256-GCM field encryption and rotation support
Redacted HMAC-chained audit events
Versioned plans, schedules, reviews, corrections, and reports
CSRF, browser headers, host checks, and file safeguards

Required before production use

Production evidence required before release

Appropriate vendor agreements and legal review
Risk analysis with accountable remediation owners
Unique production keys and documented recovery
Backup schedule plus a successful restore exercise
Regular activity review and incident response
Periodic technical and operational evaluation
Retention, deletion, legal-hold, access, and amendment procedures
Managing Member release approval

PII-ready foundation — not a compliance claim. The application supports encrypted names for authorized users, but production use remains blocked until the right-side evidence is complete for the chosen environment and customer.

Shared responsibility

The School OT secures the application. Your organization controls approved use.

School records are safest when the product controls and the district or practice’s operating rules reinforce one another.

The School OT

What the application handles

Enforce authentication, roles, workspace scope, and student assignments.
Encrypt selected sensitive fields and keep clinical text out of audit metadata.
Preserve version and review history for service decisions.
Keep identified-data production closed until the customer and environment gates are approved.
Provide auditable privacy-request and export workflows.

Workspace owner and customer

What your organization controls

Approve the legal basis, records in scope, retention rules, and authorized users.
Give each person an individual account and remove access when responsibilities change.
Keep devices, browsers, networks, and authenticator recovery codes secured.
Review assignments, supervision settings, exports, and unusual account activity.
Protect downloaded files and report suspected access through an approved channel.

Security questions

Security questions for district review.

Last technical review: August 10, 2026.

Does The School OT claim HIPAA compliance?

No. The current build is a PII-ready foundation, not a compliance claim. Identified student information stays disabled until the applicable legal posture, vendor agreements, production environment, risk analysis, restore evidence, incident response, security testing, and operating procedures have been reviewed and approved.

Can a new workspace enter student names today?

The application accepts student names and encrypts identity fields for authorized workspace users. That capability is not production approval: the applicable legal, vendor, security, operational, and customer release gates must still be completed.

Who can see a student record?

Owners and supervisor OTRs can oversee records inside their workspace. Treating OTRs and COTAs must have an active assignment to the student. The same boundary is applied to student pages, aggregate views, schedules, sessions, reviews, reports, imports, and exports.

What is encrypted?

Selected identity and care fields are encrypted with AES-256-GCM before database storage, including student identity, clinical notes, participant responses, goal details, consultations, review comments, correction reasons, progress narratives, MFA secrets, and short-lived import snapshots. Production transport encryption and key-management evidence remain release requirements.

Does the scheduler move students automatically?

No. Optimization produces a draft. An authorized user must review and accept it before it becomes the working week. Manual moves run the same server-side constraint checks, and prior accepted versions remain available for restoration.

Are backup, monitoring, and security-test claims included?

Not yet. The repository includes audit review and verification, retention, key rotation, and security tests, but The School OT does not present those as proof of production recovery or ongoing operations. The risk-based release evidence must be completed for the approved environment.

How should we evaluate The School OT for our organization?

Bring your data classification, applicable student-record requirements, user roles, retention rules, supervision policy, identity lifecycle, incident process, and vendor-review checklist. We will map those questions to the implemented controls and identify any remaining approval evidence.

District security review

Review your district’s security questions in a product walkthrough.

We will use synthetic data, show the relevant access and record flows, and separate what is implemented from what still needs production approval.

Request a security review Read the Privacy Notice