152-ФЗ для разработчиков: как внедрять персональные данные в сайты, React-приложения, backend и базы данных

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

152-ФЗ нужен не для того, чтобы на сайте была галочка ради галочки. Он отвечает на практический вопрос: что компания имеет право делать с данными живого человека, как объяснить это человеку, как доказать правомерность обработки, как защитить данные технически и что делать, когда пользователь просит удалить, уточнить или показать информацию о себе.

Если совсем коротко: персональные данные нельзя собирать “на всякий случай”, нельзя прятать согласие в подвал сайта, нельзя передавать все подряд в CRM, аналитику, рекламу и чат-виджеты без понимания целей и оснований, нельзя хранить бесконечно, нельзя строить frontend так, будто форма — это просто JSON в API. Форма, cookie banner, CRM-интеграция, webhook из Tilda, WordPress-плагин, React state, backend DTO, таблица в PostgreSQL, backup, лог и S3-бакет — все это части одной системы обработки персональных данных.

Содержание

• Что такое персональные данные и почему почти любой сайт их обрабатывает
• Зачем 152-ФЗ бизнесу, а не только юристам
• Базовая модель: субъект, оператор, обработчик, цель, состав данных, действие, срок
• Что нужно сделать до релиза
• Как реализовать на Tilda
• Как реализовать на WordPress
• Как реализовать в самописном React-приложении
• Что обязан делать backend
• Как проектировать базу данных
• Как получать согласия и хранить доказательства
• Что делать с cookie, аналитикой, рекламой и пикселями
• Что делать с инцидентами и утечками
• Как отвечать на запросы пользователя
• Как сравнить 152-ФЗ и GDPR
• Чеклисты для фронтенда, backend, DevOps, продукта и компании

1. Что такое персональные данные

В 152-ФЗ персональные данные определены широко: это любая информация, относящаяся к прямо или косвенно определенному или определяемому физическому лицу. Поэтому ошибка номер один — думать, что персональные данные начинаются только с паспорта.

В веб-продуктах персональными данными часто являются:

Главная инженерная мысль: персональные данные — это не “таблица users”. Это весь путь данных. Они появляются в браузере, localStorage, request body, server logs, очередях, аналитике, CRM, email-рассылке, S3, backup, BI, Excel-выгрузках, error tracking и скриншотах саппорта.

2. Зачем это нужно

152-ФЗ защищает человека от трех типовых проблем:

1. У него собрали больше данных, чем нужно.
2. Его данные начали использовать не для той цели, ради которой он их дал.
3. Его данные утекли, были проданы, оказались в рекламе, CRM, спаме, бэкапах или публичной выдаче.

Для бизнеса и команды разработки закон тоже полезен. Он заставляет ответить на вопросы, которые нужны нормальной архитектуре:

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

Если ответов нет, продукт обычно уже технически хрупкий: webhook-и без ретраев, CRM с лишними полями, логи с телефонами, продовые дампы на ноутбуках, общий аккаунт администратора, cookie banner для красоты, а не для управления обработкой.

3. Базовая схема обработки

Это хорошая ментальная модель для любой системы: лендинг на Tilda, WordPress-магазин, React SPA, корпоративный портал, LMS, CRM или мобильное приложение.

4. Кто есть кто: оператор, обработчик, субъект

Субъект персональных данных — физическое лицо, к которому относятся данные. Посетитель сайта, покупатель, кандидат, сотрудник, студент курса, подписчик рассылки.

Оператор — тот, кто определяет цели, состав данных и действия с ними. Если компания собирает заявки на сайте и решает, что с ними делать, она оператор.

Лицо, обрабатывающее данные по поручению оператора — подрядчик или сервис, который делает обработку по инструкции оператора. Например, хостинг, CRM, email-сервис, calltracking, разработчик, поддержка, облачный провайдер. В GDPR похожая роль называется processor.

Третья сторона — любой получатель данных, который не является внутренним сотрудником оператора. Передача данных в CRM, рассылку, платежку, рекламную систему, CDN, аналитику, службу доставки, Telegram-бота и подрядчику должна быть описана в карте обработки.

5. Минимальная карта обработки

