# Утечка персональных данных: что делать в первые 72 часа, шаг за шагом

Sursa / Источник: https://ongdpr.md/ru/blog/utechka-dannyh-pervye-72-chasa

## Отсчёт начинается с момента, когда вы узнали, а не когда всё случилось

Это та деталь, которая меняет всю остальную процедуру, поэтому ставим её первой. Ст. 33 ч. (1) привязывает срок в 72 часа к **дате, когда оператор узнал** о нарушении безопасности персональных данных, а не к дате самого инцидента.

На практике: если базу скопировали в марте, а вы узнали об этом в июле, 72 часа начинаются в июле. Вы не просрочили срок на четыре месяца. Но у вас есть отдельная и вполне реальная проблема — ст. 32 требует мер, включающих способность обнаружить инцидент и восстановиться после него.

И обратное, что важнее: «узнал» не означает «полностью разобрался». Нельзя откладывать запуск часов до конца расследования. Ст. 33 ч. (4) написана ровно для ситуации, когда вы ещё не всё знаете: информацию можно предоставлять **поэтапно**, без необоснованных задержек. Уведомляете с тем, что есть, и дополняете по мере выяснения.

## Что считается утечкой и почему важны последствия для человека

Нарушение безопасности персональных данных охватывает пять форм, и четыре из них не предполагают никакого злоумышленника:

- **уничтожение** данных (стёртый сервер, повреждённая резервная копия);
- **потеря** (ноутбук, флешка, бумажная папка);
- **несанкционированное изменение** (данные испорчены неудачным импортом);
- **несанкционированное раскрытие** (письмо ушло не тем получателям);
- **несанкционированный доступ** (скомпрометированный аккаунт, открытая наружу база).

Типичная ошибка — считать, что утечка это обязательно «нас взломали». В небольшой молдавской компании самые частые случаи бытовые: Excel с клиентами, отправленный по ошибке; почтовый ящик без второго фактора; уволившийся сотрудник, у которого не закрыли доступы.

Руководство CNPDCP формулирует ставку со стороны человека, а не компании. Утечка может привести к **краже личности, мошенничеству, финансовым потерям или ущербу репутации** субъекта персональных данных. Эти четыре последствия и есть та сетка, по которой вы оцениваете риск: вопрос не «насколько плохо это выглядит для нас», а «что конкретно может произойти с человеком, чьи данные ушли».

## Хронология первых 72 часов

Таблица ниже — это процедура, записанная как расписание. Правая колонка и есть то, что имеет значение при проверке: каждый шаг должен оставить документ с датой.

| Интервал | Что делаете | Кто | Статья | Что остаётся на бумаге |
|---|---|---|---|---|
| **Час 0** — обнаружение | Кто-то заметил и сообщил: клиент, сотрудник, поставщик, система мониторинга. Фиксируете точную дату, время и кто сообщил. С этой минуты идёт срок. | Тот, кто обнаружил → ответственный внутри компании | ст. 33 ч. (1) | Первая строка в реестре утечек: дата, время, источник сообщения |
| **Первые 4 часа** — остановить кровотечение | Изолируете затронутую систему, отзываете сессии, меняете учётные данные и API-ключи, блокируете скомпрометированные аккаунты. **Сохраняете логи до того, как их перезапишет ротация.** Ничего не удаляете и не «прибираете». | IT или хостинг-провайдер | ст. 32 п. b)–c) | Список действий по изоляции с временем каждого; копия логов отдельно |
| **4–24 ч** — установить факты | Три вопроса: какие категории данных, сколько субъектов персональных данных, сколько записей. Приблизительно — достаточно: ст. 33 ч. (3) п. a) прямо требует «приблизительное количество». | Ответственный + IT | ст. 33 ч. (3) п. a) | Служебная записка с категориями данных, числом людей и записей |
| **24–48 ч** — оценка риска и решение | Применяете дерево решений ниже: есть ли риск и является ли он высоким. Решение оформляется письменно с обоснованием, каким бы оно ни было. | Руководство + DPO, если он есть | ст. 33 ч. (1), ст. 34 ч. (1) | Подписанная и датированная оценка риска с решением уведомлять или нет |
| **До 72 ч** — уведомление CNPDCP | Если риск есть, отправляете уведомление с четырьмя элементами из ст. 33 ч. (3). При просрочке к нему прилагается **мотивированное объяснение задержки**. | Оператор | ст. 33 ч. (1) и (3) | Отправленное уведомление с датой и временем отправки |
| **После 72 ч** — информирование и закрытие | При высоком риске информируете людей без необоснованных задержек. Досылаете дополнения поэтапно. Закрываете случай в реестре. | Оператор | ст. 34 ч. (1), ст. 33 ч. (4)–(5) | Текст информирования и канал; отправленные дополнения; закрытая карточка |

