GDPR и персональные данные учащихся: что важно знать школам и администраторам ENT

Когда я начинала работать с цифровыми средами в школах, типичный разговор о данных звучал так: «У нас всё в Excel, кому это нужно». Сегодня тот же самый учитель за день создаёт десятки цифровых следов — выставляет оценки в электронный журнал, пишет комментарий в чате, загружает презентацию в облако, отмечает отсутствующих. И каждая такая операция — это обработка персональных данных. Не абстрактных «сведений об ученике», а конкретной информации, которая может повлиять на реального ребёнка и его семью.

GDPR перестал быть юридической абстракцией в тот момент, когда школы начали массово использовать облачные платформы, видеоконференции и учебную аналитику. Теперь это практическая рамка, без которой невозможно построить безопасную цифровую среду. И администратор ENT здесь — ключевая фигура: именно он настраивает доступы, управляет интеграциями и решает, какие данные вообще попадают в систему.

Что считается персональными данными учащихся

Определение из регламента звучит широко, и это не случайно: персональные данные — любая информация, которая позволяет идентифицировать человека прямо или косвенно. В школьной практике это означает, что защищать нужно не только очевидные поля вроде фамилии и адреса, но и комбинации данных, которые по отдельности кажутся безобидными.

Вот что попадает в эту категорию в типичной школе:

• имя и фамилия;
• адрес и контактные данные;
• класс, номер учащегося, логин в системе;
• оценки и отчёты об успеваемости;
• записи о дисциплине и посещаемости;
• фото, видео, аудиозаписи;
• медицинские сведения, включая информацию об аллергиях;
• данные о питании, если они могут косвенно указывать на религиозные убеждения или состояние здоровья;
• биометрические данные — отпечатки пальцев, распознавание лица.

На практике я не раз сталкивалась с ситуацией, когда школа искренне считала: «У нас нет чувствительных данных, только журнал и расписание». А потом выяснялось, что в том же журнале есть пометки об освобождении от физкультуры, которые прямо указывают на медицинский диагноз. Или что система питания фиксирует выбор постного меню, что косвенно говорит о религиозных предпочтениях семьи. Цифровая среда не делает такие данные менее чувствительными — наоборот, она делает их доступнее для accidental disclosure, если не настроены права.

Почему тема GDPR критична именно для школ и ENT

ENT и облачные платформы проектировались ради удобства: единое окно для расписания, заданий, общения и отчётности. Но архитектура, которая объединяет всё в одной среде, автоматически повышает цену ошибки. Один неверно настроенный доступ — и человек видит не только оценки, но и медицинские пометки, переписку с родителями, историю посещаемости за несколько лет.

За годы внедрения я наблюдала повторяющиеся проблемы, которые возникают независимо от конкретной платформы:

• права доступа к классам и документам настроены шире, чем необходимо — например, все учителя параллели видят данные всех учеников, а не только своих;
• родители случайно получают доступ к информации о чужих детях через общие таблицы или открытые ссылки;
• данные выгружаются в сторонний сервис для аналитики или дополнительных занятий без проверки правовых оснований;
• школа хранит информацию выпускников годами просто потому, что «никто не сказал удалить»;
• фото с уроков, геолокация в учебных приложениях, биометрические отметки внедряются без отдельной оценки рисков;
• педагоги не имеют чётких инструкций — что можно публиковать в общем доступе, а что должно оставаться внутри защищённого контура.

Самое неприятное, что большинство таких инцидентов — не результат злого умысла, а следствие отсутствия понятных правил и регулярного аудита. Когда я проводила тренинги для администраторов, типичный инсайт звучал так: «Я думал, что настроил роли правильно, но не проверял их уже полтора года».

Основные принципы GDPR, которые нужно держать в голове

Юридический текст регламента читать непросто, но для практической работы достаточно держать в уме семь принципов. Они работают как чек-лист при любом решении: внедряем новый сервис, настраиваем интеграцию, даём доступ практиканту.

Когда я помогала школам переходить с бумажных журналов на ENT, принцип минимизации данных был самым трудным для принятия. Учителя привыкли записывать любые пометки «на полях», а администраторы — собирать максимум информации при зачислении. Приходилось буквально сидеть и разбирать каждое поле в форме: зачем оно, кто его видит, можно ли без него обойтись.

