# ISO 42001 или SOC 2, что проходить первым?

> Сравниваем ISO 42001 и SOC 2 по сегментам покупателей, границам аудита, повторному использованию доказательств и порядку прохождения.

Выбор между ISO 42001 и SOC 2 в первую очередь связан с очередностью продаж, а уже потом с соответствием требованиям. Сначала получите тот документ о надежности, который требуют ближайшие серьезные покупатели, а базовые средства контроля устройте так, чтобы второй аудит использовал уже собранные доказательства, а не заставлял снова разбирать всю компанию.

Большинству разработчиков ПО, которые продают услуги американским компаниям, сначала нужен SOC 2: отделы закупок уже запрашивают этот отчет и знают, как его проверять. Компании с ИИ, которая продает систему с серьезными последствиями регулируемым предприятиям, государственным организациям или международным клиентам, может раньше понадобиться ISO/IEC 42001. Особенно если покупателю нужны доказательства надзора за моделями, оценки воздействия, ответственности людей и допустимого применения ИИ. Обоснованная потребность в обоих документах встречается часто. Но считать их взаимозаменяемыми нельзя.

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

## SOC 2 обычно открывает первые двери на рынке ПО в США

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

SOC 2 не сертификат, и общего статуса «соответствует SOC 2» не существует. Лицензированная аудиторская фирма CPA проводит проверку и выпускает отчет ограниченного распространения. В отчете описаны система, заявление руководства, заключение аудитора, тесты средств контроля, результаты, исключения и дополнительные средства контроля, которые могут требоваться от клиентов. Логотип или одностраничный сертификат не заменит этих подробностей.

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

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

SOC 2 следует поставить перед ISO 42001, если препятствующие сделке вопросы звучат так: как вы разрешаете доступ к рабочей среде? Можете ли вы восстановить данные клиента? Как вы проверяете изменения? Как обрабатываете инциденты и контролируете поставщиков? Эти вопросы одинаково применимы к продукту на ИИ, правилах или обычном программном коде.

## ISO 42001 отвечает покупателю на другой вопрос

ISO/IEC 42001 стоит проходить первым, если покупателю нужна уверенность в том, как компания управляет ИИ на всем его жизненном цикле, а не только защищает облачный сервис. Стандарт устанавливает требования к созданию, внедрению, поддержке и постоянному улучшению системы менеджмента искусственного интеллекта, сокращенно СМИИ. Организации сертифицируют независимые органы по сертификации, а не сама ISO.

По описанию ISO стандарт применим к организациям, которые разрабатывают, предоставляют или используют системы ИИ. Эта формулировка важна. Компания не избавляется от управленческой задачи, когда вызывает внешнюю модель через API. У внутреннего ИИ тоже бывают существенные последствия для сотрудников, клиентов и операций, даже если компания не продает продукт на ИИ. В области сертификации нужно указать, какие виды деятельности, системы, команды и организационные границы охватывает СМИИ.

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

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

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

## Сегмент покупателя определяет ценность доказательств

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

Малому бизнесу обычно прежде всего нужны практическая безопасность, непрерывность работы, обращение с данными и ответственность по договору. Иногда ему достаточно краткого пакета документов по безопасности, иногда требования более крупного клиента переходят по цепочке. Если малый бизнес запросил SOC 2 по имени, сертификат ISO 42001 не уберет пустое поле в портале. При покупке функции ИИ, способной заметно повлиять на людей или деньги, такой клиент может задать точные вопросы об ИИ, даже не зная номера стандарта.

Средние компании в США часто проводят повторяемую проверку поставщика вокруг SOC 2. Проверяющий может запросить отчет Type II, письмо о промежуточном периоде, сводку теста на проникновение, политики безопасности, схему потоков данных, список субподрядчиков и состояние исправления исключений. ISO 42001 усиливает ответ об управлении ИИ, но редко заменяет привычный пакет документов, если сам покупатель не подтвердил обратное.

Крупные предприятия США обычно делят проверку. Специалисты по безопасности изучают SOC 2 и технические доказательства. Юристы, специалисты по приватности и риску моделей либо комитет по ИИ проверяют данные обучения, тесты, запрещенные способы применения, надзор человека, объяснимость, мониторинг и эскалацию инцидентов. В этом сегменте чаще всего нужны оба документа, потому что разные внутренние владельцы принимают разные доказательства. Отправлять один сертификат каждому проверяющему бесполезно.

