Статья 19 152-ФЗ обязывает оператора принимать правовые, организационные и технические меры для защиты персональных данных от неправомерного доступа, копирования, распространения и уничтожения. Конкретный перечень мер в самом законе не написан — он определяется уровнем защищённости системы по постановлению Правительства № 1119 и составом мер по приказу ФСТЭК России № 21.
Именно на этой статье ломается большинство компаний, которые «привели документы в порядок». Политика обработки персональных данных, согласия и уведомление в реестре операторов закрывают части 2, 3 и 10 статьи 13.11 КоАП — составы на сотни тысяч рублей. Статья 19 закрывает другое: реальную возможность добраться до данных. Когда она не выполнена, это выясняется в момент утечки, а цена вопроса — от 3 до 15 млн ₽ за инцидент.
Что требует статья 19 дословно
Норма формулируется через результат, а не через список продуктов. Оператор обязан принимать меры, «необходимые и достаточные» для обеспечения выполнения обязанностей по закону, в том числе защищать данные от неправомерного или случайного доступа, уничтожения, изменения, блокирования, копирования, предоставления, распространения. Закон отдельно называет:
- определение угроз безопасности при обработке в информационных системах;
- применение организационных и технических мер, необходимых для выполнения требований к защите, установленных Правительством РФ;
- оценку эффективности принимаемых мер до ввода системы в эксплуатацию;
- учёт машинных носителей, обнаружение фактов несанкционированного доступа и принятие мер по их устранению;
- восстановление данных, изменённых или уничтоженных из-за несанкционированного доступа;
- установление правил доступа к данным и контроль принимаемых мер.
«Обнаружение фактов несанкционированного доступа» и «контроль принимаемых мер» — это процессы, а не разовые действия. Компания, которая настроила защиту при запуске сайта в 2021 году и с тех пор ничего не проверяла, формально не выполняет статью 19, даже если тогда всё было сделано правильно.
Как «достаточные меры» превращаются в конкретику
Цепочка нормативки выглядит так: 152-ФЗ задаёт обязанность → постановление № 1119 определяет, какой у вашей системы уровень защищённости → приказ ФСТЭК № 21 перечисляет, какие меры для этого уровня нужны.
| Документ | Что определяет | Что из него следует для сайта |
|---|---|---|
| 152-ФЗ, ст. 19 | Обязанность защищать и контролировать | Нужны меры и регулярная проверка их работы |
| ПП РФ № 1119 | Уровни защищённости УЗ-1…УЗ-4 по типу данных, типу угроз и числу субъектов | Клиника с данными о здоровье и интернет-магазин с именами и телефонами — разные уровни |
| Приказ ФСТЭК № 21 | Состав и содержание мер для каждого уровня | Идентификация и аутентификация, разграничение доступа, регистрация событий, контроль уязвимостей, защита среды |
| Приказ ФСБ № 378 | Требования при использовании криптографии | Актуально, если применяются сертифицированные СКЗИ |
Уровень защищённости определяется сочетанием факторов: категория данных (специальные, биометрические, иные, общедоступные), актуальный тип угроз и количество субъектов — больше или меньше 100 тысяч. Для типичного коммерческого сайта с обычными данными и менее чем 100 тысячами клиентов это обычно УЗ-3 или УЗ-4, что не отменяет базового набора мер.
Что из требований видно прямо на сайте
Часть мер по приказу № 21 проверяется только изнутри — по документам, настройкам серверов и правам доступа. Но существенная часть наблюдаема снаружи, и именно её первой видит и регулятор, и атакующий.
| Мера из приказа № 21 | Как выглядит нарушение на сайте | Проверяется снаружи |
|---|---|---|
| Идентификация и аутентификация субъектов доступа | Админ-панель доступна по прямому адресу без ограничений, дефолтные учётные записи | Да |
| Управление доступом | Смена идентификатора в адресе показывает чужую запись (IDOR) | Да, при наличии тестового доступа |
| Защита среды виртуализации и системы | Устаревшая CMS и компоненты с известными уязвимостями | Да |
| Защита информации при передаче по каналам связи | Формы с персональными данными без HTTPS, отсутствие HSTS, смешанный контент | Да |
| Выявление и устранение уязвимостей | Инъекции в параметрах, XSS, доступные бэкапы и служебные файлы | Да |
| Регистрация событий безопасности | Логи не ведутся или хранятся сутки — инцидент невозможно расследовать | Нет, только изнутри |
| Обнаружение вторжений | Нет мониторинга, об утечке узнают из публикации в Telegram | Нет, только изнутри |
Почему документы не закрывают статью 19
Разделение простое: документы описывают, как вы намерены обращаться с данными. Статья 19 требует, чтобы намерение было подкреплено техникой. Проверка этого происходит в один из двух моментов — при плановом наблюдении регулятора или в день утечки.
Отсюда практический вывод, который редко произносят вслух: компания с идеальными документами и уязвимым сайтом рискует в десятки раз больше, чем компания с неидеальными документами и защищённым сайтом. Подробнее о том, как считается верхний диапазон — в разборе оборотных штрафов за утечку персональных данных.
Как подтвердить выполнение статьи 19
Регулятор оценивает не ваши намерения, а следы деятельности. Минимальный набор артефактов, который стоит иметь:
- Приказ о назначении ответственного за организацию обработки персональных данных.
- Положение о защите персональных данных и перечень обрабатываемых данных с целями обработки.
- Определение уровня защищённости и модель угроз для вашей системы.
- Отчёты о проверках защищённости с датами — они доказывают, что контроль мер реально ведётся, а не заявлен на бумаге.
- Журнал инцидентов и регламент реагирования с указанием, кто уведомляет Роскомнадзор в первые 24 часа.
- Подтверждения устранения найденных недостатков: тикеты, даты релизов, повторные проверки.
Один аудит — это снимок состояния. Серия аудитов с интервалом — это доказательство процесса контроля, которого требует статья 19. Разница принципиальна: в первом случае у вас есть документ, во втором — история должной осмотрительности.