Перед разработкой формы или фичи составьте таблицу. Без нее нельзя нормально написать ни политику, ни consent UI, ни backend DTO.

Если в таблице появляется поле “на всякий случай” — его надо убрать. Если появляется сервис “потом пригодится” — его нельзя подключать без цели и основания.

6. Какие документы обычно нужны

Минимальный публичный набор для сайта:

• политика обработки персональных данных;
• согласие на обработку персональных данных для форм, где основание именно согласие;
• отдельное согласие на рекламные/маркетинговые коммуникации;
• cookie notice или cookie policy, если используются cookies/пиксели/аналитика;
• форма или email для запросов субъекта;
• информация об операторе: юрлицо/ИП/ФИО, адрес, контакты;
• перечень целей, категорий данных, действий, сроков, получателей;
• сведения о трансграничной передаче, если есть зарубежные сервисы;
• сведения о мерах защиты в понятном объеме.

Внутренний набор для компании:

• приказ о назначении ответственного за обработку ПДн;
• реестр процессов обработки;
• локальные акты по каждой цели обработки;
• матрица доступов;
• регламент запросов субъектов;
• регламент удаления и обезличивания;
• регламент инцидентов;
• договоры/поручения с обработчиками;
• модель угроз и меры защиты для ИСПДн, если применимо;
• регламент работы с backup, логами, дампами и тестовыми средами.

7. Согласие: как получать и что хранить

Согласие должно быть свободным, конкретным, предметным, информированным, сознательным и однозначным. Практически это означает:

• не ставим чекбокс заранее;
• не объединяем “я согласен с договором”, “я согласен на обработку ПДн” и “я согласен на рекламу” в одну галочку;
• даем ссылку на конкретную версию политики/согласия;
• указываем цель обработки;
• не заставляем давать маркетинговое согласие для покупки товара;
• храним доказательство: кто, когда, где, на какую версию, с какого IP/user-agent, какой текст согласия, какой контекст формы.

Плохой вариант:

Нажимая кнопку, вы соглашаетесь со всем.

Лучше:

Нажимая “Отправить”, я даю согласие ООО “…” на обработку имени, телефона, email и текста сообщения для ответа на заявку. Политика обработки персональных данных: ссылка.

Для рекламы отдельная галочка:

Я согласен получать информационные и рекламные сообщения по email/телефону/мессенджерам. Я понимаю, что могу отозвать согласие в любой момент.

Для cookies отдельный слой:

Необходимые cookies работают для безопасности и работы сайта. Аналитические и рекламные cookies включаются только после согласия.

8. Последовательность получения согласия

Ключевой момент: согласие — не boolean в таблице users. Это событие. У события есть версия, текст, цель, источник, контекст, timestamp и доказательства.

9. Пример таблицы согласий

create table privacy_consent_events (
  id uuid primary key default gen_random_uuid(),
  subject_id uuid null,
  anonymous_id text null,
  email text null,
  phone text null,
  purpose text not null,
  consent_version text not null,
  consent_text_hash text not null,
  granted boolean not null,
  source text not null,
  form_id text null,
  ip inet null,
  user_agent text null,
  created_at timestamptz not null default now(),
  revoked_at timestamptz null
);

create index idx_consent_subject on privacy_consent_events(subject_id, purpose, created_at desc);
create index idx_consent_email on privacy_consent_events(email, purpose, created_at desc);

Почему consent_text_hash, а не только version? Потому что через год важно доказать, какой именно текст видел пользователь. Текст согласия можно хранить в отдельной таблице версий, а в событии хранить hash.

create table privacy_documents (
  id uuid primary key default gen_random_uuid(),
  slug text not null,
  version text not null,
  title text not null,
  body_markdown text not null,
  body_sha256 text not null,
  published_at timestamptz not null,
  archived_at timestamptz null,
  unique(slug, version)
);

10. Как делать на Tilda

Tilda часто используют как быстрый лендинг, но юридически это не “просто конструктор”. Если форма собирает имя, телефон, email или комментарий — оператором обычно остается владелец бизнеса, а Tilda и подключенные интеграции становятся частью цепочки обработки.

Что проверить:

1. В каждой форме есть понятный текст рядом с кнопкой или чекбоксом.
2. Чекбокс согласия не предустановлен.
3. Ссылка ведет на актуальную политику обработки ПДн.
4. Маркетинговая рассылка отделена от заявки/заказа.
5. В интеграциях нет лишней передачи: Telegram, email, CRM, Google Sheets, webhook, amoCRM, Bitrix24, платежка.
6. В уведомлениях на email/Telegram не отправляются лишние поля.
7. Если данные граждан РФ собираются на сайте, первичная запись/накопление/хранение должны быть в базе РФ. Для Tilda это нужно проверять по настройкам, договору и фактической схеме.
8. Если webhook уходит в ваш backend, backend должен логировать согласие и версию документа.

Пример текста под формой:

<label>
  <input type="checkbox" name="pdnConsent" required>
  Я даю согласие на обработку имени, телефона, email и сообщения
  для ответа на заявку. Я ознакомлен с политикой обработки персональных данных.
</label>

Если Tilda отправляет заявку напрямую в Telegram, плохо хранить там полную историю навсегда. Telegram-чат легко превращается в нерегламентированную базу ПДн. Лучше: форма -> backend/CRM -> уведомление без лишних персональных данных, например “новая заявка #123, откройте CRM”.

11. Как делать на WordPress

WordPress опасен не ядром, а количеством плагинов. Contact Form 7, Elementor forms, WooCommerce, комментарии, аналитика, reCAPTCHA, anti-spam, SMTP, CRM-интеграции, backup-плагины, security-плагины — каждый может обрабатывать ПДн.

Чеклист WordPress:

• обновить WordPress, тему и плагины;
• удалить неиспользуемые плагины;
• включить HTTPS;
• ограничить админ-доступы и включить 2FA;
• проверить, где хранятся submissions: база WP, email, CRM, Google Sheets;
• добавить отдельные чекбоксы в формы;
• не сохранять лишние поля формы;
• отключить публичную индексацию профилей/комментариев, если это не нужно;
• проверить cookies и внешние скрипты;
• настроить retention для заявок и заказов;
• ограничить выгрузки заказов и пользователей;
• не отправлять полные данные заказа в админские Telegram-уведомления;
• проверить backup: где лежит, кто имеет доступ, шифруется ли.

Пример для Contact Form 7:

[acceptance pdn-consent] Я даю согласие на обработку персональных данных для ответа на обращение. [/acceptance]

[acceptance marketing-consent optional] Я согласен получать рассылку и рекламные сообщения. [/acceptance]

Для WooCommerce согласие на обработку заказа обычно связано с договором/покупкой, но маркетинг все равно отдельно. Покупка товара не должна автоматически подписывать человека на рекламные письма.

12. Как делать в React-приложении

Во фронтенде 152-ФЗ проявляется в пяти местах:

1. Состав формы.
2. Текст согласия и ссылки на документы.
3. Состояние согласия.
4. Управление cookies/analytics/marketing SDK.
5. Передача consent evidence в backend.

Плохой frontend:

• собирает phone, email, name, company, role, utm, ip, comment, source, analyticsId, хотя для ответа нужен только email;
• отправляет событие в аналитику до согласия;
• держит персональные данные в localStorage;
• пишет форму в Sentry breadcrumb;
• логирует request body в console/log collector;
• показывает одну общую галку “согласен со всем”.

Хороший frontend:

• собирает минимум;
• разделяет обязательную обработку, рассылку, аналитику и рекламу;
• не включает необязательные SDK до согласия;
• отправляет на backend версию согласия;
• умеет показать актуальную политику;
• хранит consent state отдельно от бизнес-сущности;
• очищает черновики форм;
• не кладет ПДн в URL query params.

Пример модели согласия в TypeScript:

type ConsentPurpose = 'lead_processing' | 'newsletter' | 'analytics' | 'ads';

type ConsentDecision = {
  purpose: ConsentPurpose;
  granted: boolean;
  version: string;
  documentHash: string;
  decidedAt: string;
};

type LeadFormPayload = {
  name: string;
  email: string;
  message: string;
  consents: ConsentDecision[];
};

const REQUIRED_CONSENT_VERSION = 'pdn-lead-v2026-06-30';

