Организационное обеспечение информационной безопасности: политики, регламенты, ОРД и приказы в 2025–2026

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

В этом руководстве — как построить работающую документацию: иерархия от политики до инструкции, обязательные комплекты для ИСПДн, ГИС, КИИ и финансовых организаций, разработка и контроль исполнения

Организационная информационная безопасность: роль в системе защиты

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

Что такое организационное обеспечение информационной безопасности и его место в архитектуре СЗИ

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

• правовой — требования закона (152-ФЗ, 187-ФЗ, приказы ФСТЭК и ФСБ, положения ЦБ РФ);
• организационный — как они превращаются во внутренние правила: политики, регламенты, инструкции, приказы;
• технический — чем правила реализуются: средства защиты информации (СЗИ), контроль доступа, мониторинг;
• физический — контролируемая зона, СКУД, защита помещений и носителей.

Организационный слой первичен: сначала решается, что защищаем и кто отвечает, потом подбираются средства. Обратный порядок дает закупленные СЗИ, которые никто не эксплуатирует — ответственный не назначен, регламент не написан.

Услуга «Разработка комплекта ОРД»

Организационные меры информационной безопасности: отличие от технических и криптографических мер

Организационные меры информационной безопасности отличаются от технических предметом воздействия: технические меры ограничивают возможности систем, организационные — регулируют поведение людей и порядок процессов. Практическая разница:

• техническая мера — межсетевой экран не пропускает трафик из пользовательского сегмента в серверный;
• организационная мера — регламент: кто и на каком основании запрашивает такой доступ, кто согласует, как документируется;
• криптографическая мера — отдельный класс со своим регулятором (ФСБ) и правилами учета и допуска персонала (Инструкция ФАПСИ № 152).

Ни один слой не заменяет другой: техника без организации — набор устройств с настройками «по умолчанию от интегратора», организация без техники — декларация, которую нечем проконтролировать.

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

Требования регуляторов к организационному обеспечению (ФСТЭК, ЦБ РФ, ФСБ)

Требования к составу ОРД задаются по типу защищаемой системы и не унифицированы: комплекты для ИСПДн, ГИС и банка отличаются по составу и глубине. Ключевые источники на 2025–2026 годы:

• ФСТЭК России — Приказ № 21 (ИСПДн), Приказ № 117 (ГИС, заменил Приказ № 17 с 1 марта 2026 года), Приказ № 239 (значимые объекты КИИ), Приказ № 31 (АСУ ТП);
• ФСБ России — организация работ с СКЗИ: учет средств и ключевых документов, ответственные пользователи криптосредств;
• ЦБ РФ — ГОСТ Р 57580.1 как базовый стандарт, Положение № 851-П (заменило № 683-П с 29 марта 2025 года), Положение № 821-П (заменило № 719-П с 1 апреля 2024 года), а также 716-П, 742-П, 757-П, 802-П, 833-П по своим направлениям;
• Роскомнадзор — организационные аспекты обработки ПДн: политика на сайте, согласия, ответы на запросы субъектов.

Иерархия документов по информационной безопасности

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

Таблица 1. Иерархия организационных документов ИБ

Тип документа	Назначение	Детализация	Кто утверждает	Кто исполняет	Пересмотр
Политика ИБ	Принципы и цели защиты	Минимальная	Руководитель организации	Все сотрудники	Раз в 2–3 года
Положение	Правила по области: ПДн, доступ, инциденты	Средняя: «что» и «кто»	Руководитель или зам по безопасности	Подразделения в своей части	Раз в 1–2 года
Регламент	Процесс: действия, роли, сроки	Высокая: «как» и «когда»	Руководитель службы ИБ или ИТ	Владельцы процессов, ИБ, ИТ	Раз в год
Инструкция	Пошаговые действия для роли	Максимальная	Руководитель службы ИБ	Конкретная роль	Раз в год
Приказ	Назначение ответственных, ввод в действие	Точечная, обязывающая	Только руководитель	Названные в приказе лица	При изменениях

Политика информационной безопасности: стратегический документ верхнего уровня

Политика информационной безопасности — короткий документ, фиксирующий принципы защиты, область применения и распределение ответственности на уровне всей организации. Отвечает на вопрос «зачем и по каким правилам защищаем», но не описывает настройки и процедуры.

