SOC 2 для українських SaaS: коли звіт справді потрібен і як до нього підготуватися

Що таке SOC 2 і чому про нього питають клієнти

SOC 2 це звіт незалежного аудитора про засоби контролю сервісної організації, пов'язані з безпекою та іншими критеріями довіри. Рамку визначає Американський інститут сертифікованих публічних бухгалтерів (AICPA), а звіт може випустити лише фірма сертифікованих публічних бухгалтерів (CPA), що має право проводити такі завдання з надання впевненості.

На відміну від ISO/IEC 27001, SOC 2 не є сертифікатом. Результатом є детальний звіт, який містить опис вашої системи, твердження керівництва, висновок аудитора і, для Type II, перелік контролів з результатами їх тестування. Звіт має обмежене поширення: його надають клієнтам і потенційним клієнтам, зазвичай за угодою про нерозголошення.

Для американських компаній, особливо фінтеху, охорони здоров'я, HR-технологій і корпоративного сектору, SOC 2 став стандартною вимогою до постачальників хмарних сервісів. Служба безпеки клієнта читає звіт, щоб не надсилати вам анкету на кількасот запитань і не проводити власний аудит.

Коли українському SaaS справді потрібен SOC 2

Не кожному продукту звіт потрібен одразу. Стартап на етапі перших пілотів часто може закрити угоду, надавши заповнену анкету безпеки, опис архітектури і політики. Але коли продукт переходить до корпоративних клієнтів, без звіту цикл продажів помітно розтягується, бо кожен клієнт проводить власну перевірку. Тому рішення про SOC 2 варто ухвалювати разом з комерційною командою, дивлячись на конкретні угоди.

Варто серйозно розглядати SOC 2, якщо виконується хоча б одна з умов:

• Основний ринок або великі цільові клієнти знаходяться в США.
• У воронці продажів є угоди, що зупинилися на етапі перевірки безпеки, і клієнт прямо вимагає SOC 2.
• Продукт обробляє чутливі дані клієнтів: фінансові, медичні, кадрові, дані їхніх кінцевих користувачів.
• Ви продаєте в корпоративний сегмент, де процеси закупівлі формалізовані.
• Інвестори або партнери очікують незалежного підтвердження зрілості безпеки.

SOC 2 чи ISO 27001: що обрати першим

Якщо ваші клієнти переважно в Європі, частіше запитують сертифікат ISO/IEC 27001. Якщо в США, то SOC 2. Багато SaaS-компаній з часом мають обидва, і це логічно, бо значна частина контролів збігається: управління доступом, управління змінами, резервне копіювання, реагування на інциденти, оцінка постачальників, навчання персоналу.

Для українського продукту, що продає і в ЄС, і в США, розумна стратегія полягає в тому, щоб побудувати єдину систему контролів і документів, а потім проходити обидві перевірки на одній доказовій базі. Порядок визначає воронка продажів: що блокує більше угод, те й робіть першим.

Варто враховувати і різницю у форматі. Сертифікат ISO 27001 діє три роки з щорічними наглядовими аудитами і підтверджує наявність системи управління. Звіт SOC 2 Type II описує конкретні контролі та результати їх тестування за минулий період, тому клієнти сприймають його як детальніший доказ того, що контролі справді працюють.

Type I чи Type II і як обрати критерії

Звіт Type I оцінює, чи правильно спроєктовані контролі на певну дату. Звіт Type II оцінює, чи вони ефективно працювали протягом періоду, який зазвичай становить від трьох до дванадцяти місяців. Клієнти здебільшого хочуть бачити Type II, але Type I дозволяє швидше показати прогрес і почати продажі, поки триває період спостереження.

Критерії довіри (Trust Services Criteria) включають п'ять категорій. Безпека обов'язкова завжди і спирається на загальні критерії CC1-CC9: середовище контролю, комунікація, оцінка ризиків, моніторинг, контрольні дії, логічний і фізичний доступ, експлуатація систем, управління змінами, зниження ризиків. Інші чотири категорії, а саме доступність, цілісність обробки, конфіденційність і приватність, ви додаєте за потреби.

Не додавайте всі категорії лише для солідності. Кожна категорія збільшує обсяг роботи і кількість контролів, які потрібно підтримувати. Доступність має сенс, якщо ви берете зобов'язання щодо SLA. Конфіденційність підходить, якщо обробляєте комерційно чутливі дані клієнтів. Приватність варто додавати лише тоді, коли клієнти цього прямо вимагають.

Особливості для українських компаній

