Утечка данных Fakturownia: кто отвечает и что делать бизнесу
В конце сентября 2026 года неизвестное лицо получило доступ к системам польского сервиса Fakturownia и скопировало значительную часть его базы данных. Инцидент затронул все учетные записи, но состав доступной злоумышленнику информации различается в зависимости от периода ее добавления и используемых функций.
Для бизнеса основная сложность заключается в том, что взломан был поставщик сервиса, а обязанности по GDPR могут возникнуть и у его клиентов. Если компания или индивидуальный предприниматель хранили в Fakturownia данные своих заказчиков, покупателей, подрядчиков либо сотрудников контрагентов, именно пользователь сервиса остается администратором этих данных.
При этом наиболее вероятные потери связаны не только со штрафами или требованиями о компенсации. Сведения о счетах, платежах, контрагентах и банковских реквизитах позволяют создавать убедительные письма с просьбой перечислить деньги на новый счет.
Разбираемся, какие данные оказались затронуты, нужно ли уведомлять польский регулятор UODO и как бизнесу действовать после утечки.
Что произошло с Fakturownia
По официальной информации Fakturownia, несанкционированный доступ продолжался с 27 сентября примерно с 03:20 до 28 сентября 2026 года примерно до 17:45.
Злоумышленник получил доступ к системе и скопировал данные на собственные серверы. Инцидент квалифицирован как нарушение конфиденциальности: информация не была просто просмотрена, а была выгружена из инфраструктуры сервиса.
После обнаружения атаки Fakturownia заблокировала доступ, заменила системные ключи и пароли, перенесла трафик на новые серверы и деактивировала скомпрометированные ключи. 29 сентября сервис сообщил об инциденте в UODO, CERT Polska и полицию, а 1 октября начал рассылать индивидуальные уведомления владельцам и пользователям аккаунтов.
Однако уведомление, поданное самой Fakturownia, не всегда освобождает ее клиентов от собственной оценки инцидента. Для применения GDPR необходимо определить, чьи именно данные хранились в конкретном аккаунте и какую роль выполняла каждая сторона.
Какие данные были скопированы
По информации сервиса, в выгруженной базе могли находиться:
- названия компаний, NIP, адреса и банковские реквизиты
- имена, фамилии, адреса электронной почты и телефоны пользователей
- хеши паролей, идентификаторы сессий, API-токены и ключи интеграций
- сведения о контрагентах, включая имена, адреса, NIP, телефоны, электронную почту и номера счетов
- суммы счетов, сведения об оплате и задолженности
- полное содержание части старых счетов
- наименования товаров и услуг из отдельных документов
- сведения о платежах, товарах, прайс-листах и складских операциях
- данные из выполненных импортов и экспортов
Для разных категорий установлены разные временные границы. Например, полное содержание было скопировано только для счетов, выставленных до 22 марта 2021 года, а позиции счетов — для документов до 6 июня 2019 года. При этом суммы, отдельные описательные поля и данные дополнительных сторон счета могли попасть в выгрузку и за более поздние периоды.
Сертификаты KSeF, данные для входа в интернет-банкинг и данные платежных карт, согласно официальному сообщению, затронуты не были. Fakturownia не хранит банковские логины и реквизиты карт. Конкретный состав информации необходимо проверять в панели инцидента внутри аккаунта. Общего сообщения сервиса недостаточно для индивидуальной оценки риска.
Почему за один инцидент отвечают разные стороны
Fakturownia выполняет разные роли в зависимости от категории информации. В отношении данных владельцев аккаунтов и пользователей сервиса Fakturownia самостоятельно определяет цели и способы обработки. Для этих данных она выступает администратором.
Иная ситуация возникает со сведениями, которые клиент внес в систему о собственных заказчиках, покупателях, подрядчиках или других лицах. Здесь администратором остается клиент, а Fakturownia выступает обработчиком, который хранит информацию по его поручению.
Поэтому компания, использующая сервис для выставления счетов, должна самостоятельно решить:
- относятся ли затронутые сведения к персональным данным
- какие физические лица пострадали
- какие последствия для них возможны
- нужно ли уведомить UODO
- требуется ли сообщить об утечке самим людям
Fakturownia может предоставить состав данных, хронологию и техническое описание инцидента. Но сервис не знает контекст отношений между клиентом и лицами, указанными в счетах, поэтому не может провести окончательную оценку риска вместо пользователя.
Какие сведения считаются персональными данными
Данные юридического лица сами по себе обычно не относятся к персональным данным. Название sp. z o.o., ее NIP, юридический адрес или общий адрес вида biuro@company.pl, как правило, не позволяют идентифицировать конкретного человека.
Однако в счетах и карточках контрагентов могут находиться имена сотрудников, индивидуальные адреса электронной почты, номера телефонов и личные банковские счета. Такая информация относится к физическим лицам и подпадает под GDPR.
Сведения об индивидуальном предпринимателе, зарегистрированном как JDG, также являются персональными данными, даже если часть из них опубликована в CEIDG. Публичность информации не меняет ее правовую природу.
При этом UODO указывает, что утечка только общедоступных сведений из CEIDG, например имени, названия бизнеса, NIP и официального адреса, обычно создает небольшой риск. Оценка может измениться, если вместе с ними раскрыты номера счетов, история платежей, сведения о покупках, контактные данные или другая информация, полезная для мошенничества и социальной инженерии.
Когда необходимо уведомить UODO
Статья 33 GDPR требует уведомить надзорный орган, если нарушение может создать риск для прав и свобод физических лиц. Уведомлять UODO необходимо не из-за самого масштаба атаки, а по результатам оценки конкретных данных. У двух пользователей Fakturownia последствия одного инцидента могут отличаться.
Например, компания, которая выставляла счета только юридическим лицам и хранила общедоступные корпоративные реквизиты, может прийти к выводу, что риск для физических лиц маловероятен.
Другая оценка потребуется клинике, психологу, интернет-магазину, B2C-сервису или специалисту, работавшему с физическими лицами. Высокое значение имеют номера PESEL, личные банковские счета, содержание приобретенных услуг, сведения о здоровье и другие данные, позволяющие совершить мошенничество либо узнать конфиденциальную информацию о человеке.
Даже если уведомление UODO не требуется, компания должна зафиксировать инцидент во внутреннем реестре нарушений. В записи следует указать, что произошло, какие данные были затронуты, какие риски рассматривались и почему принято решение не направлять уведомление.
С какого момента отсчитываются 72 часа
Уведомление подается без неоправданной задержки и, если возможно, не позднее 72 часов с момента, когда администратор узнал о нарушении с достаточной степенью уверенности.
Когда инцидент происходит у обработчика, таким моментом обычно становится получение информации от него. Для многих владельцев аккаунтов Fakturownia это письмо, отправленное 1 октября 2026 года. Однако момент может быть более ранним, если компания уже получила достаточно конкретную информацию из официального сообщения Fakturownia от 29 сентября или из другого надежного источника.
Поэтому в документации необходимо зафиксировать не только дату письма, но и момент, когда компания фактически получила достаточные сведения о возможном затрагивании данных из ее аккаунта. Если 72 часа уже прошли, это не отменяет обязанность подать уведомление. GDPR позволяет сделать это позднее, указав причины задержки. При недостатке информации можно направить первоначальное уведомление, а затем дополнить его по мере получения результатов анализа.
Позднее уведомление с обоснованием обычно предпочтительнее полного бездействия, если оценка показала наличие риска.
Нужно ли сообщать контрагентам
Уведомление UODO и сообщение пострадавшим лицам — две разные обязанности. Информировать человека по статье 34 GDPR необходимо, когда нарушение может создать высокий риск для его прав и свобод. Для обычного риска достаточно уведомления регулятора. При низком риске может не потребоваться ни одно из внешних сообщений, однако внутренняя документация остается обязательной.
Высокий риск может возникнуть, если утечка включает PESEL, сведения о здоровье, личные финансовые данные либо подробную информацию, позволяющую убедительно выдать себя за компанию, банк или контрагента.
Сообщение должно быть написано понятным языком и объяснять:
- что произошло
- какие категории данных затронуты
- какие последствия возможны
- что компания уже сделала
- какие действия рекомендуется предпринять человеку
- куда обращаться за дополнительной информацией
GDPR не требует во всех случаях отправлять бумажное письмо каждому контрагенту. Если индивидуальное уведомление потребовало бы несоразмерных усилий, его можно заменить публичным сообщением или сопоставимой мерой, которая столь же эффективно информирует пострадавших.
Но публикация объявления на сайте не является автоматической заменой индивидуальной рассылки. Компания должна обосновать, почему связаться с людьми напрямую невозможно или несоразмерно сложно, и почему выбранный способ позволит им действительно узнать об инциденте.
Главный практический риск — подмена банковских реквизитов
В распоряжении злоумышленника могли оказаться реальные суммы, даты платежей, названия товаров и услуг, сведения о задолженности и номера банковских счетов.
Эти данные позволяют создать письмо, которое выглядит как продолжение настоящей переписки. Получатель может увидеть правильное название компании, номер старого счета, привычную сумму и знакомое описание проекта. Отличаться будет только новый банковский счет. Для использования такой схемы злоумышленнику необязательно получать доступ к почте компании. Достаточно отправить бухгалтерии убедительное сообщение от имени поставщика с просьбой использовать обновленные реквизиты.
После инцидента бизнесу стоит установить отдельное правило: любая смена банковского счета подтверждается по независимому каналу. Звонить нужно по номеру, который был известен до получения письма, а не по контактам из сообщения с новыми реквизитами.
Счет польского плательщика НДС следует дополнительно проверять в белом списке налогоплательщиков VAT. Однако такая проверка не заменяет подтверждение у самого контрагента, особенно при работе с иностранными компаниями, физическими лицами и поставщиками, не зарегистрированными как плательщики НДС.
Для значительных переводов полезно ввести двойное согласование: один сотрудник проверяет документ и контрагента, другой отдельно подтверждает платеж.
Что необходимо сделать пользователям Fakturownia
Компаниям и предпринимателям, использовавшим сервис, следует последовательно выполнить следующие действия:
- Сохранить письмо Fakturownia и зафиксировать дату и время его получения.
- Открыть панель инцидента и определить категории, периоды и количество затронутых записей.
- Изменить пароль, проверить пользователей аккаунта и включить двухфакторную аутентификацию.
- Обновить API-ключи и проверить все подключенные интеграции.
- Убедиться, что в шаблонах счетов сохранены правильные банковские реквизиты.
- Определить, содержал ли аккаунт данные физических лиц, JDG, сотрудников контрагентов или потребителей.
- Отдельно найти PESEL, личные счета, сведения о здоровье и другую конфиденциальную информацию.
- Провести и документально оформить оценку риска.
- Уведомить UODO, если нарушение может создать риск для физических лиц.
- При высоком риске сообщить пострадавшим людям.
- Предупредить бухгалтерию и контрагентов о возможной подмене платежных реквизитов.
- Пересмотреть сроки хранения старых данных и удалить информацию, которая больше не нужна и не подлежит обязательному хранению.
Удалять старые счета автоматически только на основании даты документа нельзя. Необходимо учитывать налоговые сроки, незавершенные проверки, споры, сроки исковой давности и другие законные основания хранения. Но сохранение информации без определенной цели и установленного срока также противоречит принципу ограничения хранения.
Кто отвечает за причиненный ущерб
Статья 82 GDPR позволяет физическому лицу требовать компенсацию материального или нематериального ущерба от администратора или обработчика.
Администратор отвечает за нарушения, связанные с обработкой данных под его контролем. Обработчик отвечает, если нарушил обязанности, которые GDPR непосредственно возлагает на обработчиков, либо вышел за пределы законных инструкций администратора.
Если несколько сторон участвовали в одной обработке и несут ответственность за причиненный ущерб, пострадавший может потребовать полную компенсацию от любой из них. После выплаты стороны могут распределить расходы между собой в порядке регресса с учетом своей доли ответственности.
Это не означает, что клиент Fakturownia автоматически отвечает за все последствия взлома или что вся ответственность безусловно лежит на сервисе. Необходимо установить, какие нарушения допустила каждая сторона, были ли меры безопасности достаточными и как конкретное нарушение связано с ущербом.
Суд ЕС в деле C-340/21 разъяснил, что сам факт успешной кибератаки еще не доказывает недостаточность мер защиты. Однако администратор должен уметь подтвердить, что применял надлежащие технические и организационные меры.
Суд также признал, что обоснованный страх возможного неправомерного использования данных может представлять нематериальный ущерб. При этом пострадавший должен показать наличие реального вреда и связь с нарушением. Одного факта несоблюдения GDPR для присуждения компенсации недостаточно.
Ограничение ответственности в правилах сервиса
Регламент Fakturownia ограничивает ответственность сервиса перед клиентами, не являющимися потребителями, размером текущего абонемента и фактическим ущербом. Кроме того, соответствующее положение связывает договорную ответственность с виновным и умышленным действием поставщика.
Однако наличие такого условия не означает, что любые требования заранее исключены. Его применимость зависит от статуса клиента, обстоятельств нарушения, императивных норм польского права и основания конкретного требования.
Договорное ограничение также не лишает пострадавших физических лиц прав по статье 82 GDPR и не ограничивает полномочия UODO. Поэтому компаниям не стоит исходить из того, что все затраты на расследование, уведомления, юридическую помощь или мошеннический перевод удастся автоматически взыскать с поставщика сервиса.
Чему этот инцидент учит SaaS-компании
История Fakturownia важна не только для пользователей бухгалтерских сервисов. Она показывает риски любого SaaS-продукта, в котором клиенты хранят данные своих заказчиков.
После обнаружения инцидента обработчик должен без неоправданной задержки сообщить о нем администраторам и передать информацию, необходимую для оценки риска. Без этого клиенты не смогут выполнить собственные обязанности в течение 72 часов.
В DPA стоит определить канал экстренной связи, ответственных лиц, состав первоначального уведомления и порядок последующих обновлений. Полезно установить конкретный внутренний срок сообщения, который будет короче регуляторных 72 часов.
SaaS-провайдеру также необходимо заранее подготовить план реагирования: изоляцию инфраструктуры, замену ключей, сбор логов, работу с внешними специалистами, информирование клиентов и сохранение доказательств.
Отдельный вопрос — сроки хранения. Наличие налоговой обязанности хранить часть документов не означает, что все сведения должны бессрочно находиться в основной рабочей базе. Сервис может предусмотреть удаление ненужных данных, архивирование, отдельное шифрование старых периодов и понятные настройки сроков хранения.
Что следует проверить в договорах с SaaS-провайдерами
Инцидент показывает, что стандартного упоминания GDPR в пользовательском соглашении недостаточно. Компании стоит проверить:
- заключен ли DPA
- какие категории данных передаются сервису
- где физически хранятся данные
- привлекаются ли субобработчики
- в какой срок поставщик сообщает об инциденте
- какие сведения он обязан передать
- можно ли выгрузить и удалить данные
- как организовано резервное копирование
- предусмотрены ли аудит и подтверждение мер безопасности
- как распределяется договорная ответственность
Wolja Digital помогает компаниям оценить необходимость уведомления UODO, подготовить документацию по инциденту и сообщения для пострадавших лиц. Для SaaS-проектов мы разрабатываем DPA, политику реагирования на утечки и договорные механизмы, которые позволяют действовать по готовому плану, а не составлять его после обнаружения атаки.
Утечка у поставщика не всегда означает, что его клиент нарушил GDPR. Но после получения уведомления бездействовать уже нельзя: необходимо установить состав данных, оценить риск и документально зафиксировать принятое решение.