SOC 2 — это независимое подтверждение (attestation) в отношении пяти критериев доверительных услуг AICPA: «Безопасность» обязательна, а остальные критерии — опциональны и ограничиваются рамками вашего сервиса. Это не сертификация. В отчёте показано, насколько ваши меры контроля (controls) надлежащим образом спроектированы, а для Type II — насколько эффективно они работали в течение времени.

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

Я уже помогал командам разобраться в этой путанице. Полезнее думать о соответствии SOC 2 не как о «значке», который вы покупаете. Это структурированный способ показать, что ваша организация защищает информацию клиентов с помощью мер контроля, которым реально следуют и которые можно подтвердить доказательствами.

Оглавление

• Что на самом деле означает соответствие SOC 2 на практике

  • Рабочие части взаимодействия по SOC 2

• Пять критериев доверительных услуг: объяснение

  • Безопасность задаёт базовый уровень

  • Доступность важна, когда клиенты зависят от бесперебойной работы

  • Целостность обработки — это про надёжные результаты

  • Конфиденциальность защищает ограниченную информацию

  • Конфиденциальность персональных данных: Privacy

• SOC 2 Type I vs Type II и когда выбирать каждый

  • SOC 2 Type I vs Type II — кратко

• Практический чек-лист подготовки к SOC 2: реальные меры контроля и доказательства

  • Начните с идентификации и доступа

  • Свяжите меры контроля инфраструктуры с записями

  • Сделайте поставщиков и инциденты проверяемыми

• Сроки и ожидания по стоимости SOC 2 для команд SaaS

  • Сроки SOC 2 и диапазоны стоимости в зависимости от стадии компании

• Как SOC 2 соотносится с ISO 27001 и GDPR

  • SOC 2 фокусируется на мерах контроля сервиса

  • ISO 27001 фокусируется на системе менеджмента информационной безопасности

  • GDPR создаёт юридические обязательства по защите персональных данных

• Типичные ошибки SOC 2 и как их избежать

  • Относиться к аудиту как к галочке

  • Задать рамки не той системы

  • Использовать инструменты, не определив меру контроля

  • Внедрять меры контроля в последнюю минуту

• Как Trupeer помогает с процедурами и обучением по SOC 2

• Вопросы по соответствию SOC 2, которые команды задают до начала

  • Кому нужен SOC 2?

  • Может ли стартап сразу перейти к Type II?

  • Как долго отчёт SOC 2 остаётся актуальным?

  • SOC 2 заменяет проверку безопасности клиента?

  • Какие доказательства клиенты запрашивают помимо отчёта?

Что на самом деле означает соответствие SOC 2 на практике

Соответствие SOC 2 — это независимый отчёт о подтверждении, а не сертификация. AICPA представила SOC 2 в 2009 году как аудиторский отчёт, ориентированный на меры контроля в сервисных организациях, и независимый аудитор оценивает эти меры контроля по выбранным критериям доверительных услуг. Пояснение PwC о SOC 2 даёт полезный контекст о том, как работает эта структура.

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

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

Рабочие части взаимодействия по SOC 2

Я объясняю процесс через четыре вопроса:

1. Какую услугу оценивают? Определите системы, людей, процессы и локации, которые поддерживают эту услугу.

2. Какие риски важны? Выберите критерии доверительных услуг, которые соответствуют обязательствам клиентов и модели сервиса.

3. Какие меры контроля устраняют эти риски? Сопоставьте ожидания с управлением доступом, мониторингом, управлением изменениями, реагированием на инциденты и связанными активностями.

4. Какие доказательства подтверждают, что меры контроля работают? Соберите записи, показывающие, что меры контроля были надлежащим образом спроектированы и, для Type II, работали последовательно.

Безопасность обязательна в каждом отчёте SOC 2. Доступность, целостность обработки, конфиденциальность и Privacy — опциональны, поэтому компания не включает автоматически все пять критериев.

