Оборотные штрафы за утечки начнутся с 10 тысяч пострадавших

Оборотные штрафы за утечки начнутся с 10 тысяч пострадавших

Оборотные штрафы за утечки начнутся с 10 тысяч пострадавших

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

О подвижках в работе над законопроектом о штрафах за утечки пишет сегодня РБК. Обсуждение началось еще в мае, после громких скандалов с Яндекс.Едой, Delivery Club и Гемотестом.

Обсуждалось, что штраф составит от 1% до 3% оборота. Однако крупные ИТ-компании просили смягчить формулировки документа. Как альтернативу они предлагали трехступенчатую систему наказания: предупреждение за первую утечку; крупный штраф — за вторую; при третьей утечке выплачивается оборотный штраф.

В середине июля Минцифры сообщало, что обсуждаемые предложения включают следующие:

  • штрафы будут применяться в два этапа: за первую утечку — фиксированный (размер зависит от объема данных), при повторной утечке станет применяться оборотный штраф. Будут установлены границы, “от” и “до” какого процента от выручки можно будет взыскать оборотный штраф;
  • будут учитываться смягчающие и отягчающие обстоятельства при определении размера штрафа. Вкладывалась ли компания в защиту информации или пыталась скрыть утечку;
  • будет определено, как устанавливать вину конкретной компании за утечку данных: как отличить, произошла ли новая утечка или мошенники выдают за нее данные из разных баз, слитых ранее;
  • рассматривалась возможность создания специального фонда, в который будут перечислять собранные штрафы и из которого станут выплачивать компенсации гражданам, пострадавшим от утечек.

Сейчас обсуждается, что оборотный штраф может грозить компаниям в том числе и за первую утечку, если она коснулась более 10 тыс. субъектов персональных данных.

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

Вопрос создания фонда для компенсации ущерба еще прорабатывается с отраслью. Участники обсуждения хотят создать такой механизм, чтобы этот “фонд не позволил откупиться от утечки”.

Еще один источник РБК на ИТ-рынке говорит, что обсуждение формулировок законопроекта продолжается и они еще могут поменяться. Например, ранее в ходе обсуждений звучали предложения ввести личную уголовную ответственность за утечки персональных данных, но “пока от этой идеи вроде отказались”.

Предварительные сроки предоставления документа — середина сентября.

“Ищем компромисс с бизнесом и отраслью. Минцифры выступает за ужесточение и усиление ответственности за утечки персональных данных. Но задача не в самих штрафах, дополнительная ответственность в виде оборотных штрафов побудит бизнес инвестировать в развитие инфраструктуры информационной безопасности и защиту персональных данных пользователей”, — говорят в министерстве.

Подпишитесь на новости

НКЦКИ потребовал срочно обновить PHP на объектах критической инфраструктуры

История PHP2Shell дошла до официальных указаний для российской критической инфраструктуры. Национальный координационный центр по компьютерным инцидентам, действующий при ФСБ России, предписал устранить уязвимости PHP.

Если быстро установить исправления не получается — рассмотреть ограничение внешнего доступа вплоть до отключения серверов.

О письме НКЦКИ от 22 октября сообщил РБК, получивший копию документа. Его подлинность редакции подтвердили три организации-получателя. Указания разосланы через ГосСОПКА.

Обращение касается владельцев объектов критической информационной инфраструктуры (в том числе госорганов, финансовых, энергетических, транспортных, медицинских организаций и операторов связи).

Одной установки патча недостаточно: получателям предписано проверить серверы антивирусом, изучить журналы на предмет следов взлома и сообщать о подозрительных инцидентах в дежурный центр ГосСОПКА.

Повод — CVE-2026-109618 и CVE-2026-109619. Разработчики закрыли их 21 октября в PHP 8.2.35, 8.3.36, 8.4.27 и 8.5.12. Проблема находится в интерпретаторе: обновление одной только CMS её не устраняет.

RSS: Новости на портале Anti-Malware.ru