Security plan
This document is ValidBound LLC’s information security plan for the hosted SpeechGradebook product. It describes how we protect institutional and student data, who is responsible for security, and how controls are operated.
This plan is a technical and operational overview for IT security, privacy, and procurement reviewers. It is not legal advice. Pair it with your institution’s counsel, FERPA officer, and any contract or DPA.
Last updated: July 2026
Product: SpeechGradebook (hosted SaaS)
Operator: ValidBound LLC
Contact: speechgradebook.com/contact (note Security in the subject)
1. Purpose and scope
Purpose
Define security objectives, roles, controls, and response practices for SpeechGradebook so institutions can evaluate the platform as a vendor of education-related technology.
Scope
| In scope | Out of scope |
|---|---|
| Hosted SpeechGradebook web app and API | ValidBound marketing site (validbound.com) content alone |
| Supabase Auth, database, and storage used by the product | Customer-managed devices and local browsers |
| SpeechGradebook Model inference path used for evaluations | Institution LMS configuration outside SpeechGradebook |
| Documentation site (no student education records) | Coaching services sold separately (see coaching agreement when applicable) |
2. Security objectives
- Confidentiality — Limit education records and media to authorized institution users and approved subprocessors.
- Integrity — Protect evaluation and roster data from unauthorized modification; retain audit trails for access and admin actions.
- Availability — Keep the hosted service usable for instructional terms; communicate material outages through support channels.
- Accountability — Authenticate users, enforce role and institution boundaries, and log access to student evaluation data.
- Privacy — Always-store instructional records under institutional authorization; require affirmative student consent for ValidBound R&D / model-improvement exports, consistent with FERPA-oriented design.
3. Roles and responsibilities
| Role | Responsibility |
|---|---|
| ValidBound operations | Platform security configuration, subprocessor oversight, incident response, vulnerability remediation |
| Institution admin | User approval/roles within the institution, roster accuracy, local policy for retention and instructor use |
| Instructor | Course-level data access, consent link distribution, responsible handling of exports and shared links |
| Student / practice user | Consent decisions and account credentials under institution and product terms |
| Subprocessors | Controls for infrastructure they operate (see Subprocessors and data locations) |
4. System architecture
flowchart TB
subgraph client [Browser]
UI[SpeechGradebook UI]
end
subgraph app [Application tier]
API[FastAPI on Render]
Proxy["/qwen-api/* model proxy"]
end
subgraph data [Data tier]
Auth[Supabase Auth]
PG[(PostgreSQL + RLS)]
Store[Supabase Storage]
end
subgraph ai [Evaluation tier]
Model[SpeechGradebook Model on Modal]
end
UI -->|HTTPS| API
API --> Auth
API --> PG
API --> Store
API --> Proxy
Proxy -->|TLS| Model
Student education records are stored in Supabase. The application enforces business rules; row-level security (RLS) enforces access at the database even if application logic regresses.
Detail: Security overview.
5. Control baseline
5.1 Identity and access
| Control | Implementation |
|---|---|
| Authentication | Supabase Auth (email/password) for portal login; LTI 1.3 (OIDC) for Canvas/LMS launch SSO; standalone SAML/CAS IdP SSO available for evaluation per contract |
| Transport | HTTPS / TLS 1.2+ for sign-in and API traffic |
| Sessions | Tokens issued by Supabase; validated on protected routes |
| MFA | Available for portal / non-LMS logins via Supabase Auth TOTP (optional today); LMS users authenticate through the institution’s Canvas/LTI launch and any MFA required there |
| Authorization | Role-gated UI plus PostgreSQL RLS keyed to user identity, role flags, and institution |
| Account approval | New users may require admin approval before full access |
5.2 Data protection
| Control | Implementation |
|---|---|
| Encryption in transit | TLS 1.2+ for browser ↔ app and service-to-service calls |
| Encryption at rest | AES-256 via Supabase PostgreSQL and Storage platform encryption |
| Data residency (U.S. institutions) | Institutional data (including UTK) resides in the United States and is not transferred outside the U.S. in the standard hosted configuration |
| Media access | Authenticated uploads; instructional media stored under user/institution path prefixes and currently served via public object URLs (private bucket + signed URLs planned) |
| Secrets | Production model and service credentials in environment variables on the app host — not in client-side production model routing |
| Consent gate | Affirmative student consent required for ValidBound LLM / R&D exports; instructional storage is not consent-gated |
| AI evaluation control | Contractual tenant kill-switch available: ValidBound will disable AI evaluation for an institution within a commercially reasonable time when required by agreement |
5.3 Logging and monitoring
Access to student evaluation data is recorded (who, what, when, action, IP/user agent where applicable). Admins can review compliance logging under Settings → Admin → Compliance.
See FERPA and student records.
5.4 Application security practices
| Practice | Detail |
|---|---|
| AI credential isolation | Browser calls /qwen-api/* on the app host; model secrets stay server-side |
| Evaluation jobs | Background workers call the model service with configured secrets |
| Error reports | Optional user-submitted context for support; not a substitute for security incident reporting |
| Change deployment | Application updates via hosted deploy pipeline on Render |
5.5 Subprocessors
Primary subprocessors for the hosted product:
- Supabase — Auth, database, object storage
- Render — Application and API hosting
- Modal — GPU inference for the SpeechGradebook Model
Full list and data categories: Subprocessors and data locations.
6. Data classification (product view)
| Class | Examples | Handling |
|---|---|---|
| Education records | Evaluations, scores, feedback, speech media tied to students | RLS, instructional hosting, R&D consent gate, audit logging |
| Account data | Name, email, institution, role | Auth-protected; institution admin management |
| Operational logs | App logs, audit events | Restricted to ValidBound ops and institution compliance views as designed |
| Public | Marketing and documentation content | No student education records on docs site |
7. Retention and deletion
Retention follows institution agreement and FERPA-oriented policy. Soft-deleted data may be recoverable within configured windows. See Data handling and retention and Recover deleted data.
8. Incident response
Suspected unauthorized access, data exposure, or vulnerabilities should be reported through the contact form with Security / incident noted.
ValidBound process: acknowledge → triage → contain → investigate → notify affected institutions → remediate → post-incident review.
Full detail: Incident response and contact.
9. Vulnerability management
- Review and prioritize reported vulnerabilities from institutions and good-faith researchers.
- Prefer private disclosure via the contact form (Security / vulnerability).
- Deploy remediations through the normal application release process.
- Rotate credentials and revoke sessions when compromise is suspected.
10. Business continuity (summary)
| Area | Approach |
|---|---|
| Hosting | Cloud application host (Render) and managed data platform (Supabase) |
| Backups | Supabase automated backups with point-in-time recovery (PITR) for PostgreSQL; object storage redundancy per Supabase; app redeployable from version control on Render |
| Target RPO | Typically ≤ 24 hours for database recovery objectives; often minutes when PITR is enabled for the project |
| Target RTO | Best-effort SaaS restoration measured in hours for application redeploy and provider recovery |
| Formal BCP/DRP docs | ValidBound-owned annually tested BCP/DRP documents are on the near-term roadmap; continuity currently relies on subprocessor capabilities above plus this plan |
| Communication | Material availability issues handled through support/contact channels |
| Institution continuity | Instructors should retain the LMS gradebook as system of record where required by policy; LTI 1.3 keeps grading workflow anchored in Canvas when used |
Institution-specific contractual RTO/RPO commitments may be added in a DPA or order form.
11. Compliance and questionnaires
| Artifact | Location |
|---|---|
| Privacy Policy | speechgradebook.com/privacy.html |
| Terms of Service | speechgradebook.com/terms.html |
| Accessibility statement | speechgradebook.com/accessibility.html |
| VPAT / ACR | Accessibility Conformance Report (VPAT) |
| HECVAT 4 response guide | HECVAT 4 response guide |
| Completed HECVAT workbook | HECVAT-4.1.6-SpeechGradebook-ValidBound.xlsx |
| Institutional addendum | U.S. residency / LTI / MFA |
| Security overview | Security overview |
For institution-specific DPAs or SOC-style attestations from subprocessors, contact ValidBound.
12. Review cycle
ValidBound reviews this security plan when architecture, subprocessors, or material controls change, and at least annually. The Last updated date at the top reflects the latest substantive revision.