function buildLeadPayload(form: HTMLFormElement): LeadFormPayload {
  const data = new FormData(form);
  return {
    name: String(data.get('name') ?? '').trim(),
    email: String(data.get('email') ?? '').trim(),
    message: String(data.get('message') ?? '').trim(),
    consents: [
      {
        purpose: 'lead_processing',
        granted: data.get('pdnConsent') === 'on',
        version: REQUIRED_CONSENT_VERSION,
        documentHash: 'sha256:replace-with-published-document-hash',
        decidedAt: new Date().toISOString(),
      },
      {
        purpose: 'newsletter',
        granted: data.get('newsletterConsent') === 'on',
        version: 'newsletter-v2026-06-30',
        documentHash: 'sha256:replace-with-newsletter-document-hash',
        decidedAt: new Date().toISOString(),
      },
    ],
  };
}

Пример управления аналитикой:

export function bootstrapAnalytics(consents: ConsentDecision[]) {
  const analyticsAllowed = consents.some(
    (item) => item.purpose === 'analytics' && item.granted,
  );

  if (!analyticsAllowed) {
    return;
  }

  import('./analytics').then(({ initAnalytics }) => {
    initAnalytics({ anonymizeIp: true, respectDoNotTrack: true });
  });
}

Не надо грузить рекламные пиксели “пока пользователь думает”. Согласие после загрузки пикселя уже не спасает, потому что передача могла произойти до клика.

13. Frontend checklist для компаний

Для каждого PR, где появляется форма, аналитика или интеграция, задавайте вопросы:

• Какие поля формы действительно нужны?
• Есть ли поле, которое можно удалить или сделать необязательным?
• Есть ли отдельное согласие на обязательную обработку?
• Есть ли отдельное согласие на рекламу/рассылку?
• Не стоит ли чекбокс заранее?
• Ссылка на политику ведет на актуальную версию?
• Версия согласия отправляется в API?
• Есть ли e2e-тест, что без обязательного согласия форма не отправляется?
• Не попадают ли данные в URL?
• Не пишутся ли данные в localStorage/sessionStorage без причины?
• Не отправляются ли данные в analytics до согласия?
• Не отправляет ли error monitoring содержимое формы?
• Не попадают ли ПДн в client logs?
• Можно ли удалить или отозвать согласие?

Пример e2e-сценария:

test('lead form requires personal data consent', async ({ page }) => {
  await page.goto('/contacts');
  await page.getByLabel('Имя').fill('Мария');
  await page.getByLabel('Email').fill('maria@example.com');
  await page.getByLabel('Сообщение').fill('Хочу консультацию');
  await page.getByRole('button', { name: 'Отправить' }).click();
  await expect(page.getByText('Нужно согласие на обработку персональных данных')).toBeVisible();
});

14. Что делать на backend

Backend не должен доверять frontend. Если frontend прислал pdnConsent: true, backend обязан проверить, что:

• для цели есть опубликованный документ;
• версия документа актуальна;
• обязательное согласие действительно есть;
• состав данных соответствует цели;
• пользователь может отозвать согласие;
• событие согласия сохранено;
• передача в CRM/рассылку происходит только при нужном основании;
• данные не пишутся в логи целиком;
• включены retention, удаление и аудит.

Пример API:

app.post('/api/leads', async (req, res) => {
  const payload = LeadSchema.parse(req.body);
  const leadConsent = payload.consents.find(
    (item) => item.purpose === 'lead_processing' && item.granted,
  );

  if (!leadConsent) {
    return res.status(422).json({ code: 'PDN_CONSENT_REQUIRED' });
  }

  const document = await privacyDocuments.findActive('pdn-lead', leadConsent.version);
  if (!document || document.bodySha256 !== leadConsent.documentHash) {
    return res.status(422).json({ code: 'PDN_CONSENT_VERSION_INVALID' });
  }

  const lead = await db.transaction(async (tx) => {
    const lead = await tx.leads.insert({
      name: payload.name,
      email: payload.email,
      message: payload.message,
      source: 'website',
    });

    await tx.privacyConsentEvents.insert({
      subjectId: lead.subjectId,
      email: payload.email,
      purpose: 'lead_processing',
      consentVersion: leadConsent.version,
      consentTextHash: leadConsent.documentHash,
      granted: true,
      source: 'website-lead-form',
      formId: 'lead-v3',
      ip: req.ip,
      userAgent: req.get('user-agent'),
    });

    return lead;
  });

  await crm.enqueueLeadCreated({ leadId: lead.id });
  return res.status(201).json({ id: lead.id });
});

