Оффбординг сотрудника в Яндекс 360: что попадает в журналы, а что придётся вписывать в акт руками

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

Я разбираю задачу не со стороны «как удалить», а со стороны «что остаётся в системах после удаления и как это оттуда достать». Речь про два продукта компании «+Альянс»: «+Альянс Поток», которым в Яндекс 360 автоматизируют рутинные операции (в том числе кадровые), и «+Альянс Бэкап Яндекс 360», который снимает копии почты, Диска, календарей и прочего содержимого той же платформы. Там, где подтверждения нет, я это говорю прямо: текст про доказательства, а в нём догадка обходится дороже молчания.

Одна рамка перед разбором. Приказ Роскомнадзора от 28.10.2022 № 179 обращён к оператору персональных данных — он задаёт, чем оператор подтверждает уничтожение. Требований к программному обеспечению в приказе нет, и вывести из возможностей сервиса соблюдение нормы (равно как и её нарушение) нельзя. Разбор ниже инженерный: какие сведения система способна отдать и в каком виде.

Факты в статье приведены по состоянию на 7 августа 2026 года.

Коротко

• Приказ Роскомнадзора от 28.10.2022 № 179 при обработке персональных данных с использованием средств автоматизации требует двух подтверждающих документов: акта об уничтожении и выгрузки из журнала регистрации событий информационной системы (п. 2; текст приказа сверен 03.08.2026).
• Запись о запуске в «+Альянс Потоке» содержит статус, имя потока, способ запуска и длительность каждого шага; у шага копирования дополнительно раскрывается блок логов бэкапа (разработчик «+Альянс Потока», 03.08.2026).
• Экспорта истории запусков в «+Альянс Потоке» нет: перечисленное доступно только в веб-интерфейсе (разработчик, 03.08.2026).
• В «+Альянс Бэкапе Яндекс 360» журналы операций выгружаются в CSV, инициатор указан у каждой операции (страница продукта plus-aliance.ru, зафиксирована 16.07.2026).
• Срок хранения в «+Альянс Бэкапе Яндекс 360» назначается архивной копии; у копии на регулярном треке такого параметра нет (разработчик, 03.08.2026).

Что приказ № 179 называет подтверждением уничтожения

Подтверждение уничтожения персональных данных — это комплект документов, которым оператор доказывает факт уничтожения данных конкретного человека; при автоматизированной обработке в комплект входят акт об уничтожении и выгрузка из журнала регистрации событий информационной системы персональных данных (приказ Роскомнадзора от 28.10.2022 № 179, п. 2).

Полное имя акта — «Об утверждении Требований к подтверждению уничтожения персональных данных», регистрация в Минюсте 28.11.2022 под № 71167. Текст мы сверяли 03.08.2026 по публикациям rulaws.ru и КонсультантПлюс; на ту же дату приказ действует в редакции от 28.10.2022.

Два документа, а не один

Обработка без средств автоматизации закрывается одним документом — актом об уничтожении (п. 1 приказа № 179). Как только появляется автоматизация, документов становится два: «акт об уничтожении персональных данных <…> и выгрузка из журнала регистрации событий в информационной системе персональных данных» (п. 2).

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

Пять сведений в выгрузке, подпись — в акте

Состав выгрузки задан пунктом 5 приказа № 179, и позиций там ровно пять:

1. ФИО субъекта или иная относящаяся к нему информация.
2. Перечень категорий уничтоженных персональных данных.
3. Наименование информационной системы, из которой данные уничтожены.
4. Причина уничтожения.
5. Дата уничтожения.

Акт устроен подробнее: десять подпунктов, среди которых реквизиты оператора, категории данных, способ и причина. Для инженерного разбора важен подпункт «г» — ФИО, должность лиц, уничтоживших персональные данные, и их подпись. Ни одну из этих трёх позиций журнал не хранит, и появиться им там неоткуда.

