NIS2 и GDPR: как доказать соответствие результатами пентеста
Директива NIS2 формально не действует в Молдове — и всё же всё чаще звучит вопрос: «Можете доказать, что ваши системы тестировали?» Разбираем, что именно требуют NIS2 и GDPR и какие доказательства даёт пентест.
Представьте типичный разговор. Молдавская компания выигрывает тендер у европейского заказчика, согласовывает цены, сроки, логистику — и вдруг получает письмо от юридического отдела партнёра: «Предоставьте, пожалуйста, доказательства того, что ваши системы проходили тестирование на проникновение в рамках требований NIS2». Никто в компании не нарушал закон. Никто не обязан был ничего делать по молдавскому законодательству. Но сделка замирает, пока на этот вопрос нет ответа.
Именно так европейское регулирование кибербезопасности просачивается в Молдову — не через парламент, а через контракты. В этом материале мы разберём, кому и почему стоит беспокоиться уже сегодня, что конкретно требуют статьи NIS2 и GDPR и какие документы превращают пентест из технической процедуры в доказательство для аудитора, заказчика и регулятора.
Кому это вообще грозит в Молдове
Начнём с главного недоразумения. NIS2 — это директива Европейского союза, и она не применяется напрямую как закон в Молдове. Услышав это, многие расслабляются: мол, нас это не касается. Это ошибка, и ошибка дорогая.
Требование приходит к молдавским компаниям тремя путями, и каждый из них работает уже сейчас.
- Операции или филиалы в ЕС. Если вы предоставляете услуги на европейском рынке, вы можете напрямую попасть в категорию «существенных» или «важных» субъектов — со всеми вытекающими обязанностями.
- Цепочка поставок. Если вы поставщик регулируемой европейской организации, она потребует от вас доказательства безопасности как часть собственного соответствия NIS2. Требование передаётся вверх по цепочке — к вам.
- Законодательная гармонизация. Молдова постепенно приводит свою нормативную базу в соответствие с европейскими стандартами, и компании, которые внедряют требования заранее, получают реальное конкурентное преимущество в тендерах и партнёрствах.
Проще говоря: не ждите, пока NIS2 станет местным законом. Если вы продаёте в ЕС или находитесь в цепочке поставок того, кто это делает, требование уже вас касается — через договор, а не через закон.
Примечание: это не юридическая консультация. Применимость NIS2 и GDPR зависит от конкретной ситуации каждой организации — для правовой интерпретации обращайтесь к профильному юристу.
Что NIS2 понимает под словом «тестирование»
Статья 21 NIS2 требует «соразмерных технических, операционных и организационных мер» по управлению киберрисками. Среди этих мер — политики оценки эффективности мер безопасности. Разница между «у нас есть файрвол» и «мы можем доказать, что файрвол работает» — это и есть разница между декларацией и соответствием.
Пентест даёт именно это доказательство: практическую проверку защиты против реальных сценариев атаки, задокументированную в отчёте, который аудиторы и партнёры принимают как свидетельство. Не слайд с галочками, не самооценку в опроснике, а документ, где написано: такую-то систему атаковали такими-то методами, вот что получилось, вот как это исправили.
GDPR: где здесь персональные данные
Статья 32 GDPR требует технических мер для обеспечения конфиденциальности, целостности и доступности персональных данных — плюс «процесс регулярного тестирования, оценки и анализа эффективности» этих мер. Обратите внимание на слово «регулярного»: однократная проверка три года назад не закрывает вопрос.
Пентест показывает, где персональные данные могут оказаться открытыми. Это может быть уязвимое веб-приложение, неаутентифицированный API, неправильно настроенное облачное хранилище или избыточные права сервисной учётной записи. Для Data Protection Officer это прямая доказательная база: меры не просто задекларированы, а проверены. Когда регулятор или партнёр задаёт вопрос «как вы убедились, что защита работает», на него есть что ответить кроме слов.
Кто что требует — и что даёт пентест
Удобнее всего свести соответствие разных框架 к одной таблице. Слева — что требует норматив, справа — какой артефакт вы получаете на выходе.
| Рамка | Требование | Результат пентеста |
|---|---|---|
| NIS2 — ст. 21 | Оценка эффективности мер управления рисками | Практическая проверка защиты и отчёт с находками |
| GDPR — ст. 32 | Конфиденциальность, целостность, доступность и регулярное тестирование | Пути утечки персональных данных и доказательства для DPO |
| OWASP Top 10 | Референсная методология для веб-приложений | Структурное тестирование по классам уязвимостей |
| Отраслевые требования | Тестирование по стандартам регулятора (например, BNM) | Отчёт, валидированный требование за требованием |
Последняя строка заслуживает отдельного внимания. Финансовый сектор и платёжные компании в Молдове работают под надзором Национального банка, и здесь отчётность должна быть не просто технически корректной, но и выстроенной в логике регулятора. Пентест, выполненный без понимания этой логики, придётся переделывать.
Что попадает в папку соответствия
Разговор о пентесте часто сводится к «найденным дырам». Но для целей соответствия важнее не то, сколько уязвимостей нашли, а то, какие документы остались после работы. Хороший пентест оставляет четыре вещи, и все они ложатся в досье.
- Технический отчёт с перечнем уязвимостей, оценкой риска и шагами по устранению.
- Резюме для руководства и совета директоров — на языке бизнес-рисков, а не CVE-идентификаторов.
- Картирование находок на требования NIS2 и GDPR — по запросу, чтобы аудитор видел связь между технической находкой и пунктом норматива.
- Повторное тестирование после устранения — доказательство того, что проблемы действительно закрыты, а не отмечены как «в работе».
Именно такой набор документов уже помогал финансовым учреждениям и платёжным процессорам Молдовы проходить аудиты и процедуры регистрации в Национальном банке. Разница между «мы провели пентест» и «мы можем это доказать» — ровно в этих четырёх артефактах.
Внимание: отчёт годичной давности без повторного тестирования — слабое доказательство. Аудитор первым делом спросит, что изменилось после устранения находок и проверял ли кто-нибудь, что исправления действительно работают.
Как часто это нужно делать
Универсального ответа нет, но есть рабочая отправная точка: минимум раз в год и после любого существенного изменения систем. К существенным изменениям относятся крупный релиз, новая инфраструктура, миграция в облако или смена архитектуры аутентификации. Регулируемые среды часто тестируют чаще или переходят к непрерывному тестированию — особенно там, где цена ошибки измеряется не репутацией, а лицензией.
Логика здесь простая. Соответствие — это не статус, который однажды получают и вешают на стену. Это состояние, которое нужно поддерживать, потому что системы меняются каждый день, а вместе с ними меняется и поверхность атаки. Пентест — это фотография этого состояния на конкретную дату. Чем дольше вы не делаете новый снимок, тем меньше он говорит о реальности.
Что делать на практике
Если вы узнали себя хотя бы в одном из трёх сценариев выше, порядок действий довольно предсказуем. Сначала определите периметр: какие системы обрабатывают персональные данные, какие участвуют в оказании услуг европейским партнёрам, какие попадают под отраслевое регулирование. Затем сформулируйте, какие доказательства у вас спросят — и кто именно: заказчик, аудитор, DPO или регулятор.
Дальше стоит выбрать методологию и исполнителя, который понимает не только техническую сторону, но и язык соответствия. Пентест, отчёт которого невозможно приложить к досье, — это потраченные деньги. И наконец, встройте повторное тестирование в процесс устранения, чтобы цикл закрывался документально, а не на словах.
Важно: если вы поставляете услуги европейской организации, требование о доказательствах безопасности почти наверняка уже прописано в вашем договоре или в приложении к нему. Стоит перечитать контракт до того, как партнёр напомнит о нём сам.
Самое интересное в этой истории то, что NIS2 и GDPR — не бюрократическая повинность, а довольно точное описание того, что и так имеет смысл делать. Регулярно проверять свою защиту против реальных атак — это ровно то, чем занимается зрелая инженерная команда, независимо от директив. Нормативы лишь превращают эту практику в документ, который можно предъявить. Компании, которые поняли это раньше других, выигрывают не потому, что выполнили требования, а потому, что действительно стали устойчивее — и могут это доказать.