Практическое правило: отчёт SOC 2 отвечает на вопрос клиента о подтверждении, но не гарантирует, что исчезли все возможные риски безопасности.

Если вы оцениваете поставщика, SOC 2 trust center может быть полезной отправной точкой, но вам всё равно нужно проверить рамки отчёта, даты, включённые критерии, мнение аудитора и любые исключения. Trupeer, например, имеет сертификации SOC 2 Type II и ISO 27001 и публикует детали безопасности через свой trust center.

Итог: соответствие SOC 2 означает построение и независимую проверку среды мер контроля, которая соответствует вашему сервису. Это доказательство подтверждения, а не постоянный сертификат или универсальная гарантия безопасности.

Пять критериев доверительных услуг: объяснение

Пять критериев доверительных услуг — это Security, Availability, Processing Integrity, Confidentiality и Privacy. Безопасность требуется в каждом взаимодействии, а остальные четыре выбираются в зависимости от сервиса, обещаний клиентов и рисков.

Безопасность задаёт базовый уровень

Безопасность отвечает на вопрос, защищает ли организация системы и информацию от несанкционированного доступа, использования или изменения. На практике это включает меры контроля идентификации, ограничения логического и физического доступа, операции системы, мониторинг и управление изменениями. Критерий Security обычно сопоставляют с Common Criteria AICPA, включая меры контроля, которые часто описывают как CC1–CC9. Руководство по критериям доверительных услуг SOC 2 объясняет, как эти меры контроля связаны с операционными рисками.

Каждая компания SaaS начинает с этого. Если ваша команда не может показать, кто имеет доступ к production, как утверждается доступ или как обнаруживается подозрительная активность, опциональные критерии не спасут взаимодействие. Чтобы понять, как эти меры контроля встраиваются в более широкую программу, см. что такое enterprise security и как его уровни сочетаются друг с другом.

Доступность важна, когда клиенты зависят от бесперебойной работы

Доступность охватывает, доступен ли сервис для работы и использования так, как обещано. Она связана с обязательствами по бесперебойной работе, планированием мощностей, процедурами резервного копирования, аварийным восстановлением и тестированием восстановления.

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

Целостность обработки — это про надёжные результаты

Целостность обработки отвечает на вопрос, является ли обработка в системе полной, валидной, точной, своевременной и авторизованной. Это особенно актуально, когда ПО рассчитывает счета, маршрутизирует транзакции, формирует отчёты или преобразует данные клиентов.

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

Конфиденциальность защищает ограниченную информацию

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

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

Конфиденциальность персональных данных: Privacy

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

Я заметил, что команды часто выбирают критерии, потому что их перечисляет конкурент. Это неверно. Начните с обещаний в ваших контрактах и рисков в вашей архитектуре, а затем выберите критерии, которые позволят аудитору проверить эти обязательства.

Для практического взгляда на меры контроля доступа меры безопасности для баз знаний дают полезный пример того, как идентификация и разрешения связаны с защитой информации.

Итог: задайте критерии вокруг реальных рисков вашего сервиса. Security — это базовый уровень, а остальные критерии должны отражать то, на что клиенты полагаются, чтобы вы могли доставлять и защищать.

SOC 2 Type I vs Type II и когда выбирать каждый

Встреча по закупкам может свестись к одному вопросу: «Можете показать, что ваши меры контроля безопасности работают?» Ответ зависит от того, есть ли у вас отчёт Type I, отчёт Type II или ни того, ни другого. Type I оценивает дизайн мер контроля в конкретный момент времени. Type II оценивает дизайн и операционную эффективность в течение периода проверки, обычно 6–12 месяцев. Различие аудита Type I и Type II важно, потому что «снимок» политики не показывает, что люди следовали процессу многократно.

