Trust Services Criteria у SOC 2: які категорії потрібні SaaS-компанії та як не розширити scope без потреби
Коли міжнародний клієнт запитує у SaaS-компанії звіт SOC 2, перше питання зазвичай стосується термінів і бюджету. Проте ще до початку перевірки потрібно ухвалити важливе рішення: які саме категорії Trust Services Criteria включити до її обсягу. Помилка на цьому етапі може коштувати компанії додаткових місяців підготовки, зайвих витрат і значного навантаження на команду.
Trust Services Criteria SOC 2 охоплюють п’ять категорій: Security, Availability, Processing Integrity, Confidentiality та Privacy. Але це не означає, що кожній SaaS-компанії необхідно проходити перевірку за всіма п’ятьма. Правильний вибір залежить від функціональності продукту, договірних зобов’язань, ризиків і потреб користувачів звіту.
Що таке Trust Services Criteria та як вони впливають на scope SOC 2
Trust Services Criteria (TSC) — це критерії, розроблені AICPA для оцінювання контролів, пов’язаних із безпекою, доступністю, цілісністю обробки, конфіденційністю та приватністю інформації.
Security є обов’язковою категорією для кожної перевірки SOC 2. Решту категорій компанія включає відповідно до характеристик системи та зобов’язань перед клієнтами.
Важливо розрізняти категорії TSC та scope перевірки. Категорії визначають, які аспекти роботи системи оцінюватиме аудитор, а scope — які сервіси, інфраструктура, процеси та організаційні підрозділи охоплює перевірка.
Наприклад, якщо компанія включає Availability, аудитор оцінюватиме відповідні контролі забезпечення доступності системи. Це може потребувати додаткових доказів щодо моніторингу, резервного копіювання, відновлення та управління інцидентами.
П'ять категорій SOC 2: що обрати SaaS-компанії
1. Security — обов’язкова основа
Охоплює захист систем від несанкціонованого доступу, розкриття інформації та інших загроз. Передбачає управління доступом, моніторинг безпеки, реагування на інциденти та управління ризиками.
2. Availability — доступність сервісу
Доцільна для SaaS-продуктів із договірними зобов’язаннями щодо доступності, безперервності роботи або відновлення. Особливо актуальна для платформ, простої яких впливають на бізнес-процеси клієнтів.
3. Processing Integrity — цілісність обробки
Стосується повноти, точності, своєчасності та авторизованості обробки даних відповідно до цілей системи. Може бути важливою для платіжних платформ, білінгових сервісів та систем автоматизованого обліку.
4. Confidentiality — конфіденційність
Стосується захисту інформації, визначеної як конфіденційна. Її варто розглядати, якщо компанія зберігає комерційні таємниці клієнтів, фінансові документи або інші дані з договірними обмеженнями на використання й розкриття.
5. Privacy — приватність
Охоплює обробку персональної інформації відповідно до зобов’язань компанії та застосовних критеріїв приватності. Актуальна для сервісів, які збирають і використовують персональні дані та мають відповідні зобов’язання перед користувачами.
Важливий нюанс: наявність персональних даних не означає автоматичної необхідності включення Privacy. Так само використання хмарної інфраструктури не робить Availability обов’язковою категорією.
Як визначити критерії SOC 2 для SaaS без зайвих витрат
Починати варто не з переліку контролів, а з аналізу реальних зобов’язань компанії. Перед затвердженням scope залучіть sales, legal, product, security та compliance до спільного обговорення.
Насамперед перевірте:
- Договори та SLA: які гарантії компанія надає щодо доступності, обробки та захисту інформації.
- Вимоги клієнтів: які категорії SOC 2 прямо зазначені в контрактах, тендерах і security questionnaires.
- Архітектуру продукту: які компоненти системи забезпечують виконання заявлених зобов’язань.
- Ризики: які порушення можуть істотно вплинути на клієнтів і користувачів звіту.
- Готовність команди: які контролі вже функціонують і які докази їхньої роботи доступні.
За результатами такого аналізу формується обґрунтований scope SOC 2. Наприклад, B2B SaaS-платформа з вимогами щодо захисту інформації та доступності сервісу може розглядати поєднання Security і Availability, не включаючи автоматично решту категорій.
Чому не варто включати всі категорії SOC 2
Розширення scope має бути обґрунтованим. Кожна додаткова категорія може потребувати нових контролів, процедур, документування та аудиторських доказів.
Це впливає не лише на вартість перевірки, а й на роботу product, DevOps, security та compliance. Крім того, що більше контролів перевіряється, то більше потенційних відхилень може виявити аудитор.
Водночас економія не повинна суперечити зобов’язанням компанії. Якщо великий корпоративний клієнт прямо вимагає Availability або Confidentiality, виключення відповідної категорії може зробити звіт недостатнім для його потреб.
Як підготувати scope SOC 2 разом із консультантами
Оптимальний підхід — зіставити сервісні зобов’язання, ризики та очікування клієнтів із відповідними категоріями TSC ще до початку аудиту.
Компанія «Систем Менеджмент» допомагає SaaS-бізнесу структурувати підготовку до SOC 2, визначити обґрунтований обсяг перевірки, оцінити наявні контролі та спланувати усунення прогалин.
Головне правило: обирайте категорії SOC 2 Security Availability Confidentiality, а також Processing Integrity і Privacy не заради максимально широкого звіту, а відповідно до реальних зобов’язань вашого продукту. Саме такий підхід допомагає контролювати бюджет і отримати звіт, який відповідає потребам клієнтів.
