«Формальный комплаенс мертв. Его заменили диалог с архитекторами, репутацией ключевых инженеров и проверкой кода на живом внедрении. Успех проекта теперь зависит от способности ИБ-службы вести техническое расследование, а не сверять галочки. На бумаге требования остались прежними — на практике сертификат уступил место экспертизе, которую невозможно подделать»
.
Почему комплаенс-чеклист больше не работает как единственный фильтр
Исторически оценка поставщиков в госсекторе строилась под западных вендоров. Их готовые сертификаты ФСТЭК, ISO и коробочная документация воспринимались как надёжный индикатор. Система была пассивной: заказчик получал документы, а не углублялся в архитектуру. Внутренние регламенты закрепляли этот подход, делая бумагу главным критерием.
С уходом крупных международных игроков и переходом на российский софт модель дала сбой. Для отечественной разработки отсутствие сертификата ФСТЭК — обычная ситуация. Процесс сертификации долог, требует существенных ресурсов и часто не поспевает за темпом разработки. Это создаёт системный конфликт: бизнес-заказчики требуют внедрения новых решений, а комплаенс, следуя старым инструкциям, блокирует проекты из-за отсутствия формальных бумаг.
Тупиковая ситуация, где критичные для развития проекты зависали, заставила пересмотреть саму философию контроля. Фокус сместился с проверки предоставленного на оценку того, что можно увидеть и проверить на практике — архитектуры, команды и реальных внедрений.
Три новых столпа для оценки российского вендора
Когда проверить документ невозможно, на первый план выходит практическая экспертиза. Новый подход строится на трёх принципах, которые оценивают не формальности, а реальное положение дел.
Открытая архитектура и доступ к коду
Запрос архитектурной схемы или выборочного доступа к исходному коду критичных модулей (например, модуля аутентификации или работы с ключами) перестал быть исключением. Цель — не получить контроль над разработкой, а убедиться в отсутствии фундаментальных рисков: например, что система не хранит пароли в открытом виде или использует рекомендованные криптографические библиотеки. Часто выясняется, что документация устарела. Тогда практикуется совместная сессия, где архитектор вендора в реальном времени рисует схему, а специалисты заказчика задают вопросы и фиксируют ответы. Этот диалог становится частью протокола оценки.
Проверка команды, а не только юрлица
Опыт и репутация ключевых специалистов стали валидным аргументом. Проверяют не только компанию, но и технического лида, ведущих разработчиков, архитекторов безопасности. Наличие в команде людей с подтверждённым опытом в проектах для госсектора или банковской сфере снижает воспринимаемый риск. Интересен не только позитивный бэкграунд, но и участие в реальных инцидентах, это позволяет оценить зрелость процессов реагирования и культуру безопасности в коллективе.
Эталонное внедрение и практические отзывы
Успешный проект в другой крупной компании со схожими требованиями, это практическое доказательство жизнеспособности продукта. Важны не общие фразы, а детали. Запрашивают контакты для обратной связи: как организована поддержка, как часто и как проходят обновления, с какими типами инцидентов сталкивались. Такие данные дают картину достовернее любой маркетинговой презентации и позволяют оценить операционную зрелость поставщика.
Итогом подобной проверки становится не простое «да/нет», а карта рисков. Каждое выявленное несоответствие (например, отсутствие сертификата) сопровождается предложением конкретной компенсирующей меры — например, развёртывание в изолированном сегменте, усиленный аудит логов или поэтапный ввод в эксплуатацию.
Пример: внедрение отечественной CRM в энергетическом холдинге
Требовалось заменить уходящую международную платформу. Выбранный российский поставщик — команда из 35 человек, компания зарегистрирована в 2020 году. Ключевой формальный риск — отсутствие сертификата ФСТЭК.
Вместо отказа комплаенс-команда инициировала создание совместной рабочей группы. Первым шагом стал аудит процессов разработки: предоставление доступа к системе управления задачами для оценки культуры работы с обновлениями и уязвимостями. Это выявило, что документация отставала от продукта, что стало основанием для нового требования — ведения открытого журнала значимых изменений.
Далее был изучен отчёт о тестировании на проникновение, выполненный для другого заказчика. Ключевым было не просто получить отчёт, а возможность задать вопросы непосредственно специалисту, проводившему тесты, чтобы понять контекст и критичность выявленных проблем.
Отдельно оценивался ключевой сотрудник — архитектор с десятилетним опытом в сфере ИБ из известного интегратора. Его экспертиза была признана дополнительным смягчающим фактором.
Итоговое решение: допуск к пилотному внедрению в реальный, но ограниченный контур (85 пользователей из бухгалтерии) с набором условий. Среди них — предоставление ежеквартальных отчётов об актуальных уязвимостях и обязательная интеграция логов в SIEM-систему заказчика. Успешный восьмимесячный пилот без инцидентов безопасности стал основанием для решения о масштабировании на всю компанию.
Что изменить во внутренних документах
Чтобы новый подход стал системой, а не исключением, необходимо обновить внутреннюю нормативную базу. Формальные регламенты должны легализовать практику риск-ориентированной оценки.
| Область изменений | Старый подход | Новый подход |
|---|---|---|
| Шаблоны ТЗ и требования | Жёсткие списки с пунктами «обязательно наличие сертификата». | Градация требований: «критичные» (функциональная безопасность), «рекомендуемые» (сертификация) и «дополнительные». Введение понятия «компенсирующие меры контроля». |
| Процедура внедрения | Внедрение возможно только после полного формального соответствия. | Введение статуса «экспериментальной (пилотной) зоны внедрения» — работа в реальном контуре с ограниченным масштабом и усиленным мониторингом. |
| Работа с поставщиками | Каждый департамент проводит оценку вендора с нуля. | Создание внутреннего реестра поставщиков с результатами аудитов, картами рисков и контактами для верификации отзывов. |
| Договорные отношения | Стандартный договор поставки. | Дополнительное соглашение о прозрачности: обязательства по предоставлению отчётов об уязвимостях, содействию аудитам, участию в тренировках по реагированию на инциденты. |
Типичные ошибки при переходе
Смена парадигмы часто встречает сопротивление и приводит к характерным ошибкам, которые сводят на нет преимущества нового подхода.
- Тотальное недоверие и ужесточение требований сверх разумного. Вместо адаптации начинают запрашивать недостижимые в короткие сроки документы или требовать физического доступа к инфраструктуре вендора. Это блокирует процесс, не добавляя реальной безопасности.
- Ручное управление и отсутствие документирования. Решения принимаются на основе личных договорённостей и устных заверений без фиксации условий в протоколах. При смене ответственного лица весь процесс верификации начинается заново, наработанная экспертиза теряется.
- Игнорирование необходимости переобучения команды. Специалисты, привыкшие проверять сертификаты, часто не обладают навыками для анализа архитектурных схем, чтения отчётов pentest или ведения переговоров о доступе к коду. Без обучения их решения становятся субъективными и необоснованными.
- Неверная коммуникация с руководством. Предоставление отчётов в бинарном формате «одобрено/отклонено» не даёт руководству информации для взвешенного решения. Необходим формат с явным указанием уровня остаточного риска, перечнем принятых компенсирующих мер и зоной ответственности каждой из сторон.
Современный комплаенс, это не отказ от контроля, а его трансформация из формального в операционный. Главным активом становится не папка с документами, а способность ИБ-специалиста вести технический диалог, оценивать реальные компетенции команды и договариваться о практических мерах контроля. Этот подход требует большей вовлечённости и экспертизы, но именно он позволяет внедрять необходимые решения, управляя рисками, а не блокируя развитие бизнеса.