Первый запрос на SOC 2 часто приходит вместе с перспективным контрактом: заказчик хочет понять, как защищены его данные. Однако подготовку стоит начинать с определения системы, которую будет оценивать аудитор. В компании BALTUM BUREAU мы рекомендуем сначала согласовать границы проверки. Это помогает связать ожидания клиента с реальной архитектурой продукта и объёмом работ.

Отчет SOC 2 Type I актуален для компаний из Узбекистана, предоставляющих B2B-услуги казахстанскому бизнесу. Покрытие и границы аудита (Scope) определяются архитектурой конкретного сервиса, потоками обрабатываемых данных и договорными обязательствами перед заказчиками, а не страной юрисдикции или физической регистрации провайдера. 

Что оценивает первая проверка

SOC 2 Type I предполагает оценку описания системы и пригодности устройства контролей на определённую дату. Он не подтверждает эффективность их работы за продолжительный период — это задача Type II. Результатом становится отчёт независимого аудитора, а не ISO-сертификат.

Поэтому подготовка к SOC 2 облачного сервиса требует определить продукт, пользователей, обязательства по безопасности и применимые категории критериев. Например, обещание доступности должно быть связано с конкретными механизмами резервирования и восстановления.

Какие продукты, системы и команды включить

Область аудита SOC 2 должна охватывать компоненты, от которых зависит выполнение заявленных обязательств. Недостаточно указать название приложения: нужно проследить путь клиентских данных и способы управления сервисом.

При составлении SOC 2 scope проверьте следующие элементы:

• Продукты: веб-приложение, API, административная панель и включённые в услугу модули.
• Инфраструктура: облачные аккаунты, регионы размещения, базы данных, хранилища, резервные копии и журналы событий.
• Средства управления: система идентификации, репозитории, инструменты развёртывания, мониторинг и управление секретами.
• Команды: разработка, DevOps, поддержка, безопасность и сотрудники, отвечающие за найм и прекращение доступа.
• Подрядчики: хостинг, внешние администраторы и поставщики, которые обрабатывают данные либо обеспечивают значимые функции.

Включение команды не означает проверку всей её деятельности. Значимы процессы, влияющие на выбранную систему. Например, HR подтверждает порядок проверки сотрудников и передачи информации об увольнении, а ИТ-команда — своевременное закрытие доступа.

Где заканчивается ответственность облачного провайдера

SOC 2 для облачного провайдера и SOC 2 для SaaS-компании, использующей его инфраструктуру, имеют разные границы. Размещение приложения в облаке не снимает с владельца сервиса ответственность за настройки, учётные записи и защиту данных. Точное распределение зависит от используемых облачных услуг.

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

С аудитором также согласуют способ отражения субсервисных организаций: включение их контролей в проверку или исключение этих контролей с описанием зависимости и необходимых мер со стороны поставщика.

Пример границ B2B-сервиса

Представим компанию из Ташкента, которая предоставляет клиентам Казахстана облачную платформу согласования договоров. Для первой проверки она выбирает основной SaaS-продукт и категорию Security.

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

Отдельный экспериментальный продукт можно исключить, если он изолирован и не влияет на проверяемую услугу. Но общий сервис авторизации или команда администраторов остаются значимыми зависимостями. Каждое исключение требует понятного обоснования.

Что зафиксировать до начала подготовки

Итог определения границ — согласованное описание системы: услуга, данные, компоненты, ответственные, подрядчики, критерии и дата проверки. К нему полезно приложить схему потоков данных и матрицу ответственности.

Если сервис работает с европейскими заказчиками, дополнительно изучите материал об ISO 27701 и персональных данных. Сопоставить направления подготовки поможет статья о стандартах для IT-компаний Казахстана и СНГ.

BALTUM BUREAU поможет определить scope перед началом подготовки, выявить зависимости и составить план работ. Оставьте заявку через форму обратной связи, чтобы обсудить границы первой проверки вашего облачного сервиса.