Короткий ответ
Перед запуском составь карту данных, а уже по ней проверяй форму, согласие и политику.
Для каждого поля зафиксируй категорию данных, конкретную цель, место хранения, внешних получателей, круг доступа, срок и способ удаления. Затем сравни эту фактическую схему с текстом согласия и политики. Отдельно проверь аналитику, cookies, логи, резервные копии и передачу в зарубежные сервисы.
Что получится
- Инвентаризация всех точек сбора, включая невидимые пользователю SDK и логи.
- Карта от формы до базы, CRM, аналитики, рассылки, backup и удаления.
- Отдельные основания и интерфейсы для обработки заявки и маркетинговых сообщений.
- Список технических доказательств для разговора с юристом.
01 · Два слоя
Юрист отвечает, можно ли. Техническая карта показывает, что происходит на самом деле.
Закон Республики Казахстан «О персональных данных и их защите» регулирует сбор, обработку и защиту персональных данных. В нём описаны согласие, доступ, конфиденциальность, хранение, трансграничная передача и обязанности собственника или оператора. Текст в ИПС «Әділет» отмечен как обновлённый и содержит историю изменений. [1]
Страница политики сама по себе не доказывает соблюдение требований. Если документ говорит «email нужен для ответа», а код одновременно отправляет адрес в CRM, рекламную аудиторию, систему аналитики и сервис рассылок, фактический поток шире заявленного. Поэтому работа начинается с кода, настроек и договоров с поставщиками, а заканчивается согласованием текста с юристом. До сбора реальных данных определи режим запуска через матрицу риска продукта.
По состоянию на 7 сентября 2026 года официальные акты продолжают меняться. Перед релизом нужно повторно открыть действующую редакцию закона, правила сбора и обработки и действующие правила осуществления мер по защите, утверждённые приказом № 179/НҚ от 12 июня 2023 года. [2] [3]
Разделение ролей простое: разработчик показывает факты — какие поля собираются, куда уходят, где лежат и кто их видит. Юрист сопоставляет эти факты с действующим правом и документами компании. Если фактический маршрут неизвестен, качественно проверить политику невозможно.
02 · Инвентаризация
Начни не с шаблона политики, а со списка полей и событий.
Персональные данные могут появиться не только в поле «ФИО». Email, телефон, адрес доставки, ID аккаунта, IP-адрес, запись поддержки, содержимое загруженного документа и связка cookie с действиями пользователя могут относиться к человеку или позволять выделить его среди других. Конкретную квалификацию нужно подтвердить с юристом, но технически безопаснее сначала считать такую информацию потенциально персональной.
Для каждой точки сбора ответь на семь вопросов:
- Что собираем? Перечень полей, автоматически добавляемые идентификаторы и метаданные.
- Зачем? Одна конкретная цель, понятная пользователю и команде.
- Где обрабатываем? Браузер, backend, база, очередь, логи, резервные копии.
- Кому передаём? CRM, почта, аналитика, облако, AI-провайдер, подрядчик.
- Кто видит? Роли сотрудников, администраторы сервиса, техническая поддержка.
- Как долго? Срок или событие, после которого данные удаляются либо обезличиваются.
- Как подтвердить выбор? Версия текста, время, источник и доказательство согласия, если оно требуется.
Закон ограничивает объём данных целью обработки и предусматривает содержание согласия, включая перечень собираемых данных, срок, сведения о третьих лицах и трансграничной передаче. [1] Это хороший тест для продукта: если назначение поля нельзя объяснить одним предложением, поле лучше не собирать до отдельного решения.
Пример без юридического языка. Поле телефона в форме «Заказать звонок» нужно, чтобы менеджер позвонил по заявке. Дата рождения, должность и ссылка на соцсеть для этой работы обычно не очевидны. Если бизнесу они всё-таки нужны, для каждого поля должна появиться отдельная понятная причина, срок и место обработки — не формулировка «на всякий случай».
03 · Артефакт
Карта потока данных для обычной формы заявки.
Скопируй таблицу в рабочий документ и замени примеры фактическими названиями систем. Одна строка должна описывать один набор данных с одной целью. Если цель меняется, создай отдельную строку.
| Точка и данные | Цель | Маршрут и хранение | Получатели | Доступ | Срок и удаление |
|---|---|---|---|---|---|
| Форма заявки: имя, телефон | Связаться по запросу | HTTPS → API → база в Казахстане | Назначенная CRM, если используется | Менеджер своей команды | Срок по утверждённой политике; удаление из базы и CRM |
| Технические логи: IP, request ID | Безопасность и диагностика | Reverse proxy → log storage | Хостинг, мониторинг | Ограниченная инженерная роль | Короткий технически обоснованный срок; автоматическое удаление |
| Аналитика: идентификатор браузера, события | Измерить использование сайта | Браузер → аналитическая платформа | Поставщик аналитики | Аналитик и администратор | Настройка срока хранения у поставщика плюс проверка удаления |
| Email для рассылки | Маркетинговые сообщения | Форма подписки → сервер → сервис рассылок | Поставщик рассылки | Маркетинг по роли | До отзыва или иного применимого основания; список адресов, которым запрещена повторная отправка, учитывается отдельно |
Не копируй из примера формулировки как юридическое решение. Особенно проверь место хранения, сроки, способ удаления из резервных копий и допустимость каждого получателя.
Как строить карту. Открой форму и иди за одной тестовой записью. Сначала браузер отправляет запрос на сервер. Сервер может записать тело запроса в журнал, положить задачу в очередь, сохранить контакт в базе и переслать его в CRM. CRM может запустить письмо, а система ошибок — получить часть запроса. Каждая новая копия становится отдельной строкой карты. Резервная копия тоже считается копией, даже если пользователь никогда не видит её в интерфейсе.
04 · Хранение
«Сервер в Казахстане» нужно доказать для каждого слоя, а не написать в политике.
Официальный проверочный лист включает хранение персональных данных в базе, находящейся на территории Республики Казахстан. Правила мер защиты отдельно описывают требования к объектам, где обрабатываются данные ограниченного доступа. [4] [3]
Техническая проверка должна охватить основную базу, её копии для чтения, файловое хранилище, логи, систему ошибок, резервные копии, тестовую среду, выгрузки и кеши. Облачный кабинет с регионом KZ ещё не подтверждает расположение всех перечисленных копий. Запроси у поставщика документы и настройки, а вывод об их достаточности передай юристу.
Доступ проверяется отдельно от размещения. Создай матрицу ролей: кто читает, изменяет, экспортирует и удаляет данные. Удали общие аккаунты, закрой публичные файловые контейнеры, включи журнал административных действий и проверь, что поддержка не получает больше полей, чем нужно для задачи. Технический контур можно дополнить чек-листом безопасности AI-сервиса.
05 · Получатели
Каждый внешний модуль добавляет получателя, маршрут и договорный вопрос.
SDK — готовый программный модуль внешнего сервиса — может незаметно отправлять данные своему поставщику. CRM, сервис писем, аналитика, captcha, чат поддержки, платёжный провайдер, CDN для быстрой раздачи файлов, система ошибок и AI API могут получать разные части пользовательского запроса. Собери список из кода, менеджера тегов, DNS, сетевых запросов браузера, названий переменных окружения и счетов поставщиков. Для каждого сервиса зафиксируй юридическое лицо, регион обработки, категории данных, цель, настройки хранения и процедуру удаления. Разделять такие интеграции технически помогает архитектура по зонам ответственности.
Согласие по закону включает сведения о возможности передачи третьим лицам и наличии либо отсутствии трансграничной передачи. [1] Это не означает, что универсальная фраза автоматически делает любую интеграцию допустимой. Конкретный текст и основание проверяет юрист, а разработчик обязан предоставить ему правдивую карту.
06 · Цели
Ответить на заявку и подписать на маркетинг: две разные работы.
Человек оставляет телефон, чтобы получить ответ на конкретный запрос. Автоматически добавлять этот контакт в постоянную маркетинговую рассылку означает использовать данные для другой цели. Закон связывает объём, срок и обработку с заявленными целями, а правила описывают получение и отзыв согласия. [1] [2]
В интерфейсе безопаснее разделить действия: обязательная обработка заявки и отдельный необязательный выбор получать маркетинговые сообщения. Не делай рекламную галочку заранее включённой. Храни версию текста и время выбора, а отписку синхронизируй не только в интерфейсе, но и в сервисе рассылки и связанных списках. Конкретную правовую конструкцию, формулировки и исключения утверждает юрист.
Важно не потерять и список запретов на отправку: многие сервисы рассылок хранят отдельный suppression list — перечень адресов, которым письмо больше отправлять нельзя. Полное физическое удаление адреса без учёта этой механики может случайно разрешить повторную загрузку контакта. Технический план удаления и юридически допустимый объём такого списка нужно согласовать отдельно.
08 · Сквозная проверка
Пройди весь путь одной тестовой заявки — от отправки до удаления.
- Сбор
Отправь вымышленный контакт.
Используй специальный тестовый адрес и номер, не данные реального клиента. Зафиксируй текст рядом с формой, состояние галочек, время и версию страницы.
- Маршрут
Найди каждую появившуюся копию.
Проверь запрос браузера, серверный лог, основную базу, очередь, CRM, рассылку, аналитику и систему ошибок. Отметь неожиданные поля и получателей.
- Доступ
Зайди под разными ролями.
Менеджер должен видеть только необходимое. Обычный пользователь не должен открывать чужую заявку подменой идентификатора. Административный экспорт должен журналироваться и быть ограничен.
- Отзыв
Останови маркетинговые сообщения.
Проверь, что выбор дошёл до сервиса рассылок, повторный импорт не возвращает подписку, а заявка и маркетинг управляются отдельно.
- Удаление
Выполни утверждённую процедуру.
Зафиксируй, что произошло в базе и внешних сервисах, что остаётся в резервных копиях и журналах, когда эти копии исчезнут и на каком основании что-либо сохраняется.
Результатом теста должна быть не фраза «удаление работает», а таблица с системой, владельцем шага, командой или интерфейсом удаления, фактическим результатом и нерешённым вопросом для юриста.
Артефакт · Форма
Чек-лист перед включением формы на проде.
Сбор
Поля и цель
- У каждого поля есть цель.
- Нет данных «на всякий случай».
- Обязательные и необязательные поля различимы.
- Текст рядом с формой соответствует действию.
Маршрут
Система и получатели
- Известны база, резервные копии и логи.
- Перечислены CRM, аналитика, рассылки и AI.
- Проверены регионы и трансграничная передача.
- Доступы выданы по ролям.
Жизненный цикл
Согласие и удаление
- Фиксируется версия текста и выбор.
- Заявка отделена от маркетинга.
- Есть маршрут отзыва и исправления.
- Удаление охватывает внешние системы.
Дополнительный технический ориентир по минимизации и защите пользовательских данных даёт OWASP User Privacy Protection Cheat Sheet. [10]
Промпт для Claude
Попроси AI найти факты, а юридическое решение оставь специалисту.
Скачать полный промпт в Markdown.
Работай как технический аудитор. Не давай окончательных юридических заключений. Сначала изучи код, конфигурацию и документацию. Не меняй проект без моего подтверждения.
Не проси и не выводи реальные персональные данные, cookies, токены и ключи. Не отправляй тестовые формы во внешние сервисы. Не запускай deploy, миграции, seed и install-скрипты.
Построй таблицу: точка сбора | поля | цель | обработчик | хранение | внешние получатели | доступ | срок | удаление | доказательство согласия.
Отдельно проверь формы, различие заявки и маркетинга, cookies и аналитику, логи, резервные копии, тестовую среду, трансграничные передачи и фактическое расположение баз.
Для каждого вывода укажи файл и строку. Отметь результат как «проверено статически», «требует технического теста» или «требует юриста по праву Республики Казахстан». Верни неизвестные параметры, расхождения с политикой, план исправлений, тестовые сценарии и вопросы юристу. После отчёта остановись.FAQ
Частые вопросы о данных на сайте в Казахстане.
Форма с именем и телефоном уже считается обработкой персональных данных?
Как минимум она создаёт технический поток сведений, связанных с человеком: браузер отправляет их серверу, после чего они могут попасть в базу, логи и внешние сервисы. Точную правовую роль компании и применимые требования определяет юрист, но откладывать карту данных до появления большой CRM нельзя.
Достаточно ли ссылки на политику под кнопкой?
Нет. Политика должна соответствовать реальной системе, а способ получения согласия — действующим требованиям и конкретной цели. Ссылка не исправляет лишние поля, неизвестные получатели, открытую базу или автоматическую подписку на рекламу.
Можно ли одной галочкой покрыть заявку и рассылку?
Это разные цели и разные действия пользователя. Практически их лучше разделять в интерфейсе и в хранении доказательств выбора. Конкретную формулировку и допустимое правовое основание должен подтвердить юрист.
Что делать, если сервис не даёт выбрать Казахстан как регион?
Не скрывать это из карты. Запиши юридическое лицо поставщика, маршрут и регион, категории передаваемых данных и доступные настройки. До передачи реальных данных попроси юриста оценить допустимость и условия трансграничной передачи либо замени архитектуру.
Может ли Claude написать готовую политику?
Claude может собрать черновик по подтверждённой карте и найти расхождения между кодом и документом. Он не видит автоматически все договоры, настройки облака и действующие правовые исключения. Финальную версию и основания обработки проверяет профильный юрист.
Финальная проверка
Политика должна описывать систему, которая действительно запущена.
После согласования документов снова пройди сайт как пользователь: отправь тестовую заявку, откажись от аналитики, запроси удаление тестового контакта и проследи каждую копию до конца. Сохрани доказательства проверки вместе с релизом. Перед открытием трафика передай карту и документы профильному юристу.