Если компания внедряет ISO 27001, именно оценка рисков становится центральной логикой всей СУИБ. Без нее система управления информационной безопасностью быстро превращается в набор политик, шаблонов и технических мер, которые не всегда связаны с реальными угрозами для бизнеса. ISO/IEC 27001:2022 определяет требования к СУИБ и прямо строит ее вокруг подхода к оценке и обработке рисков информационной безопасности. Стандарт применим к организациям любого размера и профиля, а его задача — помочь выстроить, внедрить, поддерживать и постоянно улучшать систему управления информационной безопасностью.
Для бизнеса это важно не только ради сертификации ISO 27001. Через оценку рисков компания определяет, где у нее реальные слабые места, какие меры защиты информации действительно нужны, на чем нельзя экономить и какие решения руководству стоит принимать в первую очередь. Хорошая оценка рисков помогает не просто “готовиться к аудиту ISO 27001”, а управлять инцидентами, подрядчиками, доступами, облаком, удаленной работой и критичными процессами более осознанно.
Эта статья будет полезна тем, кто готовится к внедрению ISO 27001, выстраивает СУИБ с нуля, пересматривает существующий реестр рисков или хочет понять, как сделать оценку рисков не формальностью, а рабочим управленческим инструментом.
Что такое оценка рисков в ISO 27001 простыми словами
Оценка рисков в ISO 27001 — это способ понять, что именно может нанести ущерб информации и бизнесу, насколько это вероятно и к каким последствиям может привести.
Проще говоря, компания отвечает на три вопроса: что для нас важно, что может пойти не так и какие риски требуют действий в первую очередь. Речь идет не только о кибератаках. В СУИБ рассматриваются риски для конфиденциальности, целостности и доступности информации. Это может быть утечка клиентских данных, случайное удаление базы, остановка критичного сервиса, ошибка подрядчика, слабый контроль доступа, фишинг, неудачное изменение в инфраструктуре или отсутствие резервных копий. ISO прямо описывает ISMS как систему для защиты активов, включая финансовую информацию, интеллектуальную собственность, данные сотрудников и сведения, доверенные третьими сторонами.
Почему оценка рисков — ключевой элемент СУИБ
В ISO/IEC 27001 меры защиты не должны выбираться “по привычке” или по чужому шаблону. Их нужно обосновывать через риски. Именно поэтому зрелая СУИБ всегда начинается не с перечня контролей, а с понимания бизнес-контекста, активов, угроз, уязвимостей и последствий.
Это особенно важно для компаний, которые готовятся к сертификации ISO 27001. Аудитор обычно смотрит, есть ли логическая цепочка: контекст организации → оценка рисков → решения по обработке рисков → выбранные меры → Statement of Applicability → подтверждение, что меры реально работают. Когда этой связи нет, СУИБ выглядит формальной, даже если документов много. ISO и материалы комитета SC 27 отдельно подчеркивают, что Annex A используется именно в контексте обработки рисков, а SoA должен объяснять включение и исключение мер защиты.
С чего начать организацию оценки рисков
Начинать нужно не с таблицы вероятности и ущерба, а с рамки, в которой компания будет оценивать риски.
На практике первый шаг включает четыре вещи: определить область применения СУИБ, понять контекст организации, установить критерии оценки рисков и согласовать сам подход. Без этого разные подразделения будут понимать “критичный риск” по-разному, а результаты окажутся несопоставимыми.
Полезно заранее ответить на такие вопросы:
- какие процессы и данные критичны для бизнеса;
- какие обязательства есть перед клиентами, партнерами и регуляторами;
- где хранятся и обрабатываются ключевые данные;
- какие сервисы зависят от подрядчиков и облака;
- какие последствия для компании считаются неприемлемыми.
Отдельно стоит помнить, что в действующей редакции стандарта действует Amendment 1:2024 по climate action changes. Для оценки рисков это не означает, что каждую компанию нужно искусственно нагружать климатической тематикой, но если внешние обстоятельства такого рода реально влияют на контекст и ожидания заинтересованных сторон, их нужно учитывать.
Какие риски нужно рассматривать на практике
Одна из самых частых ошибок — думать, что оценка рисков информационной безопасности касается только ИТ-отдела. На деле риски возникают в процессах, людях, договорных отношениях, организационных изменениях и ежедневной операционной деятельности.
Обычно компании рассматривают риски, связанные с:
- информацией и данными;
- приложениями, серверами, рабочими станциями и облачной инфраструктурой;
- сотрудниками и правами доступа;
- поставщиками и внешними сервисами;
- бизнес-процессами и их устойчивостью;
- ошибками, инцидентами и изменениями;
- физической и организационной средой.
Зрелый подход здесь в том, чтобы смотреть не только на гипотетические сценарии, но и на реализовавшиеся риски. Это один из самых полезных принципов в реальной практике внедрения ISO 27001. Компания может долго обсуждать маловероятные угрозы, которые никогда не наступят, но если риск уже реализовался — произошла утечка, сбой, ошибка доступа, потеря данных, несанкционированное изменение, инцидент у подрядчика, — он обязательно должен попасть в реестр рисков. И дальше с ним нужно работать системно: разбирать причины, оценивать последствия, принимать меры и отслеживать повторяемость. Именно такая связка между управлением инцидентами информационной безопасности и оценкой рисков делает СУИБ живой, а не бумажной.
Как выявлять риски, угрозы и уязвимости
Лучше всего работает не один метод, а их сочетание.
Обычно для выявления рисков используют интервью с владельцами процессов, анализ активов, разбор прошлых инцидентов, результаты внутренних аудитов, данные по несоответствиям, обзоры инфраструктуры, анализ подрядчиков, результаты тестов и оценок, а также экспертные сессии с ИТ, ИБ и бизнесом.
Практически это выглядит так: компания берет конкретный процесс или актив, например CRM, платежный модуль, систему документооборота или кадровую базу, и задает вопросы. Что здесь может нарушить конфиденциальность? Что может повредить целостности? Что может остановить доступность? Где слабые места? Были ли уже реальные инциденты? Что изменилось за последний год?
Это гораздо полезнее, чем составлять абстрактный перечень угроз “из интернета” без привязки к своим активам и процессам.
Как оценивать вероятность и последствия
На этом этапе компания определяет, насколько риск реален и что произойдет, если он наступит.
Модель может быть простой: низкая, средняя и высокая вероятность; низкие, средние и высокие последствия. Может быть и более детальная шкала — например, пятибалльная. Важно не количество уровней, а единые критерии.
Последствия стоит смотреть не только через ИТ-ущерб. Для бизнеса часто важнее другое: остановка продаж, потеря клиента, срыв SLA, штрафные последствия, нарушение договорных обязательств, ущерб репутации, простой команды, перерасход бюджета, повторные инциденты. Именно поэтому оценка рисков информационной безопасности должна идти через бизнес-эффект, а не только через технические параметры.
Хорошая практика — заранее описать, что считается высоким последствием. Например: остановка критичного сервиса более чем на один рабочий день, компрометация персональных данных, невозможность выполнить обязательства перед ключевым клиентом, существенные финансовые потери или публичный инцидент.
Как установить критерии и приоритеты
Критерии оценки рисков нужны, чтобы разные люди в компании не оценивали одну и ту же ситуацию по-разному. Это особенно важно, если в оценке участвуют владельцы процессов, ИТ, ИБ, комплаенс и руководство.
Обычно компания фиксирует:
- шкалу вероятности;
- шкалу последствий;
- правила расчета уровня риска;
- порог приемлемости риска;
- правила эскалации и согласования.
После этого можно ранжировать риски по приоритету. Здесь цель не в том, чтобы “посчитать все красиво”, а в том, чтобы понять, куда направлять ресурсы в первую очередь. Если у компании ограниченный бюджет или команда, приоритет должен идти на риски с наибольшим потенциальным ущербом для бизнеса и с высокой вероятностью повторения.
Как оформлять результаты оценки рисков
Для ISO 27001 важно не только провести обсуждение, но и оставить воспроизводимую запись.
Обычно результаты оформляют в реестре рисков. В нем чаще всего фиксируют актив или процесс, описание риска, источник угрозы, уязвимость, возможные последствия, текущие меры защиты, оценку вероятности, оценку последствий, итоговый уровень риска, владельца риска и решение по дальнейшим действиям.
Если риск уже реализовался, это тоже нужно отражать. Такой риск не должен “жить отдельно” только в журнале инцидентов. Зрелый подход — когда сведения из управления инцидентами попадают в реестр рисков и влияют на пересмотр вероятности, приоритетов и мер защиты.
Как связать оценку рисков с обработкой рисков и SoA
Сама по себе оценка рисков еще ничего не улучшает. Она становится полезной только тогда, когда переводится в решения: снижать риск, избегать его, передавать или осознанно принимать.
Именно здесь оценка рисков связывается с планом обработки рисков, приложением A ISO 27001 и Statement of Applicability. SoA нужен не как формальный список контролей, а как объяснение, какие меры выбраны, какие не выбраны и почему. Официальные материалы по аудиторской практике SC 27 прямо указывают, что SoA должен быть связан с результатами обработки рисков и обосновывать включение или исключение контролей Annex A.
Кто должен участвовать в оценке рисков
Оставлять эту работу только ИТ-службе — плохая идея. ИТ видит инфраструктуру, но не всегда понимает бизнес-приоритеты, договорные обязательства и операционные последствия.
В хорошей практике участвуют владелец СУИБ, ИТ, ИБ, владельцы ключевых процессов, представители бизнеса, иногда юристы, комплаенс и руководство. Именно владельцы процессов часто лучше всех понимают, где реальный ущерб, какие данные действительно критичны и какие инциденты уже происходили.
Типовые ошибки и слабые места
Самые частые проблемы выглядят так:
- оценивают риски слишком абстрактно;
- копируют чужой реестр рисков;
- не учитывают реальные инциденты;
- отделяют оценку рисков от поставщиков, облака и удаленной работы;
- делают оценку один раз “для сертификации” и не обновляют ее;
- не назначают владельцев рисков;
- не связывают риски с SoA и мерами обработки.
На аудите ISO 27001 такие слабые места обычно видны быстро. Если сотрудники не могут объяснить, почему риск считается высоким или почему выбран конкретный контроль, значит система работает поверхностно.
Практические рекомендации
Чтобы оценка рисков в ISO 27001 работала на бизнес, а не только на аудит, имеет смысл сделать следующее.
Первое: начните с нескольких критичных процессов, а не пытайтесь охватить все сразу.
Второе: встроите в процесс прошлые инциденты, сбои, ошибки и реальные кейсы. Реализовавшийся риск всегда дает компании более ценную информацию, чем десяток умозрительных сценариев.
Третье: назначьте владельцев рисков, а не оставляйте реестр “ничейным”.
Четвертое: пересматривайте риски не только по календарю, но и после изменений — новых проектов, миграции в облако, смены подрядчика, запуска удаленного режима, инцидента или серьезного аудиторского замечания.
Пятое: связывайте оценку рисков с решениями руководства, планом действий, бюджетом и выбором мер защиты информации. Тогда СУИБ начинает приносить реальную пользу.
Итоги
Оценка рисков в ISO 27001 — это не приложение к СУИБ и не бюрократическая таблица для внешнего аудита. Это основа всей логики системы управления информационной безопасностью.
Если компания организует оценку рисков правильно, она лучше понимает свои слабые места, осознаннее выбирает меры защиты информации, сильнее готовится к аудиту ISO 27001 и делает сертификацию ISO 27001 не формальной целью, а подтверждением зрелого подхода к безопасности.
А один из самых практичных выводов здесь простой: смотреть нужно не только на гипотетические угрозы, но и на то, что уже происходило в реальности. Если риск реализовался, он должен попасть в реестр рисков и стать предметом системной работы. Именно так требование ISO/IEC 27001 превращается в полезный инструмент управления, а не в документ ради галочки.
Полезные сервисы и ресурсы по сертификации ISO
Планируете пройти сертификацию по ГОСТ Р ИСО/МЭК 27001 или другим стандартам? Отправьте одну заявку и получите до 5 коммерческих предложений за 1 раз только от аккредитованных ФСА органов по сертификации.
📢 Подписывайтесь на наш Telegram-канал с новостями и статьями по ISO;
💬 Присоединяйтесь к чату специалистов по системам менеджмента;
💰 Рассчитайте примерную стоимость сертификации в нашем онлайн-калькуляторе;
🗺️ Найдите орган по сертификации в нашем реестре — по стандарту или прямо на карте.
Планируете пройти сертификацию по ГОСТ Р ИСО/МЭК 27001 или другим стандартам? Отправьте одну заявку и получите до 5 коммерческих предложений за 1 раз только от аккредитованных ФСА органов по сертификации.
📢 Подписывайтесь на наш Telegram-канал с новостями и статьями по ISO;
💬 Присоединяйтесь к чату специалистов по системам менеджмента;
💰 Рассчитайте примерную стоимость сертификации в нашем онлайн-калькуляторе;
🗺️ Найдите орган по сертификации в нашем реестре — по стандарту или прямо на карте.