Реестр НЦЗПД: как написать DFD для аудита без воды

С темой реестра НЦЗПД у многих начинается путаница уже на первом шаге. Одни уверены, что любой сайт с формой обратной связи надо срочно регистрировать. Другие, наоборот, считают, что реестр касается только больших госплатформ. Обе крайности мимо. В белорусском праве нет требования «нарисовать Data Flow Diagram» как отдельной сакральной бумажки, но есть куда более приземлённая вещь: тебе нужно показать, какая система обрабатывает персональные данные, где она живёт, кто в ней оператор, кто уполномоченное лицо, зачем собираются данные, сколько они хранятся и куда вообще уезжают. Это прямо ложится на нормальную инженерную DFD, а не на декоративную схему для презентации. Смотри Закон № 99-З, приказ ОАЦ № 94 и пояснения по реестру операторов персональных данных.

Сначала проверь: твой сайт вообще должен попадать в реестр или нет

Это главная развилка. Реестр не для «всех, кто поставил форму заявки». По приказу ОАЦ № 94 туда включаются сведения об информационных ресурсах или системах, если через них идет: трансграничная передача специальных персональных данных в страны без надлежащего уровня защиты, обработка биометрических или генетических данных, обработка персональных данных более 100 тысяч физических лиц, либо обработка данных более 10 тысяч лиц младше шестнадцати лет. Именно эти критерии — базовый фильтр, а не ощущение владельца сайта, что проект «наверное серьезный». Приказ № 94 лучше читать именно в этой логике: сначала критерий, потом уже документы.

Из этого следует неприятная, но полезная мысль: маленький корпоративный сайт с формой «оставьте номер, перезвоним» не всегда попадает в реестр, а вот довольно обычная на вид система может попасть. Например, CRM, в которой накопили массив клиентских карточек, проект с детской аудиторией, сервис с видеоидентификацией или решение, где персональные данные ездят через внешний зарубежный сервис. НЦЗПД отдельно приводит примеры с большими клиентскими базами, системами видеонаблюдения с уникальной идентификацией и совокупной оценкой нескольких ресурсов внутри одной системы. Это важно, потому что аудит смотрит не на название проекта, а на фактическую обработку. Есть хорошие пояснения в разделе реестра операторов и на странице about у register.cpd.by.

Отдельный практический момент: оператор сам оценивает, подпадает ли ресурс под критерии приказа № 94. И если подпадает, сведения по системе, созданной после 1 января 2024 года, вносятся в течение десяти рабочих дней после ввода в постоянную эксплуатацию. Это не та история, где можно полгода жить в проде, а потом «доделать документы». НЦЗПД прямо пишет, что оценка делается оператором, а сроки внесения и изменения сведений привязаны к эксплуатации системы.

Почему без DFD всё разваливается

Когда юрист просит у разработчика «описание потоков данных», многие несут схему уровня: браузер → сервер → база. Для гос. аудита это почти бесполезно. В реестр по приказу № 94 заносятся не только название системы и оператор, но и местонахождение систем хранения данных и серверного оборудования, основания включения в реестр, количество субъектов, цели и правовые основания обработки, срок хранения, а в нужных случаях — перечень иностранных государств, куда идет трансграничная передача. Если у тебя это не связано в одну карту, ты начнешь противоречить сам себе между анкетой, политикой, договором с подрядчиком и реальной инфраструктурой. Приказ № 94 в этом смысле предельно предметный.

Я обычно объясняю это так: DFD для НЦЗПД — не дизайнерская диаграмма, а карта доказательств. По ней должно быть видно, откуда данные вошли, через какой процесс прошли, где сохранились, кому передались, по какому основанию это вообще допустимо и кто за какой участок отвечает. Если схема не отвечает на эти вопросы, она не помогает ни инженеру, ни юристу, ни руководителю, который потом подписывает пакет документов.

Что должно быть на DFD, если ты делаешь её не для галочки

Минимальный состав я бы собирал так:

• Источники данных: формы на сайте, регистрация аккаунта, чат-виджет, телефонный callback, админка, импорт из CSV, API-партнёры.
• Категории данных: ФИО, email, телефон, адрес, история заказов, логины, IP, cookie ID, записи звонков, медиафайлы.
• Процессы: создание лида, регистрация, оформление заказа, проверка платежа, поддержка, маркетинговая рассылка, экспорт отчёта.
• Хранилища: PostgreSQL, S3-совместимое хранилище, файловый сервер, резервные копии, лог-сервер.
• Получатели: CRM, email-провайдер, SMS-шлюз, хостинг, облачный бэкап, платёжный сервис, аналитика.
• Роли: оператор, уполномоченное лицо, внутренние сотрудники с разными правами доступа.
• География: Беларусь / не Беларусь, потому что на этом ломается половина разговоров про трансграничную передачу.
• Срок хранения и удаление: не абстрактное «храним по необходимости», а конкретная логика lifecycle.

Эта структура не взята с потолка. Статья 17 Закона требует правовые, организационные и технические меры защиты, а НЦЗПД отдельно указывает на необходимость поддерживать перечень ресурсов, категории данных, перечень уполномоченных лиц и сроки хранения в актуальном состоянии. Плюс закон жестко разводит роли оператора и уполномоченного лица: согласие получает оператор, а ответственность перед субъектом за действия уполномоченного лица несет тоже оператор. Поэтому на схеме роли должны быть не «подрядчик/клиент», а именно в юридической терминологии. Смотри статьи 5, 7 и 17 Закона и разбор НЦЗПД по мерам защиты.

