Gizlilik Politikası

1. Introduction and how to read this policy

This is the Privacy Policy for Edelio. Edelio is the international brand name for this service. In Turkey, the same service is offered under the brand name Okuldas. Both names refer to the same company, the same platform, and this same policy. Wherever this policy says Edelio, it means us, regardless of which brand name you see on your screen. Staff and Parents in Turkey sign in at app.okuldas.com, and Staff and Parents everywhere else sign in at app.getedelio.com; both addresses lead to the same Service. We are Edelio LLC, a Delaware limited liability company with a registered address at 8 The Green, Ste A, Dover, DE 19901, USA.

This policy is part of the Agreement. Section 2 of our Terms of Service defines the Agreement to include this document, so when you accepted those Terms you accepted this policy along with them, and Section 8 of the Terms of Service points here for the detail on how information is handled.

This policy covers the Service, meaning the Edelio web application, the Edelio mobile applications, and the features within them. It also covers our two marketing websites, okuldas.com and getedelio.com, and our blog, published separately at blog.okuldas.com and blog.getedelio.com. It describes how we handle Personal Information about everyone the Service touches: Staff and Parents who hold an Account, Students, whose information is processed although they never hold an Account, other named individuals recorded within the Service such as a Pickup Collector, and Visitors to our marketing websites and our blog.

If you are Staff, your Organization has also signed its own agreement with us, including a Data Processing Agreement, which governs how we handle Student Data on that Organization's behalf. This policy is not that agreement. Section 3 explains which information each of us is responsible for, and Section 26 of the Terms of Service explains how to obtain a copy of your Organization's agreement.

This policy is published in English. It is one document, identical under both brand names and in every country where the Service is offered; only the surrounding page, such as its title and navigation, appears in your own language.

Each numbered section below ends with a short paragraph starting with the words In short. Those paragraphs exist only to help you understand the section above them. They are not binding, they do not replace the full text, and they do not change your rights or obligations. If a short paragraph and the section above it ever seem to disagree, the full section governs.

In short: this is Edelio's privacy policy, and Edelio and Okuldas are the same company under two names. It covers the app, our two marketing websites, okuldas.com and getedelio.com, and our blog, blog.okuldas.com and blog.getedelio.com, and it is written in English only. Every section ends with a plain summary like this one, which is there to help you, not to replace the section it follows.

2. Definitions

This policy uses the same defined terms as our Terms of Service, with the same meaning, and adds a small number that only a document about data protection needs. Where one of these words is capitalized in this policy, it carries the meaning given here.

Service means the Edelio software platform, including its web application, mobile applications, and any related features, made available to Organizations and their authorized users.
Organization means a school, nursery, learning center, or similar institution that has signed a separate written agreement with us to use the Service, and that is responsible for its Branches, Staff, and Students within the Service.
Branch means a physical or administrative location or subdivision of an Organization, configured within the Service by that Organization.
Staff means an individual granted access to the Service by an Organization to act on its behalf, including teachers, school leaders, and administrators, regardless of the specific role or permissions assigned to that individual.
Parent means a parent or legal guardian of a Student, invited into the Service by Staff acting on behalf of that Student's Organization, who holds their own account to receive information about that Student and to communicate with Staff. A Parent cannot invite another Parent.
Student means a child enrolled with an Organization whose information is processed within the Service. A Student is a data subject and never an account holder. No account credentials are ever issued to a Student. Every reference to Student in this policy describes a person about whom information is processed, not a party who has agreed to anything here.
User, you, and your mean Staff or a Parent who holds an account and has agreed to our Terms of Service. Students are expressly excluded from this definition.
Account means the credentialed access granted to a User, created only through an invitation from an Organization-scoped user acting on that Organization's behalf. A Parent cannot invite another Parent. There is no self-registration.
Student Data means any information relating to an identified or identifiable Student, including enrollment records, attendance, meal and sleep records, body measurements, health and medical information such as allergies, medical conditions and medication schedules, wellbeing records, photographs and videos, and any content generated about a Student by the Service's AI features.
Content means anything a User submits to, or generates through, the Service, including messages, posts, announcements, comments, photographs, videos, files, and Student Data entered by that User.
AI-Assisted Content means Content that is generated, drafted, or translated in whole or in part by an automated system, including daily narrative summaries and machine-translated text.
Agreement means, together, our Terms of Service and any document they incorporate by reference, including this Privacy Policy and our Paid Features Terms, together with, for an Organization specifically, its separately signed Master Subscription Agreement and Data Processing Agreement. Section 26 of the Terms of Service describes how you can access all of these.
Visitor means a person who accesses okuldas.com, getedelio.com, blog.okuldas.com, or blog.getedelio.com without holding an Account and without being logged in, including, on our marketing websites, a prospective customer who submits the demo request form there. A Visitor has no Account and no relationship with us beyond that visit or, where they submitted the demo request form, that submission.
Pickup Collector means a named adult, holding no Account, whom an Organization records within the Service as authorized to collect a Student, together with that person's relationship to the Student and a telephone number. A Pickup Collector is a Data Subject and never a User.
Personal Information means any information relating to an identified or identifiable natural person, whether a User, a Student, a Visitor, or another individual whose information we process, such as a Pickup Collector. Student Data is a subset of Personal Information specific to Students.
Sensitive Information means Personal Information that KVKK Article 6 or GDPR Article 9 treats as a special category, requiring heightened protection, including health and medical information, biometric data, and information about religious belief, ethnicity, or criminal record.
Controller means the party that decides why and how Personal Information is processed. Edelio and an Organization can each be a Controller for different Personal Information, as Section 3 describes.
Processor means a party that processes Personal Information on a Controller's instructions and does not decide why or how it is processed for that specific activity.
Data Subject means an individual natural person about whom Personal Information is processed, whether or not that person holds an Account. Every Student is a Data Subject. Every User is also a Data Subject with respect to their own Personal Information.
Processing means any operation performed on Personal Information, including collecting, recording, storing, using, sharing, or deleting it.

In short: these are the words this policy uses in a specific sense. They are the same words our Terms of Service uses, plus a few that only a privacy document needs, such as Controller and Processor. The most important one is still Student. A Student is a child whose information we process, and a Student never holds an Edelio account.

3. Who is responsible for your information

Not all of the information described in this policy is ours to make decisions about. Data protection law separates the Controller, who decides why and how Personal Information is processed, from the Processor, who processes it on a Controller's instructions and does not make those decisions. Edelio holds information in three different capacities, and which one applies determines who decides what happens to that information.

For Student Data, the Organization is the Controller. If you are Staff, that is the Organization you act for. If you are a Parent, it is your child's school. The Organization decides which children are enrolled, what is recorded about each of them, which of its own people may see that information, and for what purpose. We act as Processor on that Organization's instructions, under the separate Data Processing Agreement it has signed with us. This is the same allocation Section 3 of our Terms of Service already describes, where it says that your Organization has its own separate agreement with us covering how Student Data is handled. Section 26 of the Terms of Service explains how to obtain a copy of that agreement.

For the Personal Information attached to your own Account rather than to a child, Edelio is the Controller. That includes your name and contact details, your login credentials, your sign-in and session records, your language and time zone preferences, your notification preferences, and the security records we keep in order to protect your Account. We decide why and how that information is processed, because it exists so that we can give you a working and secure Account, not because an Organization asked us to hold it.

For information about a Visitor to okuldas.com or getedelio.com, Edelio is the Controller and no Organization is involved at all. A Visitor has no Account, no Organization, and no connection to any Student. Section 19 describes what we collect on those websites, why we collect it, and who receives it.

These three categories describe why we hold information, not how records are filed, and a single record can sit in more than one of them. A consent decision about a child, for example, identifies both the Parent who made the decision and the Student it concerns. Where that happens, the section of this policy that covers the record in question governs how that record is handled.

Three operational aspects of how we handle Student Data are decided by us and not by the Organization. Each of them is something the Organization instructs and authorizes in advance, in the Data Processing Agreement it signs with us, rather than a decision we make on our own initiative:

We set every retention period in the Service, including the five-year period that applies to medical and wellbeing records after a consent is withdrawn. The Organization's Data Processing Agreement states this retention schedule as a term the Organization agrees to, so an Organization cannot change it, but it has already instructed it by signing that agreement.
We choose the artificial intelligence, machine-translation, and safety-check providers described in Section 12, and how they are used. An Organization can decide whether to buy the AI features, but it cannot choose a different provider, and it cannot turn machine translation or safety moderation off. The Data Processing Agreement authorizes us to engage these providers on the Organization's behalf, in the way data protection law expects a Processor's use of sub-processors to be authorized.
Automated safety moderation runs on every message, and on image and video content, sent through the Service, and an Organization cannot opt out of it. The Data Processing Agreement instructs us to run this check as part of providing the Service, for the safety of the Students, Staff, and Parents the Organization is responsible for.

Whether its own Staff may view Staff and Parent conversations within that Organization is, deliberately, not on this list. Only an Organization's own people, granted that specific permission by the Organization itself, can turn that setting on, and we do not hold that capability ourselves.

Framed this way, each of the three decisions above is us acting on an instruction the Organization gave us in advance, in a signed contract, rather than a decision we make unilaterally, which is what keeps us a Processor rather than a joint Controller of Student Data alongside the Organization.

For a Parent, the practical consequence is short. Decisions about a child's information are made by that child's school, so a question or a request about your child's information should go to the school first. Section 16 explains the rights you can exercise over information about you and about your child, and where a request has to reach your child's school rather than us.

In short: your child's school decides what happens to your child's information, and we handle it on the school's behalf under a separate contract with the school, including that contract's own instructions to us about retention, providers, and safety moderation. Your own account details are ours to look after, and so is anything we learn about someone visiting our websites. If you have a question about your child's information, ask the school first.

4. Whose information this policy covers

This policy describes four kinds of people whose information the Service, our marketing websites, or our blog, may hold. Each is defined more fully in Section 2. This section says who they are, how each one relates to us, and points ahead to where their information is covered in more detail.

The first kind is a Student. A Student is a child enrolled with an Organization whose information is processed within the Service, and a Student is a Data Subject, never an Account holder. No Student holds an Account, no credentials are ever issued to a Student, and no Student ever signs in to the Service. Every account in the Service is created by an invitation from an Organization-scoped user acting on that Organization's behalf, and there is no self-registration path a Student, or anyone else, could use to obtain one. Everything this policy says about a Student describes information processed about that child, not information given by that child. Section 3 explains that the Organization, not Edelio, is the Controller responsible for deciding what is recorded about a Student.

The second kind is an adult who holds an Account, meaning Staff or a Parent. Staff are the teachers, school leaders, and administrators an Organization has given access to the Service. A Parent is a parent or legal guardian invited into the Service to receive information about their child and to communicate with Staff. Both are Users under this policy, and both have agreed to our Terms of Service, which incorporate this policy by reference.

The third kind is a named adult who holds no Account at all: a Pickup Collector. An Organization can record a Pickup Collector within the Service as a person authorized to collect a Student, together with that person's name, their relationship to the Student, and a telephone number. Some Pickup Collectors are recorded on a standing roster for a Student, and some are recorded only as a name and relationship typed onto a single pickup request, without ever being added to that roster. A Pickup Collector is the only place in the Service where we hold a contactable adult's own phone number in connection with a Student who is not that Student's Parent. The Organization decides whether to record a Pickup Collector and what to record about them, in the same way it decides what is recorded about a Student, and we process this information on the Organization's instructions. A Pickup Collector never holds an Account and is never invited to create one. No notice mechanism exists in the Service today to tell a Pickup Collector that their name, relationship, and telephone number have been recorded, and nothing in the Service records that a listed Pickup Collector was ever told they are on file. We are stating that plainly here rather than describing a notice process that does not exist.

The fourth kind is a Visitor to our marketing websites, okuldas.com and getedelio.com, or to our blog, blog.okuldas.com and blog.getedelio.com. A Visitor has no Account and no other relationship with us beyond that visit or, where they submit our demo request form on one of our marketing websites, that submission. Our blog has no such form. Section 19 describes what we collect from a Visitor, why, and who receives it.

In short: this policy covers four kinds of people. Children, who are Students and never hold an account of their own. Staff and Parents, who are adults with their own accounts. Pickup Collectors, named adults authorized to collect a child, who never get an account and who, today, are never told that we hold their name, their relationship to the child, and their phone number. And Visitors to our marketing websites and our blog, who have no account and no relationship with us beyond that visit.

5. Children

A Student is a child whose information is processed within the Service. A Student is never a User and never an Account holder. No account credentials of any kind, no username, no password, no login, are ever issued to a Student, at any age. Every reference to a Student in this policy describes a person about whom information is processed, not a person who has agreed to anything here or who receives a notice of their own.

We collect nothing about a Student directly. Everything the Service holds about a Student reaches us because Staff at that Student's Organization entered it, or because that Student's Parent entered it. A Student never opens the Service, never fills in a field, and never submits anything to us themselves.

Because a Student has no Account, this policy has no separate chapter written for a Student to read. The rights and choices described in Section 16 belong to Users and to other named individuals who can exercise them for themselves. Where information concerns a Student, those rights and choices are exercised by the Student's Parent, not by the Student.