Европейские и международные предприятия чаще узнают сертификаты систем менеджмента ISO у поставщиков из разных стран. Для системы ИИ ISO 42001 дает команде управления общую структуру и независимо проверенную область. Но те же покупатели могут потребовать SOC 2 для облачного сервиса, ISO/IEC 27001 для информационной безопасности, документы о приватности или собственное приложение об ИИ. Сертификат 42001 дает один из элементов проверки, но не универсальный пропуск.

Государственные и регулируемые покупатели работают по формальным требованиям. Решение может зависеть от тендера, отраслевого правила, ожидания надзорного органа, пункта договора или утвержденной методики. Не считайте, что государству всегда сначала нужен ISO, а банку SOC 2. Составьте таблицу: покупатель, точная формулировка, приемлемый документ, срок, сумма сделки и ответственный. Упоминание стандарта в балльной оценке может помочь, а обязательное условие решает вопрос допуска.

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

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

## Границы важнее логотипа

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

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

Для ISO 42001 сертификат должен описывать область, которая охватывает нужную деятельность с ИИ. Сертификат на всю компанию звучит широко, но для широкой области нужны общие процессы, которым команды действительно следуют. Область одного продукта проще стабилизировать, однако отдел продаж обязан точно ее описывать. Фраза «у нас есть ISO 42001» не должна создавать впечатление, что исключенные продукты или юридические лица прошли аудит.

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

## Повторно используйте контроль, а не вывод

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

AICPA публикует сопоставления своих Критериев доверия с другими методиками безопасности. Это подтверждает разумный подход: храните одну формулировку контроля, одного владельца и один адрес доказательства, а затем связывайте их со всеми применимыми требованиями. Сопоставление показывает, где доказательство можно использовать повторно. Оно не доказывает тождество двух критериев.

До любой проверки готовности используйте реестр такого типа:

- Утвержденная проверка доступа может подтвердить тесты логического доступа и управляемый доступ к ресурсам и данным ИИ. Повторное использование не сработает, если роли ИИ или инструменты моделей не попали в проверяемую совокупность.
- Заявки на изменения могут показать разрешенные изменения рабочей среды и управляемые изменения ИИ. Добавьте явные триггеры для новой модели, промпта, источника данных, назначения или уровня автономности.
- Проверки поставщиков могут подтвердить контроль подрядчиков и ответственность по цепочке третьих лиц ИИ. Обычная проверка безопасности может не охватить происхождение модели, обязанности по тестированию и затронутые группы.
- Записи об инцидентах могут показать обнаружение, реакцию, устранение и выводы о воздействии ИИ. Сообщение о вреде от ИИ должно попадать в управляемую очередь, даже если события безопасности не было.
- Записи об обучении и решениях руководства могут подтвердить осведомленность, компетентность по ролям и надзор. Общее ежегодное обучение и стандартная повестка встречи не доказывают, что владельцы моделей умеют проводить назначенные проверки.

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

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

## Небольшой реестр ИИ предотвращает большой аврал

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

Этот короткий пример YAML достаточно прост для хранения в системе контроля версий или репозитории управления:

```yaml
system_id: support-reply-assistant
owner: customer-operations
status: production
intended_use: draft replies for agent approval
prohibited_use: autonomous account decisions
data_classes:
  - customer-support-content
model_provider: external-provider
human_oversight: agent-approval-required
security_review: SEC-184
impact_assessment: AI-027
evaluations:
  - instruction-following
  - sensitive-data-disclosure
change_triggers:
  - model-version
  - new-data-source
  - autonomous-action
incident_queue: RISK-AI
last_reviewed: 2026-07-15
```

Запись предотвращает знакомый сбой. Команда переводит помощника поддержки из режима черновиков в автоматическую отправку. Инфраструктура и поставщик не меняются, поэтому обычная проверка безопасности не видит существенной разницы. Воздействие резко меняется: человек больше не ловит выдуманное обещание или раскрытие личной информации до отправки. Триггер `autonomous-action` запускает новую оценку воздействия, тестирование, утверждение и решение по мониторингу.

Не копируйте классификации из примера, будто они подходят каждому продукту. Полезна связь объектов. Версия модели ведет к записи об изменении, риск к мере обработки, тест имеет владельца и результат, исключение имеет утверждение и срок, а инцидент обновляет операционную реакцию и оценку риска. Такая цепочка дает доказательства обоим аудитам, не смешивая их цели.

