На прошлой неделе я разбирал здесь сценарий увольнения сотрудника в облачном офисе: гейтинг на необратимом шаге, идемпотентность при повторном запуске, безопасное продолжение с точки сбоя после падения. Тогда весь разговор был инженерный — что нужно от движка автоматизации, чтобы граф не развалился между копированием данных и удалением учётной записи. И почему сам сценарий стартует не по событию из облака, а по команде человека — причина техническая, я её тут не разворачиваю, она уже разобрана в прошлый раз.
Сейчас я взял тот же сценарий и приложил к нему линейку, о которой инженеры обычно не думают вовсе: приказ Роскомнадзора от 28.10.2022 № 179 про подтверждение уничтожения персональных данных. Совпадение получилось неполным. И ровно в тех местах, где не ждёшь.
Компанией +Альянс я руковожу как её основатель, и оба класса инструментов, о которых пойдёт речь дальше — автоматизация в облаке и резервное копирование, — вижу не по чужим пересказам, а по своей работе каждый день.
Норма, которая не спрашивает про качество графа
Приказ длинно называется — “Об утверждении Требований к подтверждению уничтожения персональных данных”, — а работает по одному пункту. Если обработка ведётся без автоматизации, достаточно одного документа: акта об уничтожении. Как только автоматизация появляется, документов становится два: “акт об уничтожении персональных данных <…> и выгрузка из журнала регистрации событий в информационной системе персональных данных” (п. 2; текст я сверял 3 августа 2026 года, читал на rulaws.ru).
В выгрузке требуются пять сведений (п. 5): ФИО субъекта или иная относящаяся к нему информация; перечень категорий уничтоженных данных; наименование информационной системы; причина; дата.
Акт устроен иначе, и там прячется деталь, которая всё меняет. Среди его пунктов есть подпункт “г” — ФИО, должность лиц, уничтоживших персональные данные, и их подпись. Разница с выгрузкой тонкая, но принципиальная: там “кто” — это тот, кого уволили. Здесь “кто” — тот, кто уничтожил данные и отвечает за это подписью. Спутать эти два “кто” легко, я сам не сразу это заметил.
Электронная форма акта проблему не убирает так, как хочется думать. Пункт 4 разрешает акту быть электронным — “подписанным в соответствии с законодательством Российской Федерации” (закон об электронной подписи, 63-ФЗ, упомянут в сноске к пункту, не в его тексте) — и признаёт такой документ равнозначным бумажному. Равнозначным чему именно? Бумажному, подписанному собственноручно тем самым человеком из подпункта “г”. Цифровая форма избавляет от принтера. От фамилии внизу она не избавляет.
И сразу зафиксирую срок, чтобы не забыть в конце: оба документа приказ требует хранить три года с момента уничтожения (п. 8). Это про документы. Не про резервные копии — к ним я вернусь отдельно.
Что реально ловит журнал автоматики
Дальше — к движку. После каждого прогона сценария в истории запусков остаётся запись. Что там есть по факту: статус, какой именно поток отработал, чем он был запущен, и каждый шаг с его длительностью. Если внутри есть шаг резервного копирования, у него раскрывается отдельный блок логов: имя копии, время начала и завершения с точностью до секунды, а из чисел — выполненные и пропущенные объекты одной парой, ошибки — отдельной строкой.
Звучит подробно. Приложим это к пяти полям приказа — и подробность быстро распадается на неполноту.
Про то, кого уволили, запись молчит: такого поля среди перечисленного нет, и утверждать, что оно где-то лежит скрыто, я не буду. Категории уничтоженных данных движок тоже не хранит — он работает с учётной записью целиком, а не с перечнем данных внутри неё. Название информационной системы не предусмотрено вовсе как строка. Причина уничтожения формально присутствует, но не документом, а результатом пройденного шага согласования — что именно от него остаётся, разберу чуть ниже отдельно. А дата закрыта полностью: у каждого шага своя метка, у лога копирования она с точностью до секунды.
Из пяти пунктов приказа закрыт целиком один. И тот, который проверяющий спросит первым — “чьи именно данные”, — закрыт хуже всех.
Согласование: галочка, а не досье
В сценарии с согласованием есть логика, которую я хвалил и раньше: пока согласующие не ответили, поток стоит, и следующий шаг — копирование — не начинается. Кворум настраивается: можно требовать решения всех согласующих, можно — любого одного.
Кворум “любой один” придумывали явно не для журнала — придумывали, чтобы решение не откладывалось из-за формальной рассылки всем сразу, если хватает подписи одного ответственного. Разумно. Только заодно из журнала пропало имя того, кто в итоге решил.
В записи остаётся факт, что ветка “Согласовано” пройдена, и до решения виден список тех, кого ждут. А кто конкретно из списка нажал “Согласовать” и когда именно — в записи нет. При кворуме “любой один” это особенно неприятно: узнать решившего из журнала нельзя даже теоретически, потому что журнал имя решившего не запоминает вовсе.
К письму согласующим прикладывается сам документ-основание — тот, ради которого просят согласовать увольнение. Он проходит через процесс по-настоящему: пока не набрался кворум, поток стоит и не двигается дальше. Но в истории запуска этот файл не отображается вообще, только факт результата. Понадобится приложить его к акту — идти за ним нужно не в журнал, а туда, где реально лежит переписка.
Идентификатор в процессе есть, а в поле — не факт
Шаг удаления получает пользователя не вручную вбитым значением, а выражением вида {backup.uid} — результатом предыдущего шага копирования. Гарантия здесь не декларативная, а на уровне данных: до успешного завершения копирования этого значения просто не существует, и шаг удаления физически не может стартовать раньше.
Значит, идентификатор увольняемого в процедуре точно участвует — без него шаг не сработает. Но участвовать в процедуре — это одно. Оказаться в записи журнала отдельным полем, которое можно вытащить наружу для выгрузки, — совсем другое. Первое я вижу на графе своими глазами. Про второе у меня нет ни подтверждения, ни опровержения, и врать в обе стороны не буду.
Для проверяющего разница между “участвует в процессе” и “лежит в файле, который можно скачать” — это разница между “наверное, всё было” и “вот, смотрите”. Первое звучит убедительно только для того, кто уже вам верит.
Выгрузки нет — и это не тот же файл, что CSV у бэкапа
Дальше самое неприятное. Экспорта истории запусков не существует — я перепроверял это в начале августа, ответ был однозначный. Всё описанное выше — статусы, шаги, логи копирования — смотрится глазами в веб-интерфейсе. Файла, который можно приложить к акту как выгрузку, движок не формирует.
Тут легко потянуться за соседним решением — системой, которая хранит сами резервные копии. У неё с журналами иначе: список операций выгружается в CSV целиком, и у каждой строки есть автор — тот, кто её запустил. Соблазн подставить этот файл вместо выгрузки по приказу понятен.
Не делайте так. Тот журнал описывает операции копирования: кто запустил бэкап, когда, что скопировано. Процедуру удаления сотрудника из организации он не описывает вовсе — это другое событие. Смешать два этих журнала в ответе проверяющему легко. А распутывать получившуюся путаницу придётся не мне и не вам — тому, кто будет всё это перепроверять.
Акт достаёт то, что журнал недобрал
На этот случай приказ предусмотрел запасной ход — пункт 6: если выгрузка не позволяет указать отдельные сведения из тех пяти, недостающие вносятся в акт.
Это меняет вопрос, который стоит задавать движку. Не “закрывает ли журнал все пять полей приказа” — он их не закроет, это видно уже из разбора выше. А “сохраняет ли журнал то, что человек через год не восстановит по памяти”. Дату — сохраняет. Факт, что нужный шаг отработал, и чем он закончился, — тоже. Категории данных и название информационной системы движок не знает по своей природе: он работает с учётной записью, а не с классификатором персональных данных внутри неё. Эти два поля так и останутся за актом — и, по моим наблюдениям, у типового увольнения они от раза к разу не меняются, так что вписать их руками не так больно, как кажется на бумаге. Это наблюдение о практике, не требование приказа.
Копия остаётся жить дальше, если про неё забыли
Отдельная история — не про акт, а про то, что происходит после него. Учётную запись уничтожили, документы оформили, три года пошли. А письма и файлы того же человека спокойно лежат в резервной копии без всякого ограничения по времени — этим вопросом при увольнении просто никто не занимался.
В системе резервного копирования у копии можно выбрать тип. Срок хранения назначается только у архивного типа; копия, которая не архивная, идёт по обычному регулярному треку, и там своего срока хранения нет как параметра вообще. Есть отдельная настройка — переводить копии пользователя в архив автоматически при удалении его из организации, — но по умолчанию она выключена. Сама она не включится, включить её — осознанное действие кого-то из администраторов.
Слово “политика” здесь встречается дважды, и это ловушка, не совпадение. Политика копирования — про регулярные копии: расписание, состав. Политика хранения — про архив: сколько он живёт. У архивных тарифов срок продлевается конкретными шагами — 30, 60 или 90 дней, либо до конца текущей подписки. Добавить копию в политику — не то же самое, что назначить ей срок хранения; первое второго не делает автоматически.
На выходе из процедуры может получиться ситуация, которая выглядит образцово, а на деле — нет: акт подписан, выгрузка приложена, а данные уволенного продолжают жить бессрочно, просто в другом хранилище. Три года на документы и срок жизни самой копии — это две разные цифры про две разные вещи, и приказ вторую вообще не регулирует.
Возможно, я тут излишне придирчив. Инженер во мне гордится идемпотентностью и гейтингом, а приказу это неинтересно — ему нужны пять полей и подпись, а не элегантность графа. Стоило ли вообще строить надёжный движок, если фамилию под актом всё равно пишет человек руками? Я считаю — да: надёжность графа снимает другой класс проблем, не даёт удалить раньше, чем сняли копию, и не даёт продублировать удаление при повторном запуске. Но было бы честно услышать возражение.
У кого в вашей компании при автоматизированном увольнении подпись под актом — конкретный человек с именем, а не “наверное, кто-то из HR”?
ссылка на оригинал статьи https://habr.com/ru/articles/1068004/