Рабочая структура политики ИБ:

1. Назначение и область действия — какие подразделения, системы и информация охвачены.
2. Цели защиты — в терминах бизнеса: непрерывность, соблюдение требований, защита данных клиентов.
3. Принципы — минимальные привилегии, разделение обязанностей, эшелонированность.
4. Распределение ответственности — руководство, служба ИБ, ИТ, владельцы процессов, сотрудники.
5. Ссылки на документы нижнего уровня.
6. Ответственность за нарушение — с отсылкой к трудовому законодательству.
7. Порядок пересмотра — периодичность и основания для внеочередного.

Ориентир по объему: политика ИБ верхнего уровня укладывается в 5–10 страниц. Документ на 60 страниц с настройками антивируса — это смешение уровней, которое никто не читает.

Политика обеспечения информационной безопасности: цели, задачи и принципы

Политика обеспечения информационной безопасности отличается акцентом: описывает не только принципы, но и целевую модель — какие процессы должны существовать и каких результатов от них ждут. В организациях, строящих СМИБ по ISO/IEC 27001, это основа всей системы.

Что фиксируется в целевой части:

• измеримые цели ИБ — не «повысить защищенность», а показатели: доля критических уязвимостей, закрытых в SLA, охват обучением, время реагирования;
• перечень процессов ИБ — доступ, уязвимости, инциденты, изменения, непрерывность;
• риск-ориентированность — меры по результатам оценки рисков, а не по каталогу;
• обязательства руководства — ресурсы и поддержка на уровне первого лица.

У публичной политики обработки ПДн другая роль: она пишется для субъектов, публикуется на сайте (ст. 18.1 152-ФЗ) и проверяется Роскомнадзором дистанционно — отсутствие фиксируется без выезда инспектора.

Положение об информационной безопасности: структура и назначение

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

Типовая структура положения:

• общие положения и термины, область применения и объекты защиты;
• участники процесса и их обязанности;
• требования к организации процесса: правила, ограничения, порядок решений;
• порядок контроля и ответственность, перечень связанных регламентов.

Востребованные положения: об обработке и защите ПДн, о разграничении доступа, о работе с машинными носителями, о коммерческой тайне, об организации работ с СКЗИ.

Регламент информационной безопасности: процессные документы для подразделений

Регламент информационной безопасности описывает процесс: кто, что, в какой последовательности и в какие сроки делает. На этом уровне документ становится проверяемым — регламент можно сверить с журналами.

Обязательные элементы работающего регламента:

• триггер — событие, запускающее процесс (заявка, алерт, увольнение);
• роли и матрица ответственности — кто инициирует, согласует, исполняет, контролирует;
• сроки на каждый шаг — без них процесс неконтролируем;
• артефакты — заявки, журналы, акты, тикеты;
• исключения — аварийный доступ, отсутствие согласующего.

Минимальный набор регламентов: управление доступом, реагирование на инциденты, управление уязвимостями и обновлениями, резервное копирование, управление изменениями, работа с подрядчиками.

Инструкция по информационной безопасности: детальные процедуры для сотрудников

Инструкция по информационной безопасности — документ для конкретной роли на языке действий: что делать, чего не делать, куда сообщать. Это единственный уровень, который сотрудник действительно читает, поэтому язык и объем критичны.

Практические требования к инструкциям:

• одна роль — одна инструкция: пользователю, администратору, ответственному за ПДн нужны разные документы;
• объем 2–4 страницы — длиннее не прочитают;
• формулировки в действиях: «увидели подозрительное письмо — не открывайте вложение, перешлите в службу ИБ» вместо «сотрудник обязан обеспечивать недопущение реализации угроз»;
• раздел «куда сообщать» — телефон и адрес службы ИБ без поиска по интранету;
• фиксация ознакомления — под подпись или через LMS с логированием.

Приказ об обеспечении информационной безопасности: юридическая сила и обязательность

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

Обязательные приказы, отсутствие которых фиксируется на проверке:

• о назначении ответственного за организацию обработки ПДн (ст. 22.1 152-ФЗ);
• о назначении администратора безопасности информационных систем;
• о вводе в действие политики ИБ и комплекта ОРД;
• об утверждении перечней обрабатываемых ПДн и допущенных лиц;
• об утверждении границ и состава систем (акты классификации, категорирования);
• о назначении ответственных пользователей СКЗИ;
• о создании комиссии по категорированию объектов КИИ.

Типовая ошибка:приказ подписан один раз при создании системы защиты и не обновляется. Через год ответственный уволился, структура изменилась, а документ по-прежнему называет несуществующие должности — при проверке это трактуется как отсутствие назначенного ответственного.

Разработка организационно-распорядительной документации (ОРД)

Комплект ОРД разрабатывается не «с шаблона», а от результатов обследования: сначала выясняется, какие системы и процессы есть и какие требования применимы, потом пишутся документы. Обратный порядок дает красивую папку, не имеющую отношения к организации.

Этапы разработки документов: от анализа рисков до утверждения руководителем

Разработка комплекта ОРД занимает 1–4 месяца и проходит шесть этапов, где написание текста — далеко не первый.

• Обследование — инвентаризация систем, данных, процессов, действующих документов и ролей.
• Определение применимых требований — 152-ФЗ, требования к ГИС, 187-ФЗ, ГОСТ Р 57580, положения ЦБ РФ.
• Оценка рисков и модель угроз — основание для выбора мер; документы опираются на нее, а не на общие представления.
• Проектирование комплекта — состав документов, иерархия и связи; видно, чего не хватает и что дублируется.
• Разработка текстов — с участием владельцев процессов: регламент без ИТ и бизнеса исполняться не будет.
• Согласование и утверждение — юристы, кадры, ИТ, затем приказ руководителя.

Согласование и ввод в действие: кто подписывает и как доводить до сотрудников

Документ вступает в силу с момента утверждения приказом руководителя, а обязанности у сотрудника — только после подтвержденного ознакомления. Порядок ввода в действие:

• согласование — служба ИБ, ИТ, юристы, кадры, владельцы процессов; лист согласования прикладывается;
• утверждение — приказом первого лица;
• доведение до сотрудников — под подпись либо через LMS с фиксацией факта и даты;
• включение в процесс приема на работу — наравне с охраной труда;
• хранение — актуальные версии в едином доступном месте, с контролем версий.

Типовые шаблоны и структура документов по требованиям ФСТЭК (Приказы №117, 21, 239)

Приказы ФСТЭК не содержат готовых шаблонов, но определяют состав мер, каждая из которых должна быть отражена в ОРД. Практичнее строить документы от групп мер приказа: при проверке легко показать соответствие «мера → пункт документа → запись об исполнении».

Соответствие групп мер и документов:

• ИАФ, УПД → положение о разграничении доступа, регламент управления доступом, матрица прав;
• РСБ → регламент сбора и анализа событий, порядок хранения журналов;
• АВЗ, СОВ → регламент антивирусной защиты, инструкция администратора;
• ЗНИ → положение о работе с носителями, журнал учета;
• ИНЦ → регламент реагирования, инструкции для сотрудников;
• ОДТ → регламент резервного копирования;
• АНЗ, УКФ → регламенты управления уязвимостями и изменениями.

Обязательные документы по информационной безопасности для разных категорий объектов

Минимальный комплект ОРД зависит от применимого регулирования. Частая ошибка — брать комплект для ИСПДн и считать, что он закроет требования к ГИС или значимому объекту КИИ.

Таблица 2. Обязательные документы для разных категорий объектов

Категория	Основные требования	Минимальный комплект ОРД
ИСПДн (152-ФЗ, Приказ № 21)	Уровни защищенности по ПП РФ № 1119	Публичная политика обработки ПДн, положение об обработке и защите, перечни ПДн и допущенных лиц, акт определения уровня защищённости ПДн, модель угроз, приказы, журналы, формы согласий
ГИС (Приказ № 117)	Класс защищенности, аттестация	Все для ИСПДн + акт классификации ГИС, ТЗ на систему защиты, документация на аттестацию, регламенты эксплуатации
ЗОКИИ (187-ФЗ, Приказ № 239)	Категорирование, ГосСОПКА	Приказ о комиссии, акты категорирования, перечень объектов, модель угроз, документы по реагированию и взаимодействию с ГосСОПКА
Финансовые организации (ГОСТ Р 57580.1, 851-П, 821-П)	Уровень защиты, периодическая оценка	Комплект по процессам ГОСТ Р 57580.1, регламенты доступа, инцидентов, уязвимостей, документы по оценке, отчетность в ЦБ РФ