Электронная форма положение дел не меняет. Акт в электронной форме, «подписанный в соответствии с законодательством Российской Федерации», признаётся равнозначным бумажному, подписанному собственноручно теми самыми лицами из подпункта «г» (п. 4 приказа № 179; закон об электронной подписи 63-ФЗ упомянут в сноске к пункту, а не в его тексте). Электронная подпись снимает вопрос бумаги, но подпункт «г» продолжает требовать конкретных ФИО и должности.

И последнее по норме, что важно при проектировании процедуры: хранить оба документа приказ № 179 велит три года с момента уничтожения персональных данных (п. 8). Срок относится к документам — не к данным и не к резервным копиям.

История запусков «+Альянс Потока»: состав записи

Сначала разведу две сущности, которые склеиваются на автомате. В приказе № 179 фигурирует журнал регистрации событий информационной системы персональных данных. Ниже речь про историю запусков сценария в «+Альянс Потоке» — продукте компании «+Альянс», которым автоматизируют рутину в Яндекс 360. Знак равенства между ними я не ставлю: у истории запусков другой предмет — сработал ли сценарий и на каких шагах.

Состав записи о запуске разработчик «+Альянс Потока» перечислил 03.08.2026: статус; поток, который отработал; триггер; каждый шаг с его длительностью. Когда в потоке есть шаг копирования, внутри него раскрывается блок логов бэкапа: как называется копия, когда она началась и когда завершилась — с секундной точностью, — сколько выполнено, сколько пропущено и сколько ошибок.

Сам раздел «История потоков» показывает запуски таблицей: столбцы СТАТУС, ПОТОК, ТРИГГЕР, ЗАПУСК, ДЛИТ., ШАГОВ, статусы ГОТОВО и ОШИБКА, длительность в миллисекундах, фильтры по статусу и потоку, пагинация. Отдельный запуск раскрывается панелью хода выполнения: шаги пронумерованы, у каждого свой индикатор состояния.

Раздел «История потоков» в «+Альянс Потоке»: таблица запусков со статусом, триггером, длительностью и числом шагов. Данные на экране демонстрационные.

Сведения приказа против содержимого записи

Сопоставление ниже — про состав данных, а не про соответствие норме. Из таблицы не следует ни то, что продукт приказу соответствует, ни обратное: соблюдение процедуры оценивает оператор, и это отдельный разговор.

Пункт 6 приказа № 179 снимает с журнала требование полноты: если выгрузка «не позволяет указать отдельные сведения», недостающее вносится в акт об уничтожении. История запусков не обязана быть готовым документом. Её задача — сохранить то, из чего акт заполнят потом, не восстанавливая события по памяти.

Из пункта 6 приказа № 179 следует практический критерий для настройки сценария. Проверять журнал на «все пять полей» бессмысленно — все пять там и не появятся. Смотреть нужно, остаётся ли в записи то, чего через год без неё не восстановишь: дата, срабатывание нужного шага и его результат. Категории персональных данных и название информационной системы для типового увольнения одинаковы от случая к случаю — но это моя оценка практики, а не требование приказа.

Чего в записи нет

Дальше ограничения как есть, без смягчающих оборотов.

Экспорта истории запусков в «+Альянс Потоке» нет (разработчик, 03.08.2026). Данные о запусках читаются в веб-интерфейсе, а собрать из них файл для приложения к акту продукт не умеет.

Согласование оставляет после себя меньше, чем можно подумать. Запись сохраняет одно: ветка «Согласовано» пройдена. До решения в шаге перечислены те, чьего ответа ждут. Отметки времени у согласования нет, имени того, кто его дал, — тоже (разработчик, 03.08.2026).

Идентификатор увольняемого в процедуре участвует: узел удаления берёт пользователя выражением {backup.uid}, а это значение приходит из шага копирования. Хранится ли идентификатор в самой записи как отдельное поле, я не знаю — подтверждения этому не нашлось.

Как собран сценарий увольнения

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