Обратите внимание, где сосредоточено усилие: больше половины хронологии — это расследование и решение, а не написание текста. Компании, которые не укладываются в срок, спотыкаются почти всегда на интервале 4–24 ч, потому что у них нет логов, из которых можно узнать, что произошло.

## Два порога, а не один. Дерево решений

Самая дорогая путаница в этой теме — считать, что ст. 33 и ст. 34 это одно и то же, сделанное дважды. Это не так.

**Ст. 33 — уведомление CNPDCP.** Без необоснованных задержек и, по возможности, не позднее 72 часов с момента, когда оператор узнал, **за исключением** случая, когда нарушение вряд ли приведёт к риску для прав и свобод физических лиц. Порог: *риск*. Срок: 72 часа.

**Ст. 34 — информирование субъектов персональных данных.** Срабатывает только при **высоком риске** и выполняется «без необоснованных задержек». Порог выше. **Срок в 72 часа здесь не применяется** — не ищите его в ст. 34, его там нет.

| Есть риск для прав и свобод? | Риск высокий? | Уведомление CNPDCP (ст. 33) | Информирование людей (ст. 34) | Что остаётся задокументировано |
|---|---|---|---|---|
| Нет — вряд ли приведёт к риску | Нет | **Нет.** Исключение из ст. 33 ч. (1) | Нет | Оценка, из которой следует отсутствие риска, фактические обстоятельства, последствия, меры — ст. 33 ч. (5) |
| Да | Нет | **Да**, по возможности в пределах 72 ч | Нет | Уведомление + оценка, из которой следует, что риск не является высоким |
| Да | Да | **Да**, до 72 ч | **Да**, без необоснованных задержек, ясным и простым языком, с элементами ст. 33 ч. (3) п. b)–d) | Уведомление, текст информирования, канал и дата |
| Да | Да, но применяется ст. 34 ч. (3) | **Да**, до 72 ч | **Нет** индивидуально: данные были зашифрованы или иначе непонятны посторонним (п. a); приняты последующие меры, из-за которых высокий риск больше не может материализоваться (п. b); информирование потребовало бы несоразмерных усилий (п. c) — тогда делается **публичное информирование** или аналогичная столь же эффективная мера | Точная причина исключения с доказательством: конфигурация шифрования, последующие меры, расчёт усилий |

Три уточнения, которые обычно теряются.

**Первое: документирование не является опциональным ни в одной строке таблицы.** Ст. 33 ч. (5) требует от оператора хранить документы по **всем** случаям нарушения безопасности — фактические обстоятельства, последствия и меры по устранению — чтобы Центр мог проверить. В том числе по утечкам, о которых вы решили не уведомлять. Само решение не уведомлять и есть документ. Если его нет на бумаге, при проверке вы не сможете показать, что вы решали; вы сможете показать только, что не делали ничего.

**Второе:** ст. 34 ч. (4) говорит, что если оператор не проинформировал людей, Центр может потребовать это сделать либо решить, что одно из условий ч. (3) выполнено. Исключения остаются предметом последующей оценки органа.

**Третье:** первая строка — не лазейка. «Вряд ли приведёт к риску» — это вывод, к которому вы приходите после установления фактов, а не до него.

## Шаблон уведомления в CNPDCP (ст. 33 ч. 3)

Копируется в документ и заполняется в полях в квадратных скобках. Структура повторяет ровно четыре пункта ст. 33 ч. (3): соблюдаете порядок — получаете минимальное содержание, которого требует закон. Отправляется по каналу связи, указанному органом на datepersonale.md.