Кто за что отвечает: школа, администратор ENT, подрядчик

Путаница в ролях — одна из главных причин инцидентов. Когда все думают, что за безопасность отвечает кто-то другой, данные остаются без присмотра. Разберём три ключевые роли.

Школа как оператор данных

Школа определяет цели и средства обработки: какие данные собирать, зачем, кому и на каком основании раскрывать. Это означает, что именно школа отвечает за политику обработки, настройку доступов, сроки хранения и информирование родителей и учащихся. Передать эту ответственность провайдеру облачного сервиса нельзя — можно только делегировать технические операции, но не принятие решений.

Администратор ENT

Это не техническая должность «нажимателя кнопок». Администратор управляет учётными записями, правами доступа, интеграциями, резервным копированием и удалением данных. Если роли настроены неверно, утечка происходит именно на этом уровне — причём часто незаметно для руководства. Я рекомендую администраторам раз в квартал проводить аудит: кто к чему имеет доступ, какие интеграции активны, где лежат резервные копии.

Поставщик платформы

Когда школа использует облачный сервис, провайдер обычно выступает обработчиком данных. Это значит, что он выполняет операции по поручению школы и не может использовать данные для своих целей. При выборе провайдера важно проверить:

• где физически хранятся данные — в какой стране, на каких серверах;
• какие субподрядчики привлекаются и имеют ли они доступ к данным;
• как быстро можно удалить или выгрузить информацию по запросу;
• есть ли механизмы безопасности и журналирования действий.

На практике я сталкивалась с тем, что школа годами пользовалась платформой, не имея на руках договора обработки данных. Когда возникал инцидент, выяснялось, что провайдер хранит резервные копии на серверах в юрисдикции, где законодательство о защите данных существенно отличается. Это не значит, что облака — зло. Это значит, что договор и техническая документация должны быть изучены до загрузки первых данных.

Какие данные в школе требуют особого внимания

Не все данные одинаково чувствительны, но есть категории, где цена утечки особенно высока. И есть данные, которые часто вообще не воспринимают как объект защиты — и зря.

Особо чувствительные данные

Это информация о здоровье, религиозных убеждениях, биометрии, а также другие сведения, способные причинить вред при раскрытии. В школе к ним относятся:

• медицинские справки и информация об аллергиях;
• ограничения по здоровью, включая записи об освобождении от нагрузок;
• данные о питании, если они указывают на религиозные или медицинские особенности;
• фото для распознавания лица;
• отпечатки пальцев для прохода в школу;
• сведения о религиозных убеждениях, если они возникают в учебной практике — например, при освобождении от определённых тем или мероприятий.

С биометрией ситуация особенно сложная: в отличие от пароля, отпечаток пальца или слепок лица нельзя «сменить» после утечки. Поэтому я всегда рекомендую школам задавать вопрос: действительно ли биометрия необходима, или можно обойтись картами доступа и другими менее инвазивными методами?

Данные, которые часто недооценивают

Вот что регулярно выпадает из поля зрения при аудите:

• логи входа в систему — они показывают, когда и откуда заходил пользователь;
• история действий в ENT — кто что открывал, редактировал, скачивал;
• комментарии учителей — особенно если они содержат оценочные суждения или личные пометки;
• записи в чатах — неформальное общение часто содержит больше личной информации, чем формальные документы;
• скриншоты и экспортированные таблицы — бесконтрольно распространяемые копии данных;
• записи уроков и вебинаров — на них могут быть видны лица, имена, личные обстоятельства.

Именно эти «технические» данные часто становятся источником инцидента. Типичный кейс: учитель сделал скриншот журнала с оценками, чтобы обсудить успеваемость на собрании, а потом отправил его в общий родительский чат. Формально журнал был защищён, но копия ушла в незащищённый канал.

Что сделать школе: практический минимум по GDPR

Ниже — список, который я рекомендую пройти любой школе до запуска цифровой среды и повторять хотя бы раз в год при её эксплуатации. Это не исчерпывающий комплаенс, но без этих шагов система остаётся уязвимой.

