Пентест для українського SaaS перед SOC 2 / ISO 27001: чого вимагають enterprise клієнти у 2026

Ще кілька років тому питання на кшталт "а є у вас SOC 2?" від потенційного клієнта звучало екзотично. Сьогодні для будь-якої української SaaS-компанії, що цілиться в EU або US ринок, це вже не запитання — це умова входу.

Ситуація змінилась одночасно з кількох сторін. По-перше, Дія.City залучила увагу міжнародних інвесторів до українського tech-сектору. По-друге, EU expansion після 2022 року прискорився — компанії шукають нові ринки, і перші ж enterprise переговори виявляють прогалини в документації. По-третє, українські корпоративні клієнти — банки, великі ритейл-мережі, оборонні підприємства — теж почали вимагати підтвердження безпеки від своїх SaaS-постачальників. Регулятор рухається в тому ж напрямку.

Пентест у цьому контексті — не "тест безпеки заради безпеки". Це частина evidence package, яку перевірить аудитор під час сертифікації. І тут виникає головна проблема: більшість українських команд замовляють пентест, отримують звіт — і з'ясовують під час аудиту, що цей звіт питань аудитора не закриває.

Чому сертифікація стала реальністю для українського SaaS у 2026

Кілька конкретних сценаріїв, які зустрічаються найчастіше:

US enterprise клієнт або американський інвестор. Стандартний security questionnaire від US компанії включає питання про SOC 2 Type II. Без нього угода або зависає на procurement review, або не проходить взагалі. Інвестори категорії Series A+ все частіше роблять SOC 2 умовою закриття раунду.

EU expansion і DORA/NIS2. Якщо ваш продукт орієнтований на фінансові установи або критичну інфраструктуру в EU — DORA і NIS2 вже набрали чинності. ISO 27001 є де-факто стандартом, який підтверджує відповідність для постачальників у цих секторах.

Дія.City і міжнародна видимість. Статус резидента Дія.City дає преференційний податковий режим, але разом з тим підвищує очікування партнерів щодо зрілості процесів безпеки.

Великі UA клієнти — банки, ОПК. НБУ вимагає від банків оцінювати безпеку SaaS-постачальників. Банки транслюють цю вимогу вниз до вендорів. Аналогічна динаміка в оборонному секторі.

У всіх цих сценаріях пентест є обов'язковим елементом. Але не будь-який пентест.

Пентест для SaaS — це не типовий веб-пентест

Стандартний веб-пентест перевіряє визначену поверхню атаки: автентифікацію, управління сесіями, обробку вхідних даних, контроль доступу, API-ендпоінти, поширені класи вразливостей (OWASP Top 10 і подібне).

Пентест SaaS має ту саму відправну точку, але для цілей аудиту обсяг виходить значно далі:

Ізоляція мультиорендності. Визначальна безпекова властивість SaaS-платформи — орендар A не може отримати доступ до даних орендаря B. Цю ізоляцію треба тестувати явно. Пентест, який не перевіряє межі між орендарями, пропускає найважливіший тест для SaaS-продукту. Аудитор запитає про це першим.

Рівень інфраструктури. SaaS-продукти працюють на хмарній інфраструктурі — AWS, GCP, Azure. Неправильні IAM-політики, надмірно відкриті S3-бакети, вразливості в оркестрації контейнерів або доступ до CI/CD-пайплайну можуть розкрити дані клієнтів, не торкаючись рівня застосунку взагалі. Якщо інфраструктурний рівень не в скопі — тест неповний.

API security поза OWASP API Top 10. Більшість SaaS-платформ відкривають API для інтеграцій з клієнтами, вебхуків, third-party з'єднань. Обмеження кількості запитів, обробка токенів автентифікації, застосування scope, горизонтальне підвищення привілеїв через API-ендпоінти — все це тестується недостатньо у стандартному скопі.

CI/CD як вектор атаки. Атаки на supply chain SaaS-продуктів дедалі частіше цілять у пайплайн збірки та розгортання, а не у production. Пентест SaaS має включати оцінку того, чи може CI/CD-середовище бути використане як вектор.

Провайдер, незнайомий з архітектурою SaaS, пропустить мультиорендність та інфраструктуру. Саме там найчастіше виявляються критичні знахідки.

