Крупный клиент требует от нас сертификат соответствия в сфере кибербезопасности — чем он отличается от ISO 27001 и что нам готовить?

В прошлом году в Дубае мы потратили 85 000 AED на независимый отчёт о соответствии для похожего финансового проекта. Аудит длился 3,5 месяца, и они проверили ровно 64 технических контроля, каждый с доказательствами. У нас был ISO, но финансовая группа по требованию регулятора не приняла ISO сам по себе.

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

Примечание: пишу на основе своего опыта, у других может быть иначе.

Первым делом запросите у клиента политику безопасности для поставщиков (third-party security policy). Если в разделе ссылок указаны правила местного центробанка или стандарты национального органа по кибербезопасности, то ISO 27001 не спасёт — придётся идти на отраслевой технический аудит.

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

Финансовые организации Абу-Даби требуют от сторонних обработчиков данных полного соответствия местным законам о защите данных и финансовым регламентам. То, что они просят декларацию о соответствии с доказательствами аудита на уровне систем, а не только ISO 27001 с управленческой框架, — это требование их корпоративных стандартов.

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

Примечание: пишу на основе своего опыта, у других может быть иначе.

Будут ли в данных, которые обрабатывает клиент, персональные идентификаторы или движения по финансовым счетам? Если вы храните только анонимизированные данные кампаний, вы пробовали сослаться на это и сузить объём аудита?

В отчётах о соответствии в сфере кибербезопасности обычно обязательны: хранение данных в пределах границ ОАЭ (data residency), сильное шифрование при передаче и хранении, а также хранение подробных логов доступа минимум один год. Ваша инфраструктура в облаке соответствует этим стандартам?

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

то что делают все, не значит, что это правильно.

Я тоже так считаю. То что делают все, не значит, что это правильно.

На что обратить внимание при выполнении этого. Начните с небольшого эксперимента, не привязывайте всё сразу.

Если путь уведомления длинный, уведомление не приходит; а не пришедшее уведомление — это поздно обнаруженный инцидент.

Если пойдете этим путем, сразу решите вот этот вопрос. Если не зафиксировать это письменно с самого начала, потом возникнут споры.

Я бы пошел этим путем.

Я столкнулся с тем же два года назад. То, что делают все, не значит, что это правильно.

Ответ сильно зависит от отрасли, универсального правила нет. На этом всё, извините, если затянул.

Пишу это чтобы вы не совершили ту же ошибку. Доступность резервной копии в той же сети и под той же учетной записью делает ее частью цели атаки.

Оставлю как заметку, пригодится.

Здесь есть ловушка не могу промолчать. Любой пункт, не зафиксированный письменно, в будущем обе стороны будут помнить по-разному.

Надеюсь это будет полезно.

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

Конечно если ваша ситуация отличается всё меняется.

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

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

попробую. в общем время обнаружения проблемы напрямую определят ее стоимость.