Ловушка границ аудита: как компании сертифицируют пустую комнату

B2B-стартап закрывает крупную сделку после полугода согласований. Финальное требование службы безопасности корпоративного клиента звучало жестко: контракт на сотни тысяч долларов подпишут только при наличии официального сертификата ISO/IEC 27001.

Директор по продажам прикрепляет четкий PDF-файл. Сертификат выглядит солидно: печать авторитетного европейского органа по сертификации, золотистые логотипы, регистрационный номер в международном реестре. Безопасники заказчика подшивают документ в архив, ставят галочку и согласовывают перевод аванса.

Спустя четыре месяца в продакшен-базе стартапа происходит утечка: данные клиентов оказываются на теневом форуме.

Во время служебного расследования юристы заказчика впервые открывают приложение к сертификату — документ под названием Statement of Applicability (SoA) и определение границ системы управления безопасностью (ISMS Scope) по пункту 4.3 стандарта. Выясняется, что сертификация распространялась исключительно на «локальный офис в Мюнхене и рабочие станции сотрудников бухгалтерии». Облачная инфраструктура AWS, где реально хранились и обрабатывались клиентские базы, в границы аудита не входила вовсе.

Так работает самый популярный фокус в корпоративном комплаенсе — ловушка границ аудита (The Scope Trap).

Проверка служебного туалета вместо кухни

Прохождение полноценного аудита ISO 27001 требует колоссальных ресурсов. Аудиторы запрашивают сотни подтверждений: логи доступов, правила безопасной разработки, регламенты шифрования и акты уничтожения носителей.

Когда контракт горит, а сертификат нужен срочно, руководство ищет обходные пути. Пункт 4.3 стандарта ISO 27001 прямо разрешает компании самостоятельно определять границы своей системы менеджмента информационной безопасности (СМИБ). Задумка была разумной: банк может сертифицировать подразделение интернет-эквайринга отдельно от сети региональных отделений.

На практике молодые технологические компании используют эту свободу, чтобы сертифицировать пустую комнату.

Это похоже на получение санитарного знака отличия для ресторана путем проверки одной лишь комнаты отдыха управляющего. Инспектор осматривает чистый диван, замеряет температуру в кулере с водой, подписывает акт высшей категории и уходит. При этом за стеной на основной кухне повара разделывают рыбу на немытых столах.

Разница лишь в том, что посетитель ресторана может почувствовать запах гари из кухни. Корпоративный клиент видит на сайте SaaS-сервиса только красивую плашку «ISO 27001 Certified». Реальная граница сертификации остается скрытой до тех пор, пока клиент не потребует полный отчет аудитора.

Как создаются фиктивные границы

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

1. Исключение боевого облака: Сертификация кластера Kubernetes в нескольких регионах облачного провайдера требует регулярного сканирования уязвимостей, строгой изоляции окружений и управления секретами. Ограничив границы формулировкой «Офисная инфраструктура и внутренние IT-сервисы», компания закрывает аудит простыми политиками паролей на офисных ноутбуках.
2. Исключение подрядчиков и удаленщиков: Подключение десятков внешних фрилансеров требует внедрения систем MDM и проверки их личных устройств. Если ограничить область проверки «Штатным персоналом центрального офиса», внешние разработчики полностью выпадают из поля зрения аудитора.
3. Исключения в Statement of Applicability (SoA): Приложение к стандарту содержит 93 контрольные меры. По каждой мере компания вправе заявить: «Не применяется в силу специфики бизнеса». Организация может обладать подлинным сертификатом, официально исключив из него контроль безопасного написания кода, управление сторонними поставщиками или маскирование данных.

Как распознать формальный сертификат

Наличие сертификата ISO 27001 само по себе не доказывает защищенность софта. Оно доказывает лишь то, что аудитор посетил очерченный периметр и проверил наличие регламентов на бумаге.

При проверке контрагента важно смотреть глубже маркетинговых эмблем:

1. Запрашивайте формулировку границ (Scope Statement): Никогда не ограничивайтесь титульным листом сертификата. Изучите точный текст области применения. Если там указано «Система менеджмента для обеспечения административных процессов», а вы покупаете облачную аналитическую платформу, сертификат не дает вашим данным никакой защиты.
2. Изучайте Statement of Applicability (SoA): Документ SoA прямо фиксирует, какие именно меры безопасности были внедрены, а какие исключены. Если меры A.8.25 (Безопасный жизненный цикл разработки) или A.8.28 (Безопасное кодирование) помечены как «Не применимо», сервис создавался без сертифицированного контроля качества.
3. Требуйте отчет Stage 2 Audit Report: Аккредитованные аудиторы составляют подробный отчет с описанием несоответствий и рекомендаций. Зрелые компании без проблем предоставляют копию аудиторского отчета под стандартным соглашением о конфиденциальности (NDA).

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