SOC 2 vs ISO 27001 vs PCI DSS: що вимагається у вашому випадку

SOC 2

SOC 2 — стандарт атестації AICPA, орієнтований насамперед на US ринок. Пентест стосується критеріїв Trust Services Criteria з доступності, конфіденційності та безпеки.

Критерії SOC 2 не прописують конкретну частоту або методологію тестування. Аудитор перевіряє: чи є задокументована політика тестування безпеки, чи проводяться тести відповідно до цієї політики, чи знахідки закриваються у визначені терміни.

Ключовий нюанс для SOC 2 Type II: аудиторський період зазвичай 6 або 12 місяців. Пентест, проведений до початку цього періоду без жодного тестування всередині нього, аудитора не задовольнить. Тест має потрапляти в аудиторський вікно — і remediation evidence має підтверджувати закриття знахідок у цьому ж вікні.

Коли потрібен: US enterprise клієнти, американські інвестори, B2B SaaS з US expansion.

ISO 27001:2022

ISO 27001 Annex A Control 8.8 вимагає управління вразливостями. Control 8.26 стосується вимог до безпеки застосунків. Пентест підтримує risk treatment framework у Clause 6.

На відміну від SOC 2, аудитори ISO 27001 оцінюють систему управління в цілому, а не окремі контролі ізольовано. Пентест — це доказ того, що організація систематично виявляє і усуває технічні вразливості. Щорічне тестування є галузевою базовою лінією і відповідає очікуванням surveillance аудитів.

Коли потрібен: EU expansion, міжнародні партнери та клієнти будь-якого регіону, тендери від великих корпоративних клієнтів в Україні.

PCI DSS v4.0

PCI DSS v4.0 (єдина активна версія з березня 2024) має конкретні вимоги до пентестування в Requirement 11.4:

• 11.4.1: задокументована методологія пентестування

• 11.4.3: зовнішнє тестування не рідше одного разу на рік і після суттєвих змін інфраструктури або застосунку

• 11.4.4: знахідки що підлягають використанню усуваються і тестування повторюється для підтвердження

• 11.4.5: якщо використовується сегментація для ізоляції CDE, тестування має підтверджувати ефективність сегментації не рідше одного разу на шість місяців

Питання скопу PCI DSS — що входить до CDE і що зменшує scope — треба вирішити до планування пентесту.

Коли потрібен: якщо ваш продукт обробляє платіжні дані карток.

5 типових помилок українських SaaS-команд при скопінгу

Ці помилки ми бачимо системно.

1. Тестове середовище замість production. Staging рідко точно відтворює production конфігурацію. Аудитори всіх трьох фреймворків запитають: чи відповідає протестоване середовище тому, чим фактично користуються клієнти? Якщо пряме тестування production створює операційний ризик — рішення в ретельному тайминзі і координації, а не в заміні середовища на неточне.

2. Застосунок без інфраструктури. Для хмарного SaaS неправильні конфігурації інфраструктури — це значна поверхня атаки. Application-only scope дає неповну картину реального ризику. І аудитор це побачить.

3. Надто вузький scope навколо основного застосунку. Portals для адміністрування, customer-facing API, внутрішні дашборди з привілейованим доступом, developer tooling — все це часто залишається поза скопом на першому залученні. І саме там знаходяться суттєві знахідки.

4. Мультиорендність не специфікована явно. Якщо tenant isolation testing не прописаний у scope document, більшість провайдерів його не проведуть. Це треба вказати явно. І провайдер має продемонструвати досвід тестування ізоляції в архітектурах, подібних до вашої.

5. Немає бюджету на ретест. ISO 27001 і PCI DSS Requirement 11.4.4 вимагають підтвердження, що знахідки усунені. Пентест без ретесту залишає відкрите питання на аудиті: чи були вразливості виправлені правильно? Бюджет на ретест закладається при скопінгу початкового залучення, не після.

Як планувати pentest cycle

Щорічне тестування одним великим залученням — мінімум. Команди, що розглядають пентест як разову подію перед сертифікацією, отримують compliance gap на кожен наступний рік.

Більш обґрунтований підхід для SaaS з активною розробкою:

• Щорічне залучення з повним scope: зовнішня мережа, застосунок, інфраструктура, мультиорендність, API