We never direct advertising or marketing of any kind at a Student. We do not build profiles of Students for advertising purposes, and we do not have an advertising business at all, for Students or for anyone else who uses the Service. We do not sell Student information. This matches the promise already made in Section 9 of our Terms of Service, that we will never use Student Data to target advertising at Students or their families.

In short: your child never has an Edelio account, never logs in, and never gives us anything directly. Everything about your child comes from you or from the school. We do not advertise to children, we do not build advertising profiles of them, and we do not have an advertising business at all.

6. What you and your Organization give us

This section lists the Personal Information that reaches us because a person typed it in, uploaded it, or an Organization recorded it within the Service. It is organized by whose information it is, since a single record, such as a pickup request, can name more than one person. Section 7 describes what the Service collects automatically, without anyone entering it directly. Section 8 describes health, medical, and wellbeing information about a Student separately and in more detail, since it is Sensitive Information.

About a Student, an Organization and its Staff give us:

the Student's first, middle, and last name, a birth date, and a gender selection, which includes an option to say prefer not to say
an enrollment date and an access status
an optional photograph
free-text notes a Staff member writes about the Student, which are never shown to a Parent
attendance records, including any reason given for an absence
sleep records
meal records, including whether a meal overlapped with a known allergen
pickup requests, naming who is requesting, collecting, and confirming the Student's pickup
appointments between Staff and a Parent about the Student
calendar events connected to the Student
feed items and class-feed posts shared with a Parent about the Student
photographs and videos of the Student
where an Organization uses the Service to track tuition or fees owed for the Student, the entries in that record

Health and medical information about a Student, including allergies, medical conditions, medication schedules, body measurements such as height, weight, and head circumference, and wellbeing records, is Sensitive Information under this policy. Section 8 describes it separately and in more detail. Section 18 describes how a photograph, video, or document like this is stored, and who can retrieve it.

About you personally, if you are Staff or a Parent, you and your Organization give us:

your email address and a password, which we store as a cryptographic hash, not as ordinary readable text
your first, middle, and last name
a phone number
an avatar image
your preferred language and time zone
your role within your Organization, such as teacher or administrator
the date and the specific version of the Terms of Service you accepted
if you sign in through Google or Apple, a connection to that account, which we use to sign you in

Before you hold an Account at all, whoever invites you types in a first guess at your name, phone number, and time zone, so your invitation can be personalized. This prefill is not your own profile information. It is replaced once you set up your Account yourself.

If your Organization has a paid Subscription, its billing profile records a named billing contact's name, email address, and phone number, alongside the Organization's own legal name, tax identification number, billing address, the language its invoices are issued in, and any notes the Organization adds to an invoice.

A Pickup Collector never holds an Account. An Organization records a Pickup Collector's name, their relationship to the Student, such as grandparent or babysitter, and a phone number, so that person can be recognized when they arrive to collect a Student.

A Visitor who submits the demo-request form on okuldas.com or getedelio.com gives us a name, a school name, a student count, and an email address. That submission also carries, automatically and without anything further to type in, the Visitor's IP address, the city, region, country, and network information our infrastructure provider derives from it, the Visitor's time zone, browser user agent, the page that referred them, and any UTM tracking parameters attached to the link they followed. Section 19 describes our websites, and how this and other information is handled there, in more detail.

Many of the fields listed in this section, such as a note, a reason, a description, or a comment, are free text. The Service does not restrict what may be typed into them, and more than two dozen separate free-text fields exist across the platform for this reason. A person filling in a free-text field may enter something beyond what the field's name suggests, including something that is Sensitive Information, and this policy applies to whatever is actually entered, not only to what a field's name implies.

In short: this section lists what actually gets typed into, or generated through, the Service, organized by who it is about. Most of it is entered by your child's school on your child's behalf, or by you about yourself. A small amount comes from a visitor filling out a form on one of our two marketing websites. Free-text fields such as notes exist throughout the Service and can hold more than their label suggests, and Section 8 covers your child's health, medical, and wellbeing information on its own.

7. What we collect automatically

When you use the Service, some information is generated by the act of using it rather than typed in by anyone. This section describes that automatic collection. It does not cover the information Staff, Parents, and Organizations enter about themselves, Students, or other named individuals, which the section before this one describes.

Every request to the Service carries an IP address and a user agent string identifying the browser or app version making the request; this information is captured on every request, though it is not necessarily logged, meaning written into a stored record, on every request. An action that changes something in the Service, such as creating a record, updating a setting, or sending a message, is written to our audit logs together with this IP address and user agent, and so is a short, specific list of sensitive-record views, such as opening a medication schedule or a wellbeing record. Most other requests, including ordinary read-only browsing of the Service, are not separately logged. This IP address and user agent are stored in raw, readable form everywhere they are kept, including our audit logs, the consent records described in Section 9, and the session records described below. We do not hash, truncate, or otherwise obscure an IP address or a user agent anywhere in the Service; every one described in this section is stored exactly as collected.

Each request is also tagged with a correlation identifier and internal trace identifiers, which let a single request be followed across the different backend services that may handle it. These identifiers exist to diagnose problems and connect the parts of a single action together, and where an audit log entry is created as described above, they are stored in it alongside the IP address and user agent. These identifiers are not used to build a profile of you across separate visits.

Signing in creates session records. An access token is issued to your session for 24 hours. A refresh token, which lets your session continue without signing in again, is issued for 30 days; we store it as a one-way hash rather than in readable form, together with a device identifier and the IP address and user agent present when it was issued. This lets us detect and reject a refresh token that has been reused or replayed, for example because it was stolen. These lifetimes are current defaults and may change. A password you choose is likewise never stored in readable form; it is stored as the output of a one-way hashing function.

On the mobile application, a device identifier is generated on the device itself, a random value with no connection to your device's hardware serial number and no connection to any advertising identifier, and it is used to register that device for push notifications together with the push token issued by the push notification service. If a push notification cannot be delivered, we keep a record of the delivery attempt, the token, and any error returned, so delivery problems can be diagnosed.

For a Parent, whether an announcement or a feed item has been opened is recorded, tied to that Parent and to the item concerned. We use this to build a weekly engagement measure for each Parent, described further in Section 10. This is the one item in this section that is not purely technical; it is a record of your own reading activity, not of your device or connection.

The web application and the mobile application each use a product analytics tool and a separate error-diagnostics tool, and we describe both plainly rather than leaving you to assume either way. The analytics tool records how you use the Service as a signed-in User, tied to your own Account rather than kept anonymous: which parts of the interface you open, which features you use, and technical context such as your device type, operating system, and app version. It does not receive the substance of anything you or your Organization store in the Service, such as a Student's record, a message, or a photograph; it records that a screen or feature was used, not the content behind it. The error-diagnostics tool exists to help us find and fix what breaks. When something fails, it receives technical detail about the failure itself, such as which part of our systems was involved and the sequence code ran in, and it is built to exclude the content of the request that was being handled at the time, so it does not receive a Student's record, a message, or any other stored content either.

Several things a reader might expect from a product like this are still not present, and we say so plainly rather than leaving it to be assumed. Neither the web application nor the mobile application collects an advertising identifier. Neither tracks your location or uses GPS. No part of the Service performs facial recognition, face matching, or any other biometric processing, on a photograph, a video, or anything else.

In short: using the Service automatically generates some technical records. Every request carries an IP address and a browser or app identifier, but only certain actions, mainly changes you make and a short list of sensitive-record views, are kept as a stored log entry; correlation and trace identifiers ride along on that same basis to help us trace a request through our systems. Signing in creates session and token records, and using the mobile application adds a device identifier and a push token. Every IP address and user agent described in this section, including one tied to a consent decision, is stored exactly as collected — none of them is hashed. We also record whether a Parent has opened an announcement or feed item. Our web and mobile applications use a product analytics tool, tied to your own signed-in Account, and a separate error-diagnostics tool built to exclude the content of what you were doing when something failed; neither one receives the substance of a Student's record or anything else you or your Organization store here. We do not collect an advertising identifier, we do not track your location, and we do not perform any facial or biometric recognition.

8. Health, wellbeing, and other sensitive information about a child

Some of what the Service records about a child is Sensitive Information, meaning information that KVKK Article 6 and GDPR Article 9 treat as a special category requiring heightened protection. Health information is the clearest example, and the Service holds a great deal of it. This section sets out which information of that kind the Service records, who can reach it, what happens to it when a consent is withdrawn, and, just as importantly, which categories the Service does not collect at all. All of it is Student Data, so, as Section 3 explains, the child's Organization is the Controller for it and we act as Processor on that Organization's instructions.

The Service records the following about a child's health and wellbeing:

Allergies, including the allergen, a standard code for it, a severity, and a free-text description of the reaction.
Medical conditions, including a condition type, the name of the condition, a severity, start and end dates, and a free-text note.
Medication schedules, including the name of the medicine, the dose, how it is given, the times and days on which it is due, why the child takes it, and instructions for giving it.
Medication administration records, one for each time a dose is given or missed, holding the outcome, a reason, a free-text note, and which Staff member administered it.
Medical documents uploaded against a child, together with an optional short title a Staff member may give it, the file type, and the file size. The file's own original name, as it existed on the device it was uploaded from, is not kept anywhere in the Service.
Body measurements, including height, weight, and head circumference, plus other measurement types an Organization defines for itself, each recorded with a value, a unit, a date, and a free-text note.
Wellbeing records, holding the responses to a wellbeing questionnaire the Organization designs itself, a copy of that questionnaire as it stood on the day, an overall mood recorded for the child, and a setting controlling whether that record is visible to the child's Parents.
A derived wellbeing insight, where the Organization has the Service's AI features and a Parent's wellbeing consent stands. It is built only from the overall mood already recorded in the wellbeing records, rescaled to a common range, together with the sleep, meal, and attendance findings the Service already raises (Section 11). The insight stores dates and the identifiers of those findings, and the level the Organization's own threshold was set at. It does not store the mood value, a mood word, or anything a Staff member typed.
Allergen information copied onto meal records, so that when Staff record what a child ate, the Service also stores the allergen information that applied to that child at that moment, whether it overlapped with the food served, and whether Staff acknowledged that overlap.

The medical module and the wellbeing module are the only two parts of the Service whose data is gated on a Parent's consent. Body measurements sit behind the medical consent, and so does allergen information: where medical consent is not in place, a Student's allergens are withheld both from the screen Staff use while recording a meal and from the meal record itself, not only from one of the two. Section 9 describes how consent is asked for, given, refused, and withdrawn, and how the decision belongs to the Parent and never to the Organization.

Within a school, this information is not open to all Staff. A request to read a child's medical records is admitted only where the person asking is an administrator of that child's own Organization, a teacher whose classroom assignment covers that child, or a Staff member holding an explicit assignment to that child's Branch. Our own platform administrators hold no such assignment, and are refused access to a child's medical records for that reason. Where a medical roster, a medication schedule, a medication administration record, or a wellbeing record is read, that read is written to our audit trail. A small number of other surfaces elsewhere in the Service are logged the same way, but reading an ordinary record is not.

When a Parent withdraws medical or wellbeing consent, or when a child leaves the Organization, the records concerned are deactivated at once and are no longer available in the Service, and they are permanently deleted five years after that moment, together with any medical documents held in file storage. That five-year period is the same for every Organization, and an Organization cannot lengthen or shorten it. It runs from the withdrawal of the consent that left no other consent standing, or from the day the child left, whichever the records were deactivated for. Section 14 sets out how long we keep information in every other case.

The structured records described in this section are not sent to a translation provider today, and they are not part of the material our AI features draft from. Where information about a child's health reaches a translation or AI provider by another path, for example because someone typed it into one of the ordinary free-text boxes described later in this section, such as the reason given for an excused absence, a note on a sleep record, or a meal substitution note, each of which can be translated on request, we remove the details that identify the child first. Section 12 names the providers that receive information from us, and Section 7 of our Terms of Service explains why a machine translation of anything concerning a child's health should never be the last word, and why you should contact the Organization directly if you are in any doubt about it.

There are categories of sensitive information the Service is simply not built to collect, and we would rather name them than let you assume either way:

The Service performs no facial recognition, no face matching, and no other biometric processing of any kind, anywhere. Photographs and videos of a child are stored and delivered as files. They are never analyzed to detect or identify a face.
There is no field anywhere for a national identity number, a passport number, nationality, citizenship, ethnicity, or place of birth. The only place a national identity number appears in our software at all is in a filter whose purpose is to strip such a number out of free text before that text reaches any of the outside providers described in Section 11 - the same filter runs ahead of our content-generation, safety-check, and translation providers alike, not only the one that drafts text.
There is no field for religion or religious belief, and no dietary or religious-restriction field. Our food catalog records meal-time categories and the fourteen allergens listed under EU food law, and nothing else about a food.
There is no field for a disability, a special educational need, an individual education plan, or a classroom accommodation.
There is no emergency contact, next-of-kin, or guardian telephone field. The list of adults an Organization authorizes to collect a child is the only structured record of a contactable adult attached to a child.
The Service records no location or GPS data about a child. A pickup arrangement records a meeting point as plain text, not as a coordinate, and nothing in the Service tracks where a child is.

Of the categories that KVKK Article 6 and GDPR Article 9 treat as special, health information is the only one the Service provides a field for.