1. Запуск — вручную. Сценарий поднимает человек. Причина инженерная: событие об увольнении приходит в «+Альянс Поток» постфактум, а полную копию после удаления аккаунта уже не снять (разработчик, 30.07.2026).
2. Узел «Согласование». Подсказка в панели узла описывает механику дословно: «Согласующему уходит персональная ссылка „Согласовать“ / „Отклонить“ — по e-mail и/или в Яндекс Мессенджер (личным сообщением от бота). Поток приостанавливается до решения». Кворум настраивается: «Нужны все» либо «Достаточно любого». Файл согласования прикладывается с локального компьютера или с Яндекс Диска. Ссылка персональная и одноразовая: токен внутри неё зашифрован, ответить по ней второй раз нельзя.
3. Узел «Бэкап пользователя». Копия снимается, пока сотрудник ещё в тенанте Яндекс 360. Порядок гарантирован самим продуктом: до успешного завершения копирования необратимые действия не выполняются, в документации «+Альянс Потока» это называется гейтингом бэкапа.
4. Узел «Исходящий вебхук». В шаблоне он стоит заглушкой под любое действие заказчика — например, под задачу в Яндекс Трекере для кадровой службы. Обязательной частью оффбординга этот шаг не является.
5. Узел «Удалить пользователя». Вход узла — выражение {backup.uid}, результат предыдущего шага. Без успешно снятой копии подставлять в узел удаления попросту нечего.

Шаблон увольнения в редакторе «+Альянс Потока»: четыре узла и открытая панель узла «Согласование» с кворумом и списком согласующих. Адреса на экране демонстрационные.

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

Пара свойств движка, которые в разговоре о доказательствах значат больше, чем кажется. У каждого действия на холсте есть отдельный выход «Ошибка»; при временных сбоях действие повторяется с экспоненциальной задержкой, а если попытки закончились, запуск падает и текст ошибки сохраняется. Повторный старт упавшего потока продолжается с точки сбоя, и необратимый шаг, который уже отработал, заново не исполняется — берётся его прежний результат. То есть перезапуск после падения не превращается во второе удаление и не рисует в журнале вторую процедуру там, где она была одна.

Два журнала, которые легко перепутать

У «+Альянс Бэкапа Яндекс 360» с журналами дела обстоят иначе, чем у «+Альянс Потока», и подменять один другим не стоит.

Соблазн понятен: экспорт есть — значит, есть чем закрыть выгрузку. Поддаваться не стоит. Журналы «+Альянс Бэкапа Яндекс 360» описывают копирование данных, а не удаление аккаунта из организации в Яндекс 360. События разные, и подменять их в документе, который потом читают построчно, — плохая идея.

Срок жизни копии уволенного

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

Разработчик «+Альянс Бэкапа Яндекс 360» описал механику 03.08.2026 так: тип копии выбирается, и параметр срока хранения есть у архивного типа. Копия без него уходит на регулярный трек, где такого параметра просто не предусмотрено.

Отдельно про терминологическую ловушку: в продукте два разных понятия со словом «политика». Политика копирования — про регулярные копии, то есть про расписание и состав копирования; её назначает узел «+Альянс Потока» «Добавить пользователя в политику бэкапа». Политика хранения относится к архиву и отвечает за срок его жизни. Первое действие второго не выполняет, хотя звучат они похоже.

На стороне «+Альянс Бэкапа Яндекс 360» для этого предусмотрена штатная настройка. На вкладке «Политики компании» она сформулирована так: «Автоматически переводить копии данных пользователя в архив при удалении его из организации (с указанием бакета и политики хранения) (По умолчанию „отключено“)» (страница продукта, 16.07.2026). Само собой это не включится: настройку кто-то должен осознанно включить.

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

Возврат данных из копии «+Альянс Бэкапа Яндекс 360», в том числе когда аккаунта сотрудника уже нет, описан в статье «Как восстановить удалённый файл или письмо в Яндекс 360: где искать, сколько дней осталось и когда вернуть уже нельзя».

Выводы