Чек-лист для школы

• Определить, какие персональные данные реально нужны каждому процессу — не «вообще», а для конкретной задачи.
• Зафиксировать цели обработки по каждому сервису: зачем собираем, на каком основании, кто ответственный.
• Проверить, кто видит данные: учителя, классные руководители, администрация, родители, подрядчики — и убедиться, что доступ не шире необходимого.
• Убедиться, что у каждого сервиса есть понятные условия хранения и удаления данных — и что эти условия задокументированы.
• Настроить двухфакторную аутентификацию там, где это возможно — особенно для администраторов и всех, кто работает с чувствительными данными.
• Ограничить экспорт списков и массовые выгрузки — если учитель может выгрузить весь журнал на флешку, это потенциальная утечка.
• Назначить ответственного за обработку данных и инциденты — с понятными контактами для сотрудников, родителей и учащихся.
• Подготовить и регулярно обновлять уведомления о приватности — короткие, понятные, на том языке, которым реально пользуются родители.
• Обучить сотрудников базовым правилам работы с данными — хотя бы один инструктаж в год с разбором реальных кейсов.
• Установить срок хранения и порядок удаления для архивов, резервных копий и данных старых классов — и автоматизировать этот процесс, где возможно.

Когда нужен DPIA и зачем он школе

DPIA — Data Protection Impact Assessment, или оценка влияния на защиту данных — это не бюрократическая формальность, а инструмент предварительного анализа рисков. Он нужен, когда обработка данных может создать высокий риск для прав и свобод людей. В школьном контексте это особенно актуально, потому что речь идёт о детях.

Ситуации, когда DPIA обязателен или крайне желателен:

• внедрение биометрических систем — отпечатки пальцев, распознавание лиц для прохода или оплаты питания;
• видеонаблюдение с аналитикой — особенно если система автоматически фиксирует поведение или перемещения;
• новые облачные платформы с глубоким профилем учащегося — когда система собирает и анализирует множество параметров;
• автоматизированная оценка или профилирование — например, алгоритмы, предсказывающие успеваемость или риск отчисления;
• массовая обработка чувствительных данных — даже если каждая категория по отдельности кажется небольшой;
• новые сценарии интеграции между несколькими сервисами — когда данные начинают перетекать из одной системы в другую без явного контроля.

Что должно быть в DPIA

Хорошая оценка влияния включает:

• описание процесса и его целей — что именно мы делаем и зачем;
• оценку необходимости и соразмерности — можно ли достичь цели менее инвазивным способом;
• анализ рисков — что может пойти не так и какие последствия для учащихся;
• меры по снижению рисков — технические, организационные, процедурные;
• решение о том, можно ли запускать процесс и на каких условиях.

На практике DPIA помогает не «поставить галочку» для проверяющих, а заранее увидеть, где школа может создать лишний риск. Я не раз наблюдала, как в процессе такой оценки команда обнаруживала, что планируемая интеграция тянет за собой данные, которые вообще не планировалось передавать — просто потому, что API сервиса устроен определённым образом.

Как правильно работать с согласием и основаниями обработки

Одна из самых частых ошибок в школах — считать согласие универсальным основанием для любой обработки. «Родители подписали согласие при зачислении» — и на этом разговор о правовых основаниях заканчивается. Но GDPR требует, чтобы у каждой обработки было своё правовое основание, и согласие — лишь одно из нескольких возможных.

Если данные нужны для выполнения образовательной функции или юридических обязательств школы, согласие может не быть главным инструментом. Школа имеет право обрабатывать такие данные на других основаниях — например, для выполнения задач в общественных интересах или в рамках официальных полномочий. А вот если речь идёт о публикации фото на сайте, маркетинговых рассылках или необязательных дополнительных сервисах — здесь согласие семьи действительно необходимо, и оно должно быть отдельным, информированным и отзываемым.

Типовые ошибки

