School Governance Overview
The technical and governance view of TypiTrain for schools.
This page states the institutional setup of TypiTrain: data categories, hosting, retention, security controls, and the role of optional AI-related features in school rollouts.
At a glance
A quick orientation for governance, procurement, and school IT teams before a deeper review.
The privacy policy, DPA, and contract remain authoritative; this page summarizes school-relevant points for initial review.
- Lean student identity model
- Standard class onboarding can run with username and password only. Student email is not required for the usual class-code flow.
- Cloud-first, school-ready setup
- Core account and progress data for the managed service are stored in Frankfurt, Germany. A desktop app also exists for offline-oriented environments.
- Clear retention principles
- Personal data is kept while accounts remain active, essential logs are kept for limited operational periods, and account deletion removes personal data.
- AI is not required for the core rollout
- The classroom product works without AI. AI-related features are optional modules with their own institutional scope.
Operator & Scope
Who is involved, and whose data is in scope?
The operator contact and affected-person categories are listed explicitly for privacy, IT, and procurement review.
Operator and governance contact
TypiTrain is operated by Tobias Wetzel. Privacy, governance, and review coordination requests can be sent to [email protected].
- TypiTrain is operated by Tobias Wetzel.
- Review and privacy contact: [email protected].
- Governance coordination can be handled directly by email.
Categories of affected persons
The institutional scope includes the affected-person categories listed below.
- Students
- Teachers
- School or organization administrators
- Optional SSO-related identity contacts where integrated
Data Categories
Personal data categories
Institutional accounts are designed to minimize student identifiers while still supporting class management and progress tracking.
- Student accounts
Student accounts use the minimum account data needed for class membership and access.
- Username
- Authentication credential
- Class membership and approval status
- Role within the school context
- Teachers and administrators
Staff accounts carry the operational data needed for management, communication, and permissions.
- Name and email where applicable
- Organization and class assignments
- Role and permissions
- Optional SSO identity mapping
- Learning and progress data
The application stores the data required to show progress and support instruction.
- Completed exercises and assignments
- Typing speed, accuracy, and progress history
- Per-key performance patterns
- Practice duration and completion status
- Technical and operational data
A small operational data layer is required to keep the service secure and reliable.
- Authentication and access timestamps
- Browser and device context relevant for operation
- Essential error and performance diagnostics
- Security-related system events
Why is the data processed?
The institutional service uses data for a narrow operational scope tied to teaching, administration, and service reliability.
- Provide authentication and role-based access
- Manage schools, classes, and memberships
- Display progress, assignments, and learning history
- Support school administration and password resets
- Maintain service security, reliability, and debugging
Hosting & Processors
How is the service deployed?
The default institutional setup is a managed cloud deployment. The sections below separate core infrastructure, institutional account behavior, optional tools, and operational tooling.
Primary deployment model
The standard school rollout uses the managed cloud service.
- Managed cloud application for school browsers and devices
- Core account and progress data stored in Frankfurt, Germany
- Browser-based access for school devices
- Desktop app available for offline-oriented environments
Operational processor posture
For institutional reviews, the important distinction is between core infrastructure, essential error monitoring, and optional tracking tools.
- Cloudflare supports DNS, CDN/edge delivery, and web application protection
- Resend handles transactional email delivery through the configured Supabase SMTP setup
- Institutional accounts do not use analytics or session-recording tools
- Essential error monitoring remains active to maintain reliability
- Payment processing is only relevant for billing flows
- A processor and subprocessors overview is available for school review
Processors & International Transfers
Processors and international transfers
Core account and progress data are stored in Frankfurt, Germany. Processor-level transfer scenarios and safeguards are documented separately in the DPA and contract review.
Typical processor categories
For school deployments, the relevant external services are those supporting authentication, database operations, delivery, security, transactional email, error monitoring, or billing.
- Supabase for authentication and database services
- Cloudflare for DNS, CDN/edge delivery, and web application protection
- Resend for transactional emails such as account confirmations, invitations, and password resets
- Sentry for essential error monitoring and operational diagnostics
- Stripe only where paid billing flows are relevant
- School identity provider where OpenID Connect or VIDIS is enabled
International transfer position
Core storage and processor-level transfer scenarios are separated: EU storage for core account and progress data, separate documentation for processors and safeguards.
- Core account and progress data are stored in Frankfurt, Germany
- Institutional accounts do not use optional analytics or session-recording processors
- Potential international transfer scenarios must still be assessed per processor
- Where relevant, safeguards and processor details are documented in the DPA and contract review
Retention & Deletion
What is the retention approach?
Personal data remains tied to active school use and operational necessity; account deletion removes personal data associated with that account.
- Account data
- Retained while the institutional or personal account remains active.
- Progress and assignment data
- Retained while required for the active learning context and reporting within the account.
- Operational logs
- Essential error-monitoring data is kept for limited debugging periods rather than indefinitely.
- Deletion handling
- When an account is deleted, personal data tied to that account is removed, while non-identifying aggregated data may remain for statistics.
Retention schedule
The retention schedule lists the main data categories, retention period, and deletion handling in reviewable terms.
- Account data: retained while the account remains active
- Progress and assignment data: retained while needed for the active learning context and account reporting
- Essential error-monitoring data: retained for up to 90 days for debugging purposes
- Account deletion: removes personal data tied to that account
- Aggregated or non-identifying statistics may remain where they no longer identify a person
Security Controls
Which technical controls are already part of the service?
The current product architecture already includes core controls expected in a school SaaS environment.
- TLS-encrypted transport
- Secure password hashing
- Role-based access separation for students, teachers, and admins
- Row-level security in the database layer
- OpenID Connect support for school SSO scenarios
- Operational monitoring for availability and debugging
AI Positioning
AI-related features in institutional reviews
The core school product does not depend on AI. AI-related features are optional modules with a separate institutional scope from the main rollout.
Recommended baseline for institutional rollout
The baseline rollout uses the core classroom product with AI outside the initial review scope unless separately agreed.
- The core school workflow works without AI
- Initial review can focus on hosting, identity, student data, and access control
- AI-related features are treated as optional modules with separate review scope
- This keeps procurement and privacy review focused on the required classroom service
Optional AI review scope
If an institutional AI feature is used, the provider, model, data categories, purpose, user groups, and deployment scope are recorded for review.
- The core school workflow remains available without AI
- Institutional accounts can use a reviewed provider or keep AI features out of scope
- Activation records the feature, transmitted data, provider, model, and purpose
- The enabled user groups are defined before rollout
Review Package
Available review materials
For procurement, IT governance, or data-protection review, TypiTrain can provide focused review materials and DPA coordination.
- Short privacy and governance summary
- Pricing overview and service overview for institutional onboarding
- Processor and subprocessors overview
- Retention and deletion summary
- Security and access-control summary
- SSO and rollout coordination notes
- Contract and data processing agreement coordination for school reviews