Как разработать документы по информационной безопасности: пошаговое руководство

Документы по информационной безопасности — фундамент, на котором строится вся система защиты информации в организации. Без качественной документации невозможно ни выполнить требования регуляторов (ФСТЭК, ФСБ, Роскомнадзор), ни выстроить реальные процессы ИБ. При этом разработка документов ИБ — задача, которая пугает даже опытных специалистов: слишком много нормативных актов, слишком много типов документов, слишком высокая цена ошибки при проверке.

В этом руководстве разберём пошаговый алгоритм разработки полного пакета документов по информационной безопасности: от анализа требований до внедрения и контроля актуальности. Покажем иерархию документов, обязательные комплекты для разных типов организаций и то, как SGRC-система автоматизирует процесс.

Зачем организации нужны документы по информационной безопасности

Нормативные требования: 152-ФЗ, 187-ФЗ, ФСТЭК, ФСБ

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

• 152-ФЗ «О персональных данных» — обязывает оператора ПДн утвердить политику обработки персональных данных, назначить ответственного, разработать модель угроз, определить уровень защищённости ИСПДн.
• 187-ФЗ «О безопасности КИИ» — требует от субъектов КИИ провести категорирование объектов, разработать модель угроз, обеспечить реагирование на инциденты.
• Приказы ФСТЭК № 17, 21, 31, 239 — устанавливают конкретные требования к организационно-распорядительным документам по защите информации для ГИС, ИСПДн, АСУ ТП и значимых объектов КИИ.
• Приказы ФСБ — определяют требования к документации по криптографической защите информации (СКЗИ).

Отсутствие обязательных документов — основание для предписания регулятора и административных штрафов. С 2025 года штрафы по 152-ФЗ существенно увеличены: до 15–18 млн рублей за утечку крупных баз ПДн, до 500 млн руб. при повторном нарушении.

Документы ИБ как основа системы управления безопасностью

Документация ИБ — не просто бумага для проверяющих. Это рабочий инструмент, который:

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

Что проверяют регуляторы: чек-лист документов

При проверке регуляторы в первую очередь запрашивают:

Полный перечень документов ИБ для организации

Уровни документации: политики, стандарты, регламенты, инструкции

Документы ИБ организованы в строгую иерархию — от стратегических к операционным:

Уровень 1. Политики — верхнеуровневые документы, утверждаемые руководителем организации. Определяют цели, принципы и общие правила ИБ.

Уровень 2. Стандарты и положения — детализируют политики для конкретных областей. Например, стандарт управления доступом описывает принципы (минимальные привилегии, разделение обязанностей), но не содержит пошаговых процедур.

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

Уровень 4. Инструкции — пошаговые руководства для конкретных ролей. Инструкция администратора по настройке межсетевого экрана.

Уровень 5. Формы и записи — журналы, акты, протоколы, чек-листы. Журнал учёта СКЗИ, акт уничтожения ПДн, протокол ознакомления с политикой ИБ.

Обязательные документы для оператора ПДн

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

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

Дополнительные документы для субъекта КИИ

Субъектам КИИ (187-ФЗ, ПП-127) дополнительно требуются:

• Приказ о создании комиссии по категорированию
• Перечень объектов КИИ
• Акты категорирования для каждого объекта
• Модель угроз для значимых объектов КИИ
• План реагирования на компьютерные инциденты
• Регламент информирования ГосСОПКА (НКЦКИ)
• Регламент обеспечения безопасности значимых объектов КИИ
• План мероприятий по обеспечению безопасности значимых объектов КИИ

Для субъектов КИИ общий объём документации может достигать 40–60 документов. Ручная разработка и поддержание актуальности такого массива требует выделенного специалиста.

Документы для финансовых организаций (ГОСТ 57580)

Финансовые организации, подпадающие под требования ГОСТ Р 57580.1, дополнительно формируют:

• Политика управления операционными рисками (в части ИБ)
• Регламент обеспечения защиты информации при осуществлении переводов денежных средств
• Документы по управлению уязвимостями
• Документы по мониторингу и реагированию на инциденты ИБ
• Документы по управлению жизненным циклом АС и приложений

Шаг 1 — Определение нормативных требований

Анализ применимого законодательства

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

1. Обрабатываете ли вы персональные данные? Если да — применяется 152-ФЗ, ПП-1119, приказ ФСТЭК № 21.
2. Является ли организация субъектом КИИ? Проверьте, относится ли ваша деятельность к одной из 13 отраслей по 187-ФЗ (здравоохранение, транспорт, энергетика, связь, финансы и др.).
3. Эксплуатируете ли вы ГИС? Если да — приказ ФСТЭК № 17.

