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