• Уничтожить данные и доказать уничтожение — задачи разной природы. Вторую при проектировании процедуры обычно не формулируют вовсе.
• История запусков «+Альянс Потока» — не готовая выгрузка по приказу № 179, а источник, из которого заполняют акт; пункт 6 приказа это прямо допускает.
• Критерий для журнала один: сохраняет ли он то, чего память через год не выдаст, — дату, срабатывание шага и его исход.
• Экспорта истории запусков в «+Альянс Потоке» нет, отметки времени согласования в записи тоже нет. Процедуру нужно планировать с учётом этого, а не вопреки.
• Копии уволенного нужны тип и назначенный срок: в «+Альянс Бэкапе Яндекс 360» срок хранения существует у архивной копии, у регулярной его нет.
• Приказ № 179 отводит акту и выгрузке три года хранения. Место для них разумно определить заранее — не тогда, когда документы уже спросили.

Частые вопросы

Заменяет ли история запусков «+Альянс Потока» выгрузку из журнала регистрации событий?

Нет, и мы её так не подаём. История запусков фиксирует ход сценария; журнал регистрации событий информационной системы персональных данных — термин приказа Роскомнадзора № 179, и оснований приравнивать к нему историю запусков нет. По пункту 6 приказа сведения, которых в выгрузке не оказалось, вносятся в акт об уничтожении.

Можно ли выгрузить историю запусков «+Альянс Потока» в файл?

Нет. Разработчик «+Альянс Потока» подтвердил 03.08.2026, что экспорта истории запусков в продукте нет: статусы, шаги, длительности и логи копирования доступны в веб-интерфейсе. Экспорт в CSV есть у другого продукта — у журналов операций «+Альянс Бэкапа Яндекс 360», но там записано копирование, а не процедура увольнения.

Что остаётся в записи о согласовании?

Факт прохождения ветки «Согласовано», а до принятия решения — список тех, чьего ответа ждут. Времени согласования и имени согласовавшего в записи нет; документ-основание, приложенный к письму, в истории не отображается (разработчик «+Альянс Потока», 03.08.2026).

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

Через архивный тип копии: в «+Альянс Бэкапе Яндекс 360» параметр срока хранения существует у архивных копий, а копия без этого типа уходит под регулярное копирование, где своего срока не имеет (разработчик, 03.08.2026). Отдельно есть настройка автоматического перевода копий пользователя в архив при удалении его из организации — по умолчанию она отключена.

Соответствует ли «+Альянс Поток» приказу Роскомнадзора № 179?

Такой вопрос к продукту не адресуется. Приказ № 179 устанавливает требования к подтверждению уничтожения персональных данных оператором и описывает документы, а не свойства программного обеспечения. Мы описываем, какие сведения система отдаёт, и вывода о соответствии из этого не делаем.

Сколько хранить акт и выгрузку?

Три года с момента уничтожения персональных данных — так установлено пунктом 8 приказа Роскомнадзора от 28.10.2022 № 179 (текст сверен 03.08.2026). Сроков хранения самих резервных копий эта норма не касается.

Внесены ли «+Альянс Поток» и «+Альянс Бэкап Яндекс 360» в реестр российского ПО?

Нет. «+Альянс Поток» в реестр не внесён, а регистрацию «+Альянс Бэкапа Яндекс 360» компания «+Альянс» проходит, и она не завершена. Единственный продукт компании с записью в реестре — «Мигратор Т2Т», запись № 28672 от 09.07.2025.

Посмотреть на своей процедуре

Проверять такое лучше не по статье, а по собственному сценарию: собрать его, прогнать и посмотреть, что именно осталось в записи о запуске. Первые тридцать дней «+Альянс Поток» работает бесплатно и банковской карты не спрашивает. Хотите разобрать процедуру вместе — напишите на zakaz@plus-aliance.ru, соберём демонстрацию под ваши сценарии.

И совет напоследок: проектируйте процедуру с конца — с полей акта. Тогда список того, что обязано остаться в журнале, соберётся сам, а не выяснится через полгода в неподходящий момент.

Чем это решается. «+Альянс Бэкап» — это сервис резервного копирования Яндекс 360 для бизнеса от компании «+Альянс». Копии данных уволенного сотрудника остаются в вашем S3-совместимом хранилище и после того, как ящик удалён, а восстановить можно отдельное письмо, файл или весь ящик на выбранную дату — то есть акт подкрепляется не только записью в журнале.

Александр Жогов, основатель и руководитель компании «+Альянс».