Помимо федерального законодательства, учитывайте отраслевые стандарты: ГОСТ 57580 для финансового сектора, приказы Минздрава для медицинских организаций, требования SWIFT CSP для банков, работающих с международными платёжными системами.

Определение класса и уровня защищённости

На основе анализа определите:

• Уровень защищённости ИСПДн (УЗ-1 – УЗ-4) — по ПП-1119, на основе типа угроз, категории ПДн и объёма данных.
• Класс ГИС (К1 – К3) — по приказу ФСТЭК № 17, на основе уровня значимости информации и масштаба ИС.
• Категорию значимости объекта КИИ (1 – 3 или без категории) — по ПП-127, на основе критериев значимости.

От класса и уровня зависит конкретный набор обязательных мер защиты и, соответственно, документов.

Формирование матрицы требований к документации

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

Эта матрица становится планом работ и позволяет контролировать полноту покрытия требований.

Шаг 2 — Инвентаризация существующих документов

Аудит текущей документации

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

• разбросаны по разным отделам и сетевым папкам;
• утверждены несколько лет назад и не пересматривались;
• разработаны под старые версии нормативных актов;
• существуют в нескольких версиях, и неясно, какая актуальна.

Оценка актуальности и полноты

Для каждого найденного документа оцените:

• Актуальность — соответствует ли текущему законодательству, ИТ-инфраструктуре и организационной структуре?
• Полнота — покрывает ли все требования, которые должен закрывать?
• Применимость — используется ли документ на практике или лежит на полке?
• Версионность — есть ли история изменений, дата последнего пересмотра?

GAP-анализ: что есть и чего не хватает

Сопоставьте матрицу требований (шаг 1) с результатами инвентаризации. Для каждого требования определите статус:

Модуль документов ИБ в КиберОснова автоматически определяет, каких документов не хватает для соответствия выбранным нормативным требованиям, и формирует приоритизированный план разработки.

Шаг 3 — Разработка и адаптация документов

Иерархия документов: от политики к инструкциям

Разрабатывайте документы сверху вниз — от стратегических к операционным:

1. Политика ИБ — первый и главный документ. Определяет цели, принципы, область действия. Утверждается руководителем организации. Все остальные документы ссылаются на политику.
2. Стандарты и положения — разрабатываются на основе политики. Положение об управлении доступом, стандарт классификации информации.
3. Регламенты — описывают конкретные процессы. Регламент управления инцидентами, регламент резервного копирования.
4. Инструкции — пошаговые руководства для ролей. Инструкция пользователю ИСПДн, инструкция администратору безопасности.
5. Формы — шаблоны для фиксации результатов. Акт уничтожения, журнал учёта, лист ознакомления.

Использование типовых шаблонов

Типовые шаблоны экономят 50–70% времени разработки. Источники шаблонов:

• Методические рекомендации ФСТЭК и ФСБ
• Отраслевые стандарты (ГОСТ 57580, СТО БР ИББС)
• Консалтинговые компании и интеграторы
• SGRC-платформы с встроенными генераторами документов

Однако шаблон — это заготовка, а не готовый документ. Без адаптации он бесполезен.

Адаптация под специфику организации

При адаптации шаблона обязательно:

• Укажите конкретные информационные системы организации (не «ИС-1», а «1С:Зарплата и управление персоналом 8.3»).
• Пропишите реальные роли и должности (не «администратор», а «ведущий системный администратор отдела ИТ»).
• Учтите фактическую ИТ-инфраструктуру — серверы, сети, облачные сервисы, удалённый доступ.
• Согласуйте терминологию с другими внутренними документами.
• Приведите ссылки на актуальные версии нормативных актов.

Типичные ошибки при разработке

Копирование без адаптации. Регуляторы видят шаблонные документы: если в политике ИБ банка описана «организация здравоохранения» — это повод для предписания.

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

Внутренние противоречия. Парольная политика требует менять пароль каждые 30 дней, а инструкция администратора — каждые 90 дней. Все документы должны быть согласованы между собой.

Избыточная детализация. Политика ИБ на 80 страниц, которую никто не читает, хуже, чем ёмкий документ на 15 страниц. Детали — в регламентах и инструкциях, не в политике.

Шаг 4 — Согласование и утверждение

Порядок согласования: ИБ, ИТ, юристы, кадры

Документы ИБ затрагивают интересы нескольких подразделений. Типовая цепочка согласования:

1. Подразделение ИБ — разработчик, проверяет техническую корректность.
2. ИТ-подразделение — проверяет реализуемость технических требований.
3. Юридическая служба — проверяет соответствие законодательству, корректность ссылок на НПА.
4. Кадровая служба — проверяет корректность требований к персоналу, механизмы ознакомления.
5. Руководители бизнес-подразделений — подтверждают, что требования не блокируют бизнес-процессы.

Согласование — самый долгий этап. При ручном процессе (бумажные листы согласования, пересылка по email) один документ согласуется 2–4 недели. При наличии 20+ документов процесс затягивается на месяцы.

Утверждение руководителем

После согласования документ утверждается руководителем организации (генеральным директором) или лицом, которому делегированы соответствующие полномочия. Утверждение оформляется:

• грифом «УТВЕРЖДАЮ» на первой странице документа, или
• приказом об утверждении (рекомендуется для политик и ключевых регламентов — приказ фиксирует дату ввода в действие и список ответственных).

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

Все сотрудники, на которых распространяется действие документа, должны быть ознакомлены с ним под подпись. Это критично для:

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

Ознакомление фиксируется в листе ознакомления (приложение к документу) или в отдельном журнале.

Шаг 5 — Внедрение и контроль актуальности

Доведение до исполнителей

Утверждённый документ необходимо довести до всех исполнителей. На практике это означает:

• размещение документа в доступном месте (корпоративный портал, СЭД, SGRC-система);
• уведомление всех затронутых сотрудников о новом или обновлённом документе;
• проведение разъяснительных мероприятий по ключевым документам (политика ИБ, парольная политика, регламент инцидентов).

Обучение персонала

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

• Для всех сотрудников: базовое обучение по политике ИБ, парольной политике, правилам работы с ПДн, распознаванию фишинга.
• Для ИТ-администраторов: обучение по техническим регламентам (управление доступом, резервное копирование, мониторинг).
• Для руководителей: обзор ключевых политик, ответственность за нарушения.

Плановый и внеплановый пересмотр

Документы ИБ — не статичные артефакты. Они требуют регулярного пересмотра:

• Плановый пересмотр — не реже одного раза в год. Рекомендуется привязать к определённой дате (например, январь каждого года).
• Внеплановый пересмотр — при изменении законодательства, ИТ-инфраструктуры, после инцидентов ИБ, при организационных изменениях.

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

КиберОснова автоматически напоминает о необходимости пересмотра документов и отслеживает изменения законодательства. Модуль соответствия требованиям уведомляет, когда изменения в НПА затрагивают ваши документы.

Версионирование документов

Каждое изменение документа фиксируется:

• номер версии (1.0, 1.1, 2.0);
• дата изменения;
• автор изменений;
• краткое описание изменений;
• кто утвердил новую версию.

При проверке регулятора необходимо предъявить актуальную версию документа и историю изменений. Ведение версий в Word и на файловом сервере — источник ошибок: неясно, какая версия актуальна, кто и когда вносил правки.

Автоматизация работы с документами ИБ

Проблемы ручного ведения документации

Типичная картина в организациях, ведущих документацию вручную:

• Документы разбросаны. Часть — на файловом сервере, часть — в почте, часть — у специалистов на локальных дисках. Единой точки доступа нет.
• Версии перепутаны. На сервере лежат файлы «Политика_ИБ_v2_final_FINAL(1).docx» — непонятно, какая версия актуальна.
• Актуальность не контролируется. Документ утверждён три года назад, за это время изменились и законодательство, и инфраструктура, но пересмотра не было.
• Согласование по email. Цепочка пересылок, потерянные замечания, дублирование комментариев.
• Нет связи между документами. Политика ИБ, модель угроз, реестр рисков, план мероприятий — каждый документ живёт отдельно. Изменение в одном не отражается в других.

Как SGRC-система упрощает процесс

SGRC-платформа (Security Governance, Risk, Compliance) решает проблемы системно:

• Единый реестр документов. Все документы ИБ — в одной системе с категоризацией, метаданными и контролем доступа.
• Контроль версий. Полная история изменений: кто, когда, что изменил. Всегда понятно, какая версия актуальна.
• Маршруты согласования. Электронное согласование с уведомлениями, сроками и эскалацией. Вместо недель — дни.
• Мониторинг актуальности. Автоматические уведомления о приближении даты планового пересмотра, об изменениях в нормативной базе.
• Связь с другими процессами. Документы связаны с моделью угроз, реестром рисков, результатами аудитов. Изменение в одном модуле отражается в связанных документах.
• Генерация отчётов. При проверке регулятора — мгновенное формирование пакета актуальных документов с историей изменений.

Модуль документов ИБ в КиберОснова: возможности

