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 привлеките отделы продаж, юридический отдел, команды разработки продукта, информационной безопасности и комплаенса к совместному обсуждению.
Прежде всего проверьте:
- Договоры и SLA: какие гарантии компания предоставляет в отношении доступности, обработки и защиты информации.
- Требования клиентов: какие категории SOC 2 прямо указаны в контрактах, тендерах и опросниках по информационной безопасности (security questionnaires).
- Архитектуру продукта: какие компоненты системы обеспечивают выполнение заявленных обязательств.
- Риски: какие нарушения могут существенно повлиять на клиентов и пользователей отчёта.
- Готовность команды: какие контроли уже функционируют и какие доказательства их работы доступны.
По результатам такого анализа формируется обоснованная область проверки (scope) SOC 2. Например, B2B SaaS-платформа с требованиями к защите информации и доступности сервиса может рассматривать сочетание Security и Availability, не включая автоматически остальные категории.
Почему не стоит включать все категории SOC 2
Расширение scope должно быть обоснованным. Каждая дополнительная категория может потребовать новых контролей, процедур, документации и аудиторских доказательств.
Это влияет не только на стоимость проверки, но и на работу команд разработки продукта, DevOps, информационной безопасности и комплаенса. Кроме того, чем больше контролей проверяется, тем больше потенциальных отклонений может выявить аудитор.
В то же время экономия не должна противоречить обязательствам компании. Если крупный корпоративный клиент прямо требует Availability или Confidentiality, исключение соответствующей категории может сделать отчёт недостаточным для его потребностей.
Как подготовить scope SOC 2 вместе с консультантами
Оптимальный подход — сопоставить обязательства по предоставлению услуг, риски и ожидания клиентов с соответствующими категориями TSC ещё до начала аудита.
Компания «Систем Менеджмент» помогает SaaS-бизнесу структурировать подготовку к SOC 2, определить обоснованную область проверки, оценить существующие контроли и спланировать устранение выявленных пробелов.
Главное правило: выбирайте категории SOC 2 — Security, Availability, Confidentiality, а также Processing Integrity и Privacy — не ради максимально широкого отчёта, а в соответствии с реальными обязательствами вашего продукта. Именно такой подход помогает контролировать бюджет и получить отчёт, который соответствует потребностям клиентов.