Важная деталь: в очередь CRM лучше класть leadId, а не полный JSON с телефоном и email. Чем меньше копий ПДн гуляет между системами, тем проще контролировать удаление и инциденты.

15. Что делать с логами

Логи часто становятся второй, неуправляемой базой персональных данных. Особенно если используется request logging middleware.

Запрещенные или опасные практики:

• логировать req.body целиком;
• логировать Authorization header;
• логировать cookies;
• логировать query params с email/phone/token;
• отправлять form payload в Sentry breadcrumbs;
• хранить debug-логи месяцами;
• давать доступ к логам всей команде;
• выгружать продовые логи в ноутбуки и чаты.

Лучше:

const redactedFields = ['email', 'phone', 'name', 'message', 'password', 'token'];

function redact(value: unknown): unknown {
  if (Array.isArray(value)) return value.map(redact);
  if (!value || typeof value !== 'object') return value;

  return Object.fromEntries(
    Object.entries(value as Record<string, unknown>).map(([key, item]) => [
      key,
      redactedFields.includes(key.toLowerCase()) ? '[REDACTED]' : redact(item),
    ]),
  );
}

logger.info({
  route: req.route?.path,
  method: req.method,
  body: redact(req.body),
}, 'request accepted');

16. База данных: как проектировать хранение

Нормальная БД для ПДн должна отвечать на вопросы:

• где лежит профиль субъекта;
• какие бизнес-сущности связаны с субъектом;
• какие согласия есть;
• какие документы он видел;
• кто и когда смотрел/менял данные;
• когда данные нужно удалить;
• как удалить данные из основной БД, индексов, поисков, очередей, backup;
• какие поля надо шифровать или токенизировать;
• как выгружать данные субъекту.

Практические правила:

• не храните ПДн в jsonb без схемы, если по ним нужны удаление, аудит и retention;
• выносите чувствительные поля в отдельные таблицы или колонки с ограниченным доступом;
• не используйте email как primary key;
• не используйте телефон как idempotency key в публичном API;
• включайте created_at/updated_at/deleted_at;
• используйте soft delete только как промежуточное состояние, а не замену уничтожению;
• делайте отдельные таблицы для consent events и privacy requests;
• не копируйте ПДн в аналитические витрины без обезличивания;
• для тестовых сред используйте синтетические данные или маскирование;
• ограничивайте доступы через роли, least privilege и audit trail.

17. Retention: сколько хранить

152-ФЗ требует не хранить данные дольше, чем нужно для цели обработки, если срок не установлен законом, договором или другими обязанностями. Поэтому “храним всегда” — плохой ответ.

Пример retention matrix:

18. Удаление: не только DELETE FROM users

Удаление пользователя должно проходить по карте систем:

Удалить нужно:

• профиль;
• формы и заявки;
• CRM-карточки;
• подписки;
• рекламные аудитории;
• поисковые индексы;
• выгрузки;
• очереди;
• вложения;
• временные файлы;
• производные витрины;
• доступы;
• API tokens;
• документы, где удаление допустимо законом.

Иногда нельзя удалить все сразу: бухгалтерские документы, договоры, антифрод, безопасность, судебные требования. Тогда нужно ограничить обработку и объяснить субъекту основание продолжения хранения.

19. Инциденты и утечки

С 2025 года риски стали намного серьезнее. КоАП 13.11 содержит отдельные составы за утечки и неуведомление. Для крупных утечек и повторных нарушений суммы могут быть очень болезненными, включая оборотные штрафы.

Что считать инцидентом:

• база оказалась публичной;
• выгрузку отправили не тому получателю;
• сотрудник скачал лишние данные;
• подрядчик потерял доступы;
• в логах наружу ушли телефоны/email;
• backup лежит в открытом bucket;
• пользователь увидел чужой профиль;
• endpoint позволяет перебрать чужие заявки;
• аналитика получила email/телефон без основания;
• GitHub repository содержит dump или secrets.

