Comments 5
Подстановка идентификатора из результата предыдущего узла работает лучше любого регламента, тут соглашусь.
Удаление учётки сотрудника это ещё и уничтожение его персональных данных. Подтверждать его надо документом, и на проверке спрашивают именно его. Приказ РКН № 179: при обработке с использованием средств автоматизации подтверждающих документов два, акт об уничтожении и выгрузка из журнала регистрации событий в ИСПДн.
Ваш движок к этому ближе типовой инструкции: он и результат узла сохраняет, и текст ошибки не теряет, так что выгрузку он фактически уже формирует, вопрос только в том, попадает ли в лог нужное. Кто, что именно, когда и на каком основании.
Резервная копия уходящего, кстати, тоже не бессрочная. У неё должны быть цель и срок хранения.
Про 179-й приказ - сверился, всё так. При обработке с использованием средств автоматизации подтверждающих документа действительно два, и хранить их надо три года с даты уничтожения.
Но если разложить по составу, для движка картина не такая радужная. В выгрузке должны быть субъект, перечень категорий уничтоженных ПДн, наименование ИСПДн, причина и дата. Журнал запусков сам собой закрывает отсюда немного: дату и время, факт, что отработал именно узел удаления, статус и пройденную ветку согласования. Идентификатор сотрудника в процедуре есть - он приезжает из результата узла копии, той самой подстановкой, - но это ещё не значит, что он лежит в записи лога отдельным полем, пригодным для выгрузки. А категории ПДн и наименование системы движок не знает по своей природе: он оперирует учётной записью в тенанте, а не перечнем категорий. Эти два поля так и остаются за актом.
"На каком основании" - отдельно интересное. В процедуре основание физически присутствует: к письму согласующим прикладывается сам документ, и до кворума поток стоит, ничего не удаляя. То есть основание проходит через процесс, но в записи журнала оно не поле, а факт того, что ветка "Согласовано" была пройдена. Между "видно по подсвеченному пути" и "выгружается строкой с реквизитами документа" разница как раз в ту сторону, о которой Вы говорите.
И про "кто" - в приказе оно двоится. В выгрузке "кто" это субъект, чьи данные уничтожены. А ФИО, должность и подпись того, кто уничтожил, — это уже акт, и подписать его автомат не может. Забавно ложится на финал статьи: человек, который жмёт кнопку в начале процедуры, и есть тот, кто потом подписывает акт. В самой необратимой точке остаётся живой человек с фамилией, и это, пожалуй, единственное место, где я такой ручной труд не считаю недоработкой.
Про срок хранения копии - согласен, и это я в статье пропустил зря. Копия уходящего живёт по своей цели и своему сроку, они к сроку хранения самой учётки отношения не имеют. В системах копирования для этого есть политики с глубиной хранения и очисткой, но выставить цель и срок должен человек, а не "пусть лежит". Иначе получается смешное: учётную запись уничтожили по всем правилам, с актом и выгрузкой, а её содержимое бессрочно лежит в архиве - и проверяющему это будет интереснее аккуратного акта.
Забираю, спасибо. Тянет на отдельный разбор: не "как удалить", а "чем потом доказать, что удалил".
Дополню сам себя: у 179-го есть п. 6, который я в ответе пропустил. Если выгрузка из журнала не позволяет указать отдельные сведения из п. 5, недостающие вносятся в акт. Это снимает с лога требование полноты: он не обязан быть готовой выгрузкой, он обязан быть тем, из чего акт заполняется не по памяти. И Ваш вопрос "попадает ли в лог нужное" тогда становится точнее: важно не закрыть логом все пять полей, а закрыть те, которые человек через год уже не восстановит - идентификатор, дату, основание. Категории ПДн и наименование системы у типового оффбординга от случая к случаю не меняются, их место в акте.
Супер, вы разложили ещё точнее, чем я писал! И я как раз про п. 6 хотел написать следующим ходом. Понравилась ваша формула: лог обязан быть тем, «из чего акт заполняется не по памяти».
Тогда добавлю последнее, что осталось: п. 4 признаёт акт в электронной форме, подписанный по 63-ФЗ, равнозначным бумажному. Подписант остаётся человеком, но сам акт может жить в том же цифровом контуре, что и ваш процесс. Бумага из схемы уходит, ответственность нет.
Было бы здорово, если разберёте «Чем доказать, что удалил». С удовольствием почитаю, спасибо.
Про п. 4 - да, и он ставит последнюю точку. Когда сверялся, зацепился за концовку: электронный акт признаётся равнозначным бумажному, подписанному собственноручной подписью лиц из подпункта "г" пункта 3. Бумагу норма из схемы убирает, подпись - нет. Подписант так и остаётся человеком с ФИО и должностью, и это ровно Ваша мысль.
Мелочь для педантов: 63-ФЗ в тексте пункта не назван, он в сноске. В самом пункте - "подписанный в соответствии с законодательством Российской Федерации".
Разбор беру. Сначала закрою вопросы к своей же истории запусков: что там лежит отдельным выгружаемым полем, а что видно только глазами на подсвеченном пути. Иначе выйдет статья про приказ, а не про процедуру, а таких хватает и без меня. Спасибо за ветку - Вы мне половину плана собрали.
Оффбординг на автомате: почему «уволен» — слишком поздний сигнал, а «удалить» — шаг, который уже не отыграть