Ситуация «подписал акт по безопасности КИИ, теперь говорят я виноват» почти всегда начинается одинаково: после инцидента в критической информационной инфраструктуре ищут «крайнего», и самым заметным становится тот, чья подпись стоит в акте, журнале или отчёте по мерам защиты. Следствие нередко пытается превратить управленческий документ в доказательство личной вины, хотя по смыслу он фиксирует организационные решения и состояние работ на дату подписания.
Опасность в том, что вас могут попытаться «привязать» к нарушениям правил эксплуатации или обеспечения безопасности КИИ через формальные признаки: должность, доступ к системам, участие в комиссиях, наличие регламентов. При этом игнорируются ключевые элементы состава: конкретная обязанность именно ваша, реальная возможность повлиять, причинно-следственная связь между действиями и последствиями, а также форма вины. Эту конструкцию нужно разбирать по процессуальному порядку и через допустимость доказательств.
Кратко по сути: Подписал акт по безопасности КИИ, теперь говорят я виноват
- Подпись в акте сама по себе не доказывает умысел и не отменяет презумпцию невиновности.
- Важны роль лица и конкретные обязанности: кто обязан был внедрять меры, кто согласовывал бюджет, кто администрировал контуры.
- Следствие должно показать квалификацию: какое именно правило нарушено, где оно закреплено и как применимо к вашей функции.
- Нужно проверять допустимость доказательств: кто изымал носители, как оформлялись протоколы, были ли специалисты, не нарушена ли целостность данных.
- Защита строится на позиции защиты: фактическая картина событий, разграничение ответственности, экспертизы и документальная база.
Тактика и стратегия в ситуации: Подписал акт по безопасности КИИ, теперь говорят я виноват
Первый риск — «подмена содержания»: акт трактуют как признание, хотя юридически это фиксация результатов обследования, выполнения мероприятий или согласование плана. Вторая угроза — расширительная интерпретация должностных обязанностей, когда административная функция превращается в якобы техническую ответственность за все сбои. Третья — давление через процессуальный порядок: быстрые допросы «без подготовки», выемка техники, попытка получить объяснения вместо показаний с предупреждением.
Точки контроля защиты: квалификация (какая норма и какой объект КИИ), форма вины (небрежность, легкомыслие или вообще отсутствие вины), причинно-следственная связь (инцидент мог быть следствием внешней атаки, действий подрядчика, дефектов оборудования), допустимость доказательств (цепочка хранения цифровых следов, корректность осмотров и копирования), а также использование специальных знаний (компьютерно-технические исследования, анализ журналов событий, конфигураций, политик доступа). Правильно выстроенная позиция защиты делает «подпись в акте» лишь одним из документов, а не якорем обвинения.
Нормативное регулирование и правовые институты
Дела по КИИ обычно опираются на уголовно-правовые запреты, связанные с нарушением правил эксплуатации и обеспечения безопасности критической инфраструктуры, а также на подзаконные требования к категориям значимости, моделям угроз, мерам защиты и организационным процедурам. Для защиты важно понимать не только формулировку уголовной нормы, но и правовые институты: презумпция невиновности, распределение бремени доказывания, требования к доказательствам, пределы ответственности должностных лиц, а также правила получения и исследования цифровой информации. На практике ключевой вопрос: какое правило было обязательным именно для вас и могло ли его нарушение объективно привести к последствиям, которые вменяются.
Как это работает на практике
Сценарий 1: Акт подписан как член комиссии.
Ситуация: вы участвовали в комиссии и подписали акт обследования или приемки мер. Риск/ошибка: следствие вырывает подпись из контекста и утверждает, что вы «подтвердили безопасность». Верное решение: показываем регламент комиссии, распределение функций, особые мнения, переписку, протоколы разногласий; доказываем, что подпись означает согласование процедуры, а не гарантию отсутствия уязвимостей.
Сценарий 2: Вы руководитель, но не администратор систем.
Ситуация: вы утвердили план мероприятий и бюджет, но доступов к контурам не имели. Риск/ошибка: вменяют «обязан был обеспечить», не раскрывая конкретных действий и возможностей. Верное решение: фиксируем управленческую роль, делегирование, приказы о назначении ответственных, договоры с подрядчиками, отчёты о выполнении; ставим вопрос о причинно-следственной связи и реальном контроле.
Сценарий 3: Инцидент связан с внешней атакой и ошибками подрядчика.
Ситуация: атака/вредоносное ПО, компрометация учетных записей, некорректные обновления. Риск/ошибка: вам вменяют нарушение правил эксплуатации, хотя первопричина — действия третьих лиц и дефекты в обслуживании. Верное решение: добиваемся экспертиз, истребуем логи, SLA, акты работ подрядчика, переписку по инциденту; проверяем, кто реально изменял конфигурации и имел привилегии.
Типичные ошибки в данной ситуации
- Давать «пояснения» без адвоката, смешивая факты, оценки и предположения.
- Подписывать новые документы «задним числом» или вносить правки в журналы после инцидента.
- Передавать пароли/токены или рабочие устройства «для проверки» без протоколов и без фиксации перечня изъятого.
- Соглашаться с формулировкой «я отвечал за безопасность» без уточнения границ полномочий и ресурсов.
- Игнорировать вопрос допустимости доказательств: как снимали образы дисков, кто имел доступ к копиям, не нарушена ли целостность.
- Не заявлять ходатайства о специалисте/экспертизе, из-за чего техническая версия обвинения остается без альтернативы.
Что важно учитывать для защиты прав
Ваша задача — не «оправдываться», а выстроить доказательственную логику, где каждый тезис обвинения проверяется: (1) какая норма и какое конкретное правило нарушено; (2) была ли у вас обязанность и возможность исполнить; (3) какие действия/бездействие именно ваши; (4) есть ли причинно-следственная связь с последствиями; (5) подтверждается ли это допустимыми доказательствами. Позиция защиты усиливается документами о распределении ролей, матрицами доступа, приказами, регламентами, перепиской, тикетами, актами работ и журналами изменений, а также выводами специалистов. Важно контролировать процессуальный порядок получения цифровых доказательств: осмотр, выемка, копирование, участие понятых/специалиста, описание носителей и хэш-сумм — любые нарушения дают основание ставить вопрос об исключении доказательств.
Практические рекомендации адвоката
- Немедленно зафиксируйте статус: вас вызывают как свидетеля, подозреваемого или «для беседы». На допросы — только с адвокатом.
- Соберите пакет документов: должностная инструкция, приказы о назначении ответственных, регламенты КИИ, состав комиссии, версии актов, переписка по замечаниям, отчёты подрядчиков.
- Составьте хронологию событий: даты инцидента, обнаружения, реагирования, кто и что делал, какие решения принимались и кем.
- Обеспечьте сохранность данных: не удаляйте файлы и переписку, но и не «чистите» системы; любые изменения должны быть обоснованы и документированы.
- Подготовьте линию показаний: только факты в пределах компетенции, без оценок «виноват/не виноват», без догадок о технических причинах.
- Инициируйте экспертизы и участие специалиста: по логам, доступам, конфигурациям, действиям подрядчика, соответствию мер установленным требованиям.
- Обжалуйте нарушения при изъятиях и осмотрах, заявляйте ходатайства о приобщении оправдывающих документов и допросе ключевых лиц.
Вывод
Фраза «подписал акт по безопасности КИИ, теперь говорят я виноват» — это не приговор, а типичная следственная версия, которую можно и нужно разбирать по элементам: обязанности, роль, причинно-следственная связь, форма вины и допустимость доказательств. Чем раньше вы выстроите позицию защиты и технически грамотную доказательственную базу, тем выше шанс остановить ошибочную квалификацию или добиться прекращения преследования.
Какой именно акт вы подписали: приемки работ, обследования, внутреннего аудита или устранения замечаний — и в каком статусе (руководитель, член комиссии, ИБ-специалист, подрядчик)?
Информация актуальна по состоянию на май 2026.