Автор: Елизавета Пермякова, консультант по информационной безопасности Innostage

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

Для выполнения большинства моих рабочих задач мне необходимо анализировать существующую и разрабатывать недостающую организационно-распорядительную документацию для организаций из разных отраслей (это и ТЭК, и металлургия, и финансовые организации). На практике замечаю, где компании с низким уровнем зрелости ИБ допускают одни и те же ошибки, и благодаря каким подходам компании со средним и высоким уровнем зрелости ИБ – выстраивают работающие процессы ИБ. В этой статье я покажу, где обычно «хромает» документация, и дам лаконичный чек-лист, с которым большинство документов можно проверить примерно за 15 минут.

Когда стоит проводить диагностику ОРД

Диагностика организационно-распорядительной документации по информационной безопасности необходима, если:

• вы готовитесь к проверке ФСТЭК России, Роскомнадзора или Банка России;

• требуется аудит ИБ или оценка зрелости процессов;

• есть сомнения в актуальности документов;

• необходимо выявить типовые ошибки в документах ИБ.

Часть 1. Антипаттерны в ОРД

Начнём с типовых ошибок в документах ИБ. В этой статье разберем 5 типичных антипаттернов в ОРД — тех самых формулировок и подходов, которые могут стать причиной замечаний регулятора. Ниже — примеры и варианты, как их переписать так, чтобы документы не просто существовали, а работали на практике.

1. Размытая ответственность

Когда обязанности прописаны, но найти, кто именно и за что отвечает, невозможно.

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

2. Непроверяемые требования

Формулировки, которые нельзя измерить или подтвердить.

В чем риск? Во время проверки регулятор спросит: «Как вы подтверждаете, что уровень защиты высокий?» Без документированных критериев последует предписание об устранении нарушения, а за его неисполнение – административный штраф. Нет измеримых критериев – нет доказательств.

В этом случае документы обычно имеют следующие формулировки:

3. Документы-одиночки

Документы, которые существуют сами по себе и противоречат друг другу.

В чем риск? При сверке документов регулятор обнаружит противоречия, что будет расценено как нарушение целостности СМИБ. Сотрудник физически не может выполнить взаимоисключающие требования – нарушение неизбежно.

Типичные примеры – ниже:

4. Канцелярит

Документ написан языком, понятным юристу, но не сотруднику.

В чем риск? Массовые нарушения по незнанию, утечки через неконтролируемые каналы. Компания не может доказать, что довела до работников требования понятным образом.

На практике это выглядит так:

5. Идеальный сценарий

Документ описывает только штатный режим, но не содержит алгоритмов действий в кризис.

В чем риск? Сотрудник, столкнувшись с отклонением от процедуры, остаётся без инструкции. Он вынужден импровизировать или останавливать процесс, что ведёт к ошибкам, задержкам и неконтролируемым рискам. Регулятор же при проверке увидит, что система управления не учитывает реальные условия эксплуатации, и зафиксирует нарушение.

В таком случае в документах используются следующие формулировки:

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

Всё это можно проверить достаточно быстро с помощью чек-листа самодиагностики: без дорогостоящего аудита и привлечения внешних консультантов. 

Часть 2. Чек-лист самодиагностики

Возьмите любой документ по ИБ и задайте к нему пять вопросов. Если хотя бы на один вопрос невозможно ответить однозначно – документ в зоне риска.

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

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

UX и организационно-распорядительная документация

 На первый взгляд, верстка газеты и разработка организационно-распорядительной документации — совершенно разные задачи. Но на практике у них гораздо больше общего, чем кажется. Во время учёбы в университете я увлекалась UX/UI-дизайном и работала верстальщиком в университетской газете. Тогда я прочитала много книг о проектировании интерфейсов, типографике и исследованиях пользователей. Одна ключевая мысль из книги запомнилась на всю жизнь: «Пользователь не должен думать. Его задача – получить информацию, а не ломать голову над тем, как её прочитать».

Если сотрудник открыл политику и через 30 секунд ничего не понял – документа не существует. Он не будет в ней копаться, он просто продолжит делать по-своему. А значит, даже лучшие требования не будут работать.

Дон Норман в «Дизайне привычных вещей» пишет, что, когда что-то идёт не так, пользователь склонен винить себя. Но на самом деле виноват дизайн интерфейса. То же самое с документами: если пользователь не понял, как действовать, – это не его проблема, это проблема документа. Он должен быть спроектирован так, чтобы не оставлять места для разночтений.

Вот почему я считаю, что разработка ОРД – это не бюрократия, а инженерия. Документ – это интерфейс между требованием и реальным действием. И его надо проектировать, как интерфейс: с учётом пользователя, контекста, сценариев.

Инженерия, а не бюрократия

Хороший документ – это не набор красивых фраз. Это описание реальных процессов, которые будут выполняться людьми. Его разработка требует:

• Понимания бизнес-процессов. Вы не можете написать регламент управления доступом, не зная, как в компании получают доступ разные категории лиц, кто согласовывает право доступа, как технически это реализуется.

• Умения договариваться. Документ – это компромисс между требованиями регулятора, возможностями IT-инфраструктуры и желаниями бизнеса. Если вы не смогли договориться, документ останется «бумажкой в стол».

• Системного мышления. Документ должен быть частью системы, а не островом. Он должен ссылаться на другие документы, не противоречить им, легко обновляться.

• Эмпатии. Вы пишете для людей. Они будут его читать в разном настроении, при разных обстоятельствах. Ваш текст должен быть понятен даже в 3 часа ночи, когда случился компьютерный инцидент.

Оцените свои процессы по этим четырём критериям. Если вы не можете ответить утвердительно по каждому пункту – у вас есть повод пересмотреть свой подход. 

Вместо заключения

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

Документация – это не «бумажка», а актив, который:

• экономит время при вводе новых сотрудников в курс дела;

• снижает риски ошибок и штрафов;

• помогает проходить проверки без сюрпризов;

• даёт сотрудникам чёткое понимание, что и зачем делать.

Совет: перестаньте смотреть на документы как на неизбежное зло. Начните проектировать их как часть процессов. Используйте чек-лист выше, чтобы проверить себя при разработке ОРД. И помните: хороший документ – это когда сотрудник, прочитав его, честно говорит: «Мне понятно, что надо делать».