ОРД для информационных систем персональных данных (ИСПДн) по 152-ФЗ

Комплект для ИСПДн нужен практически любой организации — данные сотрудников обрабатывают все. Обязательный минимум:

• политика обработки ПДн, опубликованная на сайте;
• положение об обработке и защите ПДн;
• перечни обрабатываемых ПДн и допущенных лиц с приказом о допуске;
• акт определения уровня защищённости ПДн по ПП РФ № 1119  и модель угроз;
• приказ о назначении ответственного за организацию обработки;
• формы согласий по ст. 9 152-ФЗ;
• журналы учета носителей, инструктажей, обращений субъектов;
• регламент реагирования со сроками уведомления Роскомнадзора (24 и 72 часа).

Смежная статья «Защита данных и 152-ФЗ»

ОРД для государственных информационных систем (ГИС) по Приказу ФСТЭК №117

Требования к ГИС с 1 марта 2026 года устанавливает Приказ ФСТЭК № 117, заменивший № 17. Ключевое отличие от ИСПДн — обязательная аттестация системы. Из нее вытекает дополнительный пласт документации:

• акт классификации ГИС с обоснованием класса;
• ТЗ на создание системы защиты и технический проект;
• программа и методики аттестационных испытаний;
• аттестат соответствия и протоколы испытаний;
• регламенты эксплуатации СЗИ и контроля защищенности.

Приказ № 117 расширил область применения с ГИС на все информационные системы госорганов, ГУП и государственных учреждений, сохранив обязательную аттестацию только для ГИС, и добавил к разовой аттестации регулярную оценку защищённости по числовым показателям (Кзи, Пзи) с отчётностью во ФСТЭК. В комплект ОРД добавляются: план перехода на требования № 117, регламент периодической оценки защищённости с порядком расчёта показателей и порядок формирования отчётности перед регулятором

ОРД для объектов критической информационной инфраструктуры (КИИ) по 187-ФЗ

Для субъектов КИИ документация начинается раньше системы защиты: сначала категорирование, потом меры по Приказу ФСТЭК № 239 в объеме присвоенной категории. Обязательные документы:

• приказ о создании комиссии по категорированию;
• перечень объектов КИИ и акты категорирования с присвоенной категорией (или обоснованием ее отсутствия);
• сведения о результатах, направленные во ФСТЭК;
• модель угроз и документация на систему безопасности значимого объекта;
• регламент взаимодействия с ГосСОПКА;
• с 1 марта 2026 года — документы о переходе на доверенные решения по 187-ФЗ в редакции ФЗ-325.

ОРД для финансовых организаций по требованиям ЦБ РФ (ГОСТ Р 57580, 683-П, 719-П)

Финансовый сектор регулируется наиболее плотно: ГОСТ Р 57580.1 задает состав мер по восьми процессам, а положения ЦБ РФ добавляют требования к уровню защиты и отчетности. Важное уточнение на 2026 год: Положение № 683-П заменено Положением № 851-П (с 29 марта 2025 года), а Положение № 719-П утратило силу 1 апреля 2024 года — его заменило Положение № 821-П.

Комплект для финансовой организации включает:

• документы по восьми процессам ГОСТ Р 57580.1 (доступ, защита сетей, целостность, защита от вредоносного кода, утечки, инциденты, виртуализация, удаленный доступ);
• политику и регламенты под требуемый уровень защиты (минимальный, стандартный, усиленный);
• документы по оценке соответствия ГОСТ Р 57580.1: для кредитных организаций (851-П) — не реже одного раза в два года; для НФО (757-П) — не реже раза в год при усиленном уровне и не реже раза в три года при стандартном. Во всех случаях оценку проводит внешняя организация — лицензиат ФСТЭК по ТЗКИ; самооценка применяется только как внутренний промежуточный контроль и оценку соответствия не заменяет;
• регламенты под требования 851-П и 821-П;
• порядок информирования ЦБ РФ и ФинЦЕРТ об инцидентах.

