Организационно-распорядительные документы по информационной безопасности — фундамент, без которого даже самые дорогие технические средства защиты не образуют систему. Любая проверка ФСТЭК или ФСБ начинается с запроса комплекта ОРД: политик, положений, регламентов, инструкций и журналов. В этой статье — полная классификация ОРД по ИБ, иерархия шести уровней, разграничение ответственности и практические рекомендации по управлению документами.
Что такое ОРД по информационной безопасности
Как расшифровывается ОРД
ОРД — это организационно-распорядительная документация. Аббревиатура пришла из общего делопроизводства, где к ОРД относят приказы, распоряжения, положения, инструкции и протоколы любой тематики. В информационной безопасности термин используют уже, обозначая тот же тип документов применительно к защите информации: ОРД по ИБ.
Отсюда частая путаница. Запрос «ОРД» в контексте делопроизводства и запрос «ОРД по ИБ» ведут к разным перечням документов. Ниже речь только о втором.
Назначение ОРД по информационной безопасности
ОРД по ИБ — совокупность внутренних нормативных документов организации, которые определяют:
- Цели и принципы обеспечения информационной безопасности
- Роли и ответственность подразделений и сотрудников
- Порядок выполнения процессов ИБ (управление доступом, инциденты, уязвимости)
- Правила поведения пользователей при работе с информационными системами
- Доказательства выполнения — журналы, акты, отчёты
Без ОРД техническая защита остаётся набором разрозненных мер. Межсетевой экран, антивирус и SIEM не имеют смысла, если не определено, кто реагирует на инцидент, как классифицировать события и в какие сроки устранять уязвимости.
Роль ОРД в системе обеспечения ИБ
ОРД — организационный уровень системы управления информационной безопасностью (СУИБ). В модели ISO 27001 документация занимает центральное место: стандарт требует задокументированных политик, процедур и записей как доказательств функционирования СУИБ.
В российском регулировании роль ОРД закреплена явно: Приказы ФСТЭК №117, №21 и №239 содержат конкретные требования к составу и содержанию документации. Без утверждённых документов организация не может пройти аттестацию информационной системы.
Нормативные требования к наличию ОРД
| Нормативный акт | Что требует |
|---|---|
| Приказ ФСТЭК №117 (ГИС) | Комплект ОРД как обязательное условие аттестации |
| Приказ ФСТЭК №21 (ИСПДн) | Организационные меры защиты персональных данных |
| Приказ ФСТЭК №239 (КИИ) | Документация по обеспечению безопасности значимых объектов |
| 152-ФЗ «О персональных данных» | Политика обработки ПДн, приказы о назначении ответственных |
| 187-ФЗ «О безопасности КИИ» | Документация по категорированию и защите объектов КИИ |
| Приказ ФАПСИ №152 | Журналы поэкземплярного и технического учёта СКЗИ |
| ГОСТ Р 57580.1-2017 | Документация для финансовых организаций |
Отсутствие ОРД — одно из самых частых замечаний при проверках ФСТЭК. Даже если технические меры реализованы корректно, без документального подтверждения организация получает предписание.
Иерархия документов ИБ: 6 уровней
Документы ИБ выстраиваются в пирамиду: от стратегических решений верхнего уровня к конкретным записям. Каждый уровень отвечает на свой вопрос.
| Уровень | Тип документа | Ключевой вопрос | Утверждает |
|---|---|---|---|
| 1 | Концепция / Стратегия ИБ | Зачем? Куда движемся? | Руководитель организации |
| 2 | Политика ИБ | Что делаем? Какие принципы? | Руководитель организации |
| 3 | Положения и стандарты | Как организовано? Кто отвечает? | Руководитель / Заместитель |
| 4 | Регламенты и процедуры | Как делать? В каком порядке? | Руководитель ИБ |
| 5 | Инструкции и руководства | Что делает конкретный сотрудник? | Руководитель ИБ |
| 6 | Записи, журналы, акты | Что сделано? Когда? Кем? | Ответственные сотрудники |
Уровень 1 — Концепция и стратегия ИБ
Документ верхнего уровня, определяющий стратегические цели информационной безопасности на 3-5 лет. Концепция описывает:
- Бизнес-контекст и ландшафт угроз
- Стратегические цели ИБ (привязка к целям бизнеса)
- Принципы построения системы защиты
- Ресурсное обеспечение (бюджет, кадры, инструменты)
- Ключевые показатели эффективности (KPI)
Концепцию утверждает руководитель организации. Пересмотр — при изменении стратегии бизнеса или раз в 3 года.
Уровень 2 — Политика ИБ
Политика ИБ — ключевой документ, определяющий принципы и направления обеспечения информационной безопасности. В отличие от концепции, политика фокусируется не на стратегии, а на правилах и принципах.
Типичное содержание политики ИБ:
- Область применения и термины
- Принципы обеспечения ИБ
- Направления защиты (управление доступом, защита сетей, антивирусная защита)
- Классификация информационных активов
- Ответственность руководства и сотрудников
- Порядок пересмотра и актуализации
Политика утверждается руководителем организации и доводится до всех сотрудников. Пересмотр — ежегодно или при существенных изменениях.
Уровень 3 — Положения и стандарты
Положения описывают организацию конкретных процессов ИБ: кто участвует, какие роли, зоны ответственности, общие правила. Стандарты фиксируют требования к конкретным техническим параметрам.
Примеры положений:
- Положение о подразделении информационной безопасности
- Положение об управлении доступом к информационным ресурсам
- Положение о классификации информации
- Положение об управлении инцидентами ИБ
- Положение об обработке и защите персональных данных
Примеры стандартов:
- Стандарт парольной политики
- Стандарт конфигурирования рабочих станций
- Стандарт резервного копирования
Уровень 4 — Регламенты и процедуры
Регламенты описывают порядок выполнения конкретных процессов: шаги, сроки, формы документов, критерии перехода между этапами.
Структура типового регламента:
- Назначение и область применения
- Термины и определения
- Описание процесса (входы, выходы, этапы)
- Порядок выполнения (пошагово)
- Роли и ответственность на каждом этапе
- Сроки выполнения и SLA
- Формы документов (приложения)
- Порядок эскалации
Примеры регламентов:
- Регламент реагирования на инциденты ИБ
- Регламент управления уязвимостями
- Регламент предоставления и отзыва доступа
- Регламент резервного копирования и восстановления
- Регламент проведения аудитов ИБ
Ключевое отличие положения от регламента: положение отвечает на вопрос «как организовано», регламент — «как делать». Положение об управлении инцидентами определяет роли и зоны ответственности. Регламент реагирования на инциденты содержит пошаговый алгоритм: обнаружение, классификация, эскалация, устранение, отчёт.
Уровень 5 — Инструкции и руководства
Инструкции — документы для конкретных ролей, описывающие действия сотрудника в определённых ситуациях.
Инструкция администратора ИБ включает:
- Порядок настройки средств защиты информации
- Мониторинг событий безопасности
- Действия при обнаружении инцидентов
- Порядок обновления СЗИ и СКЗИ
- Ведение журналов учёта
Инструкция пользователя ИС включает:
- Правила работы с паролями
- Правила использования съёмных носителей
- Порядок действий при подозрении на инцидент
- Запреты (установка стороннего ПО, передача учётных данных)
Инструкция ответственного за СКЗИ включает:
- Порядок получения и учёта СКЗИ
- Ведение журнала поэкземплярного учёта
- Контроль ключевых документов
- Процедура уничтожения СКЗИ
Уровень 6 — Записи, журналы, акты
Записи — доказательства выполнения требований ИБ. Именно записи проверяют аудиторы и регуляторы.
Виды журналов:
- Журнал поэкземплярного учёта СКЗИ (Приказ ФАПСИ №152)
- Технический журнал учёта СКЗИ
- Журнал учёта СЗИ
- Журнал учёта машинных носителей
- Журнал регистрации инцидентов ИБ
Виды актов:
- Акт классификации информационной системы
- Акт ввода в эксплуатацию СЗИ
- Акт уничтожения СКЗИ / ключевых документов
- Акт проверки эффективности защиты
Требования к хранению записей:
- Срок хранения журналов учёта СКЗИ — не менее 5 лет
- Акты классификации — бессрочно (до переклассификации)
- Журналы инцидентов — не менее 3 лет
- Записи об ознакомлении — весь период работы сотрудника + 3 года
Политики ИБ: документы верхнего уровня
Что включают и зачем нужны
Политики — документы 2-го уровня, определяющие принципы и правила по конкретным направлениям ИБ. Помимо основной Политики ИБ, организация может разрабатывать тематические политики:
| Политика | Что регулирует |
|---|---|
| Политика ИБ (основная) | Общие принципы, направления, ответственность |
| Политика управления доступом | Принципы разграничения прав, ролевая модель |
| Политика антивирусной защиты | Правила работы с антивирусным ПО |
| Политика использования сети Интернет | Допустимое использование, фильтрация |
| Политика обработки ПДн | Правила работы с персональными данными |
| Политика удалённого доступа | Условия и требования к удалённой работе |
| Политика управления паролями | Требования к паролям, MFA |
Кто утверждает, как часто пересматривают
Политики утверждает руководитель организации (генеральный директор). Ввод в действие — приказом. Периодичность пересмотра — ежегодно. Внеплановый пересмотр — при изменении законодательства, инцидентах, реорганизации.
Положения и стандарты: организация процессов
Отличие от политик и регламентов
Положение занимает промежуточное место: оно конкретнее политики (описывает организацию определённого процесса), но абстрактнее регламента (не содержит пошагового порядка действий).
| Критерий | Политика | Положение | Регламент |
|---|---|---|---|
| Уровень | 2-й | 3-й | 4-й |
| Отвечает на | Что делаем? | Как организовано? | Как делать? |
| Детализация | Принципы | Роли, зоны ответственности | Шаги, сроки, SLA |
| Объём | 5-15 стр. | 10-20 стр. | 15-30 стр. |
| Пересмотр | Ежегодно | Ежегодно | При изменении процесса |
Структура типового положения
- Общие положения (назначение, область действия, основания)
- Термины и определения
- Цели и задачи процесса
- Участники и их роли
- Зоны ответственности
- Общие правила и ограничения
- Взаимодействие с другими процессами
- Контроль и отчётность
- Порядок пересмотра
Регламенты и процедуры: порядок выполнения
Для каких процессов ИБ нужны регламенты
Регламенты необходимы для каждого процесса ИБ, в котором задействованы несколько ролей и существуют измеримые сроки. Минимальный перечень:
- Управление инцидентами — от обнаружения до закрытия с SLA по критичности
- Управление уязвимостями — от сканирования до верификации устранения
- Управление доступом — предоставление, изменение, отзыв прав
- Резервное копирование — расписание, проверка восстановления
- Управление изменениями — согласование, тестирование, внедрение
- Аудит ИБ — планирование, проведение, отслеживание замечаний
Примеры: управление инцидентами, контроль доступа
Регламент управления инцидентами ИБ (ключевые разделы):
- Классификация инцидентов (критический, высокий, средний, низкий)
- Порядок обнаружения и регистрации
- Первичная оценка и классификация
- Эскалация (кому, в какие сроки)
- Реагирование и локализация
- Расследование и анализ причин
- Устранение последствий
- Отчётность и извлечённые уроки
- SLA: критический — реагирование за 15 минут, высокий — за 1 час
Записи и журналы: доказательства выполнения
Требования к хранению записей
Записи — единственный вид ОРД, который создаётся не единовременно, а непрерывно в ходе операционной деятельности. Именно по записям аудитор или проверяющий из ФСТЭК оценивает реальное функционирование СУИБ.
Критически важно обеспечить:
- Целостность — защита от несанкционированного изменения
- Доступность — возможность оперативно предоставить при проверке
- Полноту — отсутствие пробелов во времени
- Аудиторский след — кто, когда и что внёс в журнал
Ведение журналов в Excel не обеспечивает аудиторский след: невозможно достоверно подтвердить, что запись была сделана именно в указанную дату, а не внесена задним числом перед проверкой.
Какие ОРД требует приказ №117 напрямую
Классификации и иерархии полезны. Но проверяющий сверяет комплект с конкретным пунктом нормы. Для государственных информационных систем это пункт 14 приказа ФСТЭК №117. Он не просто перечисляет документы. Он задаёт их содержание, и по этому содержанию комплект проверяется.
Политика защиты информации (подпункт «а»)
Документ верхнего уровня. Пункт 14 требует, чтобы в ней были:
- область действия с перечнем защищаемой информации, систем и компонентов инфраструктуры;
- цели, задачи и принципы защиты информации;
- перечни объектов защиты: программные и программно-аппаратные средства, системы, сети и подсети;
- категории лиц, участвующих в защите, их обязанности и полномочия;
- состав организационной системы управления защитой и схема взаимодействия её элементов;
- ответственность работников за нарушение требований и правил обработки информации.
Политика без перечня объектов защиты формально неполна. Без схемы взаимодействия тоже.
Внутренние стандарты (подпункт «г»)
Это уровень требований к настройкам. Пункт 14 относит сюда:
- требования к первичной идентификации пользователей;
- требования к применяемым моделям доступа;
- перечень разрешённого и запрещённого программного обеспечения;
- требования к типовым конфигурациям и настройкам средств;
- отдельные требования к средствам доступа в интернет и к удалённому доступу, включая безопасную дистанционную работу;
- ограничения и запреты для пользователей при эксплуатации информационных систем;
- требования к защите физических и виртуальных устройств.
Внутренние регламенты (подпункт «д»)
Самый объёмный блок. Приказ перечисляет тринадцать порядков. Каждый должен быть описан:
| Что регламентируется | На что обратить внимание |
|---|---|
| Учётные записи: создание, учёт, изменение, блокирование, контроль, удаление | Отдельный порядок для привилегированных учётных записей |
| Аутентификационная информация и средства аутентификации | Весь жизненный цикл, включая блокирование |
| Удалённый доступ пользователей | Связан с требованиями стандартов к дистанционной работе |
| Доступ работников подрядных организаций | Включая контроль за доступом и передачей информации |
| Доступ работников иных госорганов и организаций | Нужен при информационном взаимодействии |
| Доступ в интернет и контроль его использования | |
| Повышение знаний и информированности пользователей | |
| Управление уязвимостями | Выявление, оценка, устранение |
| Управление обновлениями | Получение, оценка, тестирование, применение |
| Обращение с информацией ограниченного доступа | Обработка, хранение, обращение |
| Физическая защита информационных систем | |
| Разработка безопасного ПО | Только если оператор разрабатывает ПО сам |
Что ещё требует пункт 14
Документами дело не ограничивается. Организация деятельности включает ещё определение лиц, ответственных за защиту информации (подпункт «б»), применение средств защиты (подпункт «в») и выделение организационных, технических и иных ресурсов (подпункт «е»). Последний забывают чаще прочих. А означает он, что защита информации обеспечена бюджетом и людьми, и это тоже проверяемо.
Комплект ОРД под конкретный приказ и класс системы удобнее вести не в папке с файлами, а связанным с мерами и системами: модуль документов ИБ показывает, какой документ какую меру закрывает и где остались пробелы.
Как организовать управление ОРД по ИБ
Реестр документов
Первый шаг к порядку — создание единого реестра всех ОРД со следующими атрибутами:
| Атрибут | Описание |
|---|---|
| Наименование | Полное название документа |
| Тип | Политика / Положение / Регламент / Инструкция / Журнал |
| Версия | Текущая версия (например, 2.3) |
| Дата утверждения | Когда введён в действие |
| Срок пересмотра | Когда необходимо актуализировать |
| Владелец | Ответственное подразделение / сотрудник |
| Статус | Действующий / На пересмотре / Архивный |
| Приказ | Номер приказа о введении в действие |
Версионирование и контроль изменений
Каждое изменение документа должно фиксироваться: номер версии, дата, автор изменения, суть правок. Без версионирования невозможно понять, какой вариант документа действовал на момент инцидента или проверки.
Минимальные требования к контролю изменений:
- Нумерация версий (major.minor: 1.0, 1.1, 2.0)
- Лист регистрации изменений в каждом документе
- Архив предыдущих версий
- Контроль ознакомления сотрудников с новой версией
Автоматизация в SGRC-системе
Управление десятками ОРД вручную (в файловой системе или SharePoint) быстро становится хаотичным. SGRC-платформа автоматизирует ключевые аспекты:
- Реестр с атрибутами — все документы в единой базе с метаданными
- Контроль сроков — уведомления о приближении даты пересмотра
- Версионирование — автоматическая история изменений
- Контроль ознакомления — фиксация, кто и когда прочитал документ
- Связь с требованиями — привязка ОРД к конкретным мерам из приказов ФСТЭК
- Аудиторский след — кто, когда и что изменил
Управляйте всей иерархией ОРД в единой системе: модуль документов ИБ в КиберОснова контролирует версии, сроки пересмотра и связь документов с нормативными требованиями.
Типичные ошибки в организации ОРД
Документы «для галочки»
Самая распространённая проблема — ОРД разрабатываются формально, чтобы закрыть требование регулятора, но не отражают реальные процессы организации. Политика описывает идеальную картину, а сотрудники работают по неписаным правилам.
Как избежать: разрабатывать документы на основе реальных процессов, а не шаблонов из интернета. Привлекать к разработке исполнителей, а не только руководство.
Отсутствие актуализации
Документы, утверждённые 3-5 лет назад, содержат устаревшие требования, ссылки на несуществующие подразделения и отменённые нормативные акты. При проверке это квалифицируется как несоответствие.
Как избежать: настроить систему уведомлений о сроках пересмотра. Установить правило: любое изменение законодательства или оргструктуры — триггер для внепланового пересмотра ОРД.
Несоответствие реальным процессам
Регламент предписывает одно, а сотрудники делают другое. Причины: документ написан без участия исполнителей, процесс изменился, а регламент — нет, требования регламента физически невыполнимы.
Как избежать: проводить периодические аудиты ИБ с проверкой соответствия документов реальной практике. Фиксировать расхождения и устранять их: либо менять процесс, либо менять документ.
Документы «для галочки» не пройдут аудит. КиберОснова связывает ОРД с реальными процессами и активами организации, обеспечивая актуальность и прослеживаемость каждого документа.
Заключение
Организационно-распорядительные документы по ИБ — не бюрократическая нагрузка, а рабочий инструмент управления информационной безопасностью. Шесть уровней иерархии (концепция, политика, положение, регламент, инструкция, запись) обеспечивают полноту: от стратегических целей до ежедневных операций.
Ключевые рекомендации:
- Выстраивайте иерархию сверху вниз: сначала политика, затем положения и регламенты
- Разграничивайте типы документов: положение описывает организацию, регламент — порядок действий
- Назначайте владельца каждому документу и контролируйте сроки пересмотра
- Обеспечивайте связь ОРД с реальными процессами — документ, не соответствующий практике, бесполезен
- Автоматизируйте управление ОРД: реестр, версионирование, контроль ознакомления, уведомления
КиберОснова SGRC — платформа, в которой весь жизненный цикл ОРД управляется из единого интерфейса: от разработки и согласования до контроля актуальности и формирования отчётов для регуляторов. Запросите демо и оцените, как SGRC-платформа упрощает работу с документами ИБ.
