ISO 27001 и SOC 2:
какие технические доказательства нужны аудитору
Практическое руководство для компаний, начинающих сертификацию: какие меры требуют проверки, как часто и как выглядят доказательства, которые принимает аудитор.
ISO 27001 и SOC 2 — это системы управления, а не списки уязвимостей. Ни один из них не говорит «проводите пентест каждый год». Но оба требуют того, что нельзя показать одними документами: доказательства, что технические меры действительно работают. Здесь и появляется пентест — поэтому на практике его запрашивает почти любой аудитор.
Какие меры ISO 27001 касаются технической проверки
Редакция 2022 года реструктурировала Приложение A, и три меры напрямую опираются на проверку: A.8.8 — управление техническими уязвимостями, A.8.29 — тестирование безопасности при разработке и приёмке и A.8.9 — управление конфигурациями. К ним добавляется пункт 9.1 основного текста: мониторинг, измерение и оценка результативности СУИБ.
Практическая разница проста: автоматический сканер отвечает на A.8.8 («мы знаем свои уязвимости»), но не на A.8.29 и не на пункт 9.1 («мы убедились, что защита выдерживает»). Сканер не пытается связать две средние находки в реальную компрометацию; тестировщик — пытается.
Где пентест появляется в SOC 2
SOC 2 строится на Trust Services Criteria. Критерий CC4.1 требует периодической оценки мер контроля, а CC7.1 — выявления и мониторинга уязвимостей и новых конфигураций. В аудите Type II аудитор смотрит не на момент, а на период 3–12 месяцев: важно, что проверка произошла внутри периода и что устранение доведено до конца.
Отсюда самая дорогая ошибка: отчёт о пентесте, датированный до начала периода наблюдения, не считается доказательством за этот период. Проверку планируют вместе с окном аудита, а не после него.
Что требует каждая система — и что даёт пентест
| Мера / критерий | Требование | Доказательство из пентеста |
|---|---|---|
| ISO 27001 — A.8.8 | Технические уязвимости выявляются и устраняются | Список находок с уровнем риска, подтверждением и планом устранения |
| ISO 27001 — A.8.29 | Тестирование безопасности при разработке и приёмке | Проверка предпродакшн-среды до релиза с критериями приёмки |
| ISO 27001 — пункт 9.1 | Оценка результативности мер безопасности | Сравнение двух циклов проверки: что закрыто, что вернулось |
| SOC 2 — CC4.1 | Периодическая оценка эффективности мер | Отчёт с датой внутри периода наблюдения и задокументированным охватом |
| SOC 2 — CC7.1 | Выявление уязвимостей и изменений конфигурации | Находки по конфигурации и повторная проверка, подтверждающая закрытие |
Когда проводить проверку в цикле сертификации
- Перед аудитом второго этапа (ISO) — чтобы не обнаружить крупные находки при аудиторе.
- В первые недели периода наблюдения SOC 2 Type II — остаётся время на устранение и повторную проверку в том же окне.
- Ежегодно — для надзорных аудитов.
- После любого крупного изменения архитектуры, миграции в облако или запуска нового продукта.
Что должно быть в отчёте, чтобы он устроил аудитора
- Явный охват: какие адреса, приложения и учётные записи были в проверке и что осталось вне её.
- Заявленная методология (OWASP, PTES) и даты начала и окончания проверки.
- Обоснованный уровень риска, а не просто скопированный из сканера балл CVSS.
- Резюме для руководства, понятное без технического перевода.
- Документированная повторная проверка с итоговым статусом каждой находки.
Частые вопросы
Обязывает ли 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 проверку рекомендуют перед сертификационным аудитом и далее ежегодно при надзоре.
Какой охват нужно проверять для сертификации?
Охват проверки должен покрывать системы в области действия СУИБ либо системы, поддерживающие выбранные критерии SOC 2: клиентские приложения, инфраструктуру, механизмы аутентификации и всё чаще конфигурацию облака. Охват уже заявленного — именно то, что аудитор замечает первым.
Кто может проводить проверку — внутренняя команда?
Можно, но важна независимость. ISO 27001 требует объективной оценки, а SOC 2 благосклоннее к внешней стороне. Если система проверяется той же командой, которая её построила, аудитор запросит дополнительные доказательства разделения обязанностей. Самый простой путь — внешний исполнитель с заявленной методологией и независимым отчётом.
Связанные руководства
- Сколько стоит пентест — что определяет цену, как оценивается трудоёмкость и что делает предложения сопоставимыми.
- DORA и TLPT — цифровая операционная устойчивость в финансах и тестирование на основе угроз.
- Закон 48/2023 (Молдова) — национальная система кибербезопасности: на кого распространяется и какие обязанности вводит.
- OWASP Top 10 — десять категорий веб-рисков с примерами и тем, что проверяется в каждой.
- PCI DSS 4.0 — требования 11.3 и 11.4, проверка сегментации и что это значит для платёжных провайдеров.
- Пентест против сканирования уязвимостей — что находит каждый, что упускает и что аудиторы принимают как доказательство.
- Как подготовиться к пентесту — охват, доступы, правила взаимодействия и всё, что решается до первого дня.
Материал носит информационный характер и не является консультацией по сертификации. Точные требования зависят от заявленной области действия и выбранного органа по сертификации или аудиторской фирмы.
Идёте на сертификацию в этом году?
Запишитесь на бесплатную консультацию и получите план проверки под вашу область действия и календарь аудита.