ParentsTeachersBlog
Log inCreate account
LARNES · legalAll documents
  1. 01Company details and contacts
  2. 02Terms of use
  3. 03Personal data processing policy
  4. 04Personal data processing consent
  5. 05Child data processing consent
  6. 06B2B SaaS offer and data processing instructions
  7. 07Public offer
  8. 08Payments, cancellation, and refunds
  9. 09Cookies and analytics
  10. 10Marketing communications consent
  11. 11Child safety rules
←All documents

Legal documents

Personal data processing policy

This Policy explains what personal data LARNES processes, for what purposes and on what grounds, who may access it, how long it is retained, and how an individual may exercise their rights. The Policy is not itself consent to data processing.

Status
Effective
Data controller
Индивидуальный предприниматель Бояркин Алексей Станиславович
Data subjects
Website and app visitors, account holders, parents and guardians, children, teachers, education organisation owners and staff, invitees, and CRM contacts.
Contents
  1. 01Scope and controller
  2. 02Processing principles
  3. 03Data subjects and sources
  4. 04Website, accounts, and security
  5. 05Family and child data
  6. 06Learning and classroom
  7. 07Teacher and organisation operations
  8. 08Requests, claims, and legal duties
  9. 09Special, biometric, and public data
  10. 10Legal grounds
  11. 11Operations and methods
  12. 12Processors and external services
  13. 13Localisation and cross-border transfers
  14. 14Retention, blocking, and destruction
  15. 15Individual rights and requests
  16. 16Security and incidents
  17. 17Cookies and analytics
  18. 18Contacts and Policy changes
01

Scope and controller

  1. This Policy is based on the Constitution of the Russian Federation, Federal Law No. 152-FZ of 27 July 2006 On Personal Data, and regulations adopted under it.

  2. It applies to the LARNES website, role-based workspaces, mobile interfaces, classroom/kiosk mode, public invitations, and Platform APIs.

  3. The platform owner identified on the Company details page is the controller for purposes it determines independently, including accounts, authentication, support, security, and LARNES operation.

  4. Where a school, centre, network, or independent teacher enters student, parent, staff, lead, contract, or payment records into its closed workspace, that person determines the purpose and legal ground. Roles are allocated by contract. Where the contract contains instructions under Article 6(3) of Law No. 152-FZ, LARNES processes data only within those instructions while remaining an independent controller for necessary security data.

  5. An organisation or teacher must not enter third-party personal data before the legally required contract or processing instructions are in place. They must give subjects their own processing information and obtain required consents. A person may contact either controller or LARNES; the request will be routed without unjustified delay.

02

Processing principles

  1. LARNES follows these principles:

    • lawful, fair, and transparent processing;
    • collection for specific, predetermined, and lawful purposes;
    • data scope proportionate to the stated purpose;
    • separation of data collected for incompatible purposes;
    • accuracy, adequacy, and currency;
    • retention no longer than required by purpose, contract, or law;
    • confidentiality and protection against unlawful or accidental access;
    • no disclosure to an unrestricted audience without a separate legal ground.
  2. Where a purpose can be achieved without identifying a person or with less information, LARNES uses a minimal or anonymised data set.

03

Data subjects and sources

  1. Data may come from the individual, their legal representative, another guardian, a teacher, authorised organisation staff, or an invitation sender.

  2. CRM data may come from an organisation's form, its staff, or an advertising service connected by the organisation owner.

  3. Technical data is generated automatically: IP address, request time and outcome, browser or device information, language, session and device identifiers, and security events.

  4. A user supplying another person's data confirms authority and must inform that person who processes the data, why, and how.

  5. Where LARNES obtains data from someone other than the subject and no Article 18(4) exception applies, before processing it informs the subject of the controller and address, purpose and ground, data scope, intended users, subject rights, and data source.

04