Контроль исполнения и актуализация документов

Утвержденный документ — начало работы, а не результат. Регулятор проверяет не бумагу, а следы ее исполнения: журналы, заявки, акты, записи об ознакомлении.

Как обеспечить реальное исполнение регламентов и инструкций в организации

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

• автоматизация через рабочие системы — заявки на доступ через сервис-деск, а не по почте: остается след и соблюдаются сроки;
• владелец у каждого документа — конкретный человек, а не «служба ИБ» абстрактно;
• метрики исполнения — доля заявок в срок, процент прошедших инструктаж, инциденты по плейбуку;
• выборочные внутренние проверки — берем регламент и сверяем по журналам за последние три месяца;
• разбор отклонений без поиска виноватого — систематическое нарушение чаще означает нереалистичный регламент, а не плохих людей.

Периодичность пересмотра и актуализации ОРД: требования регуляторов

Единой обязательной периодичности пересмотра ОРД закон не устанавливает, но регуляторы ожидают закрепленного цикла и внеочередного пересмотра при значимых изменениях. Практика:

• политика ИБ — раз в 2–3 года;
• положения и регламенты — раз в 1–2 года;
• инструкции — ежегодно и при каждом изменении процедур или ПО;
• оценка эффективности принятых мер и контроль выполнения требований — не реже одного раза в 3 года (п. 6 Приказа ФСТЭК № 21, п. 17 ПП РФ № 1119); модель угроз — актуализируется при изменении систем, состава обрабатываемых данных, появлении новых угроз и по результатам такой оценки;
• внеочередной пересмотр — при изменении инфраструктуры, состава обрабатываемых данных, организационной структуры, после инцидентов и при изменении законодательства.

Типовая ошибка: обновлять документы «под проверку». Регулятор видит дату утверждения: комплект, подписанный за неделю до визита, вызывает больше вопросов, чем документы с историей планового пересмотра.

Обучение сотрудников и аттестация знаний по документам ИБ

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

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

Типовые ошибки при разработке организационных документов

Проблемы с ОРД повторяются и почти всегда сводятся к трем причинам: формализм, разрыв уровней и отрыв от реальности.

Таблица 3. Топ-10 типовых ошибок при разработке ОРД

№	Ошибка	Как проявляется	Как предотвратить
1	Шаблон из интернета без адаптации	Упоминаются несуществующие подразделения	Разработка от обследования
2	Смешение уровней	Настройки антивируса в политике верхнего уровня	Иерархия: политика → положение → регламент → инструкция
3	Нет приказов о вводе в действие	Документы юридически не действуют	Приказ руководителя на каждый комплект
4	Нет фиксации ознакомления	Невозможно доказать доведение до сотрудника	Лист ознакомления или LMS с логированием
5	Регламент без сроков и ролей	Процесс неконтролируем	Матрица ответственности и сроки на каждый шаг
6	Документы не пересматриваются	Названы уволившиеся, устаревшие системы	Календарь пересмотра с владельцами
7	Разрыв с ИТ-реальностью	Процесса из регламента нет в сервис-деске	Разработка совместно с ИТ и владельцами
8	Модель угроз не связана с мерами	Меры «по каталогу» без обоснования	Прослеживаемость: угроза → мера → документ → запись
9	Нет записей об исполнении	Регламент есть, журналов нет	Артефакты процесса определены в самом регламенте
10	Инструкции написаны канцеляритом	Сотрудники не понимают, что делать	Язык действий, объем 2–4 страницы

Формальный подход: документы «для галочки», не работающие на практике

Формальный комплект узнается сразу: документы описывают идеальную организацию, а не вашу. Признаки:

• фигурируют подразделения и должности, которых нет в штатном расписании;
• регламенты ссылаются на невнедренные системы;
• журналы не заполняются или заполнены задним числом одним почерком;
• при инциденте никто не открывает регламент.

Последствие серьезнее замечания регулятора: при разбирательстве после утечки формальный комплект работает против организации, показывая, что заявленные меры не исполнялись.

Отсутствие связи между политикой верхнего уровня и процедурами нижнего уровня

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

