ISO 27001 и SOC 2: какие технические доказательства требует аудитор

ISO 27001 и SOC 2 не содержат слова «пентест» в списке обязательных процедур — и всё же почти каждый аудитор его требует. Разбираем, какие контроли опираются на тестирование, когда его проводить и как должен выглядеть отчёт, который примут без вопросов.

Представьте типичную сцену: компания полгода писала политики, заполняла реестры рисков, обучала сотрудников — и за две недели до аудита этапа 2 выясняется, что доказать работоспособность защиты нечем. Политики есть, а подтверждения, что они действительно работают, нет. Именно на этом месте в процессе сертификации появляется пентест: ни ISO 27001, ни SOC 2 не произносят слово «pentest» как прямую обязанность, но оба требуют того, что из документов не докажешь — свидетельства, что технические меры выдерживают реальную атаку.

Почему стандарты не называют пентест напрямую

ISO 27001 и SOC 2 — это рамки управления, а не каталоги уязвимостей. Они описывают, как организация должна управлять рисками, а не какие конкретно проверки выполнять. Логика здесь та же, что в бухгалтерском аудите: стандарт не говорит «проведите инвентаризацию склада 14 марта», он говорит «обеспечьте достоверность учёта запасов» — а инвентаризация становится самым очевидным способом это доказать.

С пентестом происходит ровно то же. Контроли сформулированы в терминах результата — «уязвимости выявлены и обработаны», «безопасность проверена», «эффективность мер оценена», — а тест на проникновение оказывается самым прямым и убедительным доказательством того, что результат достигнут. Аудитор не может проверить это по документам: политика управления уязвимостями ничего не говорит о том, закрыты ли уязвимости на самом деле.

Контроли ISO 27001, которые опираются на тестирование

Ревизия 2022 года переструктурировала Приложение A, и три контроля в новой нумерации напрямую связаны с технической проверкой. A.8.8 — управление техническими уязвимостями. A.8.29 — тестирование безопасности при разработке и приёмке. A.8.9 — управление конфигурациями. К ним добавляется пункт 9.1 основного текста стандарта: мониторинг, измерение и оценка результативности СМИБ.

Практическая разница между ними проста. Автоматический сканер отвечает на A.8.8 — «мы знаем, какие уязвимости у нас есть». Но он не отвечает на A.8.29 и на пункт 9.1 — «мы проверили, что защита выдерживает». Сканер не пытается связать две находки средней критичности в реальную компрометацию: он сообщает, что может быть уязвимо. Тестировщик идёт дальше — он показывает, что можно проэксплуатировать и как далеко заходит атакующий, начав с внешнего периметра и добравшись до внутренней базы данных.

Внимание: проверьте свою Декларацию о применимости. Если вы отметили A.8.29 как применимый контроль, но не можете показать ни одного доказательства тестирования, вы создали несоответствие собственными руками. Аудиторы сверяют именно соответствие между тем, что вы объявили применимым, и тем, что способны продемонстрировать.

Что именно проверяет аудитор

Аудитор не ищет в отчёте магическую фразу «пентест проведён». Он смотрит на три вещи: покрывает ли протестированный периметр системы из области действия СМИБ, датирован ли тест внутри нужного окна, и прослеживается ли судьба каждой находки — от обнаружения до закрытия. Отчёт без ретеста выглядит как незавершённый процесс: находки есть, а доказательств их устранения нет.

Где пентест появляется в SOC 2

SOC 2 строится на Trust Services Criteria. Критерий CC4.1 требует периодической оценки эффективности контролей, а CC7.1 — обнаружения и мониторинга уязвимостей и новых конфигураций. Ключевое отличие от ISO — в природе аудита Type II: аудитор смотрит не на момент времени, а на период от 3 до 12 месяцев. Важно, что тестирование произошло внутри периода наблюдения и что ремедиация доведена до конца.

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

Что требует каждый фреймворк — и что даёт пентест

Обратите внимание на строку про пункт 9.1: она требует не просто отчёта, а сравнения между циклами. Это значит, что один-единственный пентест, сделанный ради галочки, закрывает A.8.8, но оставляет пункт 9.1 частично недоказанным. Аудитор захочет увидеть динамику: какие находки прошлого года закрыты, какие появились вновь, что изменилось в оценке риска.