Website, accounts, and security

  1. Public website and language selection.

    • Subjects: website visitors.
    • Data: IP address, request date and time, requested URL, language, browser and device data, technical cookies.
    • Purpose: deliver the page, retain technical settings, diagnose errors, and protect the resource.
    • Ground: legitimate interest in secure operation without overriding visitor rights; separate consent for non-essential cookies.
    • Period: technical cookies until their stated expiry; ordinary raw server logs up to 30 days, with confirmed security incidents handled separately.
  2. Adult account registration and management.

    • Subjects: parents and guardians, teachers, organisation owners, staff, and administrators.
    • Data: account type, first and last name and patronymic if provided, date of birth and city where required for the selected role or entered voluntarily, phone, email or login, contact verification, network display name, language, password hash, creation date, and access status. When a city or address is chosen from autocomplete, the normalised place, provider identifier, and coordinates are also stored.
    • Purpose: create an account, provide the role workspace, maintain the profile, and perform the Terms.
    • Ground: Article 6(1)(5) of Federal Law No. 152-FZ only for data objectively needed to enter into or perform the Terms; Article 6(1)(1) separate consent for other data. Merely filling a field without a separate affirmative action is not consent.
    • Period: account lifetime and then the period needed for claims and law; data without another ground is destroyed within 30 days after the purpose ends.
  3. Contact verification, login, and recovery.

    • Data: phone or email, one-time code hash, channel and flow, attempts, IP address, device ID, masked contact, outcome, and denial reason.
    • Purpose: verify contact control and prevent code guessing, flooding, and account takeover.
    • Ground: steps to enter into or perform the agreement and legitimate security interests.
    • Period: a code usually lasts 10 minutes and is deleted no later than 24 hours after expiry; temporary registration or recovery verification lasts 30 minutes; routine auth events last 180 days.
  4. Sessions and abuse prevention.

    • Data: user ID, session version and expiry, selected workspace, device ID, IP address, login and access-change events.
    • Purpose: maintain authentication, terminate compromised sessions, rate-limit requests, and investigate incidents.
    • Period: a standard user session lasts up to 24 hours and may renew on activity; the SMS rate-limit device ID lasts up to one year; routine auth events last 180 days, while confirmed incident evidence lasts up to five years after closure or until legal hold is released.
05

Family and child data

  1. Creating and maintaining a child profile.

    • Subjects: the child and legal representatives.
    • Child data: first and last name, patronymic if provided, date of birth, gender, selected colour and preset character avatar, family links, profile status.
    • Representative data: account and family relationship; authority evidence if requested in a dispute.
    • Purpose: family workspace, child selection, and connection to a teacher or organisation.
    • Ground: separate legal-representative consent or another directly applicable legal ground; the Terms do not replace consent.
    • Period: until profile deletion, family relationship ending, or consent withdrawal, except the data needed to retain learning, contractual, or accounting history lawfully.
  2. Connecting guardians and educational workspaces.

    • Data: invitation sender and recipient, relationship type, child, teacher or organisation, token, status, and expiry.
    • Purpose: verify the parties' action and grant limited role-based access.
    • Ground: action and consent of authorised persons; legal-representative or education-controller ground for child data.
    • Period: until acceptance, decline, revocation, or expiry; a tutor-parent invitation usually lasts seven days, while a technical record may be retained for security and connection evidence.
  3. A user must not create a child profile without legal-representative authority or another lawful power. An authority dispute may result in temporary profile-access restriction during review.

  4. Archiving a child profile in the family workspace stops its display and new family operations but remains reversible. Legal erasure requires a separate request from a verified legal representative; data without an independent ground is erased, while mandatory learning, contract, accounting, and legal evidence is retained only in a minimized or anonymised form.

06

Learning and classroom

  1. Learning process management.

    • Subjects: children, parents, teachers, and organisation staff.
    • Data: enrolment, groups, directions and programmes, schedule, homework assignment, current step and completion status, programme position and status, lesson grades, attendance, and related timestamps. Individual task answers, errors, and hints are not currently stored persistently.
    • Purpose: assign work, show progress, and manage schedules, attendance, and results.
    • Ground: legal-representative consent for child data; school or teacher instructions based on their relationship with the family; the agreement for adult-user data.
    • Period: for B2C, three years after learning ends; for a school or network, its documented lawful instruction applies, with a three-year default where no other period is set.
  2. Classroom and QR sessions.

    • Data: child, device, classroom, lesson and temporary-session IDs, device command, activity time, attendance, and grade.
    • Purpose: connect the child securely to the current lesson without an adult account.
    • Period: child session up to 12 hours; classroom device registration up to one year or until unbound; learning results follow the educational workspace retention period.
  3. Child-safety concerns.

    • Data: source, category and urgency; related child, family, organisation, device, lesson, account or content; an adult reporter's short description; decisions, actions and assignee.
    • Purpose: assess risk, protect the child, restrict access or content, meet legal duties, and evidence the response.
    • Ground: protection of the child's life, health and lawful interests, operator duties, and legitimate service-security interests; the alleged person is not notified automatically.
    • Period: five years after closure or until legal hold release; pseudonymised classroom rate-limit events last 30 days.
  4. Automated assignment sequencing and progress views do not create legal consequences for a child and are not solely automated decisions about educational admission, rights, or duties.