One qualification belongs here rather than in a footnote. The Service contains around twenty-five ordinary free-text boxes, spread across student notes, attendance excuses, sleep notes, appointment notes, pickup notes, payment notes, announcements, class post captions, and chat messages, along with three fields that accept a freely structured record, including the responses to a wellbeing questionnaire. Nothing in the Service can classify in advance what a person types into one of those boxes, and health information, or any other sensitive detail about a child or an adult, can end up in one of them. Those fields sit outside the medical and wellbeing consent gates, because they are not part of either module. Our Terms of Service ask Staff to keep a child's health information inside the medical and wellbeing modules rather than typing it into one of these other fields, and the Service shows a reminder of that rule beside every one of these free-text fields, regardless of whether a Parent has consented to either module: the reminder holds equally either way, since this information belongs in the medical or wellbeing module rather than here even when the school is otherwise entitled to hold it. Neither of these turns the fields above into a consent-gated flow; they are an instruction and a reminder, not a technical barrier, and do not by themselves stop a Staff member who disregards both. Section 16 explains how to ask for information about you or your child to be corrected or removed, wherever in the Service it sits.

In short: this section covers the most sensitive information the Service holds about your child, which is information about health and wellbeing. It lists exactly what is recorded, limits who at the school can see it, and explains that withdrawing consent takes the records out of the Service immediately and deletes them five years later. It also names what the Service does not collect at all: no face recognition or any other biometric processing, no national identity or nationality field, no religion or dietary field, no disability or special-needs field, no emergency contact field, and no location tracking of a child. The honest qualification is that the Service has many ordinary free-text boxes, and we cannot control what a person types into one of them.

Two kinds of information about a Student are handled only with a Parent's consent, and they are the only two. The first is medical information: allergies, medical conditions, medication schedules, the records of doses given, medical documents attached to a child's record, and the body measurements described in Section 8. The second is wellbeing information: the mood and wellbeing records an Organization builds from a questionnaire it designs itself. Both are Sensitive Information, and neither is available to Staff through the Service unless consent for that category has been granted.

The wellbeing questionnaire itself is not fixed. An Organization may add, remove, or change its fields at any time, and a Parent's consent for the wellbeing category is not tied to any particular version of it: a grant given for one version of the questionnaire continues to cover a later, different one without being asked again.

Nothing else in the Service is gated on this consent. Photographs and videos of a Student, messages between Staff and Parents, announcements, attendance, meal and sleep records, machine translation, automated moderation, and the Service's AI features are not consent-gated, and withdrawing a consent described in this section does not switch any of them off. Section 10 describes why we process that other information, and Section 16 describes the rights you can exercise over it.

There is one decision per child, per category, per linked Parent, so a Parent with two children answers separately for each of them, and where two Parents are linked to the same child, each of them answers separately too. A decision comes into existence when your child's Organization links you to that child within the Service. It starts in a pending state, and you do not create it yourself. It appears on a consent screen within the Service, where you can answer it, or change your answer, at any time.

Each linked Parent's decision is their own, and nothing about which of you the Organization treats as primary for other purposes changes that: any linked Parent may grant, decline, or withdraw consent for their own decision, at any time, and it is the decision itself the Service acts on, not who is making it. Staff can reach a category of information about your child through the Service only where a linked Parent has granted it and no linked Parent has declined or withdrawn it. A decline or withdrawal by any linked Parent blocks that access immediately, even where another linked Parent has granted it, in the same way that a decline or withdrawal by an only child's one Parent already did.

A Parent can only ever see their own consent records and never another Parent's decision, name, or identity. Where two Parents are linked to the same child and have decided differently, the consent screen tells you what is actually in effect for Staff right now whenever that differs from your own answer, for example that a category you granted is not currently reachable, or that a category you have not yet decided on is already reachable because of another linked Parent's grant. This never identifies the other Parent or states what they specifically decided, only the resulting outcome.

Blocking access is immediate, and it is not the same thing as deleting the underlying information. What withdrawal does to information already stored follows the schedule described below, and that schedule only begins once no linked Parent currently holds a granted consent for that category. Where another linked Parent's consent still stands, withdrawing yours blocks access at once, but the underlying records are not yet deactivated or scheduled for deletion, only made unreachable, until that Parent's own consent for the same category is also gone.

Once that point is reached, the following happens immediately:

Every record in that category about your child stops being visible and usable to Staff through the Service. Medical records, body measurements, and wellbeing records are each marked deactivated to achieve this, and we also check your decision every time a record is read, so access stops even in the moments before that marking has reached every part of the Service.
The identity of the Staff member who recorded a medical entry, a body measurement, a dose, or a wellbeing entry, is stripped from those records.
Medication doses that were scheduled but had not yet been given are cancelled.
The copies of that information that had already been delivered into a Parent's own feed are deleted outright, and a marker is kept so that the same item cannot reappear if the underlying event is delivered to the feed again.
The allergen information that was copied onto a meal record when Staff recorded what the child ate is removed from those meal records. The meal record itself stays, because it is a record of what was eaten.
Where our audit trail kept a before-and-after value for a change to one of those records, that value is blanked. The fact that the change happened, who made it, and when, stays.
Wellbeing insights about your child, and the weekly figures they were built from, are de-identified: the link to your child is replaced with a random value, so they no longer describe an identifiable child.

The records themselves are then kept, made inaccessible in the way described above, for five years from whichever linked Parent's withdrawal was the one that left no granted consent standing. Your child's own identity is not removed from a record during that time, only the recording Staff member's. At the end of the five years a job that runs every night deletes the records for good:

Medical conditions, allergies, medication schedules, the records of doses administered, and body measurements.
Medical documents, together with the underlying files held with our storage provider, which are queued for deletion at the same time.
Wellbeing records and the summaries built from them.

We keep this five-year period so that we and your child's Organization can still answer a later question about what was recorded and who acted on it, including a question you yourself raise after withdrawing. It is a bounded period rather than an open-ended one on purpose: holding Sensitive Information for longer than necessary is itself something data protection law asks us to avoid, and we would rather keep this period moderate than extend it on the chance that a longer one might someday be useful. One consequence of that choice, stated plainly rather than left for you to work out: if a question about how your child's information was handled is one your child only wants to raise once they are an adult themselves, this period will usually have already run its course by the time they could do that. We accept that trade-off in favor of keeping the period bounded.

The record of the consent decision itself is treated differently from the information it governed. While your decision stands granted, we keep it with no end date, because it is our proof that the decision was made and by whom; once you decline or withdraw it, we keep it for ten years from that point, for the same reason, described further in Section 14. It holds the child, the Parent who decided, which of the two categories it covers, the decision and its current status, the times it changed, the language you were using when you made it, and the internet address you made it from, stored in the same raw, unhashed form described in Section 7. Separately from that record, every consent decision is written to our audit trail, which keeps it for five years.

You can only ever see your own consent decisions, and you cannot see or change another Parent's. What an Organization is shown about consent is counts, at classroom and branch level, of how many decisions sit in each state. An Organization owner can export the branch-level counts as a report. Neither the reporting nor the export ever shows how an individual Parent answered.

If you grant a consent again after withdrawing it, your child's records start fresh from that point. The records that were deactivated at the withdrawal are not brought back, and they are still deleted five years after the withdrawal as described above. A second withdrawal later starts its own five-year period for the records created after the new grant; it does not shorten or extend the earlier one.

You may change a decision again later, including granting a consent you previously declined or withdrew. Granting again lets that category be recorded and seen from that point forward. It cannot bring back information that the five-year deletion described above has already removed, because that deletion is permanent.

This section governs information held within the Service. Your child's Organization may keep its own records outside the Service, on paper or in another system, and this policy does not govern those. Section 3 explains why decisions about your child's information sit with the Organization, and Section 16 explains which requests to bring to us and which to bring to your child's school.

In short: consent covers exactly two things, your child's medical information and their wellbeing records, and nothing else in Edelio turns on it. The decision belongs to each parent separately, never to the school, and the school cannot make it, change it, or clear it. Any linked parent can withdraw at any time, and doing so immediately stops the school seeing or using that information, even where another linked parent has granted it. What that means for the records themselves depends on whether another linked parent's consent still stands: if it does, the records stay in place, just unreachable, until that parent's consent is gone too; only then are they made inaccessible to staff, the identity of the staff member who recorded them removed, the copies already delivered into a parent's feed removed, and the records, still naming your child, actually deleted five years after that, never to be brought back. We keep that period moderate on purpose, rather than open-ended, which does mean it will not reach a question your child only wants to raise once they are an adult themselves. The record that you made the decision is kept for as long as it stands granted, and for ten years after you decline or withdraw it, as proof that you made it, and only you can see it.

10. How we use information

We use Personal Information only for the purposes described in this section and elsewhere in this policy, each tied to a specific feature of the Service, and not for a general list of uses beyond those.

To operate the day-to-day records an Organization keeps about a Student, including enrollment, attendance, meals, sleep, body measurements, medical and wellbeing records, and pickup authorizations.
To deliver messages, posts, and announcements between Staff and Parents, and to display Content within the Service to the people it is meant for.
To generate machine translations of messages, announcements, and other Content, including safety-related Content such as notes about allergies, medications, and incidents, and the free-text notes Staff add to a Student's attendance, sleep, and meal records, into a User's chosen language, through third-party translation providers.
To generate AI-assisted drafts of content about a classroom or group of Students together, and content about one identified Student, each reviewed, edited, and approved by a Staff member before the draft is shared with a Parent. Neither kind of draft is ever sent to a Parent without that approval.
To moderate chat messages for safety. An automated system checks message text shortly after it is sent, through a third-party moderation provider, and any resulting action is taken by a person, not automatically. Section 19 of the Terms of Service has more detail on this.
To bill an Organization for its subscription and any purchases made within the Service, through our payment processor. Parents are never billed directly by us.
To keep an audit trail recording actions taken within the Service, such as who created, changed, or deleted a record, and, for a limited set of sensitive record types, who viewed it.
To secure the Service, including authenticating Users, detecting and preventing unauthorized access and abuse, and enforcing rate limits on requests.

We also use a Parent's own behavior within the Service, specifically how often that Parent opens announcements and feed items addressed to them, to calculate an engagement score for that Parent. This is automated profiling of an adult User, not of a Student, and it is separate from anything described above. Its purpose is to help an Organization identify a Parent who may benefit from additional outreach, for example a Parent who has not engaged with communications about their child for an extended period. An engagement score is advisory only: nothing in the Service automatically restricts a Parent's access to the Service, changes their Account, or takes any action against them on the basis of a score, and acting on a score, if an Organization chooses to, is a decision the Organization makes itself. The lawful basis for it is our own, and your Organization's, legitimate interest in noticing when our communications are not reaching a family, weighed against your own interests, and Section 11 sets out that reasoning in full alongside the rest of our automated processing.

We do not use Student Data to target advertising at a Student or a Student's family, and we do not have an advertising business, as Section 9 of the Terms of Service also states.

In short: we use your information for specific things tied to how the Service actually works, running your school's records, delivering messages and announcements, translating content, moderating chat for safety, generating and reviewing AI-assisted drafts about classrooms and about individual Students, billing your school, keeping a record of who did what, and keeping the Service secure. If you are a Parent, we also calculate a score of how engaged you are, based on how often you open announcements and feed items, to help your school know if you might need extra outreach, and that score never automatically affects your Account. We do not build advertising profiles of children or use Student Data to advertise to families.

11. Automated processing: AI features, machine translation, and content moderation

Several parts of the Service work by sending text to an automated system, and some of that text describes a child. Section 7 of the Terms of Service explains what these features are and what you should not rely on them for. It also says that the detail of how they handle information lives here, so this is that detail.

Four third-party providers carry out automated processing for us. Each receives a different kind of text, and none of them receives all of it.

Our AI content-generation provider generates draft text. This covers text generated about a classroom or a group of Students together, where no individual child is named or singled out, and text generated about one identified Student. It is the only one of the four that writes anything.
Our safety-check provider carries out the safety checks described below. It receives the text of messages sent through the Service, the text of a generated update once that update has been written, and any image or video sent as a chat attachment. It generates nothing.
Our translation providers, a primary one and a fallback used if the primary is unavailable, translate text into the language a reader has chosen.

Section 12 describes these providers alongside every other company that receives information from us, and what each of them is allowed to do with it.

The text we send to the generating model is assembled by the Service. It is not a copy of a child's record. For a daily narrative about a Student, the prompt is built from counted, structured information about the day, such as how many meals were recorded, how attendance was marked, and how long a nap lasted. The prompt has no field capable of carrying a Student's name, identifier, or photograph, so none of those reaches the model. The child's name is placed into the finished text afterwards, by a separate step that runs on our own systems once the model has returned its answer.

Two places in the Service let a member of Staff type free text that becomes part of a prompt: a note attached to a sleep record, and the topic detail on an academic explanation. What a person types into a free-text box is not something the Service can inspect in advance. If a member of Staff types a child's name into one of those boxes, that name goes into the prompt with the rest of the note. Section 12 of the Terms of Service makes Staff responsible for what they submit, and this is one of the places where that responsibility bites.

Before Content leaves our systems for any of the four providers described above, we remove personally identifying details from it, including names, email addresses, telephone numbers, and national identification numbers.

The safety check on a generated update about your child runs before the child's name has been placed into the text, not after. A child's real first name is placed into a generated update only once that check has already passed, on our own systems, and it is never sent to the safety-check provider or any other third party for this purpose. Nothing is generated from it. It is used only to decide whether a person at your child's Organization needs to look at the update before it is published.

