Персональные данные на сайте в Казахстане: что проверить перед запуском

Как проверить обработку персональных данных на сайте до запуска?

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

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

• Инвентаризация всех точек сбора, включая невидимые пользователю SDK и логи.
• Карта от формы до базы, CRM, аналитики, рассылки, backup и удаления.
• Отдельные основания и интерфейсы для обработки заявки и маркетинговых сообщений.
• Список технических доказательств для разговора с юристом.

Что проверяет юрист, а что показывает техническая карта?

Закон Республики Казахстан «О персональных данных и их защите» регулирует сбор, обработку и защиту персональных данных. В нём описаны согласие, доступ, конфиденциальность, хранение, трансграничная передача и обязанности собственника или оператора. Текст в ИПС «Әділет» отмечен как обновлённый и содержит историю изменений.

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

По состоянию на 12 ноября 2026 года официальные акты продолжают меняться. Правила мер защиты изложены в новой редакции приказом от 3 сентября 2026 года. В правила сбора и обработки внесены изменения приказом от 17 сентября 2026 года. Проверочный лист изложен в новой редакции приказом от 19 октября 2026 года. Закон тоже изменён в 2026 году, часть поправок начнёт действовать с 1 января 2027 года. Перед релизом нужно повторно открыть действующую редакцию закона, правила сбора и обработки и действующие правила осуществления мер по защите, утверждённые приказом № 179/НҚ от 12 июня 2023 года.

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

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

Персональные данные могут появиться не только в поле «ФИО». Email, телефон, адрес доставки, ID аккаунта, IP-адрес, запись поддержки, содержимое загруженного документа и связка cookie с действиями пользователя могут относиться к человеку или позволять выделить его среди других. Конкретную квалификацию нужно подтвердить с юристом, но технически безопаснее сначала считать такую информацию потенциально персональной.

Для каждой точки сбора ответь на семь вопросов:

• Что собираем? Перечень полей, автоматически добавляемые идентификаторы и метаданные.
• Зачем? Одна конкретная цель, понятная пользователю и команде.
• Где обрабатываем? Браузер, backend, база, очередь, логи, резервные копии.
• Кому передаём? CRM, почта, аналитика, облако, AI-провайдер, подрядчик.
• Кто видит? Роли сотрудников, администраторы сервиса, техническая поддержка.
• Как долго? Срок или событие, после которого данные удаляются либо обезличиваются.
• Как подтвердить выбор? Версия текста, время, источник и доказательство согласия, если оно требуется.

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

Пример без юридического языка. Поле телефона в форме «Заказать звонок» нужно, чтобы менеджер позвонил по заявке. Дата рождения, должность и ссылка на соцсеть для этой работы обычно не очевидны. Если бизнесу они всё-таки нужны, для каждого поля должна появиться отдельная понятная причина, срок и место обработки, не формулировка «на всякий случай».

Как выглядит карта потока данных для формы заявки?

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

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

Как строить карту. Открой форму и иди за одной тестовой записью. Сначала браузер отправляет запрос на сервер. Сервер может записать тело запроса в журнал, положить задачу в очередь, сохранить контакт в базе и переслать его в CRM. CRM может запустить письмо, а система ошибок, получить часть запроса. Каждая новая копия становится отдельной строкой карты. Резервная копия тоже считается копией, даже если пользователь никогда не видит её в интерфейсе.

Как доказать, что данные хранятся в Казахстане?

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

Техническая проверка должна охватить основную базу, её копии для чтения, файловое хранилище, логи, систему ошибок, резервные копии, тестовую среду, выгрузки и кеши. Облачный кабинет с регионом KZ ещё не подтверждает расположение всех перечисленных копий. Запроси у поставщика документы и настройки, а вывод об их достаточности передай юристу.

Доступ проверяется отдельно от размещения. Создай матрицу ролей: кто читает, изменяет, экспортирует и удаляет данные. Удали общие аккаунты, закрой публичные файловые контейнеры, включи журнал административных действий и проверь, что поддержка не получает больше полей, чем нужно для задачи. Технический контур можно дополнить чек-листом безопасности AI-сервиса.

Что меняют внешние модули и сервисы на сайте?

SDK, готовый программный модуль внешнего сервиса, может незаметно отправлять данные своему поставщику. CRM, сервис писем, аналитика, captcha, чат поддержки, платёжный провайдер, CDN для быстрой раздачи файлов, система ошибок и AI API могут получать разные части пользовательского запроса. Собери список из кода, менеджера тегов, DNS, сетевых запросов браузера, названий переменных окружения и счетов поставщиков. Для каждого сервиса зафиксируй юридическое лицо, регион обработки, категории данных, цель, настройки хранения и процедуру удаления. Разделять такие интеграции технически удобно, когда архитектура разложена по зонам ответственности.

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

Практическая граница для AI. Не отправляй в модель полный документ или профиль пользователя, если задачу можно решить обезличенным фрагментом. AI-провайдер должен появиться в карте получателей так же, как CRM и аналитика.

Чем ответ на заявку отличается от подписки на маркетинг?

Человек оставляет телефон, чтобы получить ответ на конкретный запрос. Автоматически добавлять этот контакт в постоянную маркетинговую рассылку означает использовать данные для другой цели. Закон связывает объём, срок и обработку с заявленными целями, а правила описывают получение и отзыв согласия.

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

