Trust center - privacy, security, and compliance

What belongs in a trust center

Schools do not buy software on feature slides alone. They need subprocessors listed, data residency notes, incident contacts, and a path to signed agreements. The trust center collects those artifacts so your legal team is not chasing PDFs over email during a July rollout.

Privacy and agreements

Privacy policy explains categories of data - roster, fees, attendance, grades - and why each exists operationally. Data Processing Addenda align with common K-12 procurement language. Subprocessor registers update when infrastructure vendors change; schools on enterprise plans receive change notifications.

• Published privacy policy and cookie disclosure
• DPA templates and signature workflow
• Subprocessor list with service purpose
• Data subject request contact for schools

Security and uptime cross-links

Trust documentation points to the security summary - encryption, access control, logging - and the public status page for uptime history. AI and MCP pages explain optional features separately so buyers know what is core platform vs pilot tooling.

For international schools

Groups operating under GDPR, FERPA-oriented practices, or regional education privacy rules use the compliance page alongside trust docs. We document operational controls - export, deletion workflows, role scoping - not vague “certified compliant” badges.

How to start a security review

Send your standard questionnaire to security@schoolyi.com or your account contact. Include integration plans (SSO, API, MCP) so reviewers scope subprocessors correctly. Pilot schools often complete review in parallel with roster import, not after go-live.

Incident communication

Customer-impacting incidents publish on the status page with follow-up summaries when warranted. Contracted notification windows are honored for enterprise agreements. Schools should keep an IT contact current so alerts reach the right desk.