No update generated about a Student reaches a Parent on its own. A generated draft is held in a state that a member of Staff has to approve by a deliberate action, and until they do, they can edit it, generate it again, or discard it. Nothing publishes on a timer and nothing publishes because the model was confident. Section 12 of the Terms of Service places responsibility for that review on the Staff member who carries it out, and Section 7 of the Terms of Service explains why you should still ask your child's Organization directly about anything to do with health or safety.

Translation is available on demand for text a reader would otherwise not be able to read: pressing a translate control is what turns a translation on for that message, post, note, or entry, and the original is what you see until you do. That covers messages, posts and announcements, notes attached to a pickup request, calendar entries, the reason given for an excused absence on an attendance record, the note on a sleep record, and the note about what a child was given instead of a planned meal, and why, on a meal record. Neither you nor your child's Organization chooses which translation provider is used, and an Organization cannot switch translation off. Section 3 explains why decisions of that kind are ours rather than the Organization's.

Once you have asked for a translation, you can switch back to the original at any time, and the original governs if the two differ. We store a translated copy once one has been requested, so the same sentence does not have to be sent for translation twice, which means a translated copy of a message can exist separately from the message itself. Section 14 describes how long those copies are kept.

Every text message sent through the Service, and every image or video sent as a chat attachment, is checked by the moderation provider. The check runs after the message or file has been sent and delivered, not before, so it is not a filter standing between you and the person you are writing to. Section 19 of the Terms of Service describes the same thing from the other direction.

The check never blocks, hides, deletes, or edits a message by itself. What it produces is a record: an outcome, the categories the provider flagged, and a score for each of those categories, stored against that message and its named sender. Acting on a flagged message is always a human decision, taken by a member of Staff working through a review queue, and a flagged message stays visible and unchanged until a person decides otherwise. Neither an Organization nor a User can turn this check off.

We should be direct about what that record is. The categories the provider returns include self-harm, sexual content, and harassment or threats, so a flagged record is a machine-generated inference about a named person on subjects that data protection law treats as sensitive. Section 8 explains how we treat sensitive information generally. Access to these records is limited to Staff who hold the specific permission to review them, and each time one is opened, that access is written to our audit trail.

Four features look for patterns rather than writing text.

Attendance anomaly detection looks at recorded attendance for a Student and raises a finding for Staff when a pattern stands out.
Sleep and meal trend insights do the same for recorded sleep and meal information. They are about sleep and meals only and carry nothing from a child's wellbeing records.
Wellbeing insights look for a child whose recorded mood has been low across several days of a week, and for a child whose low days coincide with one of the findings above. They are built only for children whose Parent's wellbeing consent stands, only for Organizations that have the Service's AI features, and only from the mood already recorded; a level the Organization can set decides what counts as low. They are read only by Staff who hold the specific permission for them, only within the classroom, branch, or Organization that permission covers, and only while the consent still stands: if it is withdrawn, the insight stops being available at once. Each time one is read, that access is written to our audit trail. When the pattern is no longer present, the insight is marked as resolved by the system, and a member of Staff who has looked at it can mark it acknowledged.
Parent engagement scoring produces a weekly score for each Parent. It is built from whether and when you opened announcements sent to you, and whether and when you read items in your child's feed. The result is a weekly snapshot visible to Staff at your child's Organization.

All four produce advice for a person to read. None of them writes to a Student's record or to your Account, none of them changes what you can see or do, none of them affects your child's place at the Organization, and none of them is used to make a decision about you or your child by automated means alone.

The lawful basis for the engagement score specifically is our own, and your Organization's, legitimate interest in noticing when our communications are not reaching a family, so that the Organization can consider whether to reach out. We rely on that basis rather than your consent, because nothing about this score is something you opt into or can switch off, and consent has to be exactly that. Weighed against your own interests, the score reads only whether and when you opened something, never what it said, it is visible only inside your child's Organization, and it never triggers anything automatically for you or your Account. Because a person at your child's Organization always decides whether, and how, to act on a score, this does not reach the point at which the law requires the fuller disclosure it reserves for a decision made about you without a person's involvement. It is still the kind of systematic, ongoing profiling for which we carry out a data protection impact assessment before it runs for any Parent, and we do that regardless of whether the fuller disclosure applies.

A wellbeing insight is Sensitive Information about a child that we infer rather than that anyone typed in, and we treat it that way. It is shown by a separate permission from the one that lets a person record a wellbeing check-in, so being allowed to record a check-in does not allow reading an inference about the child. The Service may send the classroom's teachers, and Staff holding that permission across a whole branch, a short notification that a wellbeing insight needs review. It says only that, and names the classroom; it never names the child, never carries a value, a mood, or a reason, and does not link to the insight, which is opened inside the Service where the checks above apply.

None of the above applies to images. No feature of the Service analyzes a photograph or a video of a child. There is no face detection, no facial recognition, and no biometric processing anywhere in the Service. Photographs and video are stored and delivered, not examined.

None of the four providers described above is permitted to train a model on text we send it. That is unconditional: no consent, permission, or setting changes it, for any of the four.

We keep a record of each request sent to a generating model and of the answer that came back, with identifying details removed from both, so that we can account for what the Service did, what it cost, and what went wrong when something went wrong. Section 14 describes how long we keep that record, and how the length of that period depends on the training consent described immediately below.

Separately, we run a closed model of our own: run on our own systems and kept under our own control, never a third party's. We use Content from the Service to train this model on exactly these terms: only where you have given the consent described below, category by category, and never otherwise. Here is how that consent works:

A permission given for our own model is a permission given only to us. It is never a permission for any of the four third-party providers described above, and it never changes what any of them is allowed to do with your Content. The two are unconnected, and always will be.
Permission is asked for by category, not once for everything. A category is defined by what kind of content it covers, not by which feature produced it. There are three: content generated about a classroom or a group of Students together, where no individual child is named or singled out; content generated about one identified Student; and content connected to an Organization's own administrative or financial records, where no Student is the subject.
Every category is off unless somebody turns it on. Not answering is a refusal, and we do not treat continued use of the Service as agreement.
The classroom-or-group category and the administrative-or-financial category can be turned on only by the Organization, in the same way Section 3 describes an Organization agreeing to buy other AI features already in the Service.
The category covering content about one identified Student can be turned on only by that Student's own Parent, and only for that Student. Your child's Organization cannot give it on your behalf, which is the same rule Section 13 of the Terms of Service states for every other consent about a child.
Once a category is on, we use Content falling into it immediately, without any further waiting period. A permission can be withdrawn at any time, and withdrawal stops any further use of that information from the moment it is made.

In short: our AI writes drafts, translates text, and checks messages for safety, and this section says which company does which and what each one sees. A generated update about your child is built without the child's name in it, and a person at the school has to approve it before you ever see it. Messages are checked after they are sent, and that check never blocks or deletes anything on its own; a person decides. We also score how often parents open announcements and read feed items, based on our own and your Organization's interest in noticing when a family is not being reached, and a person always decides whether to act on that score. Our third-party providers never train a model on your content, under any circumstance. We run a closed model of our own, unconnected to any provider, and we use your Content to train it only where you have given consent first, category by category. Everything is off until you say otherwise, and for anything about your child, only you can say it.

We do not share your Personal Information beyond what actually running the Service requires. Within your Organization, it flows only to the Staff whose role needs it, as the rest of this section describes. Outside your Organization, only a small number of specific companies receive anything, and each receives only what it needs to do one job: our payment processor sees an Organization's own billing contact, and outgoing email goes out through our own mail server. Anything that could identify a Student is removed before content reaches an AI, translation, or safety-check company; the one exception is photographs, videos, and file attachments, which are stored as themselves. Even so, each file is renamed to a random identifier before storage, kept in a private location nobody can browse directly, and released only to someone whose own access already covers the record it belongs to. Our hosting provider holds everything the Service runs on, the same way any host does. Visitors to our marketing websites and blog are a separate, smaller case, described in Section 19. We do not sell Personal Information.

Within your Organization, a Staff member sees only the information their role and assignment grant them. A teacher generally sees the Students and Parents connected to their own classroom, not the rest of the Organization. Your Organization's owner sees information across every Branch that belongs to your Organization. That access comes from holding the owner role itself, not from any particular Branch assignment: unlike a teacher, an owner is never limited to specific Branches within their own Organization. It never extends to a different Organization's information. The role-based and Branch-based access described in this paragraph has one exception: it does not, by itself, give any Staff member, including your Organization's owner, access to a conversation between Staff and a Parent. A conversation is private by default regardless of role or Branch access, and it becomes visible to an administrator only if the Organization separately turns on the setting described in the next paragraph.

When Staff post an announcement, the Organization can see a read count showing how many recipients have opened it. This aggregate is visible to Staff as part of the ordinary operation of the announcements feature. Feed items separately record when each Parent opens them, and, unlike an announcement, no equivalent Staff-visible read-count aggregate exists for a feed item: a Parent's own reading activity there is used only for that Parent's own unread count, and, as described in Section 10, to build the engagement score.

Your Organization can also choose to turn on a setting that lets its own Staff view the conversations between Staff and Parents within that Organization. This setting is off by default. It is also read only: a Staff member who turns it on can see a conversation but cannot send, edit, or delete a message within it. The people in a conversation can see, from within the Service, whether this setting is turned on for their Organization. Only your Organization's own people, granted that specific permission by the Organization itself, can turn it on. We do not hold that capability ourselves: our own platform administrators cannot enable supervision of any Organization's conversations, matching how Section 19 of the Terms of Service describes this as your Organization's own choice.

We use a number of outside companies to run the Service, our marketing websites, and our blog. Each one is listed below with the purpose it serves.

Our payment processor handles billing for an Organization's paid subscription with us. It does not receive information about individual Students, Parents, or Staff beyond what an Organization's own billing contact provides.
Our AI content-generation provider, reached through an enterprise business platform rather than a consumer product, generates AI-assisted content from aggregate counts such as attendance, meals, and sleep. The prompt sent to it does not include a Student's real name or photograph.
Our safety-check provider screens content for safety after it has already been created. It receives the text of chat messages, and separately, the text of AI-assisted content, each with personally identifying details removed first, as Section 11 describes. This provider is not used to generate or translate content, only to screen it.
Our translation providers receive the text of chat messages, feed items, announcements, pickup-request notes, calendar events, and the free-text notes on attendance, sleep, and meal records, with personally identifying details removed first, in order to machine-translate them. The removed details are restored once translation completes, before you see the result.
Photographs, videos, and file attachments are stored by a dedicated storage service, kept separate from our hosting provider below.
Our bot-detection provider runs a spam check on our marketing websites.
Our error-monitoring tool receives technical error reports from our backend systems, our web application, and our mobile application.
Our push-notification provider delivers push notifications to the mobile application.
We deliver email, such as invitations and notifications, through our own mail server.
Our hosting provider hosts the infrastructure the Service runs on.
Our analytics provider receives analytics events from our marketing websites, our blog, our web application, and our mobile application.
An internal system we use for handling new leads receives every submission of the demo-request form on our marketing websites, including the name, school, student count, and email address a visitor provides, along with technical details about that visit. Our blog has no such form, so nothing from it is ever routed there. Section 19 has more detail about our marketing websites and our blog.

We do not sell Personal Information to anyone, for any purpose. We do not have an advertising business, and we do not share Personal Information with a data broker. Outside of your Organization and the service providers listed above, we disclose Personal Information only when the law requires it, such as in response to a valid court order or similar legal process, or when we believe in good faith that disclosure is necessary to protect the safety of a Student, a User, or another person.

In short: information you share flows to the people inside your school who need it for their role, to the outside companies listed here that each do a narrow job for us, and nowhere else, except where the law compels us or someone's safety is at risk. We do not sell information and we do not use it for advertising. The setting that lets a school view its own staff-parent conversations is entirely the school's own choice: only people the school itself has authorized can turn it on, and we do not hold that capability ourselves.

13. Where information is stored, and transfers outside your country

We do not own or operate data centers. The Service runs on cloud infrastructure we rent from another company, and several of the features described in this policy are delivered by third parties that process information on their own systems, in places they choose rather than places we choose. This section sets out where information sits, where it travels, and what we can and cannot tell you about each of those places.

The Service's own infrastructure is regionalized by market, so that an Organization's information stays within a territory that Organization is entitled to expect it in, and we run within the territory each customer is entitled to. Concretely: an Organization in Turkey, and the Students, Staff and Parents connected to it, has its information held in Turkey, in an AWS data center in Istanbul. An Organization in the European Union has its information held in the European Union, in an AWS data center in Frankfurt. An Organization in the United Arab Emirates has its information held in the United Arab Emirates, in an Azure data center in Dubai. Our application services, our databases, and the storage that holds photographs, videos, and file attachments all follow this same market-by-market split.

We are a United States company. Edelio LLC is registered in Delaware and its registered address is in the United States, as Section 1 sets out. That by itself does not place any Personal Information in the United States, but it belongs in an honest answer to the question this section asks, so we say it here rather than leaving you to infer it.

The Service also depends on the third-party providers listed in Section 12, and we apply the same market-by-market principle to them where a provider makes it possible. Before Content reaches any of these providers, the identifier-removal step described in Section 11 has already run, so what a provider receives is stripped of personal identifiers first, and only then sent to a provider endpoint chosen for the Organization's own market. The position for each provider is as follows.