> **Уведомление о нарушении безопасности персональных данных**
> Кому: Национальный центр по защите персональных данных
> Оператор: [полное наименование], IDNO [номер], юридический адрес [адрес]
> Дата и время, когда оператор узнал о нарушении: [ДД.ММ.ГГГГ, время ЧЧ:ММ]
> Дата и время отправки уведомления: [ДД.ММ.ГГГГ, время ЧЧ:ММ]
>
> **a) Характер нарушения**
> Описание фактов: [что произошло, три-пять фраз, без интерпретаций]. Тип: [уничтожение / потеря / изменение / несанкционированное раскрытие / несанкционированный доступ]. Затронутая система: [приложение, база данных, почтовый ящик]. Категории субъектов персональных данных: [клиенты / сотрудники / кандидаты / пациенты]. Приблизительное количество субъектов: [цифра или «примерно N, уточняется»]. Категории данных: [имя, телефон, e-mail, адрес, платёжные данные, специальные категории данных]. Приблизительное количество записей: [цифра или «уточняется»].
>
> **b) Контактное лицо**
> [Фамилия и имя]. Должность: [ответственный за защиту данных (DPO) / иное назначенное контактное лицо]. Телефон: [номер]. E-mail: [адрес].
>
> **c) Вероятные последствия нарушения**
> [Что конкретно может произойти с человеком с учётом ушедших данных: кража личности, мошенничество, финансовые потери, ущерб репутации. Пишется только то, что правдоподобно для затронутых категорий данных.]
>
> **d) Принятые или предлагаемые меры**
> Уже принятые меры: [изоляция, отзыв сессий, смена учётных данных, восстановление из резервной копии — с указанием времени]. Меры по смягчению для людей: [информирование, сброс паролей, выделенный контакт]. Меры против повторения: [MFA, сегментация, шифрование, пересмотр прав доступа], срок: [дата].
>
> **Информация, которая будет предоставлена поэтапно**, согласно ст. 33 ч. (4): [чего сейчас не хватает и когда рассчитываете передать].
>
> **Объяснение задержки** — заполняется только если уведомление выходит за 72 часа, согласно ст. 33 ч. (1): [конкретная причина, а не общие формулировки].
>
> Подпись законного представителя, дата.

Один совет по составлению: пишите в прошедшем времени то, что уже сделали, и в будущем — то, что предстоит, с датами. Расплывчатое уведомление порождает дополнительные вопросы, а вопросы съедают ровно то время, которое нужно на устранение.

## Внутренний реестр утечек (ст. 33 ч. 5)

Второй артефакт, и именно его чаще всего нет. Это таблица, которая ведётся письменно, в том числе в электронной форме, и включает **все** утечки — в том числе те, о которых не уведомляли.

| № | Дата и время обнаружения | Как узнали | Описание фактов | Категории и приблизительное число субъектов | Категории и приблизительное число записей | Оценка риска | Уведомлён CNPDCP (да/нет + дата + причина, если нет) | Люди проинформированы (да/нет + дата) | Меры по устранению | Кто закрыл случай |
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 12.09.2026, 09:40 | Сообщил клиент | Рассылка отправлена так, что все адреса видны в поле «кому» | Клиенты, ~200 | Адреса e-mail, ~200 | Риск есть, но не высокий: только адреса | Да, 12.09.2026 | Нет | Отзыв письма; переход на скрытое поле; инструктаж команды | [имя], 15.09.2026 |
| 2 | 03.10.2026, 18:15 | Оповещение от хостинга | Несанкционированный доступ в админ-панель, активная сессия 40 минут | Клиенты, уточняется | Имя, телефон, адреса доставки, уточняется | В оценке, потенциально высокий | Да, 04.10.2026; дополнение поэтапно 09.10.2026 | Да, 06.10.2026, e-mail + объявление на сайте | Отзыв сессий, сброс паролей, обязательный MFA, пересмотр прав | [имя], 20.10.2026 |
| 3 | 21.10.2026, 11:00 | Внутреннее сообщение | Потерян ноутбук, диск полностью зашифрован, активных сессий нет | Сотрудники, 1 | Рабочие файлы, число не определено | Вряд ли приведёт к риску: данные непонятны посторонним | Нет — ст. 33 ч. (1) | Нет — ст. 34 ч. (3) п. a) | Удалённая блокировка, подтверждение шифрования, замена устройства | [имя], 22.10.2026 |

Третья строка — самая важная в таблице. Это утечка, о которой вы **не** уведомляли, и именно поэтому она обязана существовать на бумаге, с записанной рядом причиной. Без неё при проверке невозможно показать разницу между «я оценил и принял решение» и «я не заметил».

Реестр утечек — отдельный документ от [реестра операций по обработке](/ru/blog/reestr-operaciy-po-obrabotke), хотя оба ведутся внутри и предоставляются Центру по запросу.

## Что делать до утечки, чтобы не импровизировать в тот самый день

