Your school controls who can sign in
School administrators create and manage user accounts, assign roles and remove access when a person's responsibilities change. Permissions are tied to the work each role needs to perform, so access can be limited instead of giving every administrator the same view.
Multi-factor authentication is required for administrators. Session controls reduce the risk of an unattended or shared device remaining signed in, and account activity provides a record for review.
Your school's records are isolated
Each school uses its own subdomain and its data is separated at the database level. Requests are scoped to the authenticated school so one school's users cannot browse another school's records.
Isolation is supported by application checks, role permissions and controlled database connections. These layers work together rather than relying on a school name or a filter shown in the interface.
Support access requires your permission
SOLASTIAN staff do not open school records as part of routine service operation. When a school asks for help that requires access, a school administrator must authorise it. Access is limited to the support need and to the duration of the session.
The authorisation and support activity should be recorded so the school can see why access was needed. Legal obligations or an immediate security incident may require a different response, but access remains limited to what is necessary and is handled under the agreement and applicable law.
Data is protected in transit and in storage
Connections to SOLASTIAN use transport encryption. Sensitive credentials are encrypted at rest, passwords are stored as secure one-way fingerprints and database connections are encrypted.
The service is hosted on Netcup infrastructure in Nuremberg, Germany. School data remains within the European Economic Area under the current hosting arrangement.
Backups and recovery are part of security
Confidentiality is only one part of data security. Schools also need records to remain available and accurate. The production database is backed up automatically each day, with backups kept on infrastructure in Nuremberg under a defined retention schedule.
Backup access is restricted. Recovery procedures and service monitoring support a timely response to technical failure without making unnecessary copies of school data.
The school remains in control of its data
The school decides what information is entered, why it is processed and which authorised users can work with it. The school can correct records, manage access and request exports or deletion according to the agreement and applicable retention duties.
SOLASTIAN acts as a processor when it handles personal data on the school's instructions. We do not sell school data or use it for unrelated purposes. The Data Processing Agreement records the responsibilities of both parties.
- The school manages users, roles and permissions.
- Support access is authorised, limited and recorded.
- School data is isolated from other customers.
- Exports, correction and deletion are supported.
- Security measures are reviewed as the service develops.
Security is an ongoing process
SOLASTIAN uses monitoring, release checks and security testing to find problems early. Updates are applied through a controlled deployment process, and the public status page communicates service availability.
Article 32 of the GDPR requires measures appropriate to risk, including confidentiality, integrity, availability, recovery and regular evaluation. German BSI IT-Grundschutz provides additional practical guidance for access control, operations and tested backups. These principles inform how the service is operated and improved.