07

Teacher and organisation operations

  1. Staff and work permissions.

    • Data: name, work contact or login, account type, organisation and branches, role, technical permissions, account creator, access status, and change dates.
    • Purpose: grant work access and terminate it on dismissal or authority revocation.
    • Ground: organisation instructions and its agreements with the staff member and LARNES; legitimate access-control interests.
    • Period: work-access lifetime and then the applicable claim or mandatory-retention period.
  2. Internal development and administration.

    • Data: task author and assignee, comment text, attached image, workflow event, and internal notification.
    • Purpose: develop, review, and release learning trainers and administer the Platform.
    • Ground and period: work relationship, agreement, and legitimate product-operation interest; data remains for the task lifecycle and necessary internal-audit period.
  3. CRM and enquiries.

    • Subjects: prospective and current organisation clients, parents, representatives, and children to the extent entered by the organisation.
    • Data: name, phone, email, lead name and source, child name, branch, status, owner, notes, activity history, and advertising-form identifiers.
    • Purpose: handle an enquiry and organise sales for a particular school, network, or teacher.
    • Ground and period: determined by the organisation as controller; LARNES acts on its instructions. If no other lawful period is set, a CRM contact is deleted one year after its last activity.
    • Source evidence: the organisation asserts an applicable ground and, where available, identifies a notice or supporting document; LARNES retains that assertion and minimal technical source and receipt-time data but does not attest that the subject consented or verify consent validity.
  4. CRM integration technical data.

    • Data: advertising account, form, channel, and inbound-event IDs, OAuth access/refresh tokens and other connection secrets, timestamps, delivery status, and minimal diagnostics without the full inbound payload.
    • Purpose: receive leads on the organisation owner's instruction, prevent duplicates, and diagnose delivery.
    • Ground and period: organisation instructions and integration settings; tokens are deleted after source disconnection or access revocation, and minimal inbound technical events after 30 days.
  5. Contracts and uploaded templates.

    • Data: DOCX template and fields, contract instance, parent and child details entered by the organisation, dates, and document status.
    • Purpose: prepare, populate, and retain an organisation's internal contract instance.
    • Ground and period: the organisation's agreement, law, and instructions; LARNES does not decide which fields are needed or sign for the parties.
  6. Lesson and payment accounting.

    • Data: child, parent or payer if entered, group, lesson, date, amount, accrual, correction, balance, and recording staff member.
    • Purpose: internal operational accounting for a school or teacher.
    • Note: LARNES receives no card details, processes no payment, and issues no fiscal receipt; records do not prove money movement.
    • Ground and period: determined by the organisation or teacher under their agreement and applicable accounting, tax, and other laws.
  7. Tasks, spreadsheets, CRM, rich text, and imported DOCX may contain arbitrary text, links, and images entered by an organisation. These fields are not intended for medical diagnoses, health data, political or religious beliefs, or other special-category data; the organisation must not enter excessive information.

08

Requests, claims, and legal duties

  1. When a person contacts LARNES, it processes their name, contact, account ID, correspondence, relevant technical details, and documents voluntarily attached only as needed to answer.

  2. Grounds are agreement performance, legal response duties, and protection of rights. The request is retained until resolution and through the applicable claim period, then destroyed or anonymised.

  3. Data may be processed to respond to Roskomnadzor, a court, law enforcement, or another authorised body. Only the scope required by a lawful request is disclosed.

09

Special, biometric, and public data

  1. LARNES does not request and is not intended to process health or diagnosis data, racial or ethnic origin, political, religious or philosophical beliefs, intimate-life data, or criminal records.

  2. The Platform does not collect biometric data for identification. A preset child character avatar is not a photograph or biometric template.

  3. The Platform has no dedicated user photo, video, or lesson-recording upload feature. Images and other information may occur in an organisation-imported DOCX, rich text, or free-text field; the user must not include excessive data. Internal help videos are uploaded only by an administrator and are not used to identify depicted persons.

  4. Accounts and child data are not public. Separate dissemination consent is required before public profiles, reviews, photographs, or achievements are introduced.