Платформа КиберОснова предоставляет полный цикл работы с документами ИБ:

1. Матрица требований. Загрузка нормативных требований (152-ФЗ, 187-ФЗ, ГОСТ 57580 и др.) и автоматическое определение необходимых документов.
2. GAP-анализ. Сопоставление существующих документов с требованиями, формирование плана разработки.
3. Шаблоны. Типовые шаблоны основных документов ИБ с возможностью адаптации под организацию.
4. Редактор документов. Создание и редактирование документов в единой среде с контролем версий.
5. Маршруты согласования. Настраиваемые цепочки согласования с уведомлениями и сроками.
6. Реестр. Единый каталог всех документов ИБ с метаданными, статусами, датами пересмотра.
7. Мониторинг. Автоматическое отслеживание изменений НПА и уведомления о необходимости актуализации.
8. Связь с модулями. Документы связаны с модулем управления рисками, аудитом ИБ, моделью угроз.

Время разработки полного пакета документов с использованием платформы сокращается с 3–6 месяцев до 3–6 недель.

Запросите демо платформы КиберОснова и посмотрите, как автоматизировать полный цикл работы с документами ИБ — от разработки до аудита.

Смотрите также: Документы ИБ — КиберОснова | Политика ИБ | Соответствие требованиям | Аудит ИБ | Категорирование КИИ

Часто задаваемые вопросы

Какие документы по ИБ обязательны для организации?

Обязательный набор документов зависит от типа организации. Для оператора ИСПДн (152-ФЗ): политика обработки ПДн, модель угроз, приказ об ответственных, согласия на обработку, инструкции пользователям. Для ГИС (Приказ ФСТЭК №117): организационно-распорядительные документы по защите информации, включая техпроект системы защиты. Для субъекта КИИ (187-ФЗ): акт категорирования, модель угроз, план реагирования на инциденты. Для всех организаций рекомендуются: политика ИБ, парольная политика, политика управления доступом, регламент резервного копирования.

С чего начать разработку документов по информационной безопасности?

Начинать нужно с аудита текущего состояния: определите, какие нормативные требования распространяются на вашу организацию (152-ФЗ, 187-ФЗ, отраслевые стандарты), проведите инвентаризацию существующих документов, выявите пробелы. Затем составьте перечень необходимых документов с приоритетами — сначала обязательные, затем рекомендуемые. Только после этого приступайте к разработке, начиная с верхнеуровневых документов (политика ИБ), далее — стандарты и регламенты, последними — инструкции и формы.

Сколько документов по ИБ нужно типичной организации?

Типичной средней организации (оператор ПДн, не субъект КИИ) требуется от 15 до 30 документов по ИБ. Базовый комплект включает: политику ИБ, политику обработки ПДн, модель угроз, парольную политику, регламент управления доступом, регламент управления инцидентами, план обеспечения непрерывности, инструкции пользователям (5–8 штук), приказы о назначении ответственных, формы (журналы, акты, согласия). Для субъектов КИИ набор расширяется до 40–60 документов. Ключевое — не количество, а полнота покрытия требований и практическая применимость документов.

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

Документы ИБ необходимо пересматривать: планово — не реже одного раза в год (требование ISO 27001 и рекомендация ФСТЭК); внепланово — при изменении законодательства, изменении ИТ-инфраструктуры, после инцидентов ИБ, при изменении организационной структуры. На практике рекомендуется проводить ежеквартальный мониторинг актуальности, а полный пересмотр — ежегодно. Важно вести реестр документов с датами утверждения и плановыми датами пересмотра — именно это автоматизирует SGRC-платформа.

Можно ли использовать типовые шаблоны документов по ИБ?

Да, типовые шаблоны — хорошая отправная точка, но использовать их «как есть» нельзя. Каждый документ необходимо адаптировать: указать конкретные информационные системы организации, учесть специфику бизнес-процессов, привести в соответствие с действующей нормативной базой (регуляторные требования часто обновляются), согласовать терминологию с другими внутренними документами. Типовой шаблон экономит 50–70% времени разработки, но адаптация обязательна, иначе документ не пройдёт проверку регулятора.

Кто в организации отвечает за разработку документов ИБ?

Разработку документов ИБ обычно выполняет подразделение информационной безопасности (или ответственный за ИБ). Согласование проходит через ИТ-отдел, юридическую службу и кадры. Утверждает документы руководитель организации или его заместитель. В малых организациях, где нет выделенного ИБ-специалиста, разработку может выполнять ИТ-подразделение или внешний консультант. Важно: даже при аутсорсинге разработки, ответственность за содержание и исполнение документов остаётся на организации.