По 152-ФЗ при факте неправомерной или случайной передачи, предоставления, распространения или доступа, повлекшем нарушение прав субъектов, оператор уведомляет уполномоченный орган: первично в течение 24 часов, затем по результатам внутреннего расследования в течение 72 часов.

Минимальный incident runbook:

1. Зафиксировать время обнаружения.
2. Остановить утечку: закрыть bucket, отозвать токен, выключить endpoint, заблокировать учетку.
3. Сохранить доказательства: logs, access trail, commit, request ids.
4. Оценить категории данных и количество субъектов.
5. Назначить владельца инцидента.
6. Уведомить РКН в 24 часа, если есть основание.
7. Провести расследование и обновить уведомление в 72 часа.
8. Уведомить субъектов, если это разумно и требуется по риску.
9. Выпустить fix и postmortem.
10. Обновить модель угроз, тесты, доступы и регламенты.

20. Трансграничная передача

Трансграничная передача — это не только “сервер за границей”. Это отправка данных зарубежному сервису: analytics, email provider, CRM, CDN logs, captcha, helpdesk, cloud storage, AI API, error monitoring, A/B testing, payment provider, video platform.

Что сделать:

• понять, какие данные уходят за пределы РФ;
• понять страну и получателя;
• проверить, входит ли страна в перечень с адекватной защитой;
• уведомить РКН о намерении трансграничной передачи, если требуется;
• описать передачу в политике;
• заключить договор/поручение с получателем;
• не передавать лишние поля;
• для граждан РФ обеспечить выполнение требований локализации первичного сбора и хранения в РФ;
• для GDPR-проектов проверить SCC, adequacy decision, transfer impact assessment.

Особенно аккуратно с AI API: если пользователь вводит персональные данные в форму, а backend отправляет их в LLM “для классификации”, это тоже передача и обработка. Часто лучше отправлять обезличенный текст или локально удалять email/phone до запроса.

21. Cookies, аналитика и реклама

Cookie banner не должен быть декорацией. Он должен управлять загрузкой необязательных скриптов.

Разделяйте категории:

Плохая практика: загрузить все скрипты в <head>, а потом показать баннер. Хорошая практика: загрузить только necessary layer, дождаться выбора, потом подключить analytics/ads.

const consent = await consentStore.get();

if (consent.analytics) {
  await import('./vendors/productAnalytics');
}

if (consent.ads) {
  await import('./vendors/adPixels');
}

22. Политика обработки: что должно быть понятно пользователю

Политика должна быть не полотном ради галочки, а читаемой документацией:

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

Версия документа — инженерно важная вещь. Без версии невозможно доказать, с чем согласился пользователь.

23. Пример структуры consent API

POST /api/privacy/consents
Content-Type: application/json

{
  "subjectId": "optional-user-id",
  "anonymousId": "browser-generated-id",
  "decisions": [
    {
      "purpose": "analytics",
      "granted": true,
      "version": "analytics-v2026-06-30",
      "documentHash": "sha256:..."
    },
    {
      "purpose": "ads",
      "granted": false,
      "version": "ads-v2026-06-30",
      "documentHash": "sha256:..."
    }
  ]
}

Backend возвращает текущее состояние:

{
  "subjectId": "...",
  "effectiveConsents": {
    "necessary": true,
    "analytics": true,
    "ads": false,
    "newsletter": false
  },
  "documents": [
    {
      "slug": "privacy-policy",
      "version": "2026-06-30",
      "url": "/legal/privacy-policy"
    }
  ]
}

24. GDPR: чем похож и чем отличается

GDPR и 152-ФЗ похожи в главном: нельзя бесконтрольно собирать данные, нужны понятные цели, правовое основание, минимизация, безопасность, права субъекта, accountability и контроль процессоров.

Но механика отличается.

Для европейского проекта дополнительно нужны:

• Record of Processing Activities;
• Data Processing Agreement с processors;
• Data Protection Impact Assessment для высоких рисков;
• механизм DSAR: access, rectification, erasure, restriction, portability, objection;
• lawful basis не только “consent везде”; часто contract или legitimate interests лучше;
• cookie consent до аналитики/рекламы;
• SCC/TIA для передачи за пределы EEA;
• privacy by design в архитектурных решениях;
• понятный язык privacy notice;
• механизм withdraw consent такой же простой, как give consent.

