Соответствие требованиям регуляторов
Требования регуляторов нередко воспринимаются как бумажная нагрузка. Иногда так и есть. Но правильно выстроенный процесс соответствия создаёт реальную структуру защиты — и открывает двери к заказчикам и партнёрам, которые без аттестата просто не начнут переговоры.
Эта глава помогает разобраться в российской нормативной базе, выбрать нужный регуляторный контур и подготовиться к первой проверке — без того чтобы утонуть в бумагах.
Почему это важно для бизнеса
Деловой аргумент
-
Доступ к крупным заказчикам. Госкорпорации, банки, промышленные холдинги требуют подтверждения соответствия требованиям ИБ. Без аттестата или декларации ряд тендеров и контрактов просто недоступен.
-
Конкурентное преимущество. Среди компаний вашего размера наличие документального подтверждения ИБ выделяет вас. «У нас аттестат ФСТЭК и задокументированная система ИБ» убедительнее, чем «мы серьёзно относимся к безопасности».
-
Доверие инвесторов. При due diligence вопрос соответствия требованиям регуляторов стоит в числе первых. Документально подтверждённая зрелость ИБ влияет на оценку.
-
Снижение страховых издержек. Страховщики по киберрискам снижают премии при наличии подтверждённых мер защиты.
-
Готовность к инцидентам. Всё, что делается ради соответствия требованиям — документация, мониторинг, процедуры, — помогает именно тогда, когда инцидент уже происходит.
Регуляторный аргумент
-
Штрафы и предписания. Нарушение 152-ФЗ влечёт штрафы; для субъектов критической информационной инфраструктуры (КИИ) по 187-ФЗ последствия серьёзнее. Роскомнадзор (федеральный регулятор по персональным данным) вправе инициировать проверку и выдать предписание об устранении нарушений.
-
Договорные обязательства. Многие контракты содержат требования ИБ. Несоответствие — это нарушение договора.
-
Ответственность руководства. Указ Президента РФ № 250 (2022) закрепил персональную ответственность руководителя организации за состояние ИБ.
Ключевые законы и регуляторы
Основные законы для большинства компаний
152-ФЗ «О персональных данных» — фундаментальный закон для любой компании, которая собирает, хранит или обрабатывает персональные данные граждан РФ. Регулятор — Роскомнадзор (РКН, Федеральная служба по надзору в сфере связи, информационных технологий и массовых коммуникаций).
Ключевые требования:
- Определить правовое основание обработки ПДн (согласие, договор, законный интерес)
- Обеспечить права субъектов: доступ, исправление, удаление, выгрузку данных
- Уведомить РКН об утечке ПДн: факт инцидента — в течение 24 часов, результаты расследования — в течение 72 часов
- Хранить ПДн граждан РФ на серверах, физически расположенных на территории России (242-ФЗ)
- Вести журнал операций с ПДн
- Выполнять технические меры защиты согласно ПП РФ № 1119 (уровни защищённости) и приказу ФСТЭК России № 21
Что требовать от лидера безопасности:
- Реестр всех категорий ПДн с указанием правового основания обработки каждой
- Технические меры, соответствующие уровню защищённости по ПП РФ № 1119
- Актуальная политика конфиденциальности
- Регламент уведомления Роскомнадзора (готов до инцидента, а не во время)
- Соглашения о конфиденциальности с поставщиками, получающими доступ к ПДн
149-ФЗ «Об информации, информационных технологиях и о защите информации» — базовый закон об ИБ. Применяется вместе с отраслевыми требованиями.
98-ФЗ «О коммерческой тайне» — режим коммерческой тайны защищает бизнес-информацию. Для его работы нужен введённый режим и перечень сведений, составляющих коммерческую тайну.
Для субъектов критической информационной инфраструктуры (КИИ)
187-ФЗ «О безопасности критической информационной инфраструктуры» распространяется на организации в 13 отраслях: здравоохранение, наука, транспорт, связь, энергетика, банки и финансовый рынок, топливно-энергетический комплекс, атомная промышленность, оборонная промышленность, ракетно-космическая промышленность, горнодобывающая промышленность, металлургическая промышленность, химическая промышленность.
Ключевые обязательства субъектов КИИ:
- Провести категорирование объектов КИИ и передать сведения в ФСТЭК России
- Создать систему безопасности объектов КИИ в соответствии с приказом ФСТЭК № 239
- Подключиться к ГосСОПКА (государственной системе обнаружения, предупреждения и ликвидации последствий компьютерных атак) через НКЦКИ (Национальный координационный центр по компьютерным инцидентам)
- Уведомлять НКЦКИ об инцидентах на объектах КИИ
Если ваша компания попадает в перечень отраслей КИИ, это направление требует отдельного правового анализа и консультации со специализированным подрядчиком.
Регуляторы: кто за что отвечает
| Регулятор | Зона ответственности |
|---|---|
| ФСТЭК России (Федеральная служба по техническому и экспортному контролю) | Технические требования к защите информации, аттестация ИС, лицензирование деятельности по ТЗКИ, база данных угроз (БДУ) |
| ФСБ России | Криптография, СКЗИ (средства криптографической защиты информации), ГосСОПКА |
| Роскомнадзор | Надзор за обработкой персональных данных |
| Банк России / ФинЦЕРТ | Требования к финансовым организациям |
| Минцифры | Реестр российского ПО, импортозамещение |
Нормативная база по направлениям
Персональные данные: 152-ФЗ + приказ ФСТЭК № 21
Кому применимо: всем, кто собирает ПДн физических лиц — это большинство компаний.
Уровни защищённости (ПП РФ № 1119) — от УЗ-4 (базовый) до УЗ-1 (максимальный). Уровень зависит от категории ПДн (общедоступные, специальные, биометрические) и объёма обработки. Большинство компаний работает с УЗ-3 или УЗ-4.
Приказ ФСТЭК № 21 устанавливает технические меры защиты для информационных систем ПДн (ИСПДн). Меры разбиты по классам: управление доступом, аудит, защита среды, антивирусная защита и другие.
Практические шаги:
- Определить, к какому уровню защищённости относятся ваши ИСПДн
- Разработать модель угроз (требование приказа № 21) — лидер безопасности с помощью методики ФСТЭК
- Внедрить меры защиты, соответствующие уровню
- Уведомить РКН о факте обработки ПДн (Реестр операторов ПДн)
Государственные информационные системы: приказ ФСТЭК № 17
Кому применимо: операторам ГИС (государственных информационных систем) и организациям, получающим доступ к ГИС. Если компания участвует в государственных контрактах с доступом к информационным системам госзаказчика — этот приказ может распространяться на неё.
Классы защищённости: К1 (высший) — К3 (базовый). Класс определяет набор обязательных мер.
Финансовый сектор: ГОСТ Р 57580.1 и положения Банка России
Кому применимо: банкам, финтех-компаниям, платёжным сервисам, страховщикам.
ГОСТ Р 57580.1-2017 «Безопасность финансовых операций» устанавливает требования к системе управления ИБ в финансовых организациях. Оценка соответствия ГОСТ Р 57580.2 — обязательна согласно положениям Банка России.
Ключевые нормативные акты Банка России:
- Положение 683-П — для кредитных организаций
- Положение 719-П — для некредитных финансовых организаций
- Положение 757-П — противодействие несанкционированным операциям
- Положение 802-П — управление операционным риском
Для карточных данных: прямого российского аналога PCI DSS нет, но требования НСПК (Национальной системы платёжных карт) и ГОСТ Р 57580.1 закрывают значительную часть тех же областей.
Практическое правило: если компания не является финансовой организацией, для приёма платежей используйте готовое платёжное решение (ЮKassa и аналоги) — вы выходите из периметра требований к обработке карточных данных.
АСУ ТП и промышленные системы: приказ ФСТЭК № 31
Кому применимо: компаниям с автоматизированными системами управления технологическими процессами.
Объекты КИИ: приказ ФСТЭК № 239
Кому применимо: значимым объектам КИИ (категории 1, 2, 3). Устанавливает требования к системе безопасности таких объектов.
ГОСТ Р ИСО/МЭК 27001-2021 (СМИБ)
Что это. Российский национальный стандарт, идентичный международному ISO/IEC 27001:2013. Устанавливает требования к системе менеджмента информационной безопасности (СМИБ).
Кому нужен. Компаниям, работающим с зарубежными заказчиками или международными холдингами, которые требуют ISO 27001; компаниям с развитым корпоративным управлением и потребностью в структурированной СМИБ; компаниям, планирующим выход на международные рынки.
Ключевые элементы СМИБ:
- Задокументированная область применения и политика ИБ
- Оценка и обработка рисков
- Заявление о применимости (SoA) — какие меры внедрены и почему
- Программа внутренних аудитов
- Анализ со стороны руководства
- Постоянное совершенствование
Сроки и стоимость: подготовка — 6–12 месяцев; сертификационный аудит аккредитованным органом — 1–2 недели; стоимость — от 500 тыс. до 2 млн руб. в зависимости от размера и сложности; ежегодные надзорные аудиты.
Честная оценка для малого бизнеса. ГОСТ Р ИСО/МЭК 27001-2021 — серьёзная работа. Рассматривайте его после того, как выстроили базовые процессы, или когда этого явно требует заказчик. Для большинства российских B2B-сделок достаточно аттестата ФСТЭК или декларации о соответствии.
Примечание. Международный ISO 27001 (без российской приставки ГОСТ Р) при необходимости упоминается как вариант для компаний, ориентированных на зарубежные рынки.
SOC 2: только для международных сделок
Что это. Американский стандарт для SaaS-компаний и сервисных провайдеров (отчёт аудитора о соответствии Trust Service Criteria). Не имеет прямого российского аналога.
Кому нужен. Исключительно компаниям, работающим с американскими корпоративными заказчиками, которые его явно требуют. Для российского рынка SOC 2 не применяется и не требуется.
Российские альтернативы:
- Аттестат соответствия требованиям ФСТЭК России
- Сертификат соответствия ГОСТ Р ИСО/МЭК 27001-2021
- Для финансового сектора — оценка соответствия ГОСТ Р 57580.1
Самооценка: с чего начать
Прежде чем двигаться к аттестации, оцените текущее состояние. Используйте эти инструменты.
Самооценка по методике ФСТЭК
Для ИСПДн (152-ФЗ + приказ № 21):
- Определите категорию ПДн и уровень защищённости (ПП РФ № 1119)
- Сопоставьте текущие меры с перечнем приказа № 21 для вашего уровня
- Оцените каждую меру: не реализована / частично / полностью
- Составьте перечень пробелов
| Мера защиты (группа) | Что включает | Быстрая проверка |
|---|---|---|
| Управление доступом (УПД) | Идентификация, аутентификация, разграничение полномочий | Есть ли у каждого пользователя отдельная учётная запись? |
| Аудит безопасности (АУД) | Регистрация событий, анализ аудита | Ведутся ли журналы доступа к ИСПДн? |
| Антивирусная защита (АВЗ) | Защита от вредоносного ПО | Установлены ли актуальные антивирусы на всех узлах? |
| Управление конфигурацией (УКФ) | Базовая конфигурация, контроль изменений | Зафиксированы ли эталонные конфигурации? |
| Защита информационной системы (ЗИС) | Сегментация, фильтрация трафика | Разделены ли ИСПДн и иные сети? |
| Реагирование на инциденты (ИНЦ) | Обнаружение, реагирование | Есть ли инструкция на случай инцидента с ПДн? |
Базовая самооценка для любой компании
Независимо от регуляторного контура, эти десять контролей — минимум, на который смотрит любая проверяющая сторона:
| Контроль | Вопрос для проверки |
|---|---|
| Инвентаризация активов | Известен ли перечень всех систем, устройств и данных? |
| Управление доступом | Принцип минимальных привилегий реализован? Удаляются ли права при увольнении? |
| Многофакторная аутентификация | MFA включена на всех критичных системах? |
| Защита данных | Чувствительные данные зашифрованы в хранении и при передаче? |
| Управление уязвимостями | Регулярное сканирование и обновление ведётся? |
| Журналы аудита | Собираются ли и хранятся ли журналы событий безопасности? |
| Обучение персонала | Есть ли регулярное обучение по ИБ с подтверждением прохождения? |
| Реагирование на инциденты | Существует ли план реагирования? Проводились ли учения? |
| Управление подрядчиками | Есть ли перечень поставщиков с оценкой доступа к данным? |
| Резервное копирование | Резервные копии создаются, хранятся отдельно и проверяются? |
Эти десять пунктов отвечают на большинство вопросов при аудите или проверке.
Подготовка к первой проверке или аттестации
За 6 месяцев: фундамент
Документация:
- Политика информационной безопасности
- Перечень персональных данных и правовые основания их обработки
- Модель угроз (для ИСПДн)
- Инвентаризация активов
- Перечень поставщиков с оценкой их доступа
- Записи о прохождении обучения по ИБ
Технические меры:
- MFA на всех критичных системах
- Шифрование данных в хранении и при передаче
- Централизованный сбор журналов событий
- Регулярное сканирование на уязвимости
- Тестирование резервного копирования и восстановления
Процессы:
- Процедура управления изменениями
- Процедура пересмотра прав доступа (ежеквартально)
- План реагирования на инциденты
- Регламент уведомления Роскомнадзора при утечке ПДн
За 3 месяца: сбор доказательств
Что хочет увидеть проверяющий / аудитор:
- Скриншоты конфигураций с видимой датой
- Документы с историей версий
- Записи о прохождении обучения
- Журналы пересмотра прав доступа
- Отчёты о сканировании уязвимостей
- Журналы инцидентов (даже если инцидентов не было — журнал «без событий» тоже ведётся)
- Записи об изменениях в системах
Советы по сбору доказательств:
- Снимайте скриншоты в момент выполнения действия, не накануне проверки
- Ведите структурированный репозиторий доказательств — папка по каждой мере защиты
- Собирайте непрерывно, не аврально перед аудитом
За 1 месяц: готовность
Внутренний аудит:
- Пройдитесь по каждой мере
- Убедитесь, что доказательства есть
- Выявите пробелы
- Устраните то, что можно быстро исправить
Подбор аттестующей организации (для аттестации ФСТЭК):
- Выбирайте из лицензиатов ФСТЭК по технической защите конфиденциальной информации (ТЗКИ)
- Запросите коммерческие предложения от 3 организаций
- Уточните опыт работы с компаниями вашего размера и отрасли
Подготовка команды:
- Определите ответственных за каждую меру защиты
- Проведите инструктаж о порядке проверки
- Согласуйте календарь присутствия ключевых сотрудников
Во время проверки
Чего ожидать:
- Запрос на предоставление документов и доказательств
- Обходы и демонстрации — проверяющий попросит показать работу процессов
- Технические тесты (выборочные)
- Интервью с ответственными
- Обсуждение выявленных замечаний
Рекомендации:
- Назначьте единственную точку контакта с проверяющим
- Отвечайте на запросы в течение одного рабочего дня
- Не добавляйте лишней информации сверх вопроса
- Если не знаете ответа — так и скажите, не домысливайте
- Все выявленные замечания фиксируйте для плана устранения
Автоматизация соответствия требованиям
Для компаний с ресурсами — российские GRC-платформы значительно сокращают ручной труд:
| Платформа | Чем полезна |
|---|---|
| R-Vision | Управление рисками и соответствием, инцидентами, активами |
| Security Vision | GRC-платформа, поддержка российских стандартов (152-ФЗ, ГОСТ Р 57580, КИИ) |
| ePlat4m | Комплаенс-автоматизация для финансового сектора |
Для большинства малых и средних компаний начинать с платформы не обязательно — достаточно структурированных таблиц и регулярных процессов. GRC-платформа оправдана, когда число контролей и объём доказательной базы становятся неуправляемыми вручную.
Анкеты безопасности от заказчиков
До получения аттестата вас будут спрашивать анкеты — иногда на 100+ вопросов. Вот как с ними работать.
Как реагировать на анкету
1. Создайте библиотеку ответов. Большинство вопросов повторяются. Собирайте готовые ответы в единый документ, переиспользуйте для каждой анкеты.
Пример:
Управление доступом
В: Применяете ли вы MFA для всех пользователей?
О: Да. MFA обязательна через [Avanpost MFA / MULTIFACTOR] для всех
сотрудников. Для доступа к производственным системам и
административным интерфейсам применяются аппаратные токены
(Рутокен/JaCarta).
Доказательство: [скриншот политики IdP]
В: Как часто проводится пересмотр прав доступа?
О: Ежеквартально. Пересмотр проводят руководители подразделений,
результаты фиксируются в Яндекс Трекере. Доступ уволенных
сотрудников отзывается в течение рабочего дня.
Доказательство: [журнал пересмотра, регламент увольнения]
2. Будьте честны в пробелах. «У нас этого нет, но мы планируем внедрить в Q2» лучше, чем ложь. Заказчики ценят честность; несоответствия проверяются.
3. Предлагайте компенсирующие меры. «У нас нет SIEM, но мы централизованно собираем журналы в OpenSearch с алертингом на критические события.»
4. Используйте «Н/П» там, где уместно. «У вас есть собственные физические дата-центры?» — для облачного сервиса это вопрос не применим.
Восемь контролей, которые отвечают на большинство анкетных вопросов
| Контроль | Почему его спрашивают | Как внедрить быстро |
|---|---|---|
| MFA | Вопрос № 1 по безопасности | Неделя на развёртывание с IdP |
| Шифрование в хранении | Защита данных | Включить на уровне СУБД/облака |
| Шифрование в передаче | Защита данных | HTTPS повсюду, проверить TLS-конфигурацию |
| Сканирование уязвимостей | Непрерывная безопасность | MaxPatrol, RedCheck или OpenVAS/Greenbone |
| Проверка персонала | Внутренние угрозы | Добавить в процесс найма |
| Обучение по ИБ | Осведомлённость | Базовый курс + запись о прохождении |
| Пересмотр доступа | Минимум привилегий | Ежеквартальное напоминание в календаре |
| План реагирования на инциденты | Готовность | Написать двухстраничный IRP |
Типичные замечания на проверках (и как их избежать)
Замечание 1: «Призрачные» учётные записи
Что находят: уволенные сотрудники имеют активные учётные записи.
Как предотвратить: автоматизировать отзыв доступа через HRIS-интеграцию; ежеквартально проводить аудит учётных записей; фиксировать дату увольнения и дату отзыва доступа.
Замечание 2: Отсутствие доказательств
Что находят: политика предусматривает квартальный пересмотр прав доступа, но подтверждений того, что он проводился, нет.
Как предотвратить: снимать скриншоты в момент выполнения действия; использовать трекер задач как журнал; ставить напоминания на периодические контроли.
Замечание 3: MFA не для всех
Что находят: политика MFA есть, но 5% пользователей без неё.
Как предотвратить: включить принудительный MFA в IdP (не просто рекомендацию); ежемесячно аудировать статус MFA; документировать исключения с визой VP.
Замечание 4: Устаревшие документы
Что находят: политика ИБ не обновлялась три года и не отражает текущее состояние.
Как предотвратить: ежегодный пересмотр политик — в календаре; версионирование документов; владелец назначен для каждого документа.
Замечание 5: Нет следов управления изменениями
Что находят: изменения в производственных системах без истории согласования.
Как предотвратить: обязательное согласование пул-реквестов; привязка деплоев к задачам в трекере; даже простой журнал «что изменено, когда, кем» помогает.
Замечание 6: Управление уязвимостями не работает
Что находят: уязвимости живут дольше установленного SLA.
Как предотвратить: определить SLA (7 дней — критические, 30 дней — высокие); вести учёт в трекере с дедлайнами; ежемесячно отчитываться о соблюдении SLA.
Истории из практики
История 1: Срочное доказательство
Стартап запланировал аттестацию на понедельник. В пятницу выяснилось: «процедура пересмотра прав доступа» существует только как электронное письмо «эй, проверьте доступ» — без единого следа реального пересмотра.
Решение за выходные: в субботу провели полноценный пересмотр доступа с документированием, утвердили регулярный квартальный график. На аттестации — замечание «процедура недавно внедрена», но не критичное нарушение.
Вывод: даже только что внедрённые контроли засчитываются. Лучше поздно, чем никогда.
История 2: Согласование объёма
Компания на 20 человек получила смету на аттестацию в 3 млн руб. — аттестующая организация хотела включить в область все системы. лидер безопасности предложил сузить область: только производственная среда; только системы, обрабатывающие ПДн; исключить внутренние инструменты и тестовые среды.
Новая смета: 1,2 млн руб. Тот же аттестат, та же ценность для заказчиков.
Вывод: область аттестации переговорная. Начинайте узко, расширяйте по мере зрелости.
История 3: Честный пробел
Во время проверки задали вопрос о пентесте. Пентеста не было.
Плохой ответ: «Мы планируем сделать это в ближайшее время.»
Реальный ответ: «У нас нет пентеста. Мы проводим автоматическое сканирование уязвимостей, ревью кода и обработку репортов от исследователей. Формальный пентест запланирован на Q2 с выделенным бюджетом.»
Результат: замечание с чётким планом устранения. Проверяющий оценил честность и конкретику.
Вывод: проверяющие предпочитают честные пробелы с планами неопределённым заверениям.
Соответствие как конкурентное преимущество
Документально подтверждённая зрелость ИБ работает на продажи:
- Ускоряет согласование сделок: аттестат снимает вопросы ИБ на этапе предпродажной проверки
- Снимает нагрузку анкет: аттестат или декларация заменяет большинство вопросов заказчиков
- Сигнал инвесторам: демонстрирует зрелость процессов сверх привычного для вашего размера
- Снижает страховые взносы: подтверждённые меры влияют на оценку киберриска страховщиком
Отчёты конкурентов об аттестации бывают доступны на запрос (как потенциальный заказчик) — это позволяет оценить, что они включают в область и какие исключения фиксируют.
Управленческое задание: самооценка соответствия требованиям
Что поручить лидеру безопасности — контрольные артефакты:
-
Карта регуляторных требований (2 часа). Перечень применимых законов и регуляторных актов для компании с кратким описанием обязательств по каждому.
-
Самооценка ИСПДн (2 часа). Определение уровня защищённости ПДн, оценка текущих мер по приказу ФСТЭК № 21, перечень пробелов.
-
Дорожная карта (1 час). 12-месячный план внедрения недостающих мер с разбивкой по кварталам, ресурсами и критериями готовности.
Контрольные точки для руководителя:
- Определён применимый регуляторный контур
- Завершена самооценка с перечнем пробелов
- Утверждена дорожная карта с бюджетом
- Подана уведомление в РКН (реестр операторов ПДн)
- Назначен ответственный за каждую меру защиты
- Регламент уведомления Роскомнадзора при утечке написан и доступен
Типичные ошибки
-
Разовый проект. Соответствие требованиям — постоянный процесс. Меры должны работать непрерывно, не только в период проверки.
-
Документы без реализации. Политики есть, но не соблюдаются. Аудиторы проверяют реальную практику, а не документы.
-
Слишком широкая область. Включение всего сразу. Начинайте с ключевых систем, расширяйте постепенно.
-
Ожидание запроса от заказчика. Подготовка к аттестации занимает 6–12 месяцев. Начинать её в ответ на уже потерянную сделку — поздно.
-
Аттестация как самоцель. Аттестат — результат, а не цель. Цель — работающая система ИБ.
-
Нет процесса сбора доказательств. Авральный сбор накануне проверки упускает важное и занимает много времени.
Итоги
Соответствие требованиям — не безопасность. Но регуляторные рамки задают структуру, требуют документирования и вынуждают проверять, что меры реально работают. Это делает программу ИБ более зрелой — хотите вы того или нет.
Выберите применимый регуляторный контур. Двигайтесь к нему последовательно. Аттестат — это результат, а не цель.
См. также
- ISO 27001 / ГОСТ 27001 — построение СМИБ по стандарту
- Аттестация и оценка соответствия — подготовка к проверке
- Политики безопасности — документы, которые придётся показать
Что дальше
Следующий раздел — работа с подрядчиками и поставщиками: безопасность компании определяется самым слабым звеном в цепочке.