10

Legal grounds

  1. Depending on the purpose, LARNES relies on one or more grounds:

    • data-subject or legal-representative consent under Article 6(1)(1) of Law No. 152-FZ;
    • steps to enter into and perform an agreement with the individual under Article 6(1)(5);
    • performance of statutory duties under Article 6(1)(2);
    • controller or third-party legitimate interests without overriding subject rights under Article 6(1)(7);
    • another controller's instructions containing mandatory processing and security terms.
  2. Consent is requested separately where no other ground properly applies. Marketing, non-essential analytics, child data, and dissemination consent are not bundled with acceptance of the Terms.

  3. Withdrawing consent ends processing based only on that consent but does not cancel processing required or permitted by an agreement or law. The continuing ground is explained to the requester.

11

Operations and methods

  1. Processing is primarily automated: collection, recording, organisation, accumulation, storage, correction, retrieval, use, matching within one purpose, role-based access, processor transfer, blocking, deletion, destruction, and anonymisation.

  2. Some operations may be manual when reviewing a request, checking authority, importing a contract, or responding to an incident.

  3. Access is limited to users and staff who need it for their role. Technical visibility does not create lawful authority to use a record for another purpose.

  4. LARNES does not sell personal data, exchange it for advertising services, or disclose it to an unrestricted audience.

12

Processors and external services

  1. The primary infrastructure provider and the following services may access data only to the extent needed for an enabled function:

    • SMS.ru — delivers SMS verification codes and checks delivery cost; the phone number, message text, and, where needed for abuse prevention, IP address are transferred. Status: not used in production.
    • Resend — delivers service emails and verification codes; the email address and service message content are transferred. Status: not used in production.
    • Cloudflare Turnstile — protects registration, login, and recovery forms against automated attacks; when enabled, it receives a verification token, IP address, and browser or device signals. Status: not used in production.
    • VK Ads — is a CRM lead source enabled by an organisation owner; advertising account identifiers, connection tokens, and lead details supplied by VK Ads are processed. Status: not used in production.
    • Yandex Direct — is a CRM lead source enabled by an organisation owner; advertising account identifiers, OAuth tokens, and lead details supplied by Yandex Direct are processed. Status: not used in production.
    • Mapbox — searches and normalises city or address data in registration, profile, and center forms; autocomplete sends query text and IP address, and saving a selected place sends a place identifier to confirm coordinates; requests are made from LARNES servers and the access token is not exposed to the user. Status: enabled in production; Mapbox, Inc., 1133 15th Street NW, Washington, DC 20005, United States, United States; cross-border transfer: yes.
    • Mux — stores and plays internal help videos uploaded by an administrator; Mux Data tracking and Mux cookies are disabled in the player, and the service is not used to record lessons or accept child video uploads. Status: not used in production.
    • Telegram — optionally alerts the team about SMS spend and aggregate verification conversion; phone numbers, email addresses, and user correspondence are not transferred. Status: not used in production.
  2. Not every service is used for every user. CRM integrations are enabled by an organisation owner; SMS or email depends on the selected verification channel; internal help videos are available only after the video provider is separately enabled; Mapbox place search runs only when the user types into autocomplete.

  3. Each service card above states production status, the recipient's full legal name, address, country, and whether transfer is cross-border. Purpose, data categories, and processing terms follow this section, the Policy, and the recipient agreement.

  4. A processor must follow confidentiality, security, purpose, and retention instructions, assist with subject requests, and report incidents. A new processor is used only after the legal ground and documents are reviewed.

  5. Other users receive data only through a role relationship: a family guardian, connected teacher, authorised organisation staff member, or administrator with a lawful service task.

13

Localisation and cross-border transfers

  1. When Russian citizen data is collected online, databases outside Russia must not be used for its recording, organisation, accumulation, storage, correction, or retrieval except in cases expressly provided by law.

  2. The application runs on Timeweb VPS. The infrastructure-data recipient is ООО «ТаймВэб.Клауд», address: 196006, г. Санкт-Петербург, ул. Заставская, д. 22, корп. 2, лит. А, помещ. 303, data-centre country: Российская Федерация. The primary PostgreSQL 16 is located in Российская Федерация.

  3. If an external service causes a cross-border transfer, LARNES first identifies the country and recipient, assesses protection and termination terms, obtains required information, and submits the separate Article 12 notice.

  4. Production personal data uses only integrations with confirmed localisation, legal ground, contractual terms, and mandatory notices.