• собирать согласие «на всё сразу» одной галочкой — это не работает, потому что родитель не понимает, на что именно соглашается;
• смешивать обязательные и факультативные процессы — нельзя ставить условие «если не согласны на фото, не получите доступ к электронному дневнику»;
• использовать данные для новой цели без повторного уведомления — собрали контакты для учебного процесса, а потом используют для рассылки коммерческих предложений;
• считать молчание согласием — отсутствие отказа не равно информированному согласию;
• хранить старые формы согласия без актуализации — особенно когда ребёнок переходит из начальной школы в среднюю и объём обрабатываемых данных меняется.

Что важно учесть при работе с ENT и облачными сервисами

В российских школах сейчас распространены гибридные сценарии: часть процессов ведётся в локальной системе, часть — в облаке. Это удобно, но требует дисциплины, потому что данные пересекают границы разных сред и юрисдикций.

Перед внедрением сервиса проверьте

• какие данные сервис собирает автоматически — часто платформа тянет метаданные, геолокацию, сведения об устройстве, о которых школа даже не подозревает;
• можно ли отключить лишнюю аналитику — особенно если сервис собирает поведенческие данные для собственных целей;
• где находятся серверы и как устроена передача данных — это критично для оценки соответствия требованиям законодательства;
• можно ли ограничить доступ по ролям — и насколько гибко настраиваются эти роли;
• есть ли экспорт и удаление данных по запросу — и как быстро это выполняется;
• как работает резервное копирование — где хранятся копии, кто имеет к ним доступ, как долго они живут;
• ведутся ли журналы действий — можно ли отследить, кто и когда обращался к данным;
• есть ли отдельные настройки для детских аккаунтов — по умолчанию многие сервисы рассчитаны на взрослых пользователей.

Особенно опасные сценарии

За годы аудитов я выделила несколько ситуаций, которые почти гарантированно приводят к проблемам:

• подключение внешних плагинов без проверки — учитель установил расширение для удобства, а оно собирает данные обо всех учениках;
• общий аккаунт для нескольких сотрудников — невозможно отследить, кто совершил действие, и пароль быстро распространяется за пределы коллектива;
• хранение списков учеников в личных облаках — учитель выгрузил журнал в свой Google Диск, который не управляется школой;
• пересылка персональных данных через незащищённые каналы — обычная электронная почта или мессенджеры без шифрования;
• открытые ссылки на таблицы и документы — «поделиться по ссылке» часто означает, что документ доступен всему интернету.

Как построить безопасный процесс внутри школы

Ниже — схема, которую я использовала при настройке цифровых сред в нескольких школах. Она не требует специальных юридических знаний, но даёт структуру, с которой можно начинать аудит.

Шаг 1. Инвентаризация данных

Составьте список по каждому сервису и процессу:

• какие данные собираются;
• где они хранятся;
• кто имеет доступ;
• как долго хранятся;
• куда передаются.

Это скучная, но необходимая работа. Без неё невозможно понять реальный масштаб обработки.

Шаг 2. Карта процессов

Привяжите данные к конкретным процессам:

• приём в школу;
• обучение;
• оценивание;
• допуск на мероприятия;
• питание;
• здоровье;
• кружки и поездки.

Это помогает увидеть, где одни и те же данные используются в разных контекстах — и где возникает избыточность.

Шаг 3. Проверка прав доступа

Принцип простой: каждому пользователю — только то, что нужно для его роли. Классный руководитель видит данные своего класса, но не всей параллели. Учитель-предметник видит оценки по своему предмету, но не медицинские пометки. Администратор ENT имеет расширенные права, но его действия логируются.

Шаг 4. Политика хранения

Задокументируйте:

• сроки хранения для каждой категории данных;
• когда данные архивируются;
• кто отвечает за удаление;
• как подтверждается, что удаление действительно выполнено.

Отдельно проработайте сценарий для выпускников: что происходит с их данными после окончания школы, как долго они хранятся, что удаляется сразу, а что остаётся в архиве.

Шаг 5. Обучение сотрудников

Даже идеально настроенная система ломается, если учитель отправил таблицу не туда или открыл общий доступ на весь интернет. Инструктаж должен быть коротким, практическим и с разбором реальных кейсов — не лекция о GDPR, а 20 минут о том, как безопасно делиться документами и куда нельзя пересылать списки учеников.

Таблица: частые риски и что делать

На что смотреть родителям и ученикам