Our AI content-generation provider, our translation providers, and our safety-check provider are each called at an endpoint matched to the Organization's market where one exists. For an Organization in the European Union, or in Turkey, we use each provider's European endpoint. Turkey does not currently have its own in-country deployment from any of these providers, so a European endpoint is the closest available option that keeps Content off an unrestricted global endpoint, rather than an endpoint specific to Turkey itself. For an Organization in the United Arab Emirates, we use each provider's United Arab Emirates endpoint where that provider offers one.
Error diagnostics from our backend, web, and mobile applications are sent to our error-monitoring tool. That integration's region is configured on our hosting platform rather than in the configuration we keep under version control.
Mobile push notifications are delivered through our push-notification provider, at a single global endpoint; that integration offers no region, data center, or endpoint location parameter. Email is sent through our own mail server; we have not set a specific region for it.
Signing in through Google or Apple involves an exchange between our own servers and that provider, carrying your email address and a stable account identifier. Neither provider offers a region setting for that exchange.
Payments for an Organization's Subscription are handled by our payment processor. We set no country or region on that integration.

The practical consequence is one we would rather state plainly than leave inside a list. For error diagnostics, push notifications, email, and sign-in, we cannot state a region here at all, either because none exists to set or because the setting is held on our hosting platform rather than in the configuration we keep under version control. Separately: the identifier-removal step described in Section 11 works from a directory of your Organization's own Students, Staff, and Parents, plus pattern-based rules for things like an email address or a phone number, and it replaces what it finds with a placeholder rather than deleting it. It is not a guarantee that every identifying detail is caught, and a placeholder is a substitution your Organization or we can reverse, not a deletion. That is why the text reaching our safety-check provider and our translation providers, even after this step has run, is still Personal Information in the form data protection law calls pseudonymized, not the form it calls anonymized. Routing that message text to a market-matched endpoint changes where it goes, not what it contains when it gets there.

KVKK Article 9, as reformed in 2024, sets out three ways a transfer of Personal Information out of Turkey can be lawful: a Board decision that the destination offers an adequate level of protection, an appropriate safeguard such as the Board's own standard contractual clauses, or a narrow exception available only for occasional, non-systematic transfers. The Board has not issued an adequacy decision covering the European Union, and the transfer described above happens continuously rather than occasionally, so the safeguard available to us is the Board's standard contractual clauses, executed with our safety-check provider and notified to the Board within five business days of signature, as KVKK Article 9 requires. We do not yet hold that instrument. We treat putting it in place as work owed, not as something already done, and we say so here rather than leave you to assume otherwise.

A transfer from an Organization based in the European Union to that same provider's European endpoint does not raise this question at all. It does not leave the European Economic Area, so Chapter V of the GDPR, which only governs a transfer to a country outside that area, has nothing to say about it.

We can also answer, without qualification, whether the text reaching our safety-check provider is personal data even after the identifier-removal step described above has run on it. It is. That step pseudonymizes rather than anonymizes: a placeholder stands in for what it removes, the link back to the real detail is not destroyed, and your Organization, or we, can reverse it. Pseudonymized information is still Personal Information under both GDPR and KVKK, since anonymization is a materially higher bar this step does not reach, so this is still a transfer of Personal Information, and the standard contractual clauses described above are still what that transfer needs.

Finally, we route this text to a European endpoint for a Turkish Organization only because no Turkey-specific deployment of this provider exists, not by choice. That absence of choice is exactly what makes this a cross-border transfer under KVKK Article 9 at all. If a Turkey-specific endpoint existed, there would be no transfer to disclose here.

Our marketing websites and our blog rely on a smaller and separate set of providers: the analytics provider, which all four sites share, and, for our marketing websites only, the internal system that receives a demo request. Section 19 describes those, and says what we can and cannot state about where each of them processes what it receives.

In short: we host the Service on a market-by-market basis, so a Turkish school's data sits in Turkey, an EU school's sits in the EU, and a UAE school's sits in the UAE. We apply the same principle to the providers that generate, translate, and check the safety of content, sending it to a European endpoint for our Turkish and EU customers and a UAE endpoint for our UAE customers. The text reaching our safety-check provider and our translation providers has personal identifiers removed first, but that removal is a pseudonymization, not an anonymization: it can be reversed, so the text is still Personal Information. For a Turkish Organization that still makes this a transfer of Personal Information out of Turkey, one that KVKK Article 9 requires the Board's standard contractual clauses for, which we do not yet hold. The same flow for an EU Organization stays inside the European Economic Area and needs no such instrument. For email, push notifications, and sign-in, we cannot state a region at all. We do not yet hold the paperwork that transfers like these normally require, and we say so above rather than leave you to assume otherwise.

14. How long we keep information

We keep Personal Information for as long as we have a reason to keep it, and then we delete it. The periods below are set by us. They apply the same way to every Organization and to every User, and an Organization cannot lengthen or shorten them. Where an Organization has a recordkeeping obligation of its own, that obligation concerns records the Organization holds outside the Service, or is dealt with in its separate agreement with us; it does not change the periods described here.

Almost every period below runs from an event rather than from a calendar date, and the event is usually one of three things: a Student leaves the Organization, a Parent withdraws a consent, or an Account is closed.

Information attached to your Account, including your name, your contact details, your credentials, and your preferences, is deleted one year after your Account is closed. The audit records of what you did within the Service while it was open are not part of that, and follow the audit schedule described below instead.
Information about your Organization's own billing relationship with us, including the billing contact's name, email, and phone number, the Organization's legal name and tax identifier, its billing address, and its invoices, is kept for as long as that relationship continues. The Service does not today have a way to close an Organization's account the way your own Account or a Student's enrollment can be closed, so this information has no scheduled deletion date; it is removed only if we end that relationship and act on it by hand.
A Student's records, meaning the enrollment record and the information recorded against it such as attendance, meal and sleep records, body measurements, appointments, pickup records, payment tracking entries, posts and feed items about that Student, and the photographs and videos of that Student stored in the Service, are deleted five years after the Student leaves the Organization.
Health and medical records, body measurements, and wellbeing records, are deleted five years after the earlier of two events: the Parent withdraws the consent that allowed us to hold them, or the Student leaves the Organization. The paragraph after this list explains what happens at the moment a consent is withdrawn, which is not the same thing as deletion.
A wellbeing insight, and the weekly figures it was built from, are de-identified at the earlier of the same two events, as Section 9 describes. The de-identified record has no scheduled deletion date; it no longer identifies a child.
Messages between Staff and Parents, and the threads that hold them, are deleted two years after the message is sent. A message you delete yourself before then is handled a little differently, described in Section 15.
The record of a consent, meaning who gave or withdrew it, what it covered, and when, is kept for ten years after the consent is withdrawn or declined. A consent that is still granted has no age-based deletion date for its record, because it remains the evidence of an authorization we are currently relying on. It is kept longer than the information it authorizes, because it is the evidence of the decision itself and it has to outlive the data whose deletion it triggers.
A record of a request you make to us under Section 16, meaning who asked, what was asked, when we received it, and what we did about it, is kept for three years after we close the request, and is then deleted. Where we compile a copy of your information to answer an access or portability request, that copy is deleted thirty days after the request is closed.
Audit records, which log who did what within the Service, are kept on a tiered schedule according to the kind of event recorded: one year, two years, or five years. A small number of event types are placed on a regulatory hold and are not deleted on a schedule at all. A small technical queue that holds audit events which failed to record is also kept indefinitely, separately from the tiered schedule, until the failure is investigated.
The text of a prompt we send to an artificial intelligence provider, and the text that provider returns, is kept for as long as the training consent described in Section 11 stands granted for it. Once that consent is withdrawn, or where none was ever given, the text is kept for two years, counted from the withdrawal or from the interaction respectively, and then deleted. The accounting record of the same interaction, which records the provider, the model, the cost, and the Organization the cost belongs to, is kept for five years.
Translated text held in our translation cache is deleted thirty days after it is written there. A separate, durable copy of translated content, kept so a message or announcement can be redelivered without re-translating it, is not deleted on an age-based schedule; it is removed only when the Organization it belongs to is deactivated. The original text is unaffected either way, and stays for as long as the record it belongs to.
A file uploaded to the Service but never attached to anything, such as an abandoned photograph or an abandoned attachment, is deleted twenty-four hours after it is uploaded.
Sign-in sessions expire on their own rather than being deleted on request. An access token lasts twenty-four hours, and a refresh token is issued with a thirty-day lifetime. Our mobile application holds onto it for that full thirty days, so a mobile session can sit inactive that long before you need to sign in again. Our web application currently holds onto it for a shorter window of seven days, because the response our web application receives when you sign in does not tell it how long the token is actually valid for, so it keeps it for a bounded window instead of an open-ended one. A web session accordingly ends, and asks you to sign in again, after seven days of inactivity, even though the token itself would still work for longer than that.
Internal technical records that make the Service work, such as the queues that carry an event from one part of the Service to another and the logs of whether a delivery succeeded or failed, are kept for between seven days and one hundred eighty days, depending on the record. A small number of them are kept until the situation they describe ends, rather than on a clock, because deleting the record would undo the thing it records. A record that an Organization is suspended is the clearest example.
Information collected on okuldas.com, getedelio.com, blog.okuldas.com, and blog.getedelio.com follows its own periods. A demo request, submitted only through our marketing websites, including the contact details submitted and the technical information described in Section 19, is deleted two years after it is submitted. The consent cookie each of these four sites sets on your device expires one year after it is written.

Withdrawing a consent, or a child leaving the Organization, has an immediate effect, and that effect is not deletion. The records concerned (health and medical records, body measurements, and wellbeing records) stop being visible and usable within the Service straight away, any pending medication doses are cancelled, and the Staff member recorded as having entered a record or administered a dose is unlinked and pseudonymized on it. The copies delivered into a Parent's feed, the allergen information copied onto meal records, and the before-and-after values held in our audit trail are removed as Section 9 describes. In none of these cases is your child's own identity removed from the record at this point, only the recording Staff member's, and the record still names your child until the five-year period described in this section ends. The five-year period then runs from that moment, and at the end of it the records themselves, and any files attached to them, are permanently deleted rather than merely made inaccessible. When that period ends after a child has left, the consents that were still pending or granted for that child end at that point as well, which is when the ten-year period for the record of a consent begins.

The five-year hold described above rests on a basis distinct from the consent that first authorized us to hold the information, since neither trigger leaves that consent basis standing: withdrawal removes it directly, and a Student leaving the Organization ends the purpose the consent was given for even where the decision itself has not been withdrawn. Under GDPR Article 9(2)(f), processing special category information for the establishment, exercise, or defense of a legal claim is a basis independent of consent, paired with Article 6(1)(f)'s legitimate interest ground, and it applies the same way regardless of which trigger started the clock: our interest, and your child's Organization's, in being able to answer a later question about what was known about a child's allergy, condition, or medication, and what was done about it, does not depend on why the consent basis ended. Turkish law reaches a similar practical position through a narrower route. KVKK Article 6(3) lists the conditions under which health information may be processed without explicit consent, and it does not name legal-claims defense among them the way GDPR Article 9(2)(f) does directly. Existing guidance from Turkey's Personal Data Protection Board has instead treated a health record's use in an active legal claim as compatible with Article 6(3) by reasoning that the original purpose the record was created for continues while that claim exists, a narrower route to a similar place, and one confirmed for an active claim rather than for information held in anticipation of one that has not yet arisen, which is what this five-year period actually does.

We may keep information for longer than the periods above where the law requires us to, or where we need it to establish, exercise, or defend a legal claim. Where that happens we keep only what is needed for that purpose, and we delete it once the reason for keeping it has ended.

If a kind of Personal Information is not named above, it is kept for no longer than the longest period that applies to the Account or to the Student it concerns, and it is deleted, or de-identified so that it no longer identifies that Account or that Student, once that period ends.

In short: we delete things on a clock, and the clock almost always starts when a child leaves the school, when a consent is withdrawn, or when an account is closed. Most information about a child, photographs and videos included, goes five years after the child leaves. Health and wellbeing information goes five years after a consent is withdrawn or the child leaves, whichever comes first, and withdrawing a consent stops that information being used straight away even though the deletion itself comes later. That hold rests on our own and your Organization's interest in being able to answer a later question about a child's health information, a basis that does not depend on consent and applies the same way regardless of which of the two triggers started the clock. Messages go after two years, and the record of a consent decision is kept for as long as it stands granted, and for ten years after it is declined or withdrawn, because it is the proof of what you decided.

15. Closing an account, leaving a school, and deletion

This section describes what happens when one of the relationships behind the Service ends: you close your Account, a Student leaves an Organization, or an Organization stops using the Service. It also explains what the word delete means inside the Service, because in most places it means less than a reader would reasonably expect, and we would rather say that here than let you discover it later.

You can close your own Account directly within the Service, from your account settings — Staff, Parents, and Organization owners alike. An administrator at your Organization can also close your Account for you by changing its status. An Organization's last remaining owner cannot close their own Account through the Service, since doing so would leave the Organization without an owner; contact us at support@okuldas.com in that case. Section 26 of the Terms of Service has our contact details, and Section 16 of the Terms of Service is where your right to ask for closure comes from.

