SOC 2: контрольные критерии безопасности

1) SOC 2 в двух словах

SOC 2 — независимая оценка того, как организация проектирует (Design) и исполняет (Operating) контроли в соответствии с Trust Services Criteria (TSC) AICPA.
В iGaming это повышает доверие регуляторов/банков/PSP/партнеров и упрощает TPRM.

• Type I — одно мгновенное состояние (на конкретную дату): корректно ли спроектированы контроли.
• Type II — за период (обычно 6–12 мес.): работают ли контроли на практике стабильно (с выборками).

2) Trust Services Criteria (TSC) и как их читать

3) Модель управления и обязательные элементы (Security – CC)

Governance & Risk: политика ИБ, риск-реестр, цели, роли/RACI, обучение.
Access Control: RBAC/ABAC, SoD, JIT/PAM, пароли/МFA, провиженинг SCIM/IGA, оффбординг ≤ 15 мин.
Change & SDLC: DevSecOps, SAST/DAST/DS, IaC-сканирование, CAB, журналы деплоев, откаты.
Logging & Monitoring: централизованные логи (WORM+подпись), SIEM/SOAR, алерты по KRI.
Vuln & Patch: процесс выявления/классификации, SLA на High/Critical, подтверждение развертывания.
Incident Response: playbook, RACI, war-room, постмортемы и CAPA.
Vendor/TPRM: due diligence, DPA/SLA, право аудита, мониторинг вендоров.

4) Расширенные критерии (A, C, PI, P)

Availability (A)

SLO/SLA и дашборды; DR/BCP (RTO/RPO), ежегодные тесты; емкость/кроss-регион; процесс инцидентов по доступности.

Confidentiality (C)

Классификация данных; шифрование at rest/in transit (KMS/HSM); токенизация PII; контроль экспортов (подпись, журнал); ретеншн.

Processing Integrity (PI)

Контроль качества данных: схемы/валидации, дедупликация, reconciliation; контроль запуска задач; управление изменениями в пайплайнах.

Privacy (P)

Политика приватности; RoPA/законные основания; CMP/согласия; DPIA/DSAR; маскирование/ретеншн; аудит трекеров/SDK.

5) Маппинг SOC 2 ↔ ваши политики/контроли

ISO 27001/ISMS → покрывает основу CC (управление рисками, политики, логи, уязвимости).
ISO 27701/PIMS → закрывает множество Privacy-критериев.
Внутренние разделы: RBAC/Least Privilege, Парольная политика и MFA, Политика логов, Инциденты, TPRM, DR/BCP — напрямую маппятся на TSC.

6) Каталог контролей и примеры evidences

Для каждого контроля: ID, цель, владелец, частота, метод (авто/ручной), источники доказательств.

• `SEC-ACCESS-01` — MFA на админ-доступы → IdP-отчет, скрины настроек, выборка логов.
• `SEC-IGA-02` — Offboarding ≤ 15 мин → SCIM-логи, тикеты увольнений, журнал блокировок.
• `SEC-LOG-05` — Неизменяемые журналы (WORM) → конфиги, хэш-цепочки, экспорт выборок.
• `AVAIL-DR-01` — Ежегодный DR-тест → протокол теста, фактические RTO/RPO.
• `CONF-ENC-03` — KMS/HSM управление ключами → политики ротации, аудит KMS.
• `PI-DATA-02` — Reconciliation по платежам → отчеты сверки, инциденты, CAPA.
• `PRIV-DSAR-01` — SLA по DSAR → реестр запросов, таймштампы, шаблоны ответов.

7) Процедуры (SOP) для поддержания SOC 2

SOP-1 Инциденты: детект → triage → containment → RCA → CAPA → отчет.
SOP-2 Управление изменениями: PR→CI/CD→сканы→CAB→деплой→мониторинг→откат/фиксы.
SOP-3 Уязвимости: intake→классификация→SLA→верификация фикса→выпуск отчета.
SOP-4 Доступы: JML/IGA, квартальная ре-сертификация, SoD-блоки, JIT/PAM.
SOP-5 DR/BCP: ежегодные тесты, частичные учения, публикация RTO/RPO фактов.
SOP-6 Экспорты/конфиденциальность: белые списки, подпись/журнал, ретеншн/удаления.

