← назад к разделу

Руководитель разработки в России почти никогда не отвечает за ИБ формально: есть офицер безопасности, юрист, служба комплаенса. Но именно в его плане оказываются задачи, без которых компания нарушает закон: локализация базы, журнал согласий, пентест перед релизом, исправление уязвимости в срок. Если менеджер не понимает, откуда эти требования и какие у них сроки, они приходят в последний момент и ломают квартал.

Это не юридическая консультация. Задача статьи: показать устройство требований и дать ссылки на тексты, чтобы разговор с юристом и офицером ИБ шёл на одном языке.

Обязательно

Карта: какие требования касаются вашей команды

Первый вопрос, который стоит задать в новой компании: «какие режимы на нас распространяются». Ответ обычно складывается из пяти источников.

ТребованиеКогда касаетсяКто проверяетЧто приходит в бэклог
152-ФЗ о персональных данныхПочти всегда: клиенты, сотрудники, кандидатыРоскомнадзорСогласия, локализация, удаление по запросу, реакция на утечку
187-ФЗ о КИИЗдравоохранение, транспорт, связь, энергетика, финансы, промышленность и др.ФСТЭК, ФСБ (ГосСОПКА)Категорирование систем, меры защиты значимых объектов, сообщение об инцидентах
ГОСТ Р 57580.1 и положения Банка РоссииБанки и другие финансовые организацииБанк России, проверяющие организацииМеры защиты по уровню, ежегодный пентест, оценка соответствия
PCI DSSХраните, обрабатываете или передаёте данные картБанк-эквайер, аудиторСужение зоны карточных данных, маскирование, сканирования
ГОСТ Р 56939Сертификация ПО, требования заказчика или регулятораИспытательная лаборатория, заказчикПроцессы безопасной разработки и их свидетельства

Таблицу полезно повесить в вики команды и сверить с офицером ИБ. Половина конфликтов вокруг безопасности возникает потому, что команда не знает, под какой режим попадает.

152-ФЗ: что из закона попадает в бэклогспросят на собеседовании

152-ФЗ «О персональных данных» касается почти любой компании. Для команды важны пять мест.

Основание обработки. Согласие лишь одно из оснований: статья 6 допускает обработку и без него, например когда она нужна для исполнения договора с субъектом. Если основание согласие, то по статье 9 оно должно быть «конкретным, предметным, информированным, сознательным и однозначным», а доказать его получение обязан оператор. В редакции 156-ФЗ от 24.06.2025 согласие ещё и оформляют отдельно от других документов, которые подписывает или подтверждает человек: галочка внутри оферты больше не годится. Для разработки это значит: хранить, кто, когда, на какую версию текста и для каких целей дал согласие, и уметь отозвать его. Галочка без журнала ничего не доказывает.

Локализация. Часть 5 статьи 18 (в редакции 23-ФЗ от 28.02.2025) при сборе данных, в том числе через интернет, запрещает запись, систематизацию, накопление, хранение, уточнение и извлечение персональных данных граждан России с использованием баз данных за пределами России (с исключениями из статьи 6). Практически: основная база с персональными данными в российском ЦОД, а выбор облака, CRM, сервиса рассылок и аналитики идёт через этот вопрос.

Уведомление об обработке. По статье 22 оператор уведомляет уполномоченный орган до начала обработки; исключений после 1 сентября 2022 года осталось мало. Изменения сведений сообщают не позднее 15-го числа следующего месяца, прекращение обработки в течение десяти рабочих дней. Для менеджера это значит: новый продукт с новыми целями или категориями данных может потребовать обновить уведомление, и юриста об этом надо предупредить до запуска. Подаётся оно на портале персональных данных Роскомнадзора.

Подрядчики. Если данные обрабатывает подрядчик или облачный сервис по вашему поручению, в договоре по части 3 статьи 6 должны быть перечень данных, действия, цели, обязанность соблюдать конфиденциальность, требование локализации (ч. 5 ст. 18), обязанность по вашему запросу подтверждать принятые меры, требования к защите, а также обязанность уведомить вас об инциденте.

Ответственный. По статье 22.1 оператор-юрлицо назначает лицо, ответственное за организацию обработки. Узнайте, кто это у вас, в первую неделю.

Как это выглядит в коде, разобрано в статье PII и секреты.

187-ФЗ: КИИ и категорированиеспросят на собеседовании

187-ФЗ «О безопасности критической информационной инфраструктуры» от 26.07.2017 касается компаний, чьи информационные системы работают в перечисленных в статье 2 сферах: здравоохранение, наука, транспорт, связь, энергетика, государственная регистрация прав на недвижимость, банковская сфера и иные сферы финансового рынка, топливно-энергетический комплекс, атомная энергия, оборонная, ракетно-космическая, горнодобывающая, металлургическая и химическая промышленность. Такая компания называется субъектом КИИ; субъектами считаются и юрлица, которые обеспечивают взаимодействие таких систем.