Closing an Account deactivates it. In practice that means the following:

You can no longer sign in, and the Service stops treating you as an active user anywhere.
You stop receiving notifications from the Service, apart from a small number of account, billing, and security messages.
If you signed in through Google or Apple, the connection between that provider and your Account is deleted outright, so the Account cannot be linked back to it.
Your profile, your sign-in record, and everything you wrote or uploaded while the Account was active stay where they are. A message you already sent stays in the conversation you sent it to, visible to the people who received it. A photograph you posted stays on the post you attached it to.

Closing an Account is not the same as asking us to erase your Personal Information, and the two should not be confused. Closure ends access. Erasure removes records, and it is a separate request with its own process, described in Section 16. Section 14 sets out how long each kind of information is kept and when it is deleted on its own. Closing an Account neither shortens those periods nor starts them early. Nor is closing an Account the deletion that ends the license you granted us in Section 9 of the Terms of Service. Content you already shared stays with the people who received it, exactly as that section already provides.

When a Student leaves an Organization, whether because the child moves to another school, finishes their time there, or is unenrolled for any other reason, the Student's record is marked inactive rather than removed immediately. The link to their classroom ends, and Staff who are no longer responsible for them lose access straight away. Leaving a school does not, by itself, delete anything about a child; it starts the five-year clock Section 14 describes. What does happen at once is that the child's health and medical records, body measurements, and wellbeing records stop being visible to Staff, and the Staff member recorded on them is unlinked, in the same way as when a consent is withdrawn (Section 9). A child who comes back to a school is enrolled as a new Student: nothing from the earlier enrolment is brought back, and a Parent's consent is asked for afresh. Five years after that date, the Student's record, meaning the enrollment record and everything Section 14 lists against it, is permanently deleted, and so is the record of every Pickup Collector named for that Student. Some of what is in the Student's record, such as health and wellbeing entries, is deleted earlier than that under the period Section 14 sets once a Parent withdraws consent for that module, if that happens first.

If you are a Parent and your Account is closed, your child's record does not close with it. Your child's Organization is the Controller for that record, as Section 3 explains, and it keeps that record for its own enrollment, safeguarding, and legal purposes whether or not you hold an Account. Section 9 of the Terms of Service says the same thing from the other direction. Closing your Account removes your access; it does not remove your child from the school's roster, and it does not remove what the school has recorded about your child.

An Organization that stops paying, or that stops using the Service, is suspended rather than erased. Its access is restricted, and everyone who signs in through that Organization loses access with it. Nothing is purged, exported, or anonymized at any stage of that process. The record of the suspension itself is deliberately never removed, because removing it would silently restore full access to every person in that Organization. The Organization's information stays with us for as long as we hold it, subject to the periods in Section 14. The commercial side of a lapse or a suspension, including what the Organization owes and how it restores access, is dealt with in that Organization's separate agreement with us, not here.

Deleting your own message removes it from the conversation for everyone in it immediately. What happens to the words you wrote depends on why it was deleted. If you deleted it yourself, the words are kept for a further fourteen days, and for longer than that if the automated safety check every message goes through when it is sent is still open when those fourteen days end, until that check concludes. Once neither applies, the words are permanently destroyed, not merely hidden: we do not keep a separate copy anywhere, including in our own internal record of what you did, which is deliberately built to never capture message text at all, for exactly this reason. Redaction works differently. When a message is redacted after a member of Staff reviews it, what people see is the masked version, and the original text is kept alongside a record of who redacted it, when, and why, so that the people who handle safety reports can still review what was actually said, on the same two-year period Section 14 sets for messages generally. A moderator deleting someone else's message outright, rather than masking it, is held to that same two-year period, for the same reason.

Removing a photograph or a video works differently from removing the words in a message, and deserves to be described precisely. A photograph is not removed on its own. It is queued for removal from storage as soon as the post or the message it is attached to is deleted, whether by you, by a moderator, by the classroom or post itself being removed, or, if nobody deletes it first, once the message reaches the end of the two-year period above — and is then removed from storage a short time afterward. It stops being served, so anyone who asks the Service for it, including someone holding a link they saved earlier, gets nothing back, from the moment the post or message is deleted, even while the underlying file is still briefly queued behind it. Which clock actually triggers that underlying removal depends on what the photograph or video was attached to. If it is a medical attachment, Section 14's period for health information applies from whichever of that section's two triggers happens first. If it is a photograph or video published on a post recorded about one specific Student, such as a Student Narrative, removal is triggered on the same five-year Student-records period Section 14 sets, once that Student leaves the Organization, even if nobody deletes the post directly. Otherwise, meaning any photograph or video attached to an ordinary message or a classroom-wide post that names no single child, removal is triggered whenever the message or post itself is deleted, or, at the latest, once the two-year message period above is reached.

Taken together, across most of the Service, delete means stops being shown and stops being served rather than erased from storage at that instant. Some things genuinely are erased on their own schedule: the connection to a Google or Apple sign-in when an Account is closed; health and wellbeing records at the end of the period that follows a withdrawal of consent; the content of the copies of an entry about a child's health or wellbeing that were fanned out to a Parent's feed, destroyed as soon as that consent is withdrawn; a photograph or video published on a post about one specific Student, once that Student's five-year period ends; and, as the two paragraphs above describe, the words in a self-deleted message, once its accountability period ends, and any photograph or video attached to a message or an ordinary classroom-wide post, once the message or post it is attached to is deleted or the two-year message period is reached, whichever happens first. We are saying this plainly rather than using the word delete and letting it carry a meaning it does not have here.

Whether making Content unreachable in this way is enough to answer a formal erasure request, or whether the underlying record and file must actually be destroyed, depends on whether a specific, defensible purpose survives the request, not on the fact of masking by itself. A moderator's redaction record is the clear case where one does, and the fourteen-day period, extended for as long as an open safety review takes, that we hold an ordinary self-deleted message's original text for is built on the same ground. GDPR Article 17(3)(e) lets us keep information a Data Subject asks us to erase where we need it to establish, exercise, or defend a legal claim, which is exactly what a safety report depends on once a message has been flagged, masked, or deleted by a moderator. KVKK reaches the same place through Article 5(2)(e), which permits processing that is necessary for the establishment, exercise, or protection of a right: ordinary message content, unlike the special category health information Section 14 discusses, is not confined to the narrower list KVKK Article 6 sets for special category data, so this broader ground is genuinely available here. Either basis carries the record only for as long as the purpose does, which is why a redacted message's original text is held on the same two-year schedule Section 14 sets for messages generally, and why an ordinary self-deleted message's text is held no longer than the fourteen days above unless a safety review is genuinely still open, rather than either being held indefinitely.

When we do rely on a lawful basis to keep something a Data Subject has asked us to erase, we tell them that plainly rather than describing it as erased. A masked record that we hold under GDPR Article 17(3) or KVKK Article 5(2)(e), or a self-deleted message's text still inside its accountability period, is a retained record, and our response to a request about it says so, together with the basis and the period it is held for. We can act, by hand, on a request that asks us to remove something earlier than its own schedule would otherwise reach it, but only once the reason it is still being kept has ended: the Account has been closed, the Student has left the Organization, or, for health and wellbeing records, the Parent has withdrawn consent. While an Account is open or a Student is enrolled, the information is still in use, so we decline and say why, and where the record is a child's, the decision is the Organization's, as Section 16 explains.

In short: closing an account switches it off rather than wiping it, and it is not the same as asking us to erase your information, which Section 16 covers. A child who leaves a school still has a record with us for five years, and the school keeps its own records about that child whether or not you still hold an account. A school that stops paying is suspended, not erased. When you delete your own message, it stops being shown to anyone straight away, and the words themselves are destroyed after fourteen days unless an open safety review needs them a little longer, in which case they are destroyed once that review concludes. A photograph or video is handled on its own, faster clock: it stops being served the moment the message or post it is on is deleted, and the stored file itself follows shortly after, or, for a photograph on a post about one specific Student, on that Student's five-year period if nobody deletes the post directly. A message a moderator redacts or deletes keeps its original text for two years, on the same basis, so a safety report can still be reviewed. We never call any of this erased when it is only retained, and we tell you which basis applies when you ask. We would rather tell you that than use the word delete and let it mean more than it does.

16. Your rights and how to exercise them

You have rights over the Personal Information we hold about you. In Turkey these rights are set out in Article 11 of the Personal Data Protection Law, which this policy calls KVKK, and for people in the European Union and the United Kingdom they are set out in the General Data Protection Regulation. We apply the same set of rights to everyone the Service touches, wherever you are, rather than offering different rights in different countries. Section 3 determines who you ask, because a right is exercised against whoever decides why and how the information is processed.

Access. You may ask whether we hold Personal Information about you, and receive a copy of it, together with the purposes it is used for, the categories of recipients it has been shared with, and how long it is kept.
Correction. You may ask that information about you which is inaccurate or incomplete be corrected or completed.
Deletion. You may ask that information about you be erased where there is no lawful reason for it to be kept.
Restriction. You may ask that we stop using information about you, while continuing to store it, for as long as a dispute about its accuracy or the lawfulness of its use is being resolved.
Objection. You may object to information about you being processed, including profiling, and you may object to a result reached by analysing your information exclusively by automated means where that result works to your detriment.
Portability. You may ask to receive the information you gave us in a structured, commonly used, machine-readable format, and to have it sent directly to another provider where that is technically possible.
Withdrawal of consent. Where processing rests on your consent, you may withdraw that consent at any time. Withdrawal stops the processing it covered from that point on; it does not make unlawful what was lawfully done before you withdrew.
Notification of third parties. You may ask that a correction or an erasure we make is notified to anyone the information had been transferred to.
Compensation. You may claim compensation for damage caused to you by unlawful processing.

Some of these you exercise yourself, without asking anyone. You can correct your own first, middle and last name, your telephone number, your preferred language and your preferred time zone from your profile in the Service, at any time and as often as you need. Changing the email address on your Account is a separate step rather than an ordinary profile edit, because a new address has to be verified before it replaces the old one. Which notifications you receive, and on which channel, is set in your own notification preferences; Section 17 explains what those preferences cover, including the small set of security and billing messages that reaches you regardless of them.

You cannot edit anything on your child's record yourself. A Parent's access to a child's record in the Service is read-only: enrollment details, date of birth, classroom, attendance, meals, sleep, measurements, medical and wellbeing entries and everything else on that record are written by Staff, who correct them through the Service. An entry the Service keeps as an append-only history, such as a pickup request or a note on one, is corrected by adding a correcting entry, or by cancelling it and entering it again. This is a deliberate consequence of Section 3, not an oversight. So a correction to your child's record is asked of your child's school, and the school makes it. If you have asked and the correction has not been made, write to us at the address in Section 21. We will raise it with the Organization and tell you that we have, but the decision remains the school's, because the school is the Controller for that information.

A Student never holds an Account, and the Service applies no age check to anyone, because everyone who signs in is an adult. In practice this means the rights listed above, as they concern a child, are exercised by that child's Parent, against that child's Organization.

A record about a Student is kept after that Student leaves a school, so a person who was once a Student can reach adulthood and make a request in their own name about a record their former Organization still holds. We do not name a single age at which that becomes possible, and that omission is deliberate rather than an unanswered question. Neither of the two legal frameworks this section already names ties the right to exercise these rights personally to a birthday. Turkish law treats a personal data right as strictly personal, one a minor may exercise without a legal representative once that minor has the capacity to understand what exercising it means, a case-by-case standard rather than a fixed age. Practice under the General Data Protection Regulation works the same way: the one fixed age it sets, sixteen, governs a child's own consent to an information society service, a different question from this one, and exercising an existing right personally is instead assessed, where it has been addressed at all, on that same understanding-based standard. We apply that standard here, in every market this policy covers, including where local guidance on this specific point has not yet been published, rather than inventing a number no framework we operate under actually uses. In practice this means a person who was once a Student, and who contacts us directly asking to exercise a right in their own name, is treated as doing exactly that, verified the same way any request under this section is verified, without our first asking whether they have reached a particular age. A Parent's authority to act for a child was always a stand in for a child who could not yet act personally, and it recedes on its own once the person it stood in for is the one asking us directly, rather than at a stated cutoff we would have to get right in every market at once.

A request to us is made in writing, at the address in Section 21. The Service does not include a screen that assembles your information and exports it for you, so a request of this kind reaches a person and is answered by a person. Say what you are asking for and, if you are a Parent asking about a child, say which child. We also keep an audit record of actions taken within the Service. Where we are the Controller, which for this purpose means actions taken on your own Account, we will tell you what that record shows when you ask. Where the record concerns your child, it belongs to your child's Organization along with the rest of that child's record, so a request to see it follows the same route as any other request about a child. Either way, the record captures actions taken on information rather than every occasion on which someone looked at it, so it is not a complete history of who has seen what.

Before we act on a request we confirm that it comes from the person it claims to come from. For a User, we do that through the email address registered to your Account. Where a request concerns a child, or health information, or anything else where getting this wrong would disclose one person's information to another, we may ask for more before we act. We ask only for what we need in order to be satisfied, and we use it only for that purpose. If we cannot satisfy ourselves that a request is genuinely yours, we refuse it and tell you why, because the alternative is handing a child's information to a stranger.