Важно не потерять и список запретов на отправку: многие сервисы рассылок хранят отдельный suppression list, перечень адресов, которым письмо больше отправлять нельзя. Полное физическое удаление адреса без учёта этой механики может случайно разрешить повторную загрузку контакта. Технический план удаления и юридически допустимый объём такого списка нужно согласовать отдельно.

Решает ли cookie-баннер вопрос с неизвестными тегами?

Сначала выясни, какие скрипты запускаются до выбора пользователя. Стандартная веб-настройка GA4 использует first-party cookies для различения пользователей и сессий; документация также перечисляет собираемые сведения вроде session statistics, приблизительной геолокации, браузера и устройства.

Google отдельно запрещает клиентам отправлять в Analytics персонально идентифицирующую информацию и указывает на необходимость информировать пользователей и управлять их выбором в применимых юрисдикциях. Consent Mode передаёт состояние выбора тегам, но не решает за компанию, какое основание требуется по местному праву.

Проверь настройки retention, срока хранения, внутри аналитической платформы, потому что они управляют временем хранения пользовательских и событийных данных. Затем проверь реальное поведение в браузере: какие cookies и сетевые запросы появляются до выбора, после отказа и после согласия.

Как пройти путь тестовой заявки от отправки до удаления?

• Сбор. Отправь вымышленный контакт. Используй специальный тестовый адрес и номер, не данные реального клиента. Зафиксируй текст рядом с формой, состояние галочек, время и версию страницы.
• Маршрут. Найди каждую появившуюся копию. Проверь запрос браузера, серверный лог, основную базу, очередь, CRM, рассылку, аналитику и систему ошибок. Отметь неожиданные поля и получателей.
• Доступ. Зайди под разными ролями. Менеджер должен видеть только необходимое. Обычный пользователь не должен открывать чужую заявку подменой идентификатора. Административный экспорт должен журналироваться и быть ограничен.
• Отзыв. Останови маркетинговые сообщения. Проверь, что выбор дошёл до сервиса рассылок, повторный импорт не возвращает подписку, а заявка и маркетинг управляются отдельно.
• Удаление. Выполни утверждённую процедуру. Зафиксируй, что произошло в базе и внешних сервисах, что остаётся в резервных копиях и журналах, когда эти копии исчезнут и на каком основании что-либо сохраняется.

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

Что проверить перед включением формы на проде?

Поля и цель

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

Система и получатели

• Известны база, резервные копии и логи.
• Перечислены CRM, аналитика, рассылки и AI.
• Проверены регионы и трансграничная передача.
• Доступы выданы по ролям.

Согласие и удаление

• Фиксируется версия текста и выбор.
• Заявка отделена от маркетинга.
• Есть маршрут отзыва и исправления.
• Удаление охватывает внешние системы.

Дополнительный технический ориентир по защите пользовательских данных и приватности даёт OWASP User Privacy Protection Cheat Sheet.

Как использовать AI для аудита, не отдавая ему юридическое решение?

Скачать полный промпт в Markdown.

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

Не проси и не выводи реальные персональные данные, cookies, токены и ключи. Не отправляй тестовые формы во внешние сервисы. Не запускай deploy, миграции, seed и install-скрипты.

Построй таблицу: точка сбора | поля | цель | обработчик | хранение | внешние получатели | доступ | срок | удаление | доказательство согласия.

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

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

На какие документы опирается статья?

Все ссылки проверены 12 ноября 2026 года. Датозависимые требования, версии документов и настройки сервисов нужно перепроверить перед применением.

• ИПС «Әділет»: Закон Республики Казахстан «О персональных данных и их защите» Определения, принципы, согласие, доступ, конфиденциальность, хранение, трансграничная передача и обязанности оператора.
• ИПС «Әділет»: Правила сбора, обработки персональных данных Порядок получения согласия, обработки, блокирования и уничтожения данных.
• ИПС «Әділет»: Правила осуществления собственником, оператором и третьим лицом мер по защите персональных данных (приказ № 179/НҚ) Организационные и технические меры защиты, размещение объектов и работа с данными ограниченного доступа.
• ИПС «Әділет»: Проверочный лист по соблюдению законодательства о персональных данных Пункты государственного контроля, включая хранение данных в базе или цифровом объекте на территории Казахстана и защитные меры. Новая редакция: приказ от 19 октября 2026 года.
• Google Analytics Help: GA4 cookie usage on websites Назначение cookies _ga и _ga_<container-id> в стандартной веб-реализации GA4.
• Google Analytics Help: Data collection Какие сведения собирает стандартная настройка GA4 и как используется client ID.
• Google Analytics Help: Data retention Настройки срока хранения пользовательских и событийных данных в Google Analytics.
• Google Analytics Help: Safeguarding your data Ограничение на передачу идентифицирующей информации и обязанности клиента информировать пользователей.
• Google Analytics Help: Introduction to user consent management Механизмы передачи выбора пользователя в Google и зависимость требований согласия от юрисдикции.
• OWASP: User Privacy Protection Cheat Sheet Технические практики защиты пользователей: шифрование при передаче и хранении, HSTS, защита от утечки IP-адреса.