25. Почему нельзя просто копировать GDPR banner в российский проект

GDPR cookie banner часто решает только часть задачи. Для РФ вам все равно нужны:

• политика оператора на русском;
• информация об операторе;
• согласия под конкретные цели;
• учет локализации для граждан РФ;
• уведомление РКН об обработке, если нет исключения;
• отдельная логика трансграничной передачи;
• регламент инцидентов 24/72;
• проверка состава согласия по российскому праву;
• договоры с обработчиками/подрядчиками в российской терминологии.

Для международного продукта лучше делать privacy layer не “под страну”, а как policy engine:

26. Как внедрять в компании

Нормальный rollout:

1. Назначить владельца privacy engineering: не обязательно юриста, но кто-то должен держать карту систем.
2. Провести data inventory: формы, API, БД, CRM, analytics, logs, backups, BI.
3. Составить реестр целей обработки.
4. Разобрать основания: договор, закон, согласие, маркетинг, безопасность.
5. Убрать лишние поля и лишние передачи.
6. Обновить документы и consent texts.
7. Реализовать consent events в backend.
8. Настроить frontend gating для analytics/ads.
9. Настроить retention и удаление.
10. Проверить логи и error monitoring.
11. Проверить доступы и роли.
12. Проверить трансграничные сервисы.
13. Настроить incident runbook.
14. Добавить privacy review в Definition of Done.
15. Раз в квартал пересматривать карту обработки.

27. Definition of Done для фичи с ПДн

Фича не готова, пока:

• есть описание цели обработки;
• известен состав данных;
• есть правовое основание;
• обновлена политика/согласие;
• frontend показывает нужный consent UI;
• backend валидирует согласие;
• согласие сохраняется как событие;
• данные не уходят в лишние интеграции;
• логи редактируются;
• есть retention;
• есть путь удаления/экспорта;
• доступы ограничены;
• тесты покрывают отсутствие согласия;
• security/privacy reviewer посмотрел PR.

28. Риски по слоям системы

29. Практический план для маленького сайта

Если у вас лендинг, Tilda или WordPress:

1. Выписать все формы.
2. Убрать лишние поля.
3. Написать политику обработки ПДн.
4. Добавить чекбокс согласия под каждую форму.
5. Отделить рассылку и рекламу.
6. Проверить, куда уходят заявки.
7. Отключить лишние пиксели.
8. Убедиться, что заявки не летят в личный Telegram с полным набором данных.
9. Настроить удаление старых заявок.
10. Подать уведомление РКН, если оно требуется.
11. Проверить хостинг и локализацию.
12. Создать email для запросов субъектов.

Минимальный антипаттерн для исправления прямо сегодня: форма “Имя, телефон, email, комментарий”, кнопка “Отправить”, никакого текста согласия, заявка улетает в Telegram, копия на Gmail, еще копия в Google Sheets, плюс Facebook/Google/Yandex/VK pixels в <head>. Это не архитектура, это неконтролируемая раздача данных.

30. Практический план для SaaS/React продукта

1. Сделать data map.
2. Ввести privacy document versions.
3. Ввести consent events.
4. Переписать формы на consent-aware компоненты.
5. Добавить consent provider в frontend.
6. Запретить analytics/ads до согласия.
7. Добавить backend validation.
8. Добавить privacy request API.
9. Добавить retention jobs.
10. Добавить data export.
11. Добавить delete/anonymize pipeline.
12. Добавить audit trail.
13. Добавить redaction middleware.
14. Проверить processors и DPAs.
15. Проверить cross-border flows.
16. Добавить incident drills.

31. Пример privacy request API

POST /api/privacy/requests
Authorization: Bearer <token>
Content-Type: application/json

{
  "type": "access",
  "comment": "Хочу получить копию данных обо мне"
}

Типы:

• access — показать, какие данные есть;
• rectification — исправить;
• erasure — удалить;
• restriction — ограничить обработку;
• withdraw_consent — отозвать согласие;
• objection — возразить против обработки;
• portability — выгрузить в машиночитаемом формате, если делаете GDPR.