We answer a verified request within thirty days of receiving it, and we do not charge you for it. If a request is complex enough that we cannot complete it in that time, we will tell you within those thirty days what we are doing, what remains, and when you can expect the rest.

Where a request concerns your child's record, the thirty day period above is not what governs us. We are not the party the law makes responsible for answering it: your child's Organization is the Controller for that record, and our own role, both under GDPR Article 28(3)(e) and under the equivalent split KVKK draws between a controller and a processor, is to assist your child's Organization in answering it, not to answer it ourselves. So we do not act on a request like that. We forward it to your child's Organization instead, and we do not leave when that happens to our own convenience: we forward it within five business days of receiving it, so the gap before your child's Organization's own thirty day period begins is a short and stated one, not an open one. From the moment your child's Organization has the request, the thirty days runs against it, because it is the party that decides what happens to the information you are asking about, and we tell you when we have forwarded your request so you know who the clock is running against.

Some information cannot be erased on request, and we would rather tell you that here than in a refusal letter. The audit record of actions taken within the Service is kept on the fixed schedules described in Section 14 and is not deleted at a Data Subject's request, because it is the record that allows us, and your Organization, to show what was done with a child's information. A record of a consent decision is kept for the same reason: it is the evidence of what you decided and when, so erasing it would remove the proof that your decision was respected. Content you have already shared with someone else through the ordinary operation of the Service, such as a message already sent, exists in that person's copy of the conversation as well as yours, as Section 9 of the Terms of Service describes. And closing your own Account does not remove your child's record, which belongs to the school's relationship with us and not to yours; Section 16 of the Terms of Service and Section 14 of this policy describe what happens to each.

Consent is the one right in the list that operates instantly and by itself. Where you have given consent for your child's health or wellbeing information to be processed, you may withdraw it at any time, directly in the Service, without writing to us and without giving a reason. Withdrawal stops that processing and closes off Staff access to the information it covered, and Section 14 describes what then happens to the records themselves. Your child's Organization cannot give that consent for you, and cannot reverse a decision you have made, as Section 13 of the Terms of Service states.

No decision that affects you or your child is taken by automated means alone. Automated checks on message text produce a result for a person to review rather than blocking, hiding or deleting anything by themselves. AI-drafted narratives about a child are published only after a member of Staff has reviewed and approved them. The engagement and attendance analyses described in this policy produce findings that Staff can read and act on, and nothing in the Service changes a Parent's or a Student's record because one of those findings appeared. If you nevertheless object to being analysed in this way, say so in a request to us at the address in Section 21.

If you are a Visitor, your rights are the same, and they are simpler to exercise because there is no Organization involved and nothing about a child in what we hold. We are the Controller for it, Section 19 describes what a visit to okuldas.com or getedelio.com and a demo request leave with us, and a request goes to us directly at the address in Section 21. Send it from the email address you used on the form, because with no Account to check a request against, that address is how we confirm the request is yours.

If you are recorded in the Service as a Pickup Collector, you hold no Account, and the Organization that recorded you is the Controller for that record. You may still write to us at the address in Section 21. We will pass your request to that Organization and tell you that we have done so, on the same basis as any other request about information a school controls.

In short: you can see, correct, delete, restrict, object to, take a copy of, and withdraw your consent to the information we hold about you. Your own profile details you can fix yourself in the app. Anything on your child's record is written by the school, so a correction to it is asked of the school first, until your child is the one asking us directly, which we do not gate on a stated age. Everything else is a request in writing to the address in Section 21: we check that it is really you, we answer within thirty days, and we do not charge for it. A request about your child's record is answered by your child's Organization, not us, and we forward it within five business days so its own thirty days starts promptly rather than not at all. A few things we will not delete, and we have said which and why rather than surprising you with it later.

17. Messages and notifications we send you

We reach you through three channels: email, a push notification to the Edelio mobile application, and an in-app notification inside the Service itself. We do not send messages by SMS or any other text-message channel; that channel does not exist in Edelio today.

We do not operate a marketing email list, a newsletter, or any mechanism for sending you a promotional email unrelated to your Account, your Organization, or something that happened inside the Service. This is not a channel we have chosen to keep off by default. It does not exist in our systems at all. There is no list you are signed up for and no unsubscribe link to look for, because there is nothing of that kind to opt out of.

On our servers, notification preferences are organized into four categories, and for each category you can, in principle, turn each of three channels, email, push, and in-app, on or off separately. The four categories are:

auth, covering account security notices
billing, covering your Organization's subscription and payment status
appointments, covering appointment-related notices
system, a broad catch-all covering everything else, including a new chat message, a pickup-related notice, a measurement being recorded, an export finishing or failing, a calendar responsibility being assigned to you, and any AI-generated content notice

Because system is a single broad category, you cannot opt out of chat notifications specifically while keeping other system notifications on, or the reverse. Neither our web application nor our mobile application currently gives you a screen to view or change any of these preferences yourself. The settings exist on our servers, but there is no page in the Service today where you can reach them.

A fixed set of messages is always delivered to you regardless of any preference, because withholding them could leave your Account exposed or your Organization unable to operate. These are:

notice that your password has been changed
a password reset request
a request to verify your email address
a request to change your email address
confirmation that your email address has been changed
notice that your Organization's subscription has lapsed
notice that additional seats have become available on your Organization's Subscription
a payment request for expanding the number of seats on your Organization's Subscription

Some messages reach a person before they hold an Account at all, and for that person there is no preference to set, because there is no Account to attach one to. This includes an invitation sent to a prospective Staff member, an invitation sent to a prospective Parent, an invitation sent to a prospective Organization owner, and notice that an invoice is ready. Each of these is sent by email, since there is no device registered for a push notification and no Account to hold an in-app notification.

A push notification about a new chat message never contains the text of that message. It shows only the name of the person who sent it, or a group description where more than two people are in the conversation, and a fixed, generic line telling you a message has arrived. You see the actual content only after you open the Service. We do this deliberately, in part because messages are checked by an automated safety system after they are sent, as Section 19 of our Terms of Service describes, and showing message content in a push notification before that check has run would work against the purpose of that check.

In short: we reach you by email, push notification, and notices inside the Service itself, never by text message, and we have no newsletter or marketing email list of any kind, nothing to sign up for and nothing to unsubscribe from. Notification preferences exist on our servers in four broad categories, but there is no page in the app today where you can actually view or change them. A short list of account and billing messages always reaches you no matter what your preferences say, and the same is true of the invitations we send someone who does not yet have an Account. A push notification about a new chat message tells you only that a message arrived, never what it says.

18. How we protect information

Section 8 of our Terms of Service points here for the detail on how information is handled, and that includes how it is protected. This section describes the specific measures that are in place today and, in the same plain terms, the ones that are not. A general assurance that we follow industry standards would tell you nothing you could check.

The measures described in this section apply to the Service. Section 19 describes information submitted through our websites, okuldas.com, getedelio.com, blog.okuldas.com, and blog.getedelio.com, which is handled separately.

The following measures are in place:

Passwords are never stored in a form anyone can read. Every password is hashed with bcrypt at a cost factor of twelve. Every password you set yourself, whether you are accepting an invitation, choosing one for the first time, or resetting a forgotten one, must be at least twelve characters long and must include an upper-case letter, a digit, and a special character.
The token that keeps you signed in is signed with an asymmetric algorithm, RS256, so the key that creates a token is not the key that checks it, and the check rejects any token presented under a different algorithm. A signed-in session lasts twenty-four hours by default.
Every other token the Service issues, including refresh tokens, password-reset links, and invitation links, is generated from a cryptographically secure random source at 256 bits and is stored only as a SHA-256 hash, so the stored value cannot be turned back into a working token. Default lifetimes are thirty days for a refresh token, one hour for a password reset, and seven days for a Staff invitation.
Refresh tokens rotate each time they are used, and a token that has already been used once is rejected rather than honored, which is how the reuse of a stolen token is detected.
Repeated failed sign-in attempts lock an account temporarily, beginning after five failures in a short period, and requests to the Service are rate limited, with tighter limits on sign-in, password-reset, and token-refresh requests than elsewhere.
What a person can see is checked in two places rather than one. Our gateway first checks that the role held by the person making a request carries the permission for that request at all. The individual service holding the data then checks the same grant again, independently, and resolves how far that person's access reaches, whether to one individual, a classroom, a Branch, or a whole Organization, filtering the records returned to that breadth. Where the breadth cannot be resolved, the request is refused rather than allowed. Roles held by our own staff are the exception: a role marked internal resolves to a breadth that is not confined to one Organization, and a request made under such a role names the Organization whose records it reaches.
Every photograph, video, and document is stored under a name we generate at random, never the name of the file as it was uploaded, inside a private cloud storage location that cannot be reached directly by its address. The only way to view one is a link we build at the moment it is requested, signed so it cannot be altered, and set to expire on its own: a fixed five minutes for a medical document or an attachment on an announcement, no less than fifteen and no more than thirty minutes for a Student's own photograph or a person's avatar, and no less than one hour and no more than two for a photograph or video shared in a chat or class feed, a chat's own picture, or a branding image such as an Organization's, Branch's, Classroom's, or term's logo. We never keep a working link for later reuse; each request mints a fresh one.
Retrieving a photograph, video, or document is checked the same way described above, against that one file specifically. A Student's photograph, a medical document about a Student, and a photograph or video posted to a class feed can only be retrieved by a Staff member whose checked access actually reaches that Student's classroom or Branch, with the same exception described above for a role marked internal. An attachment on an announcement can only be retrieved by someone within that announcement's own intended audience. A photograph or video shared in a chat is different: it can only be retrieved by someone actually taking part in that conversation, and the exception for a role marked internal does not reach here. The one way a Staff member who is not part of a conversation can see it is the supervision setting described elsewhere in this policy, which your Organization must specifically turn on, and which our own platform administrators can never enable or use themselves.
The tokens we hold from Google or Apple, when you sign in through one of them, are encrypted individually before they are stored. They are the only information anywhere in the Service that is encrypted individually at rest.

The following are not in place. We would rather state them than allow the list above to suggest otherwise:

There is no multi-factor authentication anywhere in the Service, for any role, including our own platform administrators. A password, or a sign-in through Google or Apple where that is used, is the only thing standing between an Account and what it can reach.
Apart from the Google and Apple tokens described above, no stored information is encrypted at the level of the individual field. Health and medical information, wellbeing records, and every other category of Personal Information are stored without encryption of their own, and are protected instead by the access controls described above.
Encryption is not enforced on the connections between the internal components that make up the Service.
There is no written breach-response process. No runbook, no documented notification path, and no defined escalation exists today.
We hold no security certification. There is no SOC 2 report, no ISO 27001 certification, and no independent penetration test of the Service.

The obligations that data protection law places on us if Personal Information is exposed apply whether or not we have written a process for meeting them. Turkish and European data protection law require notification to the competent supervisory authority and, in defined circumstances, to the people affected, and those obligations bind us as they stand.

Neither GDPR nor KVKK conditions the lawfulness of publishing an accurate privacy notice on a security posture being adequate first. The duty to inform, GDPR Articles 13 and 14 and KVKK Article 10, is a freestanding obligation that falls due at or before the point Personal Information is first collected, a point that has already passed for the Service this document describes, and it carries no exception for how complete an organization's security measures happen to be. The duty to secure information, GDPR Article 32 and KVKK Article 12, is a separate obligation, addressed by what this section actually describes and by what it plainly says is missing. Holding this document back until every gap above is closed does not lower the risk the paragraph above weighs. It trades a specific, contestable question about whether a particular security measure was adequate, for an unconditional, continuing failure to provide any privacy notice at all, which is not the more defensible position under either framework, and is the clearer violation of the two. The breach response process named as missing above is not a precondition of this section either: the obligation to have one, and to notify within the periods GDPR Article 33 and KVKK Article 12(5) set once a breach actually happens, exists independently of whether this document is published, and closing that gap is tracked as its own priority, not as a condition on this section.

In short: your password is stored only as a hash and never in a readable form, the tokens that keep you signed in are cryptographically signed, the long-lived one is stored only as a hash and is replaced each time it is used, and what each person is allowed to see is checked twice, by two separate parts of the system. Our own staff hold roles that can reach across Organizations. A photograph, video, or document is stored under a random name in a private location no one can reach directly, and viewing one always goes through a signed link that expires on its own, from as little as five minutes for a medical document up to about two hours for a branding image, minted fresh each time and never reused. Whether that link is handed out at all is checked against the same access rules as everything else in the Service, with one deliberate exception: a chat photo or video is only ever available to someone actually in that conversation, or to a Staff member your Organization has specifically turned supervision on for, a capability we have built so that even our own platform administrators cannot switch it on or use it. There are real gaps as well, and you should know about them. There is no two-step verification available anywhere. Your child's health records are stored without encryption of their own and are protected by access controls instead. The internal connections inside the Service are not required to be encrypted. We have no written process for what happens if information is exposed, and we hold no security certification. We say this here rather than wait until our security measures are further along, because the law that requires us to tell you what we do with your information does not wait for that either.

19. Our websites: cookies, analytics, and demo requests