Как проверить связность за полчаса: возьмите принцип из политики — например, «доступ по минимально необходимым правам». Пройдите вниз: есть ли положение о разграничении доступа, регламент выдачи прав, матрица ролей и заявки в сервис-деске за последний месяц. Обрыв на любом звене означает, что принцип не работает.

Несоответствие документов реальным бизнес-процессам и ИТ-инфраструктуре

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

• регламент требует согласования доступа за три дня, а бизнесу нужен час — согласуют задним числом;
• инструкция запрещает съемные носители, но обмен с подрядчиком идет только через них — файлы уходят в личные мессенджеры;
• порядок реагирования назначает ответственного, работающего с 9 до 18, а инциденты случаются ночью.

Решение — писать регламенты вместе с владельцами процессов и предусматривать легальные исключения: ускоренная процедура для срочных случаев лучше нарушаемого штатного порядка.

Услуга «Аудит организационных документов»

Экономика организационного обеспечения ИБ

Комплект ОРД — единственная часть системы защиты, где стоимость состоит из экспертного времени, а не лицензий. Поэтому выбор между своей разработкой и аутсорсингом — вопрос компетенций, а не только денег.

Стоимость разработки комплекта ОРД: in-house vs аутсорсинг

Разработка своими силами дешевле по прямым затратам, но требует специалиста, знающего и требования регуляторов, и внутренние процессы. Сравнение:

• in-house — ниже затраты, документы точнее отражают процессы, но выше риск пропустить требования и затянуть сроки; для зрелой службы ИБ;
• аутсорсинг — быстрее, с гарантией полноты и опытом проверок, но требует вовлечения заказчика: подрядчик без доступа к процессам напишет тот же шаблон;
• гибрид — внешняя экспертиза задает структуру, внутренняя команда наполняет содержанием; лучшее соотношение скорости и применимости.

ROI от качественного организационного обеспечения: снижение штрафов и инцидентов

Отдача от ОРД считается через предотвращенные издержки: штрафы, ущерб от инцидентов, стоимость авральной подготовки к проверкам. Порядок величин на 2026 год:

• неуведомление Роскомнадзора о начале обработки ПДн — до 300 тыс. рублей для юрлица; неуведомление об утечке в течение 24 часов — 1–3 млн;
• штрафы за утечки — до 15 млн рублей, при повторном крупном инциденте оборотный штраф 20–500 млн;
• смягчение оборотного штрафа предусмотрено ч. 3.4-2 ст. 4.1 КоАП: штраф снижается до одной десятой минимального (не менее 15 и не более 50 млн рублей) при выполнении всех условий нормы, ключевое из которых — расходы на мероприятия по защите информации не менее 0,1% годовой выручки ежегодно в течение трёх лет до года выявления нарушения, с привлечением лицензиатов. Сам по себе комплект ОРД основанием для снижения не является, но без него не подтверждается ни объём мероприятий, ни их результат;
• снижение операционных потерь — отработанный регламент реагирования сокращает простой при инциденте, а это прямые деньги.

Чек-лист: 15 обязательных документов по информационной безопасности для проверки Роскомнадзора

Комплект ниже закрывает базовые ожидания проверяющих для организации, обрабатывающей ПДн. Состав адаптируется под категорию объекта, но отсутствие любого пункта — гарантированное замечание.

1. Политика информационной безопасности — утверждена приказом.
2. Политика обработки персональных данных — опубликована на сайте организации.
3. Положение об обработке и защите ПДн.
4. Перечень обрабатываемых персональных данных и целей обработки.
5. Перечень лиц, допущенных к обработке ПДн, с приказом об их допуске.
6. Акт определения уровня защищённости ПДн по ПП РФ № 1119 (для ГИС — акт классификации, для объектов КИИ — акт категорирования).
7. Модель угроз по методике ФСТЭК с использованием БДУ.
8. Приказ о назначении ответственного за организацию обработки ПДн.
9. Приказ о назначении администратора безопасности.
10. Регламент управления доступом с матрицей прав и порядком выдачи и отзыва.
11. Регламент реагирования на инциденты со сроками уведомления регуляторов.
12. Регламент резервного копирования с проверкой восстановимости.
13. Инструкции для ролей — пользователя, администратора, ответственного пользователя СКЗИ.
14. Журналы учета — носителей, инструктажей, обращений субъектов, СКЗИ.
15. Записи об ознакомлении — листы или выгрузки из системы обучения.

