RLS
tenant isolation foundation
Tenant-owned data is designed to stay behind forced row-level security and tenant-scoped access helpers.
Security and trust
Trust center with proof status, not certification theater.
Otto's public trust story separates implemented foundations, local proofs, planned controls, and not-published documents so schools can see what exists and what still needs external review.
MFA
staff step-up posture
Staff and instructor MFA, step-up actions, and session boundaries are P0 security requirements before production use.
Audit
sensitive action trail
Sensitive record views, exports, changes, permission changes, support access, and rule-pack activations are designed for immutable audit trails.
Staged
external assurance path
External security review, penetration testing, SOC 2, HECVAT, VPAT, and status page work are shown as staged milestones, not completed claims.
Controls
The trust model buyers should be able to inspect.
The controls below are intentionally labeled by readiness level. Buyer-facing copy stays tied to local proof routes and production activation gates.
Tenant isolation and RLS
School records are designed to be separated by tenant at the database layer, not only by UI routing.
The local database foundation includes tenant-scoped schema work, forced RLS proof coverage, and RLS drift checks.
Review tenant isolation proofStaff MFA and step-up
High-risk staff actions need stronger identity checks before production access is allowed.
Role-aware staff-required and student-optional MFA policy helpers are proved locally; provider enrollment and challenge flows remain later.
Review auth readinessAppend-only audit logging
Sensitive views, exports, changes, rule-pack activations, support access, and permission changes need reviewable evidence.
Audit entry foundations are append-only for the local app role. Production audit viewers and setting write paths are later.
Preview audit logSecure SDLC checks
The build path includes code, dependency, license, secret, and RLS checks before production gates can be cleared.
Local type, lint, test, build, secret scan, license scan, dependency audit, and RLS audit commands are defined.
Review security checklistEncryption and secrets
Production secrets, TLS, encryption at rest, field-level protection for restricted data, and rotation remain provider-gated setup work.
Secrets stay out of source, auth session/device identifiers are planned as hashed metadata, and raw provider tokens are not stored.
Review production gatesPayment and file boundaries
Payment pages are planned around Stripe-hosted fields, signed URLs, short-lived links, validation, and later malware scanning.
Future Stripe-hosted payment fields should keep card numbers out of Otto systems. File security and storage policies remain later.
Review file security proofAI safety and data minimization
Student data must not be exposed to models casually, and AI cannot silently change grades, refunds, statuses, or compliance submissions.
AI output is treated as untrusted, tools are permission-scoped, restricted data is blocked, and consequential actions require human approval.
Review AI transparencyPrivacy, export, and portability
Otto is designed to serve the school under its control, not monetize student records or trap records in the platform.
The public posture is no sale of data, no secondary use of student data, FERPA-aligned school control, and school-owned export paths.
Preview FERPA proofIncident response
Incident roles, severity levels, runbooks, notification support, and status communication need production operations before launch.
Incident-response copy is a posture statement only. Production runbooks, paging, status page, and evidence packets are not published.
Review incident runbook proofAssurance timeline
External security review
PlannedBefore the first pilot
Authentication, tenancy, RLS, and production data gates need outside review before any private pilot school goes live.
Formal penetration test
Not publishedBefore the first paying school
The formal penetration test is not complete and no public report is published.
SOC 2 Type I
Not publishedAbout 6 months after the first paying school
SOC 2 is a roadmap milestone, not a current certification.
SOC 2 Type II
Not publishedAbout 12 months after Type I
Type II depends on operating evidence after Type I.
HECVAT packet
Not publishedNot published
HECVAT Full, including AI questions, is planned for sales readiness but is not published.
VPAT / Accessibility Conformance Report
Not publishedNot published
The accessibility statement is public; a VPAT/ACR remains a later milestone.
Public status page
PlannedPlanned
Status-page operations are not connected to production monitoring or incident workflows.
Counsel-approved legal/security packet
PlannedExternal later work
DPA, FERPA addendum, legal terms, and security packet need counsel and production review.
Privacy commitments
Public privacy copy is a product posture until production contracts, DPA, FERPA addendum, retention policies, and export workflows are reviewed.
- No sale of school, staff, or student data.
- No secondary use of student data.
- No model training on school data without written consent.
- Role and tenant boundaries apply before records are shown.
- School data export and portability are P0 design commitments, with production export workflows later.
Privacy governance
FERPA, retention, export, and data-use boundaries stay explicit.
Schools need to know not only that data is protected, but also who controls it, how disclosures are recorded, and how records leave Otto if a school exits.
FERPA posture
Otto is designed to operate as a school official under school control, with contract language and FERPA addendum work required before production.
Disclosure and consent workflows
Disclosure ledger, FERPA consent manager, directory opt-out, redisclosure notices, and records-access workflows are product requirements, not public launch claims.
Data classification
Restricted data such as SSNs, accommodations, health documents, and bank details needs tighter roles, field-level protection, and access logging.
Retention and export
Retention schedules, legal holds, complete school export, and closed-school archive support remain P0 design commitments before lock-in claims.
AI
Data boundaries before model or provider claims
Public trust center
AI providers, zero-data-retention terms, usage ledgers, retrieval, and Private AI mode remain gated. This page states the data posture before any live AI routing claim is made.
Payment data
Future Stripe-hosted payment fields keep card numbers out of Otto systems and logs; PCI SAQ-A remains an annual production attestation target.
File and document links
Signing links, document links, and file URLs are designed to be short-lived, signed, and single-purpose.
AI restricted data block
SSNs, government IDs, bank/card numbers, and disability documentation must not be sent to AI models.
AI human approval
AI can draft, explain, prioritize, and alert, but grades, refunds, status changes, aid-affecting determinations, and compliance submissions require authorized human approval.