Отчёт Type I отвечает на вопрос: «Были ли меры контроля надлежащим образом спроектированы на эту дату?» Отчёт Type II отвечает на вопрос: «Были ли эти меры контроля надлежащим образом спроектированы и работали ли они эффективно в течение всего периода проверки?» На практике я считаю, что это различие проще понять, если воспринимать Type I как проверку рецепта, а Type II — как проверку блюд, приготовленных по нему в течение времени.

SOC 2 Type I vs Type II — кратко

Обычно я рекомендую воспринимать Type I как осознанный «шаг» на пути, а не как финишную черту. Он может определить рамки, выявить пробелы и дать команде продаж отчёт о подтверждении, пока организация формирует более длинную историю доказательств.

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

Предположим, что корпоративный покупатель спрашивает, теряют ли бывшие сотрудники доступ своевременно. Отчёт Type I может показать, что процесс offboarding существует и надлежащим образом спроектирован. Отчёт Type II может включать повторяющиеся записи offboarding, показывая, работал ли процесс так, как описано.

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

Итог: выбирайте Type I, когда вам нужен первоначальный отчёт о подтверждении и ваши меры контроля готовы к проверке. Переходите к Type II, когда клиентам нужны доказательства того, что эти меры контроля стабильно работали в течение времени.

Практический чек-лист подготовки к SOC 2: реальные меры контроля и доказательства

Подготовка к SOC 2 лучше всего работает, когда у каждой меры контроля есть владелец, повторяемое действие и артефакт доказательств. Я не начинаю с огромной папки с политиками. Я начинаю с вопроса, что команда делает сегодня, какой риск закрывает эта активность и где живут доказательства.

Начните с идентификации и доступа

Требуйте SSO там, где это уместно, включайте MFA для доступа к production и регулярно пересматривайте привилегированный доступ. Мера контроля — это не «мы используем identity provider». Мера контроля — это повторяемое решение о том, кто получает доступ, зачем он ему нужен, кто это утверждает и когда доступ удаляется.

Полезные доказательства включают:

• Конфигурация идентичности: Скриншоты или выгрузки, показывающие настройки SSO и MFA.

• Записи обзоров доступа: Завершённый обзор, тикет на утверждение и список пользователей и ролей.

• Записи о назначении и увольнении: Тикеты или системные логи, показывающие provision и deprovision.

Свяжите меры контроля инфраструктуры с записями

Для конечных устройств и инфраструктуры задокументируйте ожидания по патчингу, шифрованию дисков, разделению сред и централизованному логированию. Аудитор может запросить PDF политик, выгрузки конфигураций, записи по управлению уязвимостями или запросы из ваших облачных и endpoint-инструментов.

Для управления изменениями требуйте тикет, peer review, доказательства тестирования и утверждение до развёртывания. Если разработчики могут и утверждать, и развёртывать свои собственные изменения в production, задокументируйте риск и внедрите соответствующее разделение обязанностей.

Сделайте поставщиков и инциденты проверяемыми

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

Реагирование на инциденты требует большего, чем аккуратный runbook. Проведите настольные учения, зафиксируйте присутствие и решения, запишите последующие действия и поддерживайте шаблоны уведомлений клиентов. Доказательства должны показывать, что люди могут использовать процесс под давлением.

Принцип доказательств: Если мера контроля выполняется, но никто не фиксирует это, аудитор может не суметь засчитать это вам.

Я рекомендую выбирать GRC-платформу заранее, централизовать сбор доказательств и связывать каждый артефакт с конкретной мерой контроля. Скринкаст, преобразованный в структурированные процедуры, тоже может помочь с инструктажем сотрудников и обучением. Например, обучающие видео по комплаенсу для сотрудников поддерживают документирование и образовательную часть программы мер контроля.

Совет: Многие меры контроля SOC 2 зависят от того, что люди каждый раз следуют одной и той же процедуре, например обзоры доступов, offboarding и реагирование на инциденты. С Trupeer владелец меры контроля записывает процедуру один раз и получает пошаговое руководство со скриншотами и коротким обучающим видео. История версий показывает, что изменилось и когда — это помогает, когда аудитор спрашивает, как процедура была доведена до команды.

