Сопоставление одного набора политик с несколькими стандартами без их переписывания

Типичная ситуация: компания пишет набор политик под ISO 27001, затем клиент запрашивает SOC 2, кто-то покупает второй пакет шаблонов, а потом появляется PCI DSS со своими требованиями. В итоге получаются три перекрывающихся набора политик, каждый из которых немного устарел и ни один не соответствует тому, что люди реально делают. Политики не должны быть привязаны к конкретному стандарту. Они должны быть привязаны к конкретной организации и сопоставлены со стандартами.

Структура: три уровня

1. Одна политика информационной безопасности: краткая, утверждённая руководством, определяющая цели, область применения, обязанности и обязательства. Пункт 5.2 ISO 27001 и 12.1.1 PCI DSS требуют её наличия.
2. Тематические политики (около десятка): управление доступом, допустимое использование, управление активами, криптография, реагирование на инциденты, непрерывность бизнеса, безопасность поставщиков, безопасная разработка, управление уязвимостями и обновлениями, журналирование и мониторинг, физическая безопасность, безопасность персонала.
3. Процедуры и стандарты ниже по уровню, где содержатся периодичность, настройки и шаги. Они меняются чаще и не должны каждый раз требовать согласования руководством.

Детали, специфичные для стандарта, размещайте в процедурах, а не в политиках: фраза «доступ проверяется каждые шесть месяцев» относится к процедуре проверки доступа, где может находиться периодичность из PCI DSS, не раздувая политику.

Сопоставлять, а не переписывать

Ведите таблицу соответствий: по одной строке на каждый раздел политики с указанием требований, которые он покрывает, для каждого стандарта. В теме Governance Policy показано, что каждый стандарт ожидает на верхнем уровне:

Полные подробности и обоснование каждой связи: Политика управления по фреймворкам →

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

Что конкретно стандарты требуют зафиксировать в письменном виде

• ISO 27001: политика информационной безопасности (5.2) и тематические политики по мере необходимости (A.5.1), доведённые до сведения и пересматриваемые.
• SOC 2: политики, определяющие ожидания, которые реализуются через процедуры (CC5.3).
• PCI DSS: для каждого из двенадцати требований — документированные актуальные политики и процедуры (x.1.1) и назначенные роли (x.1.2), пересматриваемые не реже одного раза в год.
• NIS2: политика безопасности сетевых и информационных систем и тематические политики (Implementing Regulation, пункт 1).
• NIST CSF 2.0: политика установлена, доведена до сведения и исполняется (GV.PO).

Минимальный набор политик

Для большинства малых и средних организаций следующие документы покрывают требования к политикам ISO 27001, SOC 2, NIST CSF, PCI DSS и NIS2:

1. Политика информационной безопасности (верхний уровень, утверждается руководством)
2. Политика допустимого использования
3. Политика управления доступом
4. Политика управления активами и классификации данных
5. Политика криптографии
6. Политика безопасной разработки и управления изменениями
7. Политика управления уязвимостями и обновлениями
8. Политика журналирования и мониторинга
9. Политика реагирования на инциденты (с обязательствами по уведомлению)
10. Политика непрерывности бизнеса и резервного копирования
11. Политика безопасности поставщиков
12. Политика безопасности персонала
13. Политика физической безопасности

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

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

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

Поддерживайте их актуальность

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

Полный общий набор мер, построенный на той же идее, см. в статье один набор мер для SOC 2 и ISO 27001.

Вопросы

Сколько политик безопасности нужно?

Меньше, чем предлагают большинство шаблонов. Политика информационной безопасности верхнего уровня плюс около десятка тематических политик (доступ, допустимое использование, реагирование на инциденты, безопасность поставщиков и так далее) обычно покрывают ISO 27001, SOC 2, NIST и PCI DSS.

Требует ли PCI DSS конкретных политик?

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