This section is about our four public websites: our two marketing websites, okuldas.com and getedelio.com, and our blog, published separately at blog.okuldas.com and blog.getedelio.com. It is not about the Service, which the rest of this policy covers. If you are reading one of these websites without being logged in, you are a Visitor: you hold no Account, no Organization is involved, and nothing described here concerns a Student. As Section 3 explains, Edelio is the Controller for everything in this section, and there is no school on the other side of it. The two marketing websites are the same site built twice, once under each brand name, so everything said about them below applies identically to both. Our blog is a separate codebase that shares some, but not all, of what is described below; where something applies to only our marketing websites or only our blog, this section says so.

None of these four websites keeps a session on our servers. All are served as static pages, and the only cookies any of them sets of its own are set by the page in your browser. Every one of them, including our blog, sets the same four cookies:

edl_cookie_consent records the cookie choice you made, as whether you agreed to analytics, with the necessary category always on. It lasts for 365 days. It is strictly necessary, because it is the only record we hold of your own decision. It is set at the top level of the brand's domain, so that your choice can be read by the other sites we run on that same domain instead of each of them asking you again.
edl_theme remembers the appearance you chose for the site: light, dark, or system, where system means the site follows the light or dark setting of your device. It holds only one of those three words. It is written the first time you open a page, before you have chosen anything, with the value system, and it changes only when you pick a different appearance from the selector in the page header. It lasts for 365 days from the last time it was written. It is strictly necessary, because it is how the site keeps the appearance you asked for as you move between pages. Like the consent cookie, it is set at the top level of the brand's domain, so that your choice carries over between our marketing website and our blog.
edl_locale remembers the language you chose for the site, as the two-letter code of one of the languages we publish in. It holds only that code. It is written the first time you open a page, before you have chosen anything, with the language of that page, and it changes only when you pick a different language yourself, from the language selector in the page header or, on our blog, from the list of other languages an article is available in. Opening a link into a page in another language does not change it. It lasts for 365 days from the last time it was written. It is strictly necessary, because it is how the site keeps the language you asked for when you come back or move between our marketing website and our blog. We use it in two places only: when you open an address on our marketing website that does not name a language, such as the bare domain, we send you to your remembered language instead of the default one, and when you follow an address on our blog that does not exist, we take you to the blog's home page in your remembered language. An address that names a language always shows that language. Like the consent cookie, it is set at the top level of the brand's domain, so that your choice carries over between our marketing website and our blog.
edl_internal_visitor marks a browser as ours rather than yours. It is written only when a browser arrives through a particular internal link that we use to keep our own testing out of our analytics. It lasts for 365 days and is treated as an analytics cookie.

That is the whole list. None of our websites, including our blog, sets any other cookie of its own. In particular, there is no advertising or marketing cookie, because no advertising technology of any kind runs on any of these four websites.

Other parties store things in your browser when you visit, and which ones depends on which site you are on. Our analytics provider, present on all four websites, keeps its own visitor identifier and a record of your opt-in or opt-out decision, under names derived from our analytics project, in browser storage and in a cookie of its own. Our bot-detection provider, present only on our two marketing websites as the spam check on our demo form, sets its own cookies when it loads there; our blog has no form and does not use this provider. We do not choose or control the names, contents, or durations of either provider's storage.

Our cookie banner is our own, not a vendor product, and the same banner, built the same way, runs on all four sites. It appears on your first visit, when no valid consent cookie is present, and it offers two categories: necessary, which is always on and cannot be switched off, and analytics. It has three buttons. Reject all and accept all look identical, so that refusing is as easy and as prominent as accepting, and manage preferences opens the category view, where you can choose analytics on its own. You can reopen that view at any time from the cookie preferences control in the footer. There is no marketing category, because no advertising, measurement, or remarketing technology runs on any of these four websites, and a choice that controlled nothing would only misdescribe what you were choosing.

We use one analytics provider, on all four websites. What it does is this:

Capture is switched off by default. The analytics code loads on every page of every one of these sites, but it is initialized in an opted-out state and sends nothing until you agree to analytics cookies. If you change your choice later, capture starts or stops from that point.
Once capture is on, page views and clicks are recorded automatically, alongside a small set of events we defined ourselves, which differ by site. On our marketing websites: a demo form was started, a demo form succeeded, a demo form failed, the page language was changed, and a cookie choice was given. On our blog: a category or tag filter was applied, an outbound link was clicked, the page language was changed, and a cookie choice was given. Every event, on every site, carries which brand and which of our properties, marketing website or blog, it came from, so the two are never mixed up inside this shared provider.
We do not tell our analytics provider your name or your email address, on an ordinary visit to any of these sites or when you submit the demo form, and no personal profile is created for you either way. The one event our server sends when the demo form is submitted is described below, and it too is sent only if you agreed to analytics cookies. Our blog has no such form and sends no such event.
Analytics requests do not go to our analytics provider's own address, on any of the four sites. They are each routed through a path on that site's own domain and forwarded from there, which means your IP address reaches our analytics provider through us, and a browser content blocker that blocks that provider's own address will not block these requests.
Session replay, which reconstructs a visit as a recording, is switched on, at a sample rate of one visit in five, and both the enablement and the sample rate are set in our analytics provider's own dashboard, for the one shared project all four sites report into, rather than in any site's own code. Where replay is switched on, it captures nothing until you have agreed to analytics cookies, for the same reason as everything else above. The text entered into a form field is masked in a recording. That is set explicitly in the initialization code of each of the four sites, rather than left to the analytics provider's own project setting, so it holds whatever that project setting is at any given moment. Your IP address is not stored with the recorded events: the analytics provider discards it on receipt, though it may first use it to work out an approximate location, which can be recorded with the event. That is a setting on the one shared project all four sites report into, held in the provider's own settings rather than in our code.
The analytics region is our provider's European Union region, for all four sites, since they report into the same shared project. Our own configuration files disagree with each other about this by continent, since one local development example file sets a United States value, but the production endpoint our code actually falls back to, and the one confirmed in our analytics provider's own project settings, is the European Union one.

Our bot-detection provider protects the demo form on our marketing websites from automated abuse. Our blog has no form and does not use this provider. The provider loads on the page whatever cookie choice you have made, because we treat it as strictly necessary to keep the form usable, and our banner says so. When you submit the form, the check sends a challenge token and your IP address to that provider for verification. It never receives what you typed into the form.

The demo request form exists only on our marketing websites, and it is the only form on either of them; our blog has no form of any kind. It shows four fields: your name, your school or institution, the number of students, and your work email address. It sends considerably more than that, and you should know what, because none of it is visible on the form:

Your IP address, the city, region, and country derived from it, and the code of the data center that served the request.
Your network's identifier and the organization that identifier is registered to.
The time zone our infrastructure provider associates with your connection, and the time zone reported by your browser.
Your browser's user agent string, up to four hundred characters, and the device, operating system, and browser we derive from it.
Your screen resolution and the size of your browser window.
The language version of the page, the address of the page, and the address of the page that referred you to it.
Five campaign parameters, where the link you arrived through carried them.
How many seconds you spent on the page before submitting, and an identifier for the submission itself.

All of that, together with the four fields you filled in, is sent to a single internal system we use for handling incoming leads. That system is the only place it is kept. There is no database and no customer relationship management system behind this form, and we hold no second copy. If delivery to that system fails, the submission fails and you are told so, rather than being accepted silently. A demo request is deleted from that system automatically two years after you submit it, by a retention setting applied to the one place your submission is delivered; that setting is held in the system provider's own settings rather than in our own code, and the deletion is permanent. If you want a demo request you submitted deleted, ask us and we will remove it. Section 16 explains how to make that request and what other rights you have over it.

One thing about that form is worth stating exactly. When a submission reaches our internal system, and only if you agreed to analytics cookies, we also send a single event to our analytics provider recording that a demo request completed. That event carries the analytics identifier your browser sent along with the submission, never your name, and the identifier ties the event to your earlier, previously anonymous browsing inside our analytics provider's own records. Because the same submission is what put your name in our internal system at essentially the same moment, anyone able to see both records could line them up, which is why the event is sent only with your agreement. If you refused analytics cookies, or have not made a choice, no event is sent and no identifier is created for one. Our server checks your choice from the consent cookie your browser sends with the submission. Our blog has no form and sends no such event.

Some things do not happen on any of these four websites at all, and we would rather say so than leave them to be assumed:

No advertising technology of any kind runs on any of them: no ad pixel, no tag manager, no remarketing or conversion tag, and no ad network.
No social media widget, share button, embedded video, embedded map, or chat widget is present on any of them today. Our blog's article template has a video-embed component available for its authors to use, but no published post uses it as of this draft; if one does, this section will need to describe that separately, since it loads a thumbnail image from a third-party address as soon as the page loads, before you have chosen anything about cookies.
The fonts are served from our own domain, so your browser makes no request to a font provider when you read a page, on any of the four sites.
We buy no information about you from a data broker, and we do not sell anything collected here.
We do not currently detect or act on the Do Not Track or Global Privacy Control signals a browser can send. The cookie banner is the only way to tell us your choice on these websites, and setting one of those browser signals will not change what is described above.

In short: this part covers our two marketing websites, okuldas.com and getedelio.com, and our blog, blog.okuldas.com and blog.getedelio.com. All four sites set the same four cookies, one to remember your cookie choice, one to remember whether you chose a light, dark, or system appearance, one to remember the language you chose, and one to mark our own test browsers, and none of them has an advertising cookie. We use one outside provider for analytics across all four sites, and it stays switched off until you agree, and that includes the demo form: on our marketing websites, one more event recording that a demo request completed is sent from our server only if you agreed to analytics, and nothing is sent if you refused. Our blog has no such form. Our banner offers reject all and accept all as identical buttons, so refusing is as easy as accepting. The demo form, which exists only on our marketing websites, sends far more than the four fields you can see, including your IP address, rough location, and device details, all of it into an internal system that is the only place we keep it. It is deleted from there automatically two years after you submit it, and if you ask us, we will delete yours sooner. There is no advertising on any of the four sites, nothing is sold, and the spam check on the demo form runs whatever you choose about cookies.

20. Changes to this policy

We may update this policy from time to time. Where we make a change, we will update the effective date shown at the top of this document, so the current version and the date it took effect are always visible there.

Where a change is material, meaning it meaningfully expands what we do with Personal Information already collected or meaningfully narrows the rights described in this policy, we will notify Users through the Service, through the notification channels described in Section 17, or by posting a notice on this page, before the change takes effect.

Section 8 of the Terms of Service already commits that we will not reduce the rights described in this policy for Personal Information already collected without your consent, except where the law requires it. The same commitment applies here: where we change this policy, the rights available to a Data Subject over information already collected will not be narrowed as a result, except to the extent a change in law requires it. Continuing to use the Service after a non-material change takes effect means you accept the updated policy. For a material change, Section 24 of the Terms of Service describes when we will ask you to accept the updated terms again before the change takes effect.

In short: when we change this policy, we update the date at the top so you can always see how current it is. If a change is significant, we will tell you before it applies. We will not take away your rights over information we already collected without your consent, unless a law forces that change. Continuing to use the Service after a minor change means you accept it, and for a significant change we may ask you to agree again.

21. How to contact us and how to complain

If you want to exercise any of the rights described in Section 16, or you have another question about how we handle Personal Information, contact us using the details below.

Questions and rights requests about Personal Information: support@okuldas.com
Concerns about the safety of a child, or another urgent safety matter: safety@okuldas.com
Our registered address: 8 The Green, Ste A, Dover, DE 19901, USA

If you are Staff or a Parent and your question concerns a Student, your Organization may also be able to help, particularly where the request concerns a decision the Organization itself made about that Student. Section 3 explains why the Organization, and not us, is the Controller for Student Data, and Section 26 of the Terms of Service explains how to obtain a copy of the agreement between us and your Organization.

You also have the right to complain to a supervisory authority, in addition to or instead of contacting us. If you are in Turkey, that authority is the Personal Data Protection Authority under KVKK, known in Turkish as the Kisisel Verileri Koruma Kurumu. This section does not currently name a supervisory authority for the European Union or the United Kingdom, because we do not yet operate there and have not identified which authority would apply.

The point at which we owe a formal representative under GDPR Article 27, and separately under the equivalent United Kingdom regime, since neither one satisfies the other, is fixed by law rather than by any looser sense of having entered a market. It is triggered once we offer the Service to an Organization, or to a Student, Staff member, or Parent, located in the European Union or the United Kingdom, regardless of whether payment changes hands. The exemption Article 27 itself allows, for processing that is occasional, does not include special category information, and is unlikely to carry a real risk to the people it concerns, will not be available to us once that trigger is met. Health and wellbeing information about a Student is exactly the kind of special category information that exemption excludes, and processing it for an enrolled school population is not occasional processing by its nature. So the point we owe a representative is the point our first Organization based in the European Union, and separately our first Organization based in the United Kingdom, is actually live on the Service, not a point requiring a fresh assessment each time it comes up. As of this draft that point has not been reached for either market. No Organization based in the European Union or the United Kingdom is using the Service today, the regional hosting Section 13 describes for the European Union remains a commitment rather than something built, and naming a representative or an authority now would name one we have not actually appointed or identified.

In short: email support@okuldas.com with questions or rights requests, and safety@okuldas.com if a child's safety is at stake. Our address is in Dover, Delaware. You can also complain to a data protection authority, which for Turkey is the Personal Data Protection Authority. This section does not yet name one for the European Union or the United Kingdom, because neither one has an Organization actually using the Service yet, the point at which naming a representative and an authority becomes owed rather than premature.