Итог: создайте «машину доказательств», а не спринт по документированию. Каждая повторяющаяся мера контроля должна производить понятную, датированную и проверяемую запись.

Сроки и ожидания по стоимости SOC 2 для команд SaaS

Команда SaaS может иметь готовые политики, но всё равно быть на месяцы от полезного отчёта SOC 2. По моему опыту, календарь определяется меньше тем, сколько времени уходит на написание документов, и больше тем, работают ли меры контроля последовательно и производят ли доказательства, которые аудитор сможет проверить.

Сроки SOC 2 измеряются месяцами, а не неделями. Работа Type I часто занимает примерно 3–6 месяцев «от начала до конца». Первый Type II обычно занимает 6–12 месяцев или больше, потому что аудитор должен оценить период наблюдения и проверить повторяющиеся доказательства. Этот таймлайн аудита SOC 2 объясняет разницу между обзором «в конкретный момент» и обзором «в течение операционного периода».

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

Сроки SOC 2 и диапазоны стоимости в зависимости от стадии компании

В опубликованном бенчмарке по комплаенсу указаны значения $91,000, $186,000 и $147,000 выше. Они описывают существенные инвестиции, а не гарантированную стоимость аудита. Заложите бюджет на ответственность за безопасность, инженерное время, работу с политиками, remediation, инструменты для доказательств и продолжающийся мониторинг.

Один вопрос планирования проходит сквозь неопределённость: «Кто владеет мерами контроля каждую неделю?» Если никто не несёт эту ответственность, найм аудитора не исправит операционный процесс. Назначьте чёткую ответственность, привлекайте инженерию и operations заранее и тестируйте повторяющиеся меры контроля до начала полевых работ. Мера контроля, которая работает только во время подготовки к аудиту, похожа на пожарную тревогу, отрепетированную для инспектора. Она не доказывает, что команда может действовать под нормальным давлением.

Итог: планируйте устойчивую операционную работу и цикл обзора на несколько месяцев. Самый «дешёвый на вид» маршрут может обойтись дороже, если слабая готовность заставит вашу команду переделывать рамки, меры контроля и доказательства.

Как SOC 2 соотносится с ISO 27001 и GDPR

SOC 2 и ISO 27001 дают подтверждение о программах безопасности, а GDPR — это закон о защите персональных данных. Они пересекаются по тематике, но отвечают на разные вопросы в обзоре поставщика.

Стартап, который получает своего первого корпоративного клиента, может столкнуться со всеми тремя в одном и том же разговоре. Отдел закупок клиента может запросить отчёт SOC 2. Международный покупатель может предпочесть ISO 27001. Команда по privacy клиента может спросить, как стартап обрабатывает персональные данные в рамках GDPR.

SOC 2 фокусируется на мерах контроля сервиса

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

ISO 27001 фокусируется на системе менеджмента информационной безопасности

ISO 27001 — это международно признанный стандарт, ориентированный на СУИБ (ISMS), оценку рисков и обработку рисков. Аккредитованный орган по сертификации оценивает, соответствует ли система менеджмента стандарту. Это руководство по стандартам ISO 27001 раскрывает пункты и меры контроля более подробно. Организации часто выбирают его, когда международное признание или формальная сертификация системы менеджмента важны для их клиентов.

GDPR создаёт юридические обязательства по защите персональных данных

GDPR регулирует обработку персональной информации. Он охватывает такие вопросы, как законная обработка, права субъекта данных, записи об обработке, оценка воздействия, обязательства при нарушениях и управление privacy. Отчёт SOC 2 не заменяет эти обязанности.

На практике команды часто используют SOC 2 или ISO 27001, чтобы отвечать на вопросы о подтверждении безопасности и поддерживать отдельные работы по GDPR, такие как инвентаризация данных, записи операций обработки, уведомления о privacy и оценки воздействия на защиту данных. Рекомендации по обучению GDPR для корпоративных команд помогают клиентским и операционным командам понять свою роль.