14

Retention, blocking, and destruction

  1. Each purpose has its own period ending when the purpose is achieved, an agreement ends, consent is withdrawn, or a lawful request is received unless law requires continued processing.

  2. After a purpose ends, data is destroyed or anonymised within 30 days unless another period follows from law, an agreement with the subject, or another applicable ground.

  3. Data based only on consent is destroyed within 30 days after withdrawal. A processing-stop request is performed within 10 business days, extendable by no more than five business days with a reasoned notice.

  4. Inaccurate data is blocked during review and corrected within seven business days after evidence is supplied. Confirmed unlawfully obtained or unnecessary data is destroyed within seven business days.

  5. Unlawful processing is stopped within three business days after discovery. If it cannot be made lawful, the data is destroyed within 10 business days; the subject and, where applicable, Roskomnadzor are informed of the result.

  6. If immediate destruction is technically impossible, data is blocked and destroyed within six months unless law sets another period. Destruction is documented as required by Roskomnadzor.

  7. A local PostgreSQL pg_dump backup is created daily on the production VPS and deleted after 14 days. Restored data remains subject to current deletion requirements.

15

Individual rights and requests

  1. A data subject or legal representative may:

    • learn whether data is processed and obtain the purposes, grounds, sources, scope, periods, and recipients;
    • obtain cross-border transfer details, the instructed processor's name and address, and implemented protection requirements;
    • access data in an understandable form without disclosing another person's data;
    • request correction, blocking, processing termination, or destruction;
    • withdraw consent and opt out of marketing or non-essential cookies;
    • object to a solely automated decision creating legal consequences;
    • complain to Roskomnadzor or a court and seek protection of their rights.
  2. A request may be registered through /legal/data-request or sent to the personal-data address on the Company details page. It receives a reference number and reply deadline. LARNES separately verifies identity and, for child data, representative authority; excessive passport data should not be sent in advance.

  3. A response about data processing is provided within 10 business days in the request's form unless another form is requested. It may be extended by no more than five business days with a reasoned notice.

  4. For data in a school or teacher workspace, LARNES may route the request to that controller and help perform its instructions. This does not limit access to data for which LARNES itself is controller.

16

Security and incidents

  1. LARNES uses proportionate legal, organisational, and technical controls: role and tenant isolation, contact verification, password and one-time-code hashing, signed HTTP-only sessions, rate limiting, masked contacts in technical logs, secret management, and session revocation.

  2. Implemented technical controls are supplemented by the controller's local acts covering the responsible person, threat model, harm assessment, access, backup, incident response, internal review, and destruction evidence. The controls are refined after production-infrastructure assessment.

  3. Absolute security is impossible, but this does not release the controller from the duties in Articles 18.1 and 19 of Law No. 152-FZ or responsibility for its own violations.

  4. After an unlawful or accidental disclosure affecting subject rights, LARNES blocks affected processing, investigates, and notifies Roskomnadzor: an initial notice within 24 hours and investigation results within 72 hours.

17

Cookies and analytics

  1. The Platform uses essential cookies for sessions, contact verification, account recovery, workspace selection, classroom devices, SMS protection, and organisation OAuth connections.

  2. Essential cookies support a requested function and security. Disabling them may prevent login, registration, classroom, or integration use.

  3. Third-party visit analytics and advertising cookies are not used in the current configuration on public LARNES pages. If internal help videos through Mux are enabled, opening a video will send delivery requests including playback ID and IP; Mux Data tracking and Mux cookies are disabled in the player.

  4. If non-essential analytics or advertising cookies are introduced, they must not run before the user's separate choice. The exact list, providers, and periods are published in Cookies and analytics.

18

Contacts and Policy changes

  1. The current version is continuously available under Legal information. Its version and effective date are stated, and previous versions remain archived.

  2. Material changes to purposes, data, recipients, or cross-border transfers are published before new processing begins. Where consent is required, it is requested separately; silence is not consent.

  3. Controller contacts and a dedicated personal-data address are published on the Company details page. A legally significant request may also be sent to the postal address stated there.

  4. If the Russian and English versions differ in relations governed by Russian law, the Russian version prevails. In this translation, controller and processor mean the operator and the person processing on the operator's instructions under Law No. 152-FZ.

Related documents
Company details and contacts↗Personal data processing consent↗Child data processing consent↗