«Регуляторные требования, особенно такие как 152-ФЗ или ФСТЭК, кажутся монолитом, который нужно освоить целиком. Но на практике это путь от одного важного пункта к другому, где главный риск — не объем, а слепые пятна. Понимание того, что именно считать «пропущенным», важнее заучивания всех норм.»
Почему возникает чувство, что всё пропустил?
Страх упустить что-то критическое появляется, когда требования воспринимаются как длинный, плохо структурированный список. В голове держать все 150 статей 152-ФЗ или сотни страниц методик ФСТЭК невозможно, а потому кажется, что контроль утрачен. На деле регуляторный каркас выстроен вокруг ключевых принципов. Если вы понимаете эти принципы, то сможете задавать правильные вопросы и находить пробелы. Основные причины беспокойства:
- Отсутствие карты. Нет ясного представления, как требования связаны между собой и с бизнес-процессами компании. Это превращает работу в реактивную, где вы тушите пожары вместо того, чтобы предупреждать их.
- Избыток второстепенного. Много внимания уделяется формальностям (например, оформлению журналов) в ущерб анализу реальных угроз и защите критичных активов.
- Неопределённость границ. Неясно, где кончается ваша зона ответственности и начинается работа других подразделений (юристов, кадровой службы, разработчиков).
Что именно считается «пропущенным» с точки зрения регулятора?
Важно сместить фокус с абстрактного «всего» на конкретные категории нарушений, которые аудитор или регулятор ищет в первую очередь. Это не случайный набор, а те аспекты, которые напрямую влияют на защищённость информации.
1. Отсутствие или фиктивность базовых процессов
Самая грубая ошибка — когда процессы существуют только на бумаге. Проверяющие легко это выявляют, задавая простые вопросы: «Покажите, как вы обновляли правила разграничения доступа за последний квартал» или «Как проводилось вводное обучение для нового сотрудника из отдела продаж?». Если нет документальных свидетельств, процесс считается неработающим. К таким базовым процессам относятся: классификация информации, управление доступом, реагирование на инциденты, обучение персонала.
2. Неучтённые значимые активы
Защищать можно только то, что известно. Пропущенный актив, это не просто неизвестный сервер, это любая информационная система, база данных или даже набор файлов, которые обрабатывают персональные данные или критичную для бизнеса информацию, но не включены в реестр. Пример: маркетинговая рассылка ведётся через облачный сервис, не согласованный с ИБ. Этот сервис и есть пропущенный актив.
3. Систематическое игнорирование изменений
Инфраструктура и процессы не статичны. Если в компании внедрили новую CRM-систему, запустили микросервис или изменили схему работы с подрядчиком, но модель угроз и политики безопасности не актуализировались, это пропущенное изменение. Регуляторные требования предписывают регулярный пересмотр мер защиты, особенно после модификаций.р>
Как выстроить систему, которая ничего не упустит
Вместо того чтобы пытаться запомнить всё, создайте механизмы, которые будут отслеживать важное за вас.
Картирование требований к процессам
Не читайте 152-ФЗ от корки до корки. Разбейте его на логические блоки и привяжите к конкретным процессам в вашей компании. Создайте таблицу:
| Требование (Статья 152-ФЗ / Методика ФСТЭК) | Ответственный процесс в компании | Контрольная точка (документ, событие) | Периодичность проверки |
|---|---|---|---|
| Статья 18.1. Меры по обеспечению безопасности ПДн | Управление доступом к информационным системам ПДн | Акт о назначении и изменении прав доступа; журнал учёта запросов. | Ежеквартально |
| Требования к антивирусной защите (ФСТЭК) | Обслуживание средств защиты информации | Отчёты СЗИ из центра управления; акты обновления сигнатур. | Ежемесячно |
| Статья 16. Уведомление об обработке ПДн | Юридическое сопровождение | Выписка из реестра Роскомнадзора; внутренний реестр операций. | При любом изменении цели обработки |
Такая таблица превращает абстрактное требование в задачу для конкретного сотрудника с чёткими сроками.
Регулярные кросс-функциональные проверки
Слепые пятна часто возникают на стыках отделов. Раз в полгода проводите совещание с ключевыми руководителями: руководителем IT-инфраструктуры, начальником отдела разработки, HR-директором, юристом. Обсудите:
- Какие новые системы или сервисы были внедрены?
- Изменялись ли бизнес-процессы, связанные с клиентскими данными?
- Были ли инциденты, которые не попали в службу ИБ?
Это позволяет выявить те самые «пропущенные» активы и изменения, о которых ИБ-служба могла не знать.
Фокус на доказательствах, а не на намерениях
Вместо вопроса «Мы это делаем?» задавайте вопрос «Как мы это докажем?». Собирайте доказательную базу для каждого значимого процесса. Например, для процесса обучения это будут: утверждённая программа, список обученных сотрудников с подписями, тестовые задания. Если доказательство сформировать невозможно, значит, процесс не работает и его нужно перестроить. Эта логика совпадает с подходом аудиторов.
Что делать, если пропущенное уже найдено
Обнаружение пробела — не провал, а часть работы. Важен системный подход к исправлению.
- Оцените критичность. Определите, связан ли пробел с реальным риском утечки данных или это формальное несоответствие. Пропущенный журнал учёта носителей — проблема, но менее критичная, чем отсутствие шифрования базы данных с паспортными данными.
- Задокументируйте находку. Внесите её во внутренний реестр несоответствий или рисков. Укажите дату обнаружения, описание, оценку критичности и ответственного за устранение.
- Исправляйте причину, а не следствие. Если вы пропустили новый сервис, недостаточно просто внести его в реестр. Проанализируйте, почему он был пропущен: нет ли процедуры уведомления ИБ о запуске новых IT-проектов? Исправьте процедуру.
- Проанализируйте системность. Один пропущенный актив может указывать на другие. Если не было учтено одно облачное хранилище, проверьте все договоры с подрядчиками на предмет использования иных неучтённых внешних сервисов.
Главный индикатор: вы перестали бояться проверок
Чувство, что вы что-то пропустили, постепенно сходит на нет, когда у вас есть живая, а не бумажная система. Её признаки:
- Вы можете за час подготовить доказательства по любому ключевому требованию.
- Новые проекты приходят к вам на оценку рисков до своего запуска, а не после.
- Вопрос от коллеги из другого отдела о правилах работы с данными не вызывает паники, потому что ответ есть в доступной инструкции.
Цель — не идеальное знание каждого пункта закона, а создание такой операционной среды, где важные вещи не могут быть пропущены системно. Именно это и оценивается при реальной проверке.