Итог: не спрашивайте, какая структура «побеждает». Спросите, что требуется вашему клиенту, регулятору и бизнес-модели. Многие организации создают одну базовую основу мер контроля и согласуют её с несколькими обязательствами по подтверждению и privacy.

Типичные ошибки SOC 2 и как их избежать

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

Относиться к аудиту как к галочке

Компания может собрать политики, пройти аудит, а затем перестать мониторить меры контроля. Такой подход создаёт «дрейф», когда команды меняют инструменты, людей, среды и ответственности.

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

Задать рамки не той системы

Слишком широкие рамки взаимодействия создают лишнюю работу. Слишком узкие рамки могут исключить систему, которая поддерживает обязательство перед клиентом.

Корректирующее действие: нарисуйте схему системы, показывающую потоки данных, инфраструктуру, команды, поставщиков и границы. Привяжите каждое решение о границах к сервису, который вы оцениваете.

Использовать инструменты, не определив меру контроля

Сканер уязвимостей может выявить находки, но он не доказывает автоматически, что ваша команда обрабатывает их в рамках утверждённого процесса. Identity provider может включить MFA, но он не доказывает, что обзоры доступов завершены.

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

Внедрять меры контроля в последнюю минуту

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

Корректирующее действие: начинайте повторяющиеся меры контроля заранее и сохраняйте исходные записи. Если возникает исключение, назначьте владельца и срок, а не скрывайте его.

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

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

Как Trupeer помогает с процедурами и обучением по SOC 2

Меры контроля SOC 2 держатся только тогда, когда люди каждый раз следуют одной и той же процедуре и могут это доказать. Trupeer помогает и с документированием, и с обучением:

• Документирование процедур контроля: один раз фиксируйте обзоры доступа, шаги offboarding или реагирования на инциденты и получайте пошаговое руководство со скриншотами.

• Последовательное обучение сотрудников: превращайте ту же запись в короткое обучающее видео с озвучкой от AI.

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

• Защищайте чувствительный контент: SAML SSO, SCIM provisioning, доступ по ролям и audit logs, а также инструменты размытия для чувствительных данных на экране.

• Используйте поставщика, который проходит вашу собственную проверку: Trupeer сертифицирован по SOC 2 Type II и ISO 27001.

Посмотрите Trupeer для enterprise.

Вопросы по соответствию SOC 2, которые команды задают до начала

Решения по SOC 2 обычно сводятся к ожиданиям клиентов, рискам сервиса и зрелости доказательств. Это вопросы, которые я чаще всего слышу от product marketers, sales engineers, лидов customer success и владельцев IT.

Кому нужен SOC 2?

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

Может ли стартап сразу перейти к Type II?

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

Как долго отчёт SOC 2 остаётся актуальным?

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

SOC 2 заменяет проверку безопасности клиента?

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

Какие доказательства клиенты запрашивают помимо отчёта?

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

Если вы объясняете эти ответы внутренним командам, используйте короткие walkthrough’и, ориентированные на роль, вместо того чтобы отправлять всем плотную библиотеку политик. Так проще для продаж, поддержки, инженерии и operations понять, что им нужно делать и какие доказательства сохранять.

Главный урок простой: соответствие SOC 2 — это повторяемая дисциплина операционной работы, подкреплённая независимым подтверждением. Начните с обязательств клиента, задайте правильные рамки систем, выберите критерии, которые подходят вашему сервису, и сделайте сбор доказательств частью повседневной работы.

Сделайте процедуры SOC 2 простыми для выполнения с Trupeer. Запишите каждую процедуру контроля один раз, и Trupeer превратит её в пошаговое руководство, короткое обучающее видео и запись в поисковой базе знаний на платформе, которая сама сертифицирована по SOC 2 Type II и ISO 27001, с SAML SSO и audit logs. Посмотрите Trupeer для enterprise.