Услуга «Внедрение СМИБ по ISO 27001»; смежные статьи «Технические меры защиты по ФСТЭК», «Аудит и оценка ИБ»

FAQ: частые вопросы об организационном обеспечении ИБ

Какие документы по информационной безопасности обязательны для всех организаций, обрабатывающих персональные данные?

Минимум: публичная политика обработки ПДн на сайте, положение об обработке и защите, перечни данных и допущенных лиц, приказ о назначении ответственного,акт определения уровня защищённости ПДн по ПП РФ № 1119, модель угроз, формы согласий по ст. 9 152-ФЗ и журналы учета. Набор нужен даже тем, кто обрабатывает только данные своих сотрудников.

Чем Политика информационной безопасности отличается от Положения об информационной безопасности?

Уровнем и охватом. Политика — документ верхнего уровня для всей организации: принципы, цели, ответственность, 5–10 страниц, утверждает первое лицо. Положение регулирует конкретную область и адресовано участникам процесса. Политика отвечает «зачем и по каким принципам», положение — «что и кто делает».

Нужно ли согласовывать внутренние регламенты ИБ с ФСТЭК или ЦБ РФ?

Нет. Внутренние документы утверждает руководитель организации, с регуляторами они не согласовываются — те проверяют содержание и исполнение при контрольных мероприятиях. Отдельно существует обязательное направление сведений: результаты категорирования КИИ — во ФСТЭК, уведомление об обработке ПДн — в Роскомнадзор, отчетность по инцидентам — в ЦБ РФ и ГосСОПКА.

Как часто нужно пересматривать и актуализировать документы по информационной безопасности?

Практика: политика — раз в 2–3 года, положения и регламенты — раз в 1–2 года, инструкции — ежегодно, модель угроз — не реже раза в 3 года. Внеочередной пересмотр обязателен при изменении инфраструктуры, состава данных, оргструктуры, после инцидентов и при изменении законодательства. Периодичность закрепляется в самих документах — проверяющий смотрит и на цикл, и на его соблюдение.

Обязательно ли назначать отдельного ответственного за информационную безопасность приказом руководителя?

Ответственный за организацию обработки ПДн назначается обязательно — прямое требование ст. 22.1 152-ФЗ. Для систем с повышенными требованиями добавляется администратор безопасности. Совмещение ролей допустимо, но назначение оформляется приказом: без документа обязанность юридически ни на кого не возложена.

«Какие организационные меры проверяются при проверке оператора ИСПДн?»

«У коммерческого оператора проверку проводит Роскомнадзор — по проверочному листу, утверждённому приказом РКН № 253. ФСТЭК и ФСБ контролируют меры защиты ПДн только в государственных ИСПДн и в системах госорганов (ч. 8 ст. 19 152-ФЗ), но состав мер для любого оператора задаёт Приказ ФСТЭК № 21, и проверяется наличие и исполнение документов по его группам мер. Основное: назначение ответственных, разграничение доступа и матрица прав, работа с носителями и журнал учета, регламенты антивирусной защиты и реагирования на инциденты. Дополнительно смотрят регистрацию событий и хранение журналов, обучение с подтверждением ознакомления и акт оценки эффективности мер — она проводится не реже раза в 3 года.»

Можно ли использовать типовые шаблоны документов из интернета для прохождения проверки регулятора?

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

Как доказать, что сотрудники ознакомлены с инструкциями по ИБ (под роспись, в LMS, тестирование)?

Надежнее всего лист ознакомления с личной подписью и датой — он принимается и в трудовых спорах. Электронная система допустима, если фиксирует идентифицированного пользователя, дату и факт прохождения, а порядок закреплен локальным актом. Оптимально: подпись при приеме на работу для базового комплекта плюс ежегодное обучение с тестированием в LMS.

*Материал актуален на 2026 год: учтены Приказы ФСТЭК России № 21, № 117 (заменил № 17 с 01.03.2026), № 239 и № 31, ГОСТ Р 57580.1, Положения Банка России № 851-П (заменило № 683-П) и № 821-П (заменило № 719-П), 152-ФЗ и 187-ФЗ в редакции ФЗ-325 от 31.07.2025.*