Механика по статье 7: субъект сам категорирует свои объекты (информационные системы, сети, АСУ); с изменениями 58-ФЗ, действующими с 1 сентября 2025 года, это делают с учётом перечней типовых отраслевых объектов КИИ. Оценивают значимость: социальную, политической, экономической, экологической значимости и значимости для обороны и безопасности. Категорий три. Результаты в десятидневный срок со дня решения направляются в федеральный орган, уполномоченный в области безопасности КИИ; по Положению о ФСТЭК (пункт 2) это ФСТЭК России. Значимые объекты попадают в реестр, и для них действуют требования к системе безопасности (статья 10).

Отдельно статья 9: субъект КИИ обязан «незамедлительно» сообщать о компьютерных атаках и инцидентах федеральному органу, который отвечает за государственную систему обнаружения, предупреждения и ликвидации последствий компьютерных атак (ГосСОПКА), а в финансовой сфере ещё и в Банк России. С 1 сентября 2025 года та же статья (п. 5 ч. 3) обязывает использовать на значимых объектах ПО из реестра российского ПО (или применяемое в защищённых государственных системах), в порядке и сроки перехода, которые устанавливает Правительство; подробнее в статье Вендоры и импортозамещение.

Что это значит для менеджера. Если ваша система значимый объект, любое существенное изменение архитектуры (новый внешний доступ, перенос в облако, замена СУБД) сначала обсуждают с офицером ИБ: это может менять модель угроз и набор мер. И сроки проектов на таких системах закладывают с учётом согласований.

Финансовые организации: ГОСТ Р 57580.1 и положения Банка России

ГОСТ Р 57580.1-2017 «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый состав организационных и технических мер» (введён с 1 января 2018 года приказом Росстандарта № 822-ст) задаёт базовый состав мер и три уровня защиты: минимальный, стандартный и усиленный. Сам ГОСТ ничего не обязывает; обязательным его делают положения Банка России.

Для кредитных организаций с 29 марта 2025 года действует Положение Банка России № 851-П, заменившее 683-П. По его тексту:

  • усиленный уровень обязателен для системно значимых кредитных организаций и некоторых других значимых участников платёжного рынка, стандартный для остальных кредитных организаций;
  • нужно ежегодное тестирование на проникновение и анализ уязвимостей объектов информационной инфраструктуры;
  • оценка соответствия проводится с привлечением проверяющих организаций не реже одного раза в два года;
  • прикладное ПО для банковских операций сертифицируется в системе ФСТЭК или проходит оценку соответствия по ОУД4.

Для некредитных финансовых организаций и переводов денежных средств действуют свои положения Банка России; какое из них ваше, спросите у офицера ИБ. Для менеджера главное: ежегодный пентест и оценка раз в два года это фиксированные даты в календаре, а их выводы приходят задачами с жёстким сроком. Окно под них в плане надо держать заранее.

PCI DSS: карты

PCI DSS не закон, а договорное требование платёжных систем, оно приходит через банк-эквайер. Версия 4.0.1, действующая на момент подготовки статьи, опубликована 11 июня 2024 года, отложенные требования вступили в силу 31 марта 2025 года. Главное управленческое решение здесь архитектурное: принимать карты через платёжного провайдера и токены, тогда ваши сервисы вне зоны карточных данных и проверка обычно сводится к сокращённому опроснику самооценки (SAQ). Подробно для разработчика: PCI DSS.

Безопасная разработка: ГОСТ Р 56939

ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования» утверждён приказом Росстандарта № 1504-ст, действует с 20 декабря 2024 года вместо версии 2016 года. Он описывает процессы: моделирование угроз, требования к безопасности, статический и динамический анализ, контроль заимствованных компонентов, обучение, реакция на уязвимости после выпуска.

Обязательным он становится, когда ПО идёт на сертификацию или когда этого требует заказчик. Но даже без этого он полезен как чек-лист зрелости: у каждого процесса должен быть владелец и след в артефактах (отчёт сканера в сборке, протокол разбора угроз, реестр зависимостей). Аудитор проверяет не намерения, а свидетельства.

Аудиты и пентесты

Три разные вещи, которые часто путают:

  • Оценка соответствия: сверка мер с требованием (ГОСТ, положение, PCI DSS). Результат: уровень соответствия и список несоответствий.
  • Анализ уязвимостей: сканеры и ручная проверка конфигураций и кода. Результат: список уязвимостей с критичностью.
  • Тестирование на проникновение: попытка внешней команды добиться цели (данные, деньги, админ-доступ). Результат: цепочки атак и рекомендации.

Что делает менеджер: согласует объём и окно (стенд, учётные записи, кто на связи), предупреждает дежурных, чтобы атаку не приняли за инцидент, и заранее резервирует ёмкость на исправления. Типичная картина: отчёт пентеста приходит в середине квартала с тридцатью находками, и половину нужно закрыть до повторной проверки.

Роль менеджера: бюджет, сроки, приоритет уязвимостейспросят на собеседовании

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

Сроки. Регуляторные даты не двигаются переговорами. Их заносят в roadmap как вехи с обратным отсчётом: «оценка соответствия в марте, значит исправления до февраля, значит анализ в январе».