Прозрачность — это не только требование GDPR, но и способ снизить конфликтность. Когда школа объясняет, какие данные собирает, зачем и кто их видит, у родителей меньше тревоги и больше доверия к цифровой среде.

Полезно, если в школе есть:

• короткое понятное уведомление о приватности — не юридический документ на 20 страниц, а страница с основными моментами;
• контакты ответственного за данные — чтобы родитель знал, к кому обратиться с вопросом или жалобой;
• инструкция, как запросить исправление или удаление данных — с понятными сроками ответа;
• порядок обращения при инциденте — что делать, если кажется, что данные утекли или используются неправильно;
• объяснение, какие сервисы используются в обучении и зачем — особенно если это новые облачные инструменты.

На практике такая открытость экономит школе часы объяснений и предотвращает эскалацию конфликтов. Родители, которые понимают логику работы с данными, реже пишут гневные письма и чаще задают конструктивные вопросы.

Краткий план действий для администратора ENT

Если нужно быстро проверить готовность системы — например, перед проверкой или после инцидента — используйте такой порядок:

1. Соберите список всех сервисов и интеграций — включая те, которые «кто-то когда-то подключил и забыл».
2. Определите, какие данные обрабатываются в каждом из них — пройдите по цепочке от ввода до хранения.
3. Уберите лишние поля из форм и карточек — всё, что не нужно для учебного процесса.
4. Проверьте роли, группы и права доступа — кто что видит сейчас, а не кто должен видеть по документации.
5. Настройте удаление старых аккаунтов и архивов — автоматизируйте, чтобы не зависеть от человеческой памяти.
6. Подготовьте DPIA для рискованных сценариев — биометрия, аналитика, новые интеграции.
7. Обновите уведомления для родителей, учеников и сотрудников — они должны отражать текущую реальность, а не состояние трёхлетней давности.
8. Проведите короткий инструктаж для педагогов — с фокусом на практические действия, а не на теорию.

Вывод

GDPR для школ — это не отдельная «юридическая папка», которую достают перед проверкой. Это часть нормальной цифровой гигиены, такая же, как резервное копирование или обновление паролей. Чем сложнее школьная экосистема — тем важнее контролировать, какие данные собираются, где хранятся, кто их видит и когда они удаляются.

Для администраторов ENT главный принцип такой: сначала безопасность и минимизация данных, потом удобство и интеграции. Если этот порядок нарушен, цифровая среда начинает создавать риски, которые перевешивают её пользу. А когда базовые вещи настроены правильно, платформа действительно помогает учебному процессу — и учителя могут сосредоточиться на преподавании, а не на борьбе с последствиями утечек.

FAQ

Нужно ли школе собирать согласие на все персональные данные?

Нет. Для разных процессов могут быть разные правовые основания. Согласие — лишь одно из них, и оно не всегда является главным или достаточным механизмом. Если данные нужны для выполнения образовательной функции, школа может опираться на другие основания, предусмотренные законодательством.

Можно ли хранить данные учеников в облачном сервисе?

Можно, если школа понимает, кто является обработчиком, где физически хранятся данные, как они защищены и как их можно удалить или выгрузить по запросу. Ключевое — проверить эти условия до начала использования сервиса и зафиксировать их в договоре.

Какие данные считаются наиболее чувствительными?

Особого внимания требуют данные о здоровье, религиозных убеждениях, биометрии и другие сведения, которые могут причинить вред при утечке. Также важно помнить, что комбинация «безобидных» данных может раскрывать чувствительную информацию — например, выбор блюд в столовой может указывать на религиозные ограничения.

Когда школе нужен DPIA?

Когда обработка данных может создать высокий риск для прав и свобод учащихся — например, при внедрении биометрии, массовой аналитики, автоматизированного профилирования или новых технологических сценариев, последствия которых сложно предсказать заранее.

Что делать, если в ENT много старых аккаунтов и файлов?

Провести инвентаризацию, определить сроки хранения для каждой категории данных и настроить удаление или архивирование по регламенту. Важно не просто «почистить» систему один раз, а создать процесс, который будет работать автоматически — например, аккаунты выпускников архивируются через месяц после окончания школы и удаляются через установленный срок.