Skip to content
KinderConnect
  • Features
  • Security
  • Pricing
  • FAQ
English
  • Türkçe
  • English
  • Русский
  • العربية
Request a demo
Request a demo
Home/KVKK for schools

How your school’s data is processed in KinderConnect

KVKK for schools

Last updated: 6 October 2026

This page is for schools that use or are considering KinderConnect. It explains how we process the school’s student, parent and staff data, which sub-processors we work with and which measures we take. The binding terms are in the data processing agreement signed with the school.

This English text is provided for information. If it differs from the Turkish text, the Turkish text prevails.

On this page

  1. Roles
  2. Where data is processed
  3. Sub-processors
  4. Technical and organisational measures
  5. End-to-end encrypted messages and the school’s privacy notice
  6. Retention and destruction
  7. Returning data at the end of the contract
  8. Breach notification
  9. Data subject requests
  10. Agreement and documents

Roles

For your school’s student, parent and staff data, the school is the data controller. KinderConnect’s intended role is data processor: it processes the data on the school’s instructions and only to provide the service. The roles will be confirmed through legal review and written into the agreement.

As data controller, the school is responsible for informing parents and staff, obtaining explicit consent where required (for example for sharing photos) and assessing its VERBİS obligation. KinderConnect provides the tools to keep consent and notice records in the app.

Where data is processed

The app runs on Cloudflare infrastructure. Persistent data (database, files and real-time delivery components) is kept in Cloudflare’s European Union jurisdiction. We have no servers in Turkey, so all data is transferred abroad within the meaning of Article 9 of KVKK.

The legal basis for the transfer is the standard contract published by the Board. No real school data is processed until the standard contract has been signed and notified to the Board; until then, demos and development use sample data only.

Sub-processors

Sub-processorServiceLocationWhat it sees
Cloudflare, Inc.Running the app, database, file storage, real-time delivery, queues, domain and networkPersistent data: European Union jurisdiction. Network traffic: globalStores encrypted fields and files only in encrypted form
Verbytes (verbAuth)Authentication: sign-in, password, two-step verification and account e-mailsCloudflare, European UnionName, e-mail address and sign-in details
Web push services: Google, Apple, Mozilla, MicrosoftDelivering notifications to devicesThe provider’s global infrastructureOnly the encrypted notification payload and the device address. Notification texts contain no personal data

We notify schools in advance of changes to the sub-processor list. No SMS service is used.

Technical and organisational measures

  • School isolation: each school’s data is kept separate; the school is read only from the verified session. Isolation is enforced in two layers, in the application and in the database relations, and every release passes cross-school access tests.
  • Field encryption: ID numbers, phone numbers, addresses and health information are encrypted with AES-256-GCM using a key specific to the school. The master key that protects these keys is held in a separate secret store, not in the database.
  • File encryption: every photo and document is stored encrypted with its own key. Storage is not public and no signed links are used; files open only through the app after a permission check. Location data is removed from images before upload.
  • End-to-end encrypted messaging: teacher–parent messages are encrypted on the device and can only be opened by the people in the conversation.
  • Permissions and scope: a teacher sees only their own class, a branch admin only their own branch; parent permissions are set per child.
  • Audit log: opening health information requires a reason and is recorded. Permission changes, pickup exceptions and messaging restrictions are recorded.
  • Platform access: KinderConnect’s system administrator is read-only on school data, sees sensitive fields masked, and every access is recorded with its reason. There is no impersonation feature.
  • Session security: no access token is given to the browser; the session is kept in a secure cookie that JavaScript cannot read. Two-step verification is mandatory by default for admin accounts.
  • No personal data in logs: application logs and error messages contain no personal data. Notification and e-mail texts contain no child names or message content.
  • Offline data: records waiting on a teacher’s device are encrypted with a device-specific key and deleted on sign-out and when switching schools.

End-to-end encrypted messages and the school’s privacy notice

School management and KinderConnect cannot read, export or monitor the content of teacher–parent messages. The school sees a message’s content only when someone in the conversation forwards it to school management with their explicit approval. The server sees not the content but who wrote to whom, when, and the size of the message.

The school must state this clearly in its own privacy notice. Suggested wording: “Messages between teachers and parents are end-to-end encrypted; school management cannot access their content. If one of the participants forwards a message to school management, only the content of that message is shared.”

We are also open about the limits of this protection: end-to-end encryption protects against database dumps, backups, system and school administrators and the infrastructure dashboard. Because the app code is loaded from the server each time it opens, it does not fully protect against a malicious code release.

Retention and destruction

  • Student data: permanently deleted one year after graduation or leaving.
  • Messages: deleted after two years.
  • Photo sent for pickup: deleted 7 days after the pickup.
  • When the subscription ends: data is kept for another 90 days, then permanently destroyed.
  • On destruction the school’s encryption key is deleted too, so copies left in backups become unreadable.

Returning data at the end of the contract

The school can export its records during the subscription and within 90 days after it ends. After that period the data is permanently deleted and the school is notified when deletion is complete.

Breach notification

When we detect a breach affecting the school’s data, we inform the school without delay and share the scope of the breach, the categories of data affected and the measures taken. Breach notices we receive from our sub-processors are passed on to the school in the same way. As data controller, the school notifies the Personal Data Protection Board within 72 hours at the latest, and the people affected.

Data subject requests

KVKK requests from parents or staff are made to the school as data controller. KinderConnect provides export, correction and deletion tools so that the school can answer them, and supports the school.

Agreement and documents

A data processing agreement is signed between the school and KinderConnect together with the subscription. For the draft agreement and the technical and organisational measures document, write to [EMAIL] or destek@kinderconnect.app.

  • Privacy notice
  • Cookie policy
  • Terms of use
KinderConnect

School management and parent communication for preschools.

Product

  • Features
  • Security
  • Pricing
  • FAQ
  • Request a demo

Legal

  • Privacy notice
  • Cookie policy
  • Terms of use
  • KVKK for schools

Contact

For questions and demo requests:

  • destek@kinderconnect.app
  • Report a security issue

© 2026 KinderConnect

Screens are design previews; names and numbers are illustrative.