Определение границ первого отчёта SOC 2 без лишних обязательств

Отчёт SOC 2 охватывает систему: сервис, который покупают клиенты, и всё, что за ним стоит. Если провести границу слишком широко, вы месяцами будете подтверждать контроли, о которых никто не спрашивал. Если провести её слишком узко, отчёт не ответит на вопрос клиента. Большинство дорогостоящих ошибок при первом отчёте SOC 2 допускается на неделе определения границ.

Решение 1: какая система

Отталкивайтесь от того, что покупают клиенты и от чего они зависят. Для большинства software-компаний это производственная платформа: приложение, его инфраструктура и хранилища данных, люди, которые её разрабатывают и эксплуатируют, а также процессы, которым они следуют. Обычно вне области охвата остаются внутренние корпоративные ИТ-системы, которые не затрагивают клиентские данные, другие продуктовые линейки и системы продаж.

Зафиксируйте границу на раннем этапе, поскольку она станет описанием системы в отчёте, а каждый контроль должен работать во всём, что в неё входит, каждый день периода наблюдения.

Решение 2: какие критерии

Категория Security, общие критерии CC1–CC9, обязательна. Остальные добавляйте только тогда, когда они нужны клиентам:

• Availability, если клиенты опираются на обязательства по доступности.
• Confidentiality, если вы храните клиентские данные, которые определены как конфиденциальные (большинство B2B-сервисов).
• Processing Integrity, если клиенты полагаются на то, что вы корректно обрабатываете их данные: платежи, расчёт зарплаты, биллинг.
• Privacy, если вы обрабатываете персональные данные для собственных целей и клиенты этого требуют. Большинство её критериев не имеют аналогов в стандартах информационной безопасности, как показывает наш анализ SOC 2 и ISO 27001.

Решение 3: сервисные организации

Ваш облачный провайдер, платёжный процессор или поставщик управляемой базы данных исполняют контроли, на которые вы опираетесь. Выбор из двух вариантов:

• Carve-out (наиболее распространённый): их контроли исключаются; вы описываете, для чего полагаетесь на них, и показываете, что проверяете их собственные отчёты SOC 2.
• Inclusive: их контроли тестируются в рамках вашего отчёта. Это требует их сотрудничества и редко встречается у крупных провайдеров.

Решение 4: контроли пользовательских организаций (CUEC)

Перечислите контроли, которые клиенты должны выполнять, чтобы ваши работали: управление собственными учётными записями, защита API-ключей, настройка SSO. Делайте их реалистичными и немногочисленными, поскольку клиенты их читают, а их службы безопасности будут ставить под сомнение необоснованный список.

Решение 5: Type I или Type II и период

Type I готовится быстрее, но большинство клиентов хотят Type II. Для первого Type II часто выбирают период от трёх до шести месяцев. Начинайте период только тогда, когда контроли работают уже несколько недель, чтобы в начале периода не было большого количества исключений.

Контрольный список для определения границ

Перед стартом с вашей аудиторской фирмой CPA ответьте на следующие вопросы:

• К какому продукту или сервису относится отчёт и для чего клиенты на него полагаются?
• Какие среды входят в область охвата (только производственная или также staging)?
• Какие облачные аккаунты, регионы и хранилища данных?
• Какие команды и роли эксплуатируют систему?
• От каких сервисных организаций зависит система и есть ли у вас их отчёты?
• Какие категории Trust Services Criteria и почему?
• Какие контроли пользовательских организаций понадобятся клиентам?
• Сначала Type I или сразу Type II? За какой период?
• Можно ли переиспользовать доказательства из существующих стандартов или аудитов?

Письменные ответы становятся первым черновиком описания системы и экономят недели переписки. Если у вас уже есть ISO 27001, отчёт о разрывах ISO 27001 → SOC 2 ответит на последний вопрос.

Ошибки в определении границ, которые обходятся дороже всего

• Включение корпоративной ИТ-инфраструктуры «на всякий случай»: это удваивает количество систем, для которых нужно собирать доказательства.
• Добавление Privacy или Processing Integrity, потому что звучит хорошо: каждая категория добавляет контроли и доказательства за весь период.
• Описание системы, не соответствующее действительности: аудиторы проверяют то, что вы написали.
• Начало периода до того, как контроли заработают: исключения за первый месяц остаются в отчёте.

Итоговое руководство по процессу см. в нашем руководстве по SOC 2; на странице стандарта SOC 2 перечислены все критерии с их соответствиями; а если у вас уже есть другой стандарт, анализ разрывов покажет, насколько он вам поможет.

Вопросы

Каков минимальный охват отчёта SOC 2?

Категория Security (общие критерии CC1–CC9) для определённой системы. Availability, Confidentiality, Processing Integrity и Privacy являются необязательными.

Что такое carve-out в SOC 2?

Исключение контролей сервисной организации (например, контролей дата-центров облачного провайдера) из вашего отчёта с описанием того, для чего вы на неё полагаетесь и как осуществляете её мониторинг.