DB:

create table privacy_requests (
  id uuid primary key default gen_random_uuid(),
  subject_id uuid not null references data_subjects(id),
  request_type text not null,
  status text not null default 'received',
  comment text null,
  received_at timestamptz not null default now(),
  due_at timestamptz not null,
  completed_at timestamptz null,
  response_summary text null
);

32. Что написать пользователю после формы

Плохое сообщение:

Успешно.

Лучше:

Заявка отправлена. Мы используем указанные вами имя, email и сообщение, чтобы ответить на обращение. Если захотите уточнить или удалить данные, напишите на privacy@example.com.

Это не только этично, но и снижает нагрузку на поддержку: человек понимает, что произошло.

33. Что делать с детьми, медициной, биометрией и специальными категориями

Если продукт касается детей, здоровья, биометрии, геолокации, финансовой уязвимости, HR-скоринга, образования несовершеннолетних или публичных профилей, не ограничивайтесь общим чеклистом.

Особая осторожность нужна для:

• фото/видео/голоса, если они используются для идентификации;
• медицинских данных;
• данных о политических взглядах, религии, интимной жизни;
• данных детей;
• автоматизированных решений с существенными последствиями;
• публичного распространения ПДн;
• open data и scraping;
• AI training на пользовательских данных.

Правило для инженера: если данные могут серьезно навредить человеку при утечке, относитесь к ним как к high risk даже до формальной юридической классификации.

34. Источники и нормативная база

• Федеральный закон № 152-ФЗ “О персональных данных”: https://www.consultant.ru/document/cons_doc_LAW_61801/
• 152-ФЗ, ст. 3: основные понятия: https://www.consultant.ru/document/cons_doc_LAW_61801/4f41fe599ce341751e4e34dc50a4b676674c1416/
• 152-ФЗ, ст. 5: принципы обработки: https://www.consultant.ru/document/cons_doc_LAW_61801/96fbc469f91f57235cc842a85e0516a99f23dc85/
• 152-ФЗ, ст. 6: условия обработки: https://www.consultant.ru/document/cons_doc_LAW_61801/315f051396c88f1e4f827ba3f2ae313d999a1873/
• 152-ФЗ, ст. 9: согласие: https://www.consultant.ru/document/cons_doc_LAW_61801/6c94959bc017ac80140621762d2ac59f6006b08c/
• 152-ФЗ, ст. 12: трансграничная передача: https://www.consultant.ru/document/cons_doc_LAW_61801/e4ebbe1780de623c7cf32a59ca82a7bb523a25dd/
• 152-ФЗ, ст. 18, 18.1, 19, 21, 22: обязанности оператора, меры, безопасность, инциденты, уведомления.
• КоАП РФ, ст. 13.11: нарушения законодательства о персональных данных: https://www.consultant.ru/document/cons_doc_LAW_34661/1f421640c6775ff67079ebde06a7d2f6d17b96db/
• Постановление Правительства РФ № 1119 о требованиях к защите ПДн в ИСПДн: https://www.consultant.ru/document/cons_doc_LAW_137356/
• Приказ ФСТЭК № 21 о составе и содержании организационных и технических мер: https://www.consultant.ru/document/cons_doc_LAW_146520/
• Форма уведомления РКН об обработке ПДн: https://pd.rkn.gov.ru/operators-registry/notification/form/
• GDPR Regulation (EU) 2016/679, официальный текст EUR-Lex: https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng
• GDPR Article 5, 6, 7, 25, 32, 33, 83: принципы, lawful basis, consent, privacy by design, security, breach notification, fines.

35. Финальный вывод

152-ФЗ нельзя внедрить только текстом политики. Его внедряют архитектурой: минимизацией полей, понятными согласиями, версионированием документов, consent events, backend validation, безопасной БД, redaction логов, retention, удалением, контролем интеграций и incident process.

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

• https://www.consultant.ru/document/cons_doc_LAW_61801/
• https://www.consultant.ru/document/cons_doc_LAW_34661/1f421640c6775ff67079ebde06a7d2f6d17b96db/
• https://pd.rkn.gov.ru/operators-registry/notification/form/
• https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng