Location
Set in writing.
If school data is lost, so are lessons, fees and attendance records. So the hosting location is set in writing, backups run regularly and restores are tested separately.
The application is served over an encrypted connection. Hosting location and provider are clarified with you in writing; data is not used outside your instructions.
Test and live environments are kept apart.
Backup frequency and retention are set with you. A backup is not only taken; whether it can be restored is tested periodically.
Update and maintenance scope is written into the contract.
Set in writing.
Regular and automatic.
Restores are tested.
Updates in writing.
By e-mail we discuss your processes, roles, existing systems and how data is moved, and set the scope in writing.
We build the solution around your workflow and connect it to e-mail, calendar, documents and payment.
We test every flow with realistic cases, train your team and go live only when it is right.
For systems with child data, the hosting location and where backups are kept matter. This information is provided in writing before contract; cantonal requirements are taken into account separately.
The retention period is set with you in writing.
This may be possible; scope and maintenance responsibility are clarified separately.
Child data in school software: least privilege with the FADP in mind, access logs, deletion periods and a written processing agreement.
Learn moreRoles and audit log in school software: separate permissions for management, office, teachers, parents and pupils; who changed what and when.
Learn moreStudent management software for schools and courses: records, classes, parents and documents in one place. Four languages, built for Switzerland.
Learn more