«Договор на пентест – это не формальность. Это карта, которая определяет, где закончится тестирование и где начнётся киберпреступление. Подписывая его, обе стороны снимают со стрелы предохранитель, но при этом фиксируют правила безопасной стрельбы и размер тира.»
Зачем нужен договор: не просто защита, а создание реальности
Договор выполняет две ключевые функции, выходящие за рамки простой «защиты сторон». Во-первых, он формализует общее понимание проекта, переводя разговорные «проверим безопасность» в юридически значимый перечень систем, методов и сроков. Без этого исполнитель и заказчик могут по-разному представлять себе одни и те же работы, что гарантирует конфликт на финальной стадии.
Во-вторых, договор создаёт правовую основу для легитимности действий пентестера. Вне его рамки практически любой активный шаг – сканирование портов, попытка подбора пароля, анализ уязвимостей – с юридической точки зрения ничем не отличается от действий злоумышленника. Подписанный контракт, это документ, который в спорной ситуации отделяет аудитора от хакера.
Требования к документу: точность как приоритет
Главный враг договора на пентест — размытые формулировки. Фраза «провести анализ защищённости» ничего не значит. Приемлемый документ должен содержать:
- Конкретные цели: не «повысить безопасность», а «выявить уязвимости, позволяющие получить несанкционированный доступ к сегменту бухгалтерии».
- Чёткий периметр: перечень IP-адресов, доменных имён, названия информационных систем, которые входят в область тестирования. Всё, что не указано, считается запрещённой зоной.
- Методологию: будут ли применяться методы социальной инженерии, тесты на инсайдерские угрозы, физическое проникновение? Допустима ли эксплуатация найденных уязвимостей (exploit) или только их констатация? Уровень глубины: «чёрный ящик» (без исходных данных), «серый ящик» (с частичным доступом), «белый ящик» (с полными схемами и паролями).
- Язык: избегайте избытка канцеляризмов. Условия должны быть понятны не только юристу, но и техническому руководителю заказчика.
Правовые ограничения: больше чем ИБ
Пентест почти всегда пересекается с другими регуляторными областями, которые необходимо заранее прописать в договоре.
- Обработка данных: результаты тестирования (логи, дампы, отчёты), это конфиденциальная информация. Договор должен определить, где, как и как долго они хранятся. Часто заказчики из госсектора или ФинТеха требуют, чтобы вся обработка происходила исключительно на их территории или на серверах в юрисдикции России, без использования иностранных облаков.
- Персональные данные (152-ФЗ): если в процессе тестирования возможен или неизбежен доступ к ПДн (базы сотрудников, клиентов), исполнитель по закону становится оператором ПДн. В договоре нужно зафиксировать его обязанность по соблюдению требований закона: обеспечение конфиденциальности, порядка уничтожения данных по окончании работ. На практике это часто означает обязательное шифрование всех материалов и использование выделенного, изолированного рабочего места.
- Критическая информационная инфраструктура (187-ФЗ): для объектов КИИ пентест, это не просто услуга, а часть регуляторных требований. Договор должен учитывать необходимость соблюдения отраслевых стандартов безопасности, возможное участие государственного надзорного органа (ФСТЭК России) в согласовании методик и требований к квалификации исполнителя.
Экономия на проверке этих разделов договора штатным или привлечённым юристом сегодня может привести к многомиллионным штрафам завтра.
Полномочия и сторонние согласования
Юридическую силу договору придают не печати, а полномочия подписанта. Удостоверьтесь, что лицо, подписывающее документ со стороны заказчика, имеет право заказывать и оплачивать такие работы. Запрос доверенности или выписки из приказа — нормальная практика.
Особое внимание — к сторонним инфраструктурам. Если тестирование затрагивает системы, размещённые у облачного провайдера (например, в Russian Data Center или аналогичном), необходимо заранее получить его письменное согласие. Многие провайдеры в своих условиях обслуживания прямо запрещают проведение пентестов без предварительного уведомления и координации. Несоблюдение этого правила может привести к блокировке аккаунта заказчика за «подозрительную активность».
Аналогично, если атакуемое веб-приложение принадлежит не заказчику, а его контрагенту, потребуется разрешение и от этого контрагента. Тестирование без таких разрешений выходит за рамки договора и становится незаконным.
Чек-лист готовности к старту
Перед началом любых активных действий сверьтесь с этим списком. Отсутствие хотя бы одного пункта — красный флаг.
| Статус | Пункт | Пояснение |
|---|---|---|
| ✅ | Договор подписан уполномоченными лицами | Проверены полномочия подписантов. |
| ✅ | Техническое задание или приложение с периметром и методами согласовано | Нет размытых формулировок, IP-адреса и системы утверждены. |
| ✅ | Получены разрешения от сторонних провайдеров (хостинг, облака, SaaS) | Есть письменное согласие, контакт для экстренной связи. |
| ✅ | Проработан вопрос обработки ПДн и другой конфиденциальной информации | Определены меры защиты (шифрование, изолированные стенды) на время проекта. |
| ✅ | Согласованы правила эскалации и связи на время тестирования | Кто и как будет получать уведомления о критических инцидентах. |
Итог: договор как фундамент безопасности
Грамотно составленный договор на пентест, это не бюрократическое препятствие, а инструмент управления рисками для обеих сторон. Он переводит проект из области неопределённости в плоскость контролируемого, предсказуемого процесса. Потраченное на его проработку время напрямую влияет на качество результата и отсутствие правовых последствий после сдачи отчёта. В условиях российского регулирования этот документ становится таким же обязательным элементом инфраструктуры безопасности, как межсетевой экран или система контроля доступа.