«Risk Appetite Statement часто превращается в мертвый документ из-за академичного подхода. Но можно сделать его практичным — таким, который реально использует бизнес для принятия решений, а не для отчетности. Это достигается через конкретику, привязку к бизнес-процессам и отказ от абстрактных процентов.»
Почему Risk Appetite Statement не работает в стандартном формате
Политика приемлемого риска — обязательный документ для выполнения требований регуляторов по защите информации. Его создают, утверждают и… забывают. Он лежит в папке для аудиторов, но не влияет на повседневную работу отделов. Руководители бизнес-направлений не понимают, как применять его в своих процессах. Корень проблемы — в формате.
Типичный документ состоит из общих деклараций: «Мы готовы принимать умеренные риски для достижения стратегических целей». Он перечисляет категории рисков: операционные, репутационные, киберриски. Часто включает матрицу с цветными зонами: зеленый — низкий риск, красный — неприемлемый. Проблема в том, что такая матрица слишком абстрактна. Что для одного отдела «умеренный» риск, для другого может быть «критическим». Без четкой привязки к конкретным бизнес-метрикам и процессам документ остается бесполезным.
Еще одна ошибка — попытка количественно определить аппетит ко всем рискам сразу, например, через финансовые лимиты. Для киберрисков это часто нерелевантно. Сказать «мы готовы потерять на инцидентах не более N миллионов рублей» — бессмысленно, если речь идет о потере клиентских данных и репутационном ущербе, который сложно оценить деньгами заранее. Такой подход отталкивает бизнес, так как не отражает реальность.
Принципы практичного Risk Appetite Statement
Чтобы документ стал рабочим инструментом, он должен быть интегрирован в процессы принятия решений. Это достигается за счет нескольких ключевых принципов.
Конкретика вместо абстракций
Аппетит к риску нужно формулировать для конкретных сценариев. Вместо «низкая толерантность к репутационным рискам» — «мы не запускаем новый онлайн-сервис для клиентов, если в ходе тестирования безопасности обнаружена уязвимость, позволяющая получить доступ к данным других пользователей». Это правило понятно и проверяемо.
Привязка к бизнес-решениям
Документ должен напрямую отвечать на вопросы, которые возникают у бизнеса: можно ли ускорить вывод продукта на рынок, пропустив этап пентеста? Можно ли хранить данные разработки на ноутбуках сотрудников? Ответы в формате «да/нет» с пояснениями гораздо эффективнее общих формулировок.
Язык бизнеса, а не безопасности
Необходимо избегать узкоспециальных терминов ИБ. Говорить о воздействии на бизнес-процессы, доступность сервисов, выполнение договорных обязательств, а не об «эксплуатации уязвимостей» и «нарушении конфиденциальности». Это повышает понимание и принятие со стороны руководителей.
Динамичность и контекст
Аппетит к риску не может быть статичным. Для пилотного проекта внутри компании и для массового коммерческого продукта он разный. Документ должен это учитывать, задавая рамки, в которых уровень приемлемого риска может меняться в зависимости от контекста (этап проекта, тип обрабатываемых данных, критичность сервиса).
Структура формата для быстрого согласования
Предлагаемая структура документа фокусируется на действиях, а не на описаниях. Она состоит из четырех блоков.
1. Контекст и сфера применения
Короткий раздел, который определяет, для каких процессов и решений применяется документ. Например: «Настоящий документ определяет подход к принятию рисков в области информационной безопасности при запуске новых цифровых продуктов и сервисов, изменении инфраструктуры и интеграции со сторонними системами». Это сразу отсекает обсуждения о применимости.
2. Категории решений и правила
Основная часть. Вместо категорий рисков — категории бизнес-решений. Для каждой — набор простых правил (statements).
| Категория решений | Пример правила (Statement) | Обоснование (Почему так) |
|---|---|---|
| Запуск нового продукта | Нельзя выпускать продукт для внешних пользователей без проведения и успешного завершения внешнего тестирования на проникновение. | Снижает вероятность инцидентов, ведущих к компрометации данных клиентов и репутационным потерям на раннем этапе жизненного цикла продукта. |
| Работа с данными | Запрещено хранить персональные данные или критичные для бизнеса технические секреты на ноутбуках сотрудников без использования утвержденного шифрования диска. | Минимизирует последствия утери или кражи устройства. Шифрование является базовым и обязательным контролем. |
| Интеграции и API | Любое предоставление доступа к внутренним API внешним партнерам требует предварительной оценки их системы безопасности по чек-листу и подписания NDA. | Внешние системы являются расширением периметра безопасности. Недостатки в их защите становятся нашими рисками. |
3. Процесс оценки и принятия исключений
Четко описанный алгоритм действий на случай, если бизнес хочет отступить от правила. Например: 1) Инициатор запроса заполняет форму с обоснованием бизнес-пользы и предлагаемыми компенсирующими мерами. 2) Проводится экспресс-оценка риска службой ИБ. 3) Решение принимает специальный комитет (в составе: руководитель направления, CISO, юрист) в рамках ежемесячного совещания. Такой процесс легализует отклонения и делает их управляемыми.
4. Роли и ответственность
Краткое закрепление ответственности: кто обеспечивает соблюдение правил, кто инициирует пересмотр, кто принимает решения об исключениях. Например: «Руководители продукта несут ответственность за инициацию оценки рисков в соответствии с настоящим документом. Служба ИБ обеспечивает методическую поддержку и проведение оценки. Окончательное решение об отклонении от правил принимает Комитет по рискам».
Как провести заседание по утверждению: тактика и фокус
Согласование такого документа требует особой повестки. Цель — не защитить каждый пункт, а продемонстрировать его полезность для бизнеса.
Начните встречу не с документа, а с двух-трех реальных бизнес-дилемм, которые недавно возникали: «Можно ли было запустить фичу без полного теста?», «Что делать, если партнер не проходит наш чек-лист по безопасности, но интеграция нужна срочно?». Затем покажите, как предложенный формат дает на них четкий и быстрый ответ. Это смещает фокус с теоретического соответствия требованиям на практическую пользу.
Сосредоточьте обсуждение на разделе «Категории решений и правила». Предложите участникам добавить свои типовые сценарии, в которых нужна ясность по рискам. Интегрируя их обратную связь в режиме реального времени, вы превращаете согласование в совместную работу. Возражения в духе «это нас замедлит» парируйте конкретными примерами из раздела «Процесс исключений», показывая, что механизм для быстрых решений существует и он формализован.
Ключевой аргумент для руководства: этот документ снижает операционные издержки. Он заменяет долгие импровизированные согласования и личные договоренности на понятный регламент. Это ускоряет процессы в долгосрочной перспективе, даже если добавляет один обязательный этап.
Что дальше: интеграция в бизнес-процессы
Утвержденный документ должен жить. Для этого его нужно встроить в существующие процессы.
- Управление продуктами: Включить пункт «Проверка соответствия правилам приемлемого риска» в чек-лист запуска любого нового продукта или крупного обновления.
- Закупки и интеграции: Сделать отсылку к документу в регламенте проверки новых партнеров и вендоров. Оценка их безопасности перестает быть инициативой ИБ-отдела, а становится обязательным требованием бизнес-процесса.
- Управление инцидентами: Использовать зафиксированные в документе приоритеты (например, «недопустимость простоя критичных клиентских сервисов») для калибровки реакции на различные инциденты.
Раз в год документ необходимо пересматривать. Но не с нуля. Основа пересмотра — журнал принятых исключений. Если какое-то исключение становится частым, это сигнал: либо правило нереалистично, и его нужно скорректировать, либо бизнес-процесс систематически порождает недопустимые риски, и здесь нужны более глубокие изменения. Таким образом, Risk Appetite Statement превращается из формальности в инструмент управления, который эволюционирует вместе с бизнесом и его цифровой средой.