Комплексная проверка поставщиков: один процесс для нескольких стандартов

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

Шаг 1: один реестр

Составьте перечень всех поставщиков, имеющих доступ к вашим системам, данным или объектам, и для каждого укажите: что он делает, какие данные обрабатывает и какие стандарты это затрагивает (данные держателей карт для PCI DSS, ePHI для HIPAA, персональные данные для GDPR, услуги, поддерживающие сервис, регулируемый NIS2). С этого начинают PCI DSS (12.8.1), ISO 27001 (A.5.19) и CIS Controls (15.1).

Шаг 2: разбейте по уровням

• Уровень 1: доступ к чувствительным данным или производственным системам либо критичность для вашего сервиса.
• Уровень 2: ограниченный доступ или умеренная критичность.
• Уровень 3: нет доступа к чувствительным данным; низкое воздействие при сбое.

Разбивка по уровням позволяет сохранять процесс соразмерным. CIS называет это классификацией поставщиков услуг (15.3).

Шаг 3: оценка по уровням

• Уровень 1: независимый отчёт об уверенности, охватывающий используемую вами услугу (отчёт SOC 2 Type II или сертификат ISO 27001 с релевантной областью), плюс короткий опросник по тому, что отчёт не охватывает. Читайте отчёт: область, период, исключения, carve-out и средства контроля, которые вы должны обеспечивать.
• Уровень 2: стандартный опросник или отчёт, если он у поставщика есть.
• Уровень 3: базовая проверка при подключении.

Шаг 4: один договор, покрывающий всё

Включите в договор условия безопасности, которые охватывают все стандарты сразу:

• Обязательства по безопасности, соразмерные услуге.
• Уведомление о нарушении вам в сроки, достаточно короткие для ваших собственных обязательств (24 часа по NIS2, 72 часа по GDPR).
• Условия статьи 28 GDPR, если поставщик обрабатывает персональные данные от вашего имени; соглашение о деловом партнёрстве (business associate agreement) там, где применяется HIPAA.
• Права на аудит или оценку, а также возврат или удаление данных при расторжении.
• Для PCI DSS: подтверждение ответственности поставщика за данные держателей карт (12.8.2) и документально оформленное разделение ответственности (12.8.5).

Шаг 5: мониторинг и прекращение отношений

Переоценивайте поставщиков уровня 1 ежегодно (PCI DSS требует ежегодного мониторинга соответствия поставщиков услуг, 12.8.4), уровня 2 раз в год или два, а также реагируйте на инциденты и изменения. При расторжении отзовите доступ, верните или удалите данные и зафиксируйте это (CIS 15.7).

Короткий опросник, который работает

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

1. Какие наши данные вы будете получать, хранить или обрабатывать и где?
2. Есть ли у вас действующий отчёт SOC 2 или сертификат ISO 27001, охватывающий эту услугу?
3. Обязательна ли многофакторная аутентификация для всего доступа к системам, содержащим наши данные?
4. Как быстро устраняются критические уязвимости?
5. Зашифрованы ли наши данные при хранении и при передаче?
6. Создаются ли резервные копии, защищены ли они и тестируются ли?
7. Как и как быстро вы уведомите нас об инциденте, затрагивающем наши данные?
8. Какие субподрядчики обрабатывают наши данные?
9. Как наши данные возвращаются или удаляются по окончании договора?
10. Кто у вас является контактным лицом по безопасности?

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

Ключевые выводы

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

Одна карточка на поставщика

Храните всё (уровень, оценки, прочитанные отчёты, условия договора, проверки) в одном месте для каждого поставщика. Аудиторы каждого стандарта смогут тогда найти свои доказательства в одной и той же карточке.

Страница темы «Управление рисками поставщиков» перечисляет каждое требование с его источником, а наша статья почему «SOC 2 certified» — неверный вопрос посвящена чтению отчётов поставщиков.

Вопросы

Можно ли принять отчёт SOC 2 поставщика вместо опросника?

Часто да, если это отчёт Type II, он актуален, охватывает используемую вами услугу, и вы читаете исключения и дополнительные средства контроля пользователя (complementary user entity controls). Отчёт, который не охватывает вашу услугу, мало что говорит.

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

ISO 27001 (A.5.20), PCI DSS (12.8.2), GDPR для обработчиков (статья 28), соглашения о деловом партнёрстве по HIPAA и меры NIS2 по цепочке поставок требуют включения условий безопасности в соглашения с поставщиками.

Как часто нужно переоценивать поставщиков?

Критичных поставщиков не реже раза в год (PCI DSS требует ежегодного мониторинга соответствия поставщиков услуг), остальных раз в год или два, а также любого поставщика после существенного инцидента или изменения услуги.