Составление Заявления о применимости, которое выдержит аудит

Пункт 6.1.3(d) ISO/IEC 27001 требует Заявление о применимости: документ, в котором перечислены необходимые меры, обоснование их включения, статус их внедрения и причины исключения любых из 93 мер Приложения A. Звучит как формальность, но на практике это связующее звено между оценкой рисков и мерами контроля, и аудиторы сертификации читают его внимательно, поскольку слабое Заявление обычно означает слабый процесс управления рисками, стоящий за ним.

Что оно должно содержать

Для каждой меры из Приложения A, а также для любых собственных мер:

1. Применима или нет.
2. Обоснование включения: обычно риски, которые мера обрабатывает, законодательное или договорное требование либо решение бизнеса.
3. Статус внедрения: внедрена, внедрена частично или запланирована.
4. Обоснование исключения, если мера исключена.

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

Обоснование включения

Связывайте каждую меру с конкретным основанием: риском из вашего реестра, законодательным требованием (статья 32 GDPR, NIS2, отраслевое регулирование), договором или требованием заказчика. «Лучшая практика» — слабое обоснование; «обрабатывает риски R-12 и R-17 и требуется в рамках наших обязательств по NIS2» — сильное. Привязка мер к законодательным требованиям также помогает, когда вы отчитываетесь перед несколькими стандартами: на наших страницах требований показано, с какими другими стандартами сопоставляется каждая мера Приложения A, например A.8.24 использование криптографии.

Обоснование исключения

Исключения допускаются, но каждое требует причины, которую аудитор может проверить. Хорошие причины:

• Деятельность не осуществляется в области применения. Аутсорсинга разработки нет: A.8.30 исключена.
• Риск не существует в области применения. Полностью удалённая организация без офисов может исключить некоторые меры A.7 по физической безопасности, но не те, что относятся к оборудованию и носителям, где бы они ни находились.

Слабые причины: «не относится», «занимается ИT-отдел», «это делает облачный провайдер». Если меру выполняет поставщик, она всё равно применима; вы управляете ею через меры в отношении поставщиков.

Частые замечания аудита

• Заявление не соответствует плану обработки рисков. Меры, выбранные при обработке рисков, должны присутствовать в Заявлении, и наоборот.
• Внедрённые меры без доказательств. Отметка «внедрено» вызывает запрос подтверждения.
• Шаблонные формулировки. Описания, скопированные из шаблона, которые не соответствуют реальной практике.
• Устаревшие версии. Заявление всё ещё использует нумерацию Приложения A 2013 года или не обновлялось после существенного изменения.

Практическая структура

Одна строка на меру: идентификатор и название, применимость (да/нет), причина (риски, законодательные и договорные требования), статус, однострочное описание реализации, владелец и ссылка на доказательства. Ведите документ в таблице или в вашей GRC-системе под контролем версий и пересматривайте его при каждой оценке рисков.

Поддержание Заявления в актуальном состоянии

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

• оценка рисков меняет выбранные меры;
• меняется область применения (новый продукт, офис или облачный провайдер);
• меняется статус внедрения меры;
• появляется новое законодательное или договорное требование (например, NIS2 или договор с заказчиком).

Каждый раз фиксируйте версию, дату и утверждающее лицо.

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

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

Работа сразу с несколькими стандартами

Если вам также нужно отчитываться перед SOC 2, NIS2 или PCI DSS, добавьте в каждый из них столбец с соответствующими требованиями. Тогда Заявление становится основой общего набора мер; в нашей статье один набор мер для SOC 2 и ISO 27001 показан этот подход, а анализ разрывов сопоставляет каждую меру Приложения A с любым другим стандартом. Руководство по ISO 27001 охватывает остальные аспекты сертификации.

Вопросы

Можно ли исключать меры Приложения A в ISO 27001?

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

Что должно содержать Заявление о применимости?

Пункт 6.1.3(d) ISO 27001 требует необходимые меры, обоснование их включения, информацию о том, внедрены ли они, и обоснование исключения любых мер Приложения A.

Передаётся ли Заявление о применимости заказчикам?

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