Ст. 32 — не список благих намерений, а источник трёх вещей, которые прямо определяют, как пройдут ваши 72 часа:

- **Псевдонимизация и шифрование** (п. a) — единственный механизм, способный превратить утечку с высоким риском в утечку без обязанности информировать каждого человека, через ст. 34 ч. (3) п. a). За шифрование платят один раз, а получают отдачу в день инцидента.
- **Способность своевременно восстановить** (п. c) после физического или технического инцидента. Резервная копия, которую вы ни разу не проверяли восстановлением, — это не способность, а надежда.
- **Регулярное тестирование и оценка эффективности мер** (п. d). Сюда входит и простое упражнение: заполните один раз «вхолостую» шаблон уведомления выше по выдуманному сценарию. За 20 минут вы узнаете, чего не знаете о собственных системах.

Дальше ст. 28. Поставщик, который обрабатывает данные от вашего имени — хостинг, CRM, бухгалтерия, маркетинг, — уведомляет **вас** без необоснованных задержек (ст. 33 ч. (2)), а договор с ним должен предусматривать, что он помогает вам соблюдать ст. 32–36, то есть в том числе ст. 33 и 34. Практическая проблема: «без необоснованных задержек» — это не число. Если поставщик сообщит через 60 часов, у вас останется 12. Впишите в договор конкретный срок в часах и канал оповещения. Это единственная оговорка, которая покупает вам время.

И наконец, ст. 87 ч. (2) п. h): при определении размера санкции CNPDCP учитывает **то, каким образом о нарушении стало известно Центру, в частности, уведомил ли оператор сам и в какой мере**. Самоуведомление — прямо названный в законе критерий. Рядом с ним п. c) оценивает действия по уменьшению ущерба, а п. d) — степень ответственности с учётом мер по ст. 25 и 32. Это совершенно разные позиции: уведомить самому, с задокументированной хронологией, или получить вопрос от органа после жалобы клиента. Как считается сам размер — в [статье о штрафах](/ru/blog/shtrafy-gdpr-moldova).

Закон вступает в силу 23 августа 2026 года, согласно ст. 89 ч. (1). Процедура выше — ровно тот документ, который невозможно написать в день, когда он вам понадобился.

## Источники