• Цільове тестування після значних релізів або архітектурних змін — scope обмежений зміненими компонентами

• Безперервне автоматизоване сканування між ручними циклами — не замінник ручного тестування, але скорочує вікно між залученнями, в якому можуть існувати невиявлені вразливості

Для SOC 2 Type II: прив'язуйте цикл тестування до очікуваних дат аудиту, не до календарного року. Аудиторський вікно і calendar year рідко збігаються.

Один з наших клієнтів — українська B2B SaaS-платформа для автоматизації HR-процесів — вийшов на переговори з US enterprise партнером і отримав security questionnaire за два місяці до очікуваної дати підписання. Аудиторський цикл під SOC 2 Type II потребував мінімум 6 місяців. Ціна відсутності заздалегідь спланованого pentest cycle — затримка угоди на квартал.

Що має бути у звіті

Аудит задовольняє документація, яка доводить, що засоби контролю безпеки функціонують за призначенням. Звіт, корисний як audit evidence, містить:

Опис scope. Чітке зазначення що тестувалося (системи, середовища, методології) і що явно виключалося — та чому.

Методологія. Яка методологія застосовувалась: PTES (Penetration Testing Execution Standard), OWASP Testing Guide, NIST SP 800-115 або еквівалент. Аудитори шукають визнану методологію, не proprietary frameworks провайдера.

Знахідки з оцінками severity. Кожна знахідка: опис вразливості, доказ використання або proof of concept, CVSS score або еквівалент, уражені системи, рекомендоване усунення.

Executive summary. Виклад для ради та менеджменту, що характеризує загальний стан ризику без технічної експертизи для інтерпретації.

Remediation tracking. Для аудиту сам звіт недостатній — потрібен журнал усунення: посилання на знахідку, відповідальний виконавець, цільова дата, closure evidence (результат ретесту або запис про зміну конфігурації).

Звіт без будь-якого з цих елементів генерує аудиторські знахідки. Перевіряйте структуру звіту до того, як прийняти deliverable від провайдера.

Remediation vs risk acceptance: як працювати зі знахідками

Не кожна знахідка вимагає негайного усунення. Формально задокументоване прийняття ризику, затверджене відповідним органом, є допустимою аудиторською відповіддю для знахідок, які не можна усунути в межах аудиторського вікна або де вартість усунення непропорційна ризику.

Risk acceptance — не обхідний шлях. Це задокументоване управлінське рішення: організація визнає знахідку, оцінює ймовірність та вплив, приймає залишковий ризик на визначених умовах (compensating controls, дата перегляду, відповідальний). Для ISO 27001 це пов'язане із Statement of Applicability та risk treatment process. Для SOC 2 аудитор оцінить, чи є risk acceptance обґрунтованим і чи є compensating controls.

Незадокументоване прийняття ризику — знахідка просто не усунена і формально не прийнята — найгірший результат. Це сигналізує аудитору, що vulnerability management process не функціонує наскрізно.

Для Дія.City резидентів: що це додає до pentest scope

Статус резидента Дія.City не накладає додаткових формальних вимог до пентестування поза загальнозастосовним законодавством. Але він змінює контекст двома способами.

По-перше, міжнародні партнери і інвестори, що орієнтуються на Дія.City як на маркер зрілості компанії, мають вищі очікування щодо security posture. SOC 2 або ISO 27001 стають природним наступним кроком після отримання статусу.

По-друге, якщо продукт обробляє персональні дані громадян України або ЄС, в scope пентесту варто включити перевірку технічних контролів, що підтверджують відповідність вимогам захисту даних (GDPR Article 32 або відповідні норми українського законодавства). Аудитор з ISO 27001 це перевірить.

Окрема реальність: в умовах воєнного стану українські SaaS-компанії знаходяться під підвищеним тиском з боку державно-спонсорованих атакуючих. Scope пентесту для Дія.City резидента варто обговорити в контексті цього threat landscape — не для паніки, а для адекватного пріоритизування знахідок.

Якщо ви плануєте пентест перед SOC 2 або ISO 27001 сертифікацією і хочете підійти до скопінгу так, щоб звіт задовольнив аудитора, ми допомагаємо українським SaaS-командам визначити правильний scope, вибрати методологію і підготувати evidence package. Зв'яжіться, щоб обговорити вашу ситуацію.