# Пакет решений по персональным данным и медиа

Дата подготовки: 16 июля 2026 года.

## Назначение

Пакет переводит восемь обязательных решений из `data/personal_data_readiness.json` в проверяемый рабочий процесс. Он помогает назначить роли, подготовить материалы для юридической проверки, зафиксировать утверждение и отдельно проконтролировать реализацию.

Пакет не является юридическим заключением и не выбирает решения за оператора, владельца портала или юриста.

Рабочий реестр: `data/personal_data_decision_packet.csv`.

Служебная панель: `/personal-data-decisions/`.

## Граница доверия

До реального решения поля `decision_owner_role`, `legal_reviewer_role`, `selected_option_code`, `decision_ref`, `legal_review_ref`, `approved_at` и `approved_by_role` остаются пустыми.

Нельзя:

- назначать реальные роли без договорённости;
- ставить `in_review` без фактической передачи материалов проверяющему;
- ставить `approved` без решения и юридической проверки;
- создавать фиктивные `decision:` или `evidence:` ссылки;
- загружать в публичный GitHub ФИО, контакты, сканы, подписи, закрытые ссылки и юридические документы;
- считать утверждение одного решения готовностью всего портала;
- включать сбор данных, согласий или автоматическую публикацию только изменением статуса в CSV.

## Статусы решения

- `pending` — решение ещё не передано в полноценную проверку;
- `in_review` — назначены обезличенные роли и материалы фактически переданы на проверку;
- `blocked` — продолжение невозможно, причина явно зафиксирована;
- `approved` — есть обезличенные ссылки на решение и юридическую проверку, дата и роль утвердившего.

## Статусы реализации

- `not_started` — реализация не начиналась;
- `blocked` — реализация заблокирована;
- `ready` — решение утверждено и может быть реализовано отдельным PR или организационным действием;
- `in_progress` — реализация фактически выполняется назначенной ролью;
- `completed` — есть обезличенная ссылка на доказательство реализации, дата и роль исполнителя.

Утверждение и реализация — разные этапы. `approved` не означает `completed`.

## Рекомендуемый порядок

Зависимости в CSV являются организационным маршрутом, а не самостоятельным юридическим выводом. Юридический проверяющий может предложить другой порядок, который затем фиксируется отдельным решением.

### 1. Назначение оператора

Нужно определить:

- кто отвечает за портал и принимает решения о целях и способах работы с данными;
- каков правовой статус этой стороны;
- кто вправе утверждать документы и отвечать на обращения;
- какие публичные реквизиты должны быть указаны после утверждения.

Подготовить для проверки:

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

### 2. Цели и категории данных

Нужно определить для каждого сценария:

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

Не объединять все сценарии одной формулировкой «для работы портала».

### 3. Основания обработки и распространения

Юридическому проверяющему передаётся матрица:

- сценарий;
- действие с данными;
- категория данных;
- субъект;
- публичность;
- предполагаемое основание;
- отдельные условия распространения;
- действие при отсутствии основания.

Редакционная переписка и наличие данных в социальной сети не должны автоматически считаться основанием распространения.

### 4. Форма согласия на распространение

Форма проектируется только после решений 1–3.

Нужно определить:

- конкретный перечень распространяемых данных;
- цели и способы публикации;
- информационные ресурсы;
- ограничения и запреты субъекта;
- срок действия;
- порядок отзыва;
- связь с закрытым оригиналом и обезличенным `publication_consent_ref`.

Черновик формы не публикуется как утверждённый документ.

### 5. Разрешение на фотографии, логотипы и медиа

Нужно разделить:

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

Один ответ «можно использовать фото» не должен автоматически закрывать все перечисленные вопросы.

### 6. Отзыв, исправление и удаление

Нужно утвердить:

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

До утверждения действует только временный редакционный маршрут через `/update-tos/` и `/contacts/`.

### 7. Закрытое хранилище доказательств

Нужно выбрать реальный закрытый контур и определить:

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

Сам публичный GitHub таким хранилищем не является.

### 8. Хранение, доступ и инциденты

Нужно утвердить:

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

## Как перевести решение в `in_review`

1. Назначить владельца решения в формате `role:...`.
2. Назначить юридического проверяющего в формате `role:...`.
3. Убедиться, что рекомендованные зависимости утверждены либо согласован другой порядок.
4. Фактически передать подготовленный пакет.
5. Только после передачи изменить статус на `in_review`.

## Как перевести решение в `approved`

Одновременно должны быть заполнены:

- `selected_option_code` в формате `option:...`;
- `decision_ref` в формате `decision:...`;
- `legal_review_ref` в формате `evidence:...`;
- `approved_at`;
- `approved_by_role` в формате `role:...`.

Те же статус и ссылки должны быть синхронно внесены в `data/personal_data_readiness.json`. Для назначения оператора дополнительно обновляется блок `operator`.

## Что происходит после утверждения

Для каждого решения отдельно определяется реализация:

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

Портал остаётся в `pre_legal_readiness`, пока не завершён весь обязательный набор и не выполнен отдельный контролируемый переход режима.

## Автоматическая защита

CI проверяет:

- ровно восемь решений и их порядок;
- синхронизацию с `personal_data_readiness.json`;
- рекомендованные зависимости;
- допустимые статусы и обезличенные роли;
- запрет ссылок утверждения до `approved`;
- обязательный комплект доказательств для `approved`;
- отдельный статус реализации;
- совпадение решения об операторе с блоком `operator`;
- отсутствие прямых контактов и URL в публичном CSV;
- сохранение режима `pre_legal_readiness` и выключенных публичных контролов.

Автоматический аудит подтверждает только целостность процесса. Он не заменяет юридическую проверку и не доказывает законность конкретного решения.