- [Официальное руководство CNPDCP по Закону 195/2024, PDF](https://datepersonale.md/wp-content/uploads/2026/04/GDPR.pdf) — источник четырёх возможных последствий для человека: кража личности, мошенничество, финансовые потери, ущерб репутации.
- [CNPDCP — datepersonale.md](https://datepersonale.md) — орган, которому направляется уведомление по ст. 33 и который может запросить документы по ст. 33 ч. (5).
- [Полный текст Закона 195/2024 на legis.md](https://www.legis.md/cautare/getResults?doc_id=144681&lang=ro) — точные формулировки ст. 32, 33 и 34.
- [EDPB, руководство по уведомлению о нарушениях безопасности данных](https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-92022-personal-data-breach-notification-under_en) — самый подробный европейский материал о моменте «узнал» и о поэтапном уведомлении. Руководства EDPB не имеют обязательной силы в Республике Молдова и используются как практический ориентир.
- [CNIL — уведомление об утечке персональных данных](https://www.cnil.fr/fr/notifier-une-violation-de-donnees-personnelles) — как ту же процедуру практически выстраивает европейский надзорный орган. Обязательной силы у нас не имеет.
- [Регламент ЕС 2016/679 на EUR-Lex](https://eur-lex.europa.eu/eli/reg/2016/679/oj) — для прямого сравнения с европейским текстом.

## Часто задаваемые вопросы

**С какого момента отсчитывают 72 часа?**
С даты, когда оператор узнал о нарушении, согласно ст. 33 ч. (1), а не с даты самого инцидента. Если в июле вы узнали об утечке, случившейся в марте, срок идёт с июля. Момент обнаружения нужно зафиксировать с датой и временем, потому что он является точкой отсчёта для всей остальной процедуры.

**А если 72 часа заканчиваются в субботу или в праздник?**
Срок выражен в часах, а не в рабочих днях, и закон не предусматривает приостановки на выходные. Если уложиться всё же не получается, ст. 33 ч. (1) оставляет один правильный путь: уведомить, как только сможете, и приложить мотивированное объяснение задержки.

**Что будет, если я не уложился в 72 часа?**
Уведомляете всё равно, и к уведомлению прилагается мотивированное объяснение задержки согласно ст. 33 ч. (1). Просроченный срок не отменяет обязанность и не даёт повода отказаться от уведомления. Объяснение должно быть конкретным — что именно помешало, — а не общей формулировкой.

**Обязательно ли уведомлять о каждой утечке?**
Нет. Ст. 33 ч. (1) предусматривает исключение для случая, когда нарушение вряд ли приведёт к риску для прав и свобод физических лиц. Но исключение касается только уведомления, а не документирования: ст. 33 ч. (5) требует хранить документы по всем случаям, включая те, о которых вы не уведомляли.

**У сотрудника украли ноутбук, диск был зашифрован. Это утечка?**
Да, потеря — одна из форм нарушения безопасности данных. Шифрование не отменяет сам факт, но меняет оценку риска и через ст. 34 ч. (3) п. a) может снять обязанность информировать людей, поскольку данные непонятны посторонним. В внутренний реестр случай всё равно вносится, с записанной рядом причиной решения.

**Бухгалтер сделал рассылку, и все 200 адресов клиентов оказались видны. Это считается?**
Да. Это несанкционированное раскрытие данных получателям, которые не имели права их видеть. Риск оценивается по тому, какие данные ушли: если это только адреса e-mail без контекста, риск есть, но высоким бывает редко; если сам список раскрывает что-то чувствительное, например пациентов клиники, картина меняется полностью.

**Базу взломали на стороне хостинга. Кто уведомляет — я или они?**
Вы, оператор. Поставщик, который обрабатывает данные от вашего имени, уведомляет вас без необоснованных задержек согласно ст. 33 ч. (2), а уведомление в Центр остаётся вашей обязанностью. Именно поэтому в договоре по ст. 28 должен быть прописан конкретный срок, в течение которого вас оповещают.

**Нужно ли сообщать самим клиентам?**
Только если нарушение может привести к высокому риску для их прав и свобод, согласно ст. 34 ч. (1), и тогда без необоснованных задержек, ясным и простым языком. Это другой порог, чем для уведомления CNPDCP, и срок в 72 часа к информированию людей не относится.

**Что писать, если я ещё не знаю, сколько человек затронуто?**
Пишете приблизительное число и отмечаете, что оно уточняется. Ст. 33 ч. (3) п. a) прямо требует приблизительное количество, а ст. 33 ч. (4) разрешает предоставлять информацию поэтапно, без необоснованных задержек. Неполное знание фактов не является основанием откладывать уведомление.

**Я решил не уведомлять. Нужно ли что-то записывать?**
Да, и это принципиально. Ст. 33 ч. (5) требует хранить документы по всем случаям нарушения безопасности — фактические обстоятельства, последствия и меры по устранению — как раз для того, чтобы Центр мог проверить обоснованность решения не уведомлять. Без документа корректно оценённая утечка выглядит точно так же, как проигнорированная.

**У меня нет ответственного за защиту данных. Кого указывать контактным лицом?**
Кого назначите. Ст. 33 ч. (3) п. b) требует имя и контактные данные ответственного за защиту данных (DPO) либо иного контактного лица, у которого можно получить дополнительную информацию. Выберите человека, который реально отвечает на звонки в дни после инцидента, и укажите его имя, телефон и e-mail.

**Сколько стоит неуведомление?**
Ст. 88 ч. (1) п. a) охватывает обязанности оператора и уполномоченного лица по ст. 25–39, то есть и ст. 33, и ст. 34: до 1 000 000 леев (MDL) или, в случае предприятия, до 1% от общего оборота за год, предшествующий санкции, причём берётся большая величина. Конкретный размер определяется по критериям ст. 87, среди которых и то, уведомил ли оператор сам. Подробнее — в [статье о двух уровнях штрафа](/ru/blog/skolko-stoit-shtraf-dva-urovnya).

## Проверьте, что видно снаружи

Процедура на случай утечки, договоры с поставщиками и внутренний реестр — это документы: снаружи их не видно, и доказываются они только датированными бумагами. Детерминированное сканирование закрывает вторую половину — то, что публично видно на сайте: от HTTPS и заголовков безопасности до реального поведения баннера cookie. Оно выдаёт технические констатации, не устанавливает факт нарушения закона и не заменяет описанную выше процедуру. Методика — в разделе [как работает сканирование](/ru/cum-functioneaza).

[**Проверить сайт бесплатно →**](/ru)