Приоритет уязвимостей. Нужен заранее согласованный с офицером ИБ срок исправления по критичности, иначе каждая находка становится переговорами. Пример такой политики, с подавлениями только со сроком, в статье Реакция на findings. Менеджер следит не за отдельными находками, а за метрикой: сколько просрочено и сколько исключений без срока.

Офицер ИБ: как работать вместе

Офицер ИБ не блокирующая инстанция, а владелец риска со своей стороны. Что работает:

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

Что делать при инцидентеспросят на собеседовании

Инцидент безопасности отличается от обычной аварии тем, что важны доказательства и юридические часы. Порядок для команды:

  1. Сообщить офицеру ИБ сразу, ещё до выяснения масштаба. Решение «уведомлять ли регулятора» принимает не команда.
  2. Остановить утечку, не уничтожая следов: отозвать ключи, закрыть доступ, но сохранить логи, снимки, образы.
  3. Вести хронологию с точным временем: когда обнаружили, кто, что сделали. Она понадобится для уведомлений.
  4. Не обсуждать инцидент в общих чатах и не делать публичных заявлений без согласования.
  5. После стабилизации провести постмортем по обычным правилам, с офицером ИБ в составе.

Порядок для утечек в коде и логах разобран в PII и секреты.

Типичные ошибки

  • «Безопасность это отдел ИБ». Требования реализует разработка, и если задач нет в плане, их нет вообще.
  • Выбор облака или SaaS без вопроса о локализации. Через полгода переносить базу дороже, чем спросить в начале.
  • Тестовые среды с копией боевых данных. Это тоже обработка персональных данных, и утечка из теста ничем не лучше.
  • Пентест без окна на исправления. Отчёт лежит, повторная проверка проваливается.
  • Принятый риск без срока. Через год никто не помнит, почему уязвимость открыта.
  • Тишина при инциденте. Попытка сначала разобраться самим съедает часы, которых у оператора по закону нет.
Дополнительно: при первом чтении можно пропустить

Глубже: часы инцидента с персональными даннымирасширенноеспросят на собеседовании

Часть 3.1 статьи 21 152-ФЗ устанавливает два срока с момента выявления (оператором, Роскомнадзором или иным заинтересованным лицом) неправомерной или случайной передачи, распространения или доступа к персональным данным, повлёкших нарушение прав субъектов:

  • в течение 24 часов: уведомить уполномоченный орган (Роскомнадзор) об инциденте, предполагаемых причинах, предполагаемом вреде, принятых мерах и о контактном лице оператора;
  • в течение 72 часов: сообщить результаты внутреннего расследования и, при наличии, сведения о лицах, чьи действия стали причиной.

Для менеджера из этого следуют три вещи. Первая: 24 часа считаются от выявления, поэтому разработчик, который нашёл подозрительную выгрузку в пятницу вечером, должен сообщить сразу, а не в понедельник. Это правило стоит записать в регламент дежурства. Вторая: за сутки нужно ответить на вопросы «что утекло, сколько записей, через что», значит журналы доступа к данным должны существовать заранее. Третья: если данные обрабатывает подрядчик, его обязанность уведомить вас тоже должна быть в договоре, иначе ваши 24 часа начнутся, когда он сочтёт нужным.

Для субъектов КИИ параллельно действует обязанность незамедлительно сообщать об инциденте в ГосСОПКА по статье 9 187-ФЗ, это отдельный канал.

Глубже: как защищать бюджет на ИБрасширенное

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

  • Обязательное с датой. Ежегодный пентест, оценка соответствия раз в два года, уведомления по 152-ФЗ. Не обсуждается, обсуждается только способ.
  • Цена инцидента. Простой, штрафы, расходы на расследование и уведомление, отток клиентов. Посчитайте порядок величины для своего продукта вместе с юристом.
  • Стоимость позднего исправления. Перенос базы в Россию после запуска, переделка приёма карт после аудита эквайера стоят в разы больше, чем правильное решение на этапе дизайна.

Шаблон строки в бюджетной заявке: «что делаем, какое требование закрывает (ссылка на статью или пункт), что будет, если не сделать, сколько стоит, к какой дате». Такая заявка проходит быстрее, чем «нам нужно больше безопасности».

Коротко

  • Начните с карты режимов: 152-ФЗ, 187-ФЗ, требования Банка России, PCI DSS, ГОСТ Р 56939. Сверьте её с офицером ИБ.
  • 152-ФЗ: основание обработки и доказуемое согласие, локализация базы в России, уведомление Роскомнадзора до начала обработки, условия в договорах с подрядчиками.
  • Утечка персональных данных: 24 часа на первое уведомление, 72 часа на результаты расследования, отсчёт от выявления.
  • КИИ: субъект сам категорирует объекты, три категории, результаты в ФСТЭК за 10 дней, инциденты незамедлительно в ГосСОПКА.
  • Банки: уровень защиты по ГОСТ Р 57580.1 задаёт положение Банка России, ежегодный пентест и оценка соответствия раз в два года.
  • Менеджер отвечает за ёмкость, даты и политику сроков по уязвимостям; офицер ИБ за оценку риска; принятие риска только письменно и со сроком.

Что почитать дальше