## Стройте очередь вокруг препятствия выручке

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

1. Перечислите сделки, продления, тендеры и партнерства, способные существенно изменить выручку за период планирования. Запишите точное требование и обязательность.
2. Спросите каждого покупателя, какой документ, тип, область, выдавшую организацию и давность он принимает. Сохраните ответ в карточке сделки, а не в памяти продавца.
3. Сгруппируйте запросы по цели контроля. Отделите потребности безопасности сервиса от потребностей управления ИИ, даже когда один покупатель поднял оба вопроса.
4. Выберите первый документ по заблокированной выручке, сроку, уверенности в приемке и разрыву готовности. Престиж и значки конкурентов дают слабый сигнал.
5. Спроектируйте общий реестр контроля и календарь доказательств для обоих, а договор на первый аудит подписывайте после сверки предлагаемой области с ожиданием покупателя.

Несколько ситуаций дают однозначный ответ. Американской компании с ПО для бизнеса, у которой постоянно требуют Type II и не ставят условие о сертификации ИИ, следует сначала наладить SOC 2. При этом поля об ИИ нужно добавить в реестры, изменения, проверки поставщиков и инциденты. Поставщику ИИ для принятия решений, который участвует в тендере с ISO 42001 как условием допуска, сначала нужен 42001, а доказательства безопасности стоит сразу готовить для будущего SOC 2. Если один крупный покупатель требует оба документа, отталкивайтесь от сроков приемки и вместе исправляйте общие средства контроля, даже если формальные проверки идут по очереди.

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

Не обещайте дату завершения, пока аудитор или орган по сертификации не изучит область и готовность. Срок SOC 2 зависит от типа отчета, периода наблюдения, исключений и расписания фирмы. Срок ISO 42001 зависит от зрелости СМИИ, области, внутреннего аудита, анализа руководства, исправлений и процесса органа по сертификации. Основатель может поставить цель, но не способен создать отсутствующую историю работы.

## Доказательства должны появляться в обычной работе

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

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

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

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

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

## Стоимость зависит от области и трения в организации

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

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

Самая большая скрытая статья расходов состоит в отвлечении сотрудников. Инженеры, владельцы продукта, HR, юристы, продавцы и руководители предоставляют доказательства или принимают решения. Компактная компания снизит нагрузку, если один руководитель программы получит право уточнять область, вести реестр контроля, назначать проверки и отклонять повторные запросы. Ему все равно нужны профильные специалисты: координация не переносит ответственность за риск модели или безопасность в таблицу.

Инструмент может собирать доказательства и вести соответствия, но он не решит, создает ли автоматическое решение по счету неприемлемое воздействие. Он также не заставит покупателя принять неподходящий документ. Покупайте инструмент после определения области, владельцев и процессов. Иначе компания автоматизирует путаницу.

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

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

Планируйте исключения, а не прячьте их. Исключение SOC 2 описывает результат теста в контексте, а его значение зависит от затронутого критерия, совокупности, причины, компенсирующего контроля и ответа руководства. Несоответствие ISO 42001 требует исправления и анализа причины до закрытия. Ни одна метка сама по себе не означает провал всей программы, но расплывчатое исправление насторожит внимательного проверяющего. Свяжите находку, решение по риску, владельца, срок, действие, повторный тест и утвержденное внешнее объяснение.

Цикл продления начинается до выпуска первого документа. Меняются владельцы, исчезают поставщики, разделяются продукты, переезжают модели, а ручные проверки пропускают сроки. Включите подтверждение области и снятие контроля в календарь. После каждого существенного изменения владелец должен определить, затронуты ли описание SOC 2, область СМИИ, оценка риска, обещание клиенту или несколько пунктов. Здесь общая система окупается: изменение регистрируют один раз и направляют к нужным обязательствам.

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

## Второй аудит должен начаться в первый день

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

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

Team & AI Audit от oleg.is может найти экономию в инженерной работе и выявить пробелы во владении или процессах до того, как руководство направит дефицитных специалистов в программу подтверждения. Эта услуга проверяет бизнес и команду, но не заменяет проверку CPA, решение аккредитованного органа по сертификации, юридическую консультацию или сами средства контроля.

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