[Документация Yandex Cloud](../../index.md) > [Безопасность в Yandex Cloud](../index.md) > Стандарт безопасности для внедрения и эксплуатации ИИ-систем в Yandex Cloud, версия 1.0.0 > Безопасность систем искусственного интеллекта для финтех-организаций

# Безопасность систем искусственного интеллекта для финтех-организаций

{#fintech}

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

## Источник внешних рекомендаций {#fintech-source}

Методические рекомендации Банка России по обеспечению информационной безопасности при разработке и применении искусственного интеллекта на финансовом рынке №3-МР от 16.06.2026.

## Статус приложения {#fintech-status}

Приложение является справочным и не вводит самостоятельных нормативных требований. Действия в графе «Действия пользователя» являются рекомендуемыми мерами закрытия дефицита; их обязательность возникает только после утверждения во внутреннем нормативном документе организации. Матрица соответствия не заменяет требования настоящего Стандарта.

Приложение применяется при проектировании, разработке, внедрении и эксплуатации ИИ-решений, включая:

* приложения с использованием внешних и внутренних AI API;
* RAG-системы, базы знаний, векторные хранилища и процессы приема данных;
* ИИ-агентов, MCP-серверы, MCP Gateway и подключаемые инструменты;
* ML-модели, датасеты, процессы обучения, тестирования, дообучения и развертывания;
* облачную инфраструктуру, используемую для ИИ-решения.

## Статусы соответствия {#compliance-statuses}

| Статус | Значение |
|---|---|
| **Учтено** | Требование полностью покрыто обязательными положениями Стандарта; достаточно выполнить связанные требования `AI-*` и сохранить их свидетельства. |
| **Частично** | В Стандарте предусмотрены связанные меры, но для полного соответствия внешней рекомендации их недостаточно; дополнительные действия из строки являются рекомендуемой компенсирующей мерой, которую организация утверждает своим внутренним документом. |
| **Не учтено** | В Стандарте отсутствует равнозначное требование; указанная мера рекомендуется к реализации через документацию проекта, внутренний нормативный документ или план мероприятий до ввода решения в эксплуатацию. |
| **Неприменимо** | Требование не относится к конкретному ИИ-решению; решение о неприменимости рекомендуется документировать владельцем ИИ-решения и согласовывать с функцией ИБ. |

## Распределение ответственности {#responsibility-distribution}

В матрице используются следующие роли:

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

> Если в графе «Действия пользователя» указано, что требование выполняет Yandex Cloud, это относится только к защите платформенной части соответствующего управляемого сервиса. Пользователь сохраняет ответственность за конфигурацию сервиса, учетные записи, права доступа, данные, интеграции, прикладной код и соблюдение требований к своему ИИ-решению.

## Матрица соответствия {#compliance-matrix}

### Управление ИИ-рисками {#matrix-ai-risks}

| Внешнее требование | Статус | Отражение в Стандарте / дефицит | Связанные требования AI-* | Действия пользователя | Ответственность |
|---|---|---|---|---|---|
| Учитывать ИБ-риски ИИ при выборе сценария, технологии, архитектуры и мер защиты | Частично | Стандарт устанавливает технические меры для AI API, RAG, MCP, данных и облачной инфраструктуры, но единый процесс оценки допустимости сценариев и ИБ-рисков ИИ-решения требует формализации | `AI-SDLC1` | До начала разработки зарегистрировать сценарий в реестре ИИ-решений; провести оценку ИБ-рисков, критичности процесса, допустимого уровня автоматизации и необходимости human-in-the-loop; утвердить результаты владельцем бизнеса и ИБ | Пользователь |
| Оценивать последствия для прав субъектов, операций, убытков, репутации, цепочки поставок и устойчивости организации | Не учтено | В Стандарте предусмотрены контроли конфиденциальности и соответствия требованиям, но нет формализованной оценки последствий по указанным категориям | `AI-SDLC1`, `AI-COMPLY1` | Выполнить и задокументировать оценку последствий до ввода ИИ-решения в эксплуатацию; определить недопустимые сценарии, ограничения на автоматизацию и условия эскалации человеку | Пользователь |
| Применять human-in-the-loop для высокорисковых автоматических операций | Частично | Стандарт предусматривает подтверждение отдельных действий через MCP Gateway, но не устанавливает общее правило ручной валидации результатов ИИ в критичных процессах | `AI-AGENT-HITL1` | Определить перечень критичных операций; запретить автономное выполнение таких операций; обеспечить возможность проверки, отклонения и изменения результата человеком; фиксировать решение и ответственного в журнале | Пользователь |
| Разрабатывать модель угроз ИИ-системы | Частично | Стандарт описывает границы контуров Ingress, Identity, Application, Model, Data/RAG, Egress и Logging/Monitoring, однако обязанность разработки модели угроз и ее актуализации должна быть закреплена явно | `AI-SDLC1` | Разработать модель угроз для каждого ИИ-решения; включить активы, интерфейсы, внешнего и внутреннего нарушителя, ИИ-специфичные угрозы, сценарии атак и связанные контроли; пересматривать модель угроз при существенных изменениях | Пользователь |
| Обеспечивать пропорциональность мер уровню риска и последствиям | Не учтено | В Стандарте перечислены меры защиты, но правило выбора и обоснования достаточности мер в зависимости от риска не определено | `AI-SDLC1` | Для каждого ИИ-решения установить уровень риска; выбрать минимальный набор обязательных контролей в зависимости от уровня риска; документировать обоснование исключений и компенсирующих мер | Пользователь |

### Данные и приватность {#matrix-data-privacy}

| Внешнее требование | Статус | Отражение в Стандарте / дефицит | Связанные требования AI-* | Действия пользователя | Ответственность |
|---|---|---|---|---|---|
| Контролировать происхождение, качество, структуру, формат, согласованность и метки обучающих и тестовых данных | Частично | Стандарт предусматривает контролируемый прием данных в RAG, DSPM, классификацию и защиту данных; контрольные точки качества для обучающих и тестовых наборов данных ML раскрыты недостаточно явно | `AI-DATA1`, `AI-DATA5`, `AI-DATA-CHECK1` | Вести паспорт каждого датасета; фиксировать источник, владельца, правовое основание обработки, версию, формат, классификацию, качество и результаты проверок; не использовать датасеты, не прошедшие утвержденные проверки | Пользователь |
| Очищать аномалии в обучающих и тестовых данных и повторно проверять данные после очистки | Частично | Имеются контроли входных данных и RAG-источников, но отдельный обязательный процесс для обучающих и тестовых наборов данных отсутствует | `AI-DATA-CHECK1`, `AI-DATA3` | Утвердить процедуру выявления, очистки и повторной проверки аномалий; сохранять результаты проверок и решение о пригодности датасета к использованию | Пользователь |
| Шифровать данные при передаче и вне контролируемой зоны | Учтено | Стандарт предусматривает TLS, VPC, KMS и иные механизмы защиты данных в облачном контуре | `AI-CRYPT1`, `AI-NET2` | Использовать TLS для всех внешних и внутренних соединений; использовать сетевую сегментацию и частную конечную точку там, где она официально документирована для выбранного сервиса; включить шифрование и управление ключами для поддерживаемых сервисов | Совместная ответственность: Yandex Cloud обеспечивает платформенные механизмы защиты сервиса; пользователь обязан корректно включить и настроить доступные механизмы |
| Обеспечивать целостность и аутентичность наборов данных | Частично | Object Lock, контроль доступа, аудит и журналирование снижают риск несанкционированной модификации, но обязательная проверка целостности каждого датасета не определена | `AI-DATA6` | Применять контрольные суммы, цифровые подписи либо иной утвержденный механизм контроля целостности; ограничить изменение датасетов; проверять целостность перед обучением, тестированием и загрузкой в RAG | Пользователь |
| Обеспечивать версионирование и трассировку изменений датасетов | Частично | Стандарт предусматривает инвентаризацию и элементы цепочки происхождения, но не устанавливает полное воспроизводимое версионирование | `AI-DATA6`, `AI-REL1` | Вести версии датасетов и журнал изменений; обеспечить связь «источник — версия датасета — версия модели — результаты тестирования — версия развертывания» | Пользователь |
| Обезличивать ПДн и маскировать информацию ограниченного доступа | Учтено | Стандарт предусматривает обнаружение и защитное преобразование ПДн до границы доверия, контроль преобразования и аудит; DSPM только обнаруживает данные, а KMS и Lockbox защищают ключи и таблицы соответствия, но сами по себе не выполняют маскирование | `AI-COMPLY-PII1`, `AI-COMPLY-PII3`, `AI-COMPLY-PII4`, `AI-DATA4` | Классифицировать данные до передачи в ИИ-систему; удалить, обезличить или замаскировать ПДн и иную чувствительную информацию, если их обработка не требуется и не разрешена; контролировать RAG-источники и промпты | Пользователь |
| Гарантированно уничтожать данные по завершении обработки или срока хранения | Частично | Стандарт регулирует жизненный цикл данных и облачных ресурсов, но прямое требование безопасного уничтожения данных требует уточнения | `AI-DECOM1` | Установить сроки хранения; реализовать удаление данных, резервных копий, индексов и временных артефактов; вести подтверждения выполнения удаления | Совместная ответственность: Yandex Cloud выполняет удаление данных на уровне платформы в соответствии с характеристиками сервиса; пользователь обязан инициировать удаление ресурсов и данных, установить сроки хранения и проверить отсутствие прикладных копий |
| Передавать внешнему поставщику только очищенные, синтетические, обезличенные или специально подготовленные данные | Частично | Стандарт содержит маскирование персональных данных и ограничения передачи, но не устанавливает явного правила для внешнего обучения или внешних AI API | `AI-COMPLY3`, `AI-DATA4`, `AI-NET3` | До передачи данных внешнему поставщику провести оценку допустимости; по умолчанию использовать синтетические, обезличенные или очищенные данные; запретить передачу секретов, ПДн и иной чувствительной информации без документированного основания и согласования | Пользователь |

### Модель, разработка и поставка {#matrix-model-supply}

| Внешнее требование | Статус | Отражение в Стандарте / дефицит | Связанные требования AI-* | Действия пользователя | Ответственность |
|---|---|---|---|---|---|
| Анализировать уязвимости модели, кода и компонентов на всем жизненном цикле | Частично | Стандарт предусматривает SBOM, Container Registry и меры защиты цепочки поставок, но периодичность и минимальный охват проверок требуют явного закрепления | `AI-SUPPLY4`, `AI-SUPPLY5` | Включить SAST, DAST, SCA и проверку уязвимостей образов в CI/CD; вести SBOM; определить источники сведений об уязвимостях, сроки устранения и критерии блокировки релиза | Пользователь |
| Проверять криптографическую целостность и подлинность модели, кода и контейнеров | Частично | Используются дайджест, реестр и KMS, но прямое требование подтверждать доверенную версию перед применением отсутствует | `AI-MODEL1`, `AI-SUPPLY2`, `AI-SUPPLY3` | Подписывать или иным образом подтверждать доверенные версии артефактов; разрешать развертывание только из доверенного реестра; проверять дайджест, подпись или иной идентификатор целостности перед развертыванием | Совместная ответственность: Yandex Cloud предоставляет механизмы реестра, IAM, KMS и журналирования; пользователь обязан организовать доверенную цепочку сборки и проверки |
| Отслеживать изменения кода, модели и документации | Частично | В Стандарте предусмотрены развертывания и откаты, Audit Trails и инвентаризация, но полная воспроизводимая трассировка изменений должна быть усилена | `AI-REL1`, `AI-CORE5`, `AI-AUDIT1` | Вести неизменяемый журнал изменений кода, конфигураций, промптов, датасетов и документации модели; связать изменение с автором, согласованием, тестами и версией развертывания | Пользователь |
| Применять безопасный жизненный цикл разработки ИИ | Частично | Стандарт опирается на ML-DevSecOps, но полный безопасный SDLC для ИИ-модели должен быть формализован | `AI-SDLC1`, `AI-REL1`, `AI-REL2` | Внедрить AI-SDLC: требования, оценка рисков, модель угроз, подготовка данных, разработка, тестирование, согласование, развертывание, мониторинг, переобучение, вывод из эксплуатации | Пользователь |
| Защищать от подмены модели | Частично | Реестр, дайджест, аудит и контролируемое развертывание уменьшают риск, но отдельный контроль подмены модели не выделен | `AI-MODEL1`, `AI-REL2` | Разрешать использование только утвержденных версий модели; ограничить права на публикацию и развертывание; проверять происхождение и идентификатор модели перед запуском; обеспечить откат на предыдущую доверенную версию | Пользователь |
| Применять цифровые метки моделей, данных или выходов, когда это требуется риском или регулированием | Не учтено | Явное требование о «водяных знаках» или аналогичных цифровых метках отсутствует | — | Оценить необходимость цифровых меток для защиты авторства, трассировки происхождения и выявления подмены; при необходимости выбрать технологию, определить область применения и порядок проверки | Пользователь |

### Тестирование и устойчивость {#matrix-testing-resilience}

| Внешнее требование | Статус | Отражение в Стандарте / дефицит | Связанные требования AI-* | Действия пользователя | Ответственность |
|---|---|---|---|---|---|
| Тестировать модель на отравление после обучения | Не учтено | Контроли приема данных в RAG и защиты данных предусмотрены, но тест на отравление после обучения отсутствует | `AI-DATA-CHECK1` | Включить тестирование на отравление в программу приемки и периодической проверки модели; определить сценарии, критерии приемки и порядок реагирования при выявлении признаков отравления | Пользователь |
| Разделять обучающие и тестовые наборы, их хранение и доступ | Частично | IAM, VPC, ACL, KMS и секреты создают основу для сегрегации, однако независимость тестового набора от обучающего набора должна быть закреплена | `AI-DATA3`, `AI-DATA5`, `AI-TRAIN1` | Использовать отдельные наборы, учетные записи или хранилища для обучающих и тестовых данных; запретить несанкционированное изменение тестового набора; предоставлять доступ по принципу минимальных привилегий | Пользователь |
| Проверять устойчивость к состязательным атакам | Не учтено | Стандарт рассматривает промпт-инъекцию и фильтрацию входа, но не устанавливает методы устойчивости ML-модели к состязательным атакам | — | Для применимых моделей проводить состязательное тестирование; при необходимости применять состязательное обучение, защитную дистилляцию, ансамблевые методы или иные меры; фиксировать результаты и ограничения модели | Пользователь |
| Проводить тестирование модели на проникновение по сценариям, специфичным для ИИ | Частично | В Стандарте есть защита API, WAF, Guardrails, RAG и MCP, но регулярный тест самой модели не формализован | `AI-APP-WAF1`, `AI-APP-INJECT1`, `AI-CONTENT2` | Проводить приемочное и периодическое тестирование, включающее обход ограничений, промпт-инъекцию, косвенную промпт-инъекцию через RAG, фаззинг, извлечение, инверсию, отравление, DoS и истощение ресурсов; устранять выявленные критичные недостатки до промышленной эксплуатации | Пользователь |
| Контролировать дрейф данных и модели, а также деградацию модели | Частично | В Стандарте предусмотрены журналирование и мониторинг, но ИИ-специфичные SLI/SLO, пороги и процесс управляемого переобучения должны быть определены | `AI-MON-ANOMALY2`, `AI-DATA5` | Определить метрики качества, безопасности и дрейфа данных и выходных данных; установить пороги, владельцев и порядок реагирования; переобучать и повторно валидировать модель только на проверенных данных | Пользователь |

### Эксплуатация и мониторинг {#matrix-ops-monitoring}

| Внешнее требование | Статус | Отражение в Стандарте / дефицит | Связанные требования AI-* | Действия пользователя | Ответственность |
|---|---|---|---|---|---|
| Контролировать и очищать аномалии во входных и выходных данных | Учтено | Стандарт предусматривает Guardrails, контент-фильтрацию, защиту от инъекций, проверки API и меры защиты RAG-контура | `AI-CONTENT1`, `AI-CONTENT2`, `AI-APP-WAF1` | Настроить и включить применимые Guardrails, фильтры контента и проверки входа/выхода; определить правила блокировки, маскирования, эскалации и регистрации срабатываний | Совместная ответственность: Yandex Cloud предоставляет поддерживаемые сервисные механизмы; пользователь обязан включить их, настроить политики и обработку срабатываний |
| Защищаться от прямых и непрямых промпт-инъекций | Учтено | Стандарт содержит требования AI-APP-INJECT1, контентные ограничения, Guardrails, контролируемые RAG-источники и защиту API/MCP | `AI-APP-INJECT1`, `AI-APP-INJECT2` | Реализовать фильтрацию и валидацию входных данных; ограничить инструменты и полномочия агентов; использовать список разрешенных RAG-источников; проводить тесты на прямую и косвенную промпт-инъекцию | Пользователь |
| Регистрировать события работы модели, пользователей и запросов | Учтено | Стандарт предусматривает Cloud Logging, Audit Trails и журналирование операций AI Studio, API, MCP Gateway, Kubernetes и связанных сервисов; платформенные журналы не образуют полной сквозной трассировки — прикладная трассировка модельного запроса реализуется отдельно | `AI-AUDIT1`, `AI-MON-TRACE1` | Включить журналирование для используемых сервисов; реализовать прикладную сквозную трассировку запроса; передавать журналы в Yandex SIEM при наличии требования; обеспечить хранение журналов в соответствии с политикой хранения и защиту от несанкционированного изменения | Совместная ответственность: Yandex Cloud обеспечивает сервисные журналы в объеме возможностей сервиса; пользователь обязан включить журналирование, настроить экспорт, хранение и мониторинг |
| Ограничивать число, частоту, размер и параметры запросов | Частично | WAF, API Gateway и Smart Web Security поддерживают ограничение частоты, но лимиты для токенов, сложности и потребления ресурсов ИИ должны быть определены отдельно | `AI-NET7`, `AI-APP-WAF1`, `AI-AGENT2` | Установить квоты и лимиты, максимальный размер запроса, лимиты токенов, таймауты и бюджет ресурсов; применять ограничения на уровне API Gateway, WAF, приложения и модели | Совместная ответственность: Yandex Cloud предоставляет механизмы ограничения трафика для поддерживаемых сервисов; пользователь обязан задать значения лимитов и контролировать их достаточность |
| Контролировать штатную работу, качество и поведение модели | Частично | Наблюдаемость и журналы предусмотрены, но набор ИИ-специфичных SLI/SLO и пороги деградации не определены | `AI-MON-ANOMALY2` | Установить SLI/SLO для доступности, задержек, ошибок, качества, безопасности, стоимости, дрейфа данных и выходных данных; настроить уведомления, эскалацию и регулярный анализ отклонений | Пользователь |
| Предотвращать отказ в обслуживании и истощение ресурсов | Частично | API Gateway, WAF и сетевые ограничения покрывают базовый DoS-контур, но специализированные меры против исчерпания ресурсов необходимо детализировать | `AI-NET7`, `AI-AGENT2` | Настроить квоты и лимиты, лимиты токенов, ограничения параллельной обработки запросов, таймауты и защиту от аномально дорогих запросов; тестировать сценарии исчерпания ресурсов до ввода в эксплуатацию | Совместная ответственность |
| Иметь план восстановления и аварийной остановки ИИ | Частично | Стандарт предусматривает откат и управляемую инфраструктуру, но механизм аварийной остановки ИИ-системы, роли и сценарии восстановления должны быть закреплены | `AI-REL2`, `AI-AGENT2` | Разработать план реагирования на ИИ-инциденты; определить критерии срабатывания механизма аварийной остановки ИИ-системы, роли, порядок изоляции модели или RAG-источника, отката, сохранения артефактов, уведомления и восстановления | Пользователь |

### Управление поставщиками и Open Source Software (OSS) {#matrix-suppliers-oss}

| Внешнее требование | Статус | Отражение в Стандарте / дефицит | Связанные требования AI-* | Действия пользователя | Ответственность |
|---|---|---|---|---|---|
| Утвердить внутреннюю политику ИБ при разработке и применении ИИ | Частично | Стандарт содержит технические и организационные нормы, но не заменяет внутреннюю политику организации | `AI-SDLC1` | Утвердить политику ИБ ИИ с областью действия, ролями, классификацией сценариев, порядком исключений, контролем исполнения и ответственностью за нарушения | Пользователь |
| Назначить руководителя, ответственного за ИБ ИИ | Не учтено | Технические роли и IAM описаны, но владелец политики ИБ ИИ не определен | — | Назначить ответственное должностное лицо; закрепить полномочия по утверждению политики, контролю рисков, эскалации существенных инцидентов и отчетности руководству | Пользователь |
| Проводить аудит исполнения политики и информировать руководство о нарушениях | Частично | Audit Trails, Cloud Logging и Yandex SIEM поддерживают сбор доказательств, но аудит и отчетность должны быть определены процессно | `AI-AUDIT1` | Установить периодичность внутреннего аудита; формировать отчеты о соответствии, исключениях, инцидентах и рисках; направлять результаты руководству в установленном порядке | Пользователь |
| Обучать работников безопасной разработке и применению ИИ | Не учтено | Отдельное требование к обучению разработчиков, MLOps, ИБ, владельцев продукта и пользователей отсутствует | — | Внедрить программу обучения по угрозам ИИ, работе с чувствительными данными, промпт-инъекциями, RAG, MCP, безопасной разработке и процедурам реагирования | Пользователь |
| Предоставлять минимально необходимые права доступа | Учтено | Стандарт подробно описывает IAM, RBAC, сервисные аккаунты, роли AI Studio, Kubernetes RBAC и CIEM | `AI-IAM-LEASTPRIV1`, `AI-IAM5` | Использовать отдельные сервисные аккаунты; выдавать права по принципу минимальных привилегий; проводить регулярный пересмотр доступов; запрещать совместное использование учетных записей | Совместная ответственность: Yandex Cloud предоставляет IAM и сервисные роли; пользователь назначает права, организует пересмотр и отключает неактуальные доступы |
| Устанавливать правила безопасного использования публичных ИИ-сервисов | Частично | Для внешних AI API и SaaS предусмотрены список разрешенных получателей, TLS и аспекты соответствия требованиям, но единая пользовательская политика должна быть утверждена отдельно; закрытый сетевой путь к внешнему поставщику заявляется только при наличии его официальной документации | `AI-NET3`, `AI-COMPLY3`, `AI-COMPLY4` | Утвердить перечень разрешенных публичных ИИ-сервисов; определить классы данных, которые запрещено передавать; установить порядок согласования исключений и контроля использования | Пользователь |
| Учитывать риски моделей с открытым исходным кодом, компонентов, агентов, плагинов и инструментов | Частично | SBOM, Container Registry и контроли цепочек поставок предусмотрены, но реестр OSS-компонентов и оценка их рисков должны быть формализованы | `AI-SUPPLY1`, `AI-SUPPLY4`, `AI-SUPPLY5` | Вести реестр OSS-моделей, библиотек, агентов, плагинов, MCP-серверов и инструментов; поддерживать SBOM; проводить оценку лицензий, происхождения, уязвимостей и уровня доверия до использования | Пользователь |
| Оценивать доверие к поставщику, его данным, модели и компонентам | Частично | Технические меры для облачной среды подробно описаны, но собственная методика оценки поставщика отсутствует | `AI-SUPPLY6` | До заключения договора и периодически далее оценивать поставщика: модель угроз, практики безопасного жизненного цикла разработки, аудит, лицензии, SBOM, раскрытие уязвимостей, результаты тестирования на проникновение, SLA и условия обработки данных | Пользователь |
| Получать отчеты поставщика об ИБ-аудитах, лицензиях, уязвимостях и тестированиях на проникновение | Не учтено | Контрактное и процессное требование отсутствует | `AI-SUPPLY6` | Включить в договор или процедуру закупок обязательство поставщика предоставлять предусмотренные доказательства безопасности и уведомления об изменениях, уязвимостях и инцидентах | Пользователь |
| Закреплять договорную ответственность поставщика за ИБ и уведомление об инцидентах | Не учтено | Стандарт не заменяет договорные условия и не содержит обязательства включать их в договор | `AI-SUPPLY6` | Включить в договор требования к ИБ, сроки уведомления об уязвимостях и инцидентах, порядок взаимодействия при расследовании, требования к возврату или удалению данных и ответственность сторон | Пользователь |