Аудит SOC 2 виконують CPA-фірми, переважно американські або їхні партнери в інших країнах. Більшість роботи проводиться дистанційно, тому розташування команди в Україні не є перешкодою. Але аудитор захоче зрозуміти, де фізично працюють люди, як захищені їхні пристрої, як компанія забезпечує роботу під час відключень електроенергії і проблем зі зв'язком.

Особливу увагу варто приділити безперервності. Якщо ви включаєте критерій доступності, аудитор перевірятиме план безперервності, резервне копіювання, тестування відновлення і моніторинг. Наявність хмарної інфраструктури в іншій країні допомагає, але сам процес реагування, хто і як піднімає систему після збою, має бути описаний і протестований.

Ще одна особливість стосується підрядників. Якщо частина команди працює як ФОП, аудитор розглядатиме їх у межах контролів щодо персоналу: перевірка перед наймом, підписання політик, навчання, своєчасне відкликання доступів. Ці процеси мають працювати однаково для штатних працівників і контракторів.

Нарешті, хмарний провайдер. Якщо ви працюєте на AWS, Google Cloud чи Azure, у звіті він зазвичай описується як субсервісна організація методом виключення (carve-out). Вам потрібно мати актуальний звіт SOC провайдера і показати, що ви його переглядаєте.

Що перевіряє аудитор і які докази потрібні

Під час аудиту Type II аудитор робить вибірки за весь період і перевіряє, чи контроль виконувався щоразу, як це описано. Через це важливо не лише мати процеси, а й залишати сліди їх виконання. Типовий набір доказів виглядає так:

• Політики безпеки, затверджені керівництвом, і підтвердження ознайомлення від працівників.
• Записи про прийом і звільнення: перевірка, підписання NDA, надання і відкликання доступів у визначений строк.
• Квартальний перегляд прав доступу до продакшн-систем і репозиторіїв.
• Pull request з рецензією і затвердженням для змін у коді та інфраструктурі.
• Журнали моніторингу, сповіщення і записи про реагування на них.
• Результати сканування вразливостей і тестування на проникнення, записи про усунення.
• Звіти про резервне копіювання і тест відновлення.
• Оцінка ризиків, оцінка постачальників, протоколи аналізу з боку керівництва.

Типові помилки під час першого SOC 2

Найчастіше перший звіт Type II містить винятки не через відсутність контролів, а через нерегулярність. Перегляд доступів провели в першому кварталі, а в другому забули. Двох працівників звільнили, але доступ до хмарної консолі відкликали через тиждень замість обіцяних 24 годин. Кілька змін потрапили в продакшн без рецензії, бо розробник мав права адміністратора репозиторію.

Друга помилка полягає в надто амбітному описі системи. Компанія копіює шаблонні політики, де обіцяє щомісячні тести відновлення і щотижневий аналіз журналів, а потім не може виконати ці обіцянки. Аудитор перевіряє саме те, що ви написали, тому краще описати реалістичний процес і виконувати його без пропусків.

Третя помилка стосується меж системи. Якщо до обсягу включено зайві інструменти, внутрішні сервіси чи окремий продукт, який ще не готовий, кількість контролів і вибірок різко зростає. Четверта помилка: не враховано контролі на боці клієнта (complementary user entity controls), наприклад обов'язок клієнта самостійно керувати доступами своїх користувачів. Їх потрібно чітко описати у звіті.

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

План підготовки на 4-6 місяців до старту аудиту

Конкретні строки залежать від зрілості процесів і розміру команди, тому розглядайте цей план як орієнтир. Перший місяць: визначте межі системи, критерії довіри і відповідальних, проведіть оцінку розривів. Другий і третій місяць: напишіть або оновіть політики, налаштуйте MFA, централізоване управління доступами, журналювання, захист пристроїв, процес змін через рецензування коду.

Четвертий місяць: запустіть регулярні процедури, такі як перегляд доступів, навчання, оцінка постачальників, тест відновлення. Оберіть аудитора і погодьте з ним обсяг. Далі можна пройти Type I, а потім почати період спостереження для Type II. Важливо, щоб з першого дня періоду всі контролі вже працювали, бо прогалини в середині періоду потраплять у звіт як винятки.

Звіт потрібно оновлювати щороку. Між звітами клієнти можуть попросити bridge letter, тобто лист керівництва про відсутність суттєвих змін у системі контролів після закінчення періоду попереднього звіту.

Перед тим як запрошувати аудитора, корисно чесно оцінити стартову точку. Безкоштовна самооцінка на baltum.ai за SOC 2 покаже, які критерії ви вже покриваєте і де найбільші прогалини.

Стаття має інформаційний характер і не є юридичною консультацією. baltum.ai — незалежне програмне забезпечення, а не орган із сертифікації.