Когда проводить тест в цикле сертификации

Тайминг здесь не формальность, а часть доказательной базы. Практика, которая работает:

• До аудита этапа 2 (ISO) — чтобы не обнаружить критические находки в присутствии аудитора.
• В первые недели периода наблюдения SOC 2 Type II — остаётся время на ремедиацию и ретест внутри того же окна.
• Ежегодно, для надзорных аудитов.
• После любого существенного изменения архитектуры, миграции в облако или запуска нового продукта.

Последний пункт часто недооценивают. Переезд в облако меняет модель угроз полностью: появляются новые поверхности атаки — неправильно настроенные бакеты, избыточные IAM-роли, открытые наружу сервисы. Отчёт годичной давности, сделанный до миграции, описывает уже несуществующую инфраструктуру.

Каким должен быть отчёт, чтобы аудитор его принял

Отчёт о пентесте — это не список найденных багов, а документ, который должен выдержать scrutiny со стороны человека, не знакомого с вашей инфраструктурой. Минимальный набор, который проходит проверку:

• Явный периметр: какие адреса, приложения и учётные записи тестировались — и что осталось за рамками.
• Заявленная методология (OWASP, PTES) и даты начала и окончания тестирования.
• Обоснованная критичность, а не просто скопированный из сканера балл CVSS.
• Executive summary, который руководство может прочитать без технического перевода.
• Документированный ретест с финальным статусом каждой находки.

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

Важно: периметр теста должен покрывать системы из области действия СМИБ — или системы, поддерживающие выбранные критерии SOC 2: клиентские приложения, инфраструктуру, механизмы аутентификации и, всё чаще, конфигурацию облака. Периметр уже заявленной области — первое, что замечает аудитор.

Частые вопросы, которые стоит закрыть заранее

Обязателен ли пентест по ISO 27001?

Стандарт не использует слово «пентест» как явную обязанность. Но контроли A.8.8, A.8.29 и пункт 9.1 требуют выявления технических уязвимостей, тестирования безопасности и оценки эффективности мер. На практике аудиторы принимают пентест как самое прямое доказательство для этих требований, а организация, объявившая A.8.29 применимым без возможности показать тестирование, рискует получить несоответствие.

Достаточно ли сканирования уязвимостей для SOC 2?

Сканирование покрывает часть CC7.1 о непрерывном мониторинге, но редко удовлетворяет CC4.1, который требует оценки эффективности контролей. Сканер сообщает, что может быть уязвимо; пентест показывает, что реально эксплуатируется и как далеко заходит атакующий. Большинство аудиторов ожидают оба элемента: регулярное сканирование плюс как минимум один ручной тест в период наблюдения.

Насколько свежим должен быть отчёт?

Обычное правило — не старше 12 месяцев, но для SOC 2 Type II важнее другое: отчёт должен быть датирован внутри периода наблюдения. Отличный тест, проведённый за месяц до начала окна, не даёт доказательства для этого окна. Для ISO тест рекомендуется до сертификационного аудита, а затем ежегодно, к надзорному аудиту.

Может ли тест провести внутренняя команда?

Может, но независимость имеет значение. ISO 27001 требует объективности оценки, а SOC 2 с большим доверием смотрит на внешнюю сторону. Если команда, построившая систему, сама её и тестирует, аудитор запросит дополнительные доказательства разделения обязанностей. Самый простой путь — внешний подрядчик с заявленной методологией и независимым отчётом.

Что это значит для вашего проекта сертификации

Пентест в контексте ISO 27001 и SOC 2 — это не техническое упражнение ради галочки, а элемент доказательной базы, который связывает заявленные контроли с их реальной работоспособностью. Компания, которая планирует тестирование вместе с окном аудита, документирует периметр и доводит каждую находку до ретеста, получает отчёт, работающий на сертификацию. Компания, которая заказывает тест в последний момент, рискует обнаружить, что доказательства есть, но они не попадают в нужное окно или не покрывают заявленную область.

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