Как выглядит минимально вменяемая схема

Я бы не усложнял первую версию BPMN-экзотикой. Для аудита хватает строгой инженерной схемы, где каждый поток подписан.

[Пользователь]
   │
   ├── форма заявки (имя, телефон, email)
   ├── регистрация аккаунта
   └── cookie / analytics consent
   │
   ▼
[Frontend: React/Vite]
   │  TLS
   ▼
[Backend API: FastAPI / NestJS]
   │
   ├── запись заявки ───────────────► [PostgreSQL, сервер BY]
   ├── отправка письма ─────────────► [Email provider]
   ├── синхронизация лида ──────────► [CRM]
   ├── логирование событий ─────────► [Log storage]
   └── резервное копирование ───────► [Backup storage]
   
[Admin Panel]
   │
   └── доступ по RBAC / MFA ────────► [Backend API]

[Analytics scripts]
   ▲
   └── загружаются только после consent

Но голые блоки — это только полдела. Я бы рядом с каждым потоком добавил четыре короткие пометки: какие данные, цель, правовое основание, срок хранения. Например: «форма заявки → CRM: ФИО, телефон, email; цель — обработка обращения; основание — договор/обращение либо согласие в зависимости от сценария; срок — 1 год с даты последнего контакта». Именно такие подписи превращают схему из картинки в рабочий документ.

Если у тебя есть зарубежные сервисы, они на DFD должны быть видны без гадания. НЦЗПД в разъяснениях для малого бизнеса отдельно пишет про использование Google-сервисов и то, что при таком сценарии оператор осуществляет трансграничную передачу данных и должен учитывать требования статьи 9 Закона, а субъекту нужно разъяснять риски, если основание — согласие. Для проектов на аутсорсе это не теоретика: Google Forms, Google Sheets, внешние CRM, helpdesk, аналитика и чат-боты всплывают почти в каждом втором стеке. Смотри разъяснения НЦЗПД для малого бизнеса и статью 9 Закона.

Что обычно ломает регистрацию и аудит

Первая типовая ошибка — рисуют только основную БД и забывают про резервные копии, логи, выгрузки в Excel и ручные экспорты. А потом на встрече выясняется, что «удаленные» данные еще полгода лежат в backup bucket и еженедельной CSV-выгрузке бухгалтерии.

Вторая ошибка — не показывают уполномоченных лиц. Хостинг, облачная CRM, email-сервис, аутсорс-команда сопровождения, сервис онлайн-записи — это не «технические мелочи», а участники обработки, которые влияют на документы, договоры и распределение ответственности. Закон это различие фиксирует прямо. Определение уполномоченного лица и обязанности по договорной связке там расписаны достаточно ясно.

Третья ошибка — схема расходится с реальным продом. На диаграмме написали «сервер в РБ», а фронт улетел на зарубежный CDN, изображения лежат в объектном хранилище вне Беларуси, письма идут через внешний сервис, support сидит в SaaS-тикетнице. Для юриста это уже плохой день, а для аудита — еще хуже, потому что приказ № 94 прямо спрашивает про местонахождение систем хранения и серверного оборудования.

Четвертая ошибка — на схеме нет логики доступа. Закон и методические материалы НЦЗПД требуют установить порядок доступа к данным, а на практике это означает роли, матрицу прав, MFA хотя бы для админки и понятный audit trail. Если в системе менеджер саппорта может смотреть всё то же, что и владелец бизнеса, у тебя проблема не в документах, а в архитектуре. НЦЗПД по мерам защиты об этом пишет без двусмысленности.

Как я бы готовил комплект под аудит

Я бы шел в таком порядке.

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

Потом — черновая DFD. Не надо сразу рисовать красиво. Сначала просто зафиксируй, кто куда что отправляет.

После этого — маппинг по праву: оператор, уполномоченные лица, цели, правовые основания, сроки хранения, трансграничные маршруты, меры защиты, ответственный за внутренний контроль. Это уже привязка к статье 17 Закона, приказу № 94 и требованиям НЦЗПД по мерам защиты.

Дальше — сверка с продом. Я бы отдельно проверил DNS, CDN, email route, S3 bucket, регион бэкапов, внешние SDK, consent mode, логику удаления и архивирования. Это как раз тот момент, где инженеру полезно пройтись не по Confluence, а по .env, Terraform, панели хостинга и коду инициализации сторонних скриптов.

И только потом — финальная схема и пакет документов. Если делать наоборот, получится красивый PDF, который рассыплется от первого технического вопроса.

Что это значит на практике

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

Если ты владелец сайта или digital-бизнеса, не надо требовать от подрядчика абстрактную «схему архитектуры». Проси схему потоков персональных данных с ролями, странами размещения, сроками хранения и внешними сервисами. Это дешевле, чем переделывать всё после замечаний.

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

Если у тебя сайт или веб-продукт в Беларуси и нужно разобрать архитектуру под реестр НЦЗПД, напиши мне в Telegram или через velutich.com.