8) Подготовка к аудиту: Type I → Type II

1. Гэп-анализ TSC: матрица покрытий, список недостающих контролей.
2. Политики и процедуры: актуализировать, назначить владельцев.
3. Единое хранилище evidence: логи, отчеты IdP/SIEM, тикеты, экспорт выборок (с подписями).
4. Internal Readiness Audit: прогон вопросника аудитора, фиксация выборок.
5. Type I (дата X): показать дизайн контролей и факт запуска.
6. Период наблюдения (6–12 мес.): непрерывный сбор артефактов, закрытие находок.
7. Type II: предоставить выборки за период, отчет об операционной эффективности.

9) Метрики (KPI/KRI) для SOC 2

• MFA adoption (админы/критичные роли) = 100%
• Offboarding TTR ≤ 15 мин
• Patch SLA High/Critical закрыто ≥ 95% в срок
• DR-тесты: выполнение план-графика = 100%, фактические RTO/RPO в норме
• Coverage логированием (WORM) ≥ 95% критичных систем

• Доступ к PII без `purpose` = 0
• Нарушения SoD = 0
• Инциденты уведомлены позже регламентов = 0
• Повторные уязвимости High/Critical > 5% — эскалация

10) RACI (укрупненно)

11) Чек-листы

11.1 Readiness (перед Type I)

• Scope (TSC и системы) зафиксирован
• Политики/процедуры актуальны и одобрены
• Назначены владельцы контролей и метрики
• Прототип evidence-хранилища готов (логи, отчеты IdP/SIEM, тикеты)
• Таблетоп по инциденту и DR-мини-тест проведены
• Риски и SoD-матрица подтверждены

11.2 Период наблюдения (между I и II)

• Еженедельный сбор выборок/экспортов логов
• Ежемесячный отчет по KPI/KRI
• Закрытие уязвимостей в SLA
• Квартальная ре-сертификация прав
• DR/BCP тест в соответствии с планом

11.3 Перед Type II

• Полный набор evidence за период (по каждому контролю)
• Реестр инцидентов/уязвимостей и CAPA
• Отчет Management Review (итоги периода)
• Обновленная матрица маппинга TSC↔контроли

12) Частые ошибки и как их избежать

«Политики без практики»: показывайте логи, тикеты, протоколы DR/инцидентов — не только документы.
Слабое логирование: без WORM/подписей и четкой семантики событий аудит сложнее.
Нет ре-сертификации прав: риск «висячих» доступов — критичный минус.
Неполный Scope вендоров: SOC 2 видит цепочку — добавьте TPRM, DPA/SLA, права аудита.
Разовый рывок без рутины: внедрите CCM/дашборды и ежемесячную отчетность.

13) Дорожная карта (12–16 недель → Type I, еще 6–12 мес. → Type II)

Недели 1–2: гэп-анализ TSC, Scope, владельцы, план работ.
Недели 3–4: обновить политики/процедуры, собрать каталог контролей и матрицу маппинга.
Недели 5–6: настроить логи (WORM/подпись), SIEM/SOAR, уязвимости/патчи SLA, IdP/MFA, IGA/JML.
Недели 7–8: DR/BCP минимальные тесты, TPRM-обновления (DPA/SLA), репетиция инцидента.
Недели 9–10: evidence-хранилище, отчетность KPI/KRI, внутренний readiness-аудит.
Недели 11–12: финальные правки, бронь аудитора, Type I.
Далее: еженедельный сбор артефактов, квартальные ревью → Type II по завершении периода.

TL;DR

SOC 2 = ясный Scope TSC → каталог контролей с владельцами и метриками → evidence по Design & Operating → непрерывные логи/SIEM/IGA/DR/TPRM → Readiness → Type I → период наблюдения → Type II. Делайте «доказуемость по умолчанию» — и аудит пройдет без сюрпризов.