ISO 27701: управление приватностью

1) Что такое ISO 27701 и зачем он iGaming-оператору

ISO 27701 — надстройка к ISO 27001 и 27002, расширяющая ISMS до PIMS (системы управления информацией о приватности).
Для iGaming: доказуемое соответствие требованиям приватности (GDPR/UK GDPR/ePrivacy и пр.), ускоренная работа с регуляторами/банками/партнерами KYC/PSP, снижение риска штрафов и упрощение вендор-менеджмента.

2) Область и контекст PIMS

• Роли и границы: в каких процессах вы — Controller, где — Processor; какие бренды/регионы/процессы входят в Scope.
• Категории данных: регистрация, платежи, KYC/AML/санкции, поведенческие события, RG-сигналы, саппорт, маркетинг/SDK.
• Правовые обязательства: местные законы о приватности, лицензионные условия, договоры с партнерами.

Результат: документ PIMS Scope & Context + карта заинтересованных сторон.

3) Основные роли и ответственности

4) Связка ISO 27701 ↔ ISO 27001

ISMS (27001/27002): база безопасности (активы, риски, контроли).
PIMS (27701): добавляет политику приватности, законность обработки, права субъектов, жизненный цикл данных, договорные и трансграничные механизмы.
SoA/Statement of Applicability: расширяется приватными контролями PIMS.

5) Реестр обработки (RoPA) и карта данных

Для каждого процесса: цель, правовое основание, категории субъектов/данных, срок хранения, получатели/субпроцессоры, географии, TOMs, DPIA-флаг.

yaml process: account_registration controller_role: controller purpose: account creation and contract execution lawful_basis: contract data_categories: [PII_basic, contact, device_fingerprint]
recipients: [psp, kyc_provider]
retention: P + 5y # storage policy locations: [EU, UK]
toms: [mTLS, encryption_at_rest, RBAC+ABAC, MFA, masking]
dpia_required: false

6) Законные основания и согласия (Lawful Basis & Consent)

Contract/Legal Obligation: платежи, KYC/AML, предотвращение мошенничества.
Legitimate Interest: базовая аналитика/безопасность (с оценкой интересов и opt-out, где требуется).
Consent: маркетинг, cookies/SDK для нестрого необходимых целей, определенные виды профилирования.
Специальные категории: только при четких основаниях и усиленных мерах.

CMP/управление согласиями: запись версии политики/баннеров, гранулярность по целям, доказуемость отзыва.

7) DPIA/PIA — оценка воздействия на приватность

Когда: новая технология, масштабная обработка, чувствительные данные, систематическое профилирование, трансграничность.
Содержимое: описание обработки, необходимость и пропорциональность, риски для прав субъектов, меры снижения.
Выход: решение (пойти/доработать/отклонить) + план CAPA и контроль дат.

8) Права субъектов данных (DSAR)

Права: доступ, исправление, удаление, ограничение, переносимость, возражение, отказ от профилирования/маркетинга.
SLA: подтверждение запроса быстро и исполнение в регламентный срок.
Поток исполнения: получение → верификация личности → сбор данных → ответ/исполнение → журнал.

Запрет на «слепые выгрузки»: только через витрины с маскированием и логами; ограничение малых выборок (privacy thresholds).

9) Минимизация, маскирование и ретеншн

Data Minimization: хранить только необходимое для целей; регулярно удалять/анонимизировать «мертвые» поля.
Маскирование/псевдонимизация: по умолчанию для PII; демаскировка — JIT + `purpose` + аудит.
Ретеншн-матрица: сроки хранения per процесс/категория, стоп-факторы (юридические), авто-удаление/архив.

10) Трансграничные передачи и субпроцессоры

Договорные механизмы: DPA, SCCs/IDTA, DTIA (оценка передачи).
Локация данных/ключей: где физически данные/ключи (KMS/HSM), политика BYOK/региональные ключи.
Реестр субпроцессоров: уведомление об изменениях, право возражения, уровень TOMs не ниже нашего.

11) Privacy by Design / by Default

На этапе проектирования: Data Protection Requirements в PRD, шаблон threat modeling с приватными угрозами.
В реализации: RLS/CLS, токенизация, шифрование, минимальные скопы API, telemetry без PII.
По умолчанию: выключены необязательные трекеры, отдельные ключи/неймспейсы per регион/тенант.

12) Логирование, доказуемость и аудит PIMS

Логи (WORM+подпись): `READ_PII`, `EXPORT_DATA`, `PII_UNMASK`, `CONSENT_UPDATE`, `DSAR_`, `BREACH_`.
Отчетность: статус RoPA, кампании DPIA, DSAR SLA/бэклог, ретеншн-удаления, вендорские изменения, нарушения/инциденты.
Аудит: ежегодно (или при изменениях), проверка Design/Operating Effectiveness приватных контролей.

13) Метрики (KPI/KRI) PIMS

• DSAR on-time ≥ 95%
• Актуальность RoPA ≥ 98%
• Покрытие DPIA по объектам риска = 100%
• Доля автоматических удалений по ретеншн ≥ 95%
• Уровень включенности CMP (записанные записи согласий) = 100%

• Доступ к PII без `purpose` = 0
• Несанкционированные экспорт/передача = 0
• Инциденты/утечки, уведомленные позже срока = 0
• Отсутствующие DPA/SCCs для активной передачи = 0

14) Интеграция с существующими контролями

IGA/RBAC/ABAC/JIT/PAM: минимизация прав и контекстные условия доступа.
Политика логов и аудиторские журналы: доказуемость действий с PII.
TPRM и контракты: DPA/SCCs/DTIA, права аудита, SLA уведомлений ≤ 72 ч.
ISO 27001/ISMS: общая риск-модель, SoA и внутренние аудиты.
Инциденты и утечки: playbook breach, совместные war-room с вендорами.

15) Шаблоны артефактов (фрагменты)

15.1 Политика приватности (внутренняя выдержка)

yaml privacy_policy:
principles: [lawfulness, fairness, transparency, minimization, accuracy, storage_limitation, integrity_confidentiality, accountability]
roles: {controller: true, processor: true}
data_subject_rights: enabled consent_management: CMP_v2 retention_policy: matrix_ref:v1. 4

15.2 Политика демаскировки

yaml pii_unmask:
allowed_roles: [aml_officer, dpo, fraud_analyst_jit]
approvals: [data_owner, privacy]
ttl_minutes: 30 logging: [PII_UNMASK, READ_PII]

15.3 DSAR-процесс

yaml dsar:
intake_channels: [portal, email]
verification: kyc_level>=2 sla_days: 30 export_mechanism: curated_vitrines_only audit_events: [DSAR_OPEN, DSAR_VERIFY, DSAR_FULFILL, DSAR_CLOSE]

15.4 Ретеншн-матрица (фрагмент)

yaml retention:
registration_logs: {basis: legal, period: "P5Y"}
marketing_events: {basis: consent, period: "P12M", on_withdraw: "delete"}
kyc_documents:   {basis: legal, period: "P5Y", storage: "vault_encrypted"}

16) SOP (процедуры)

16.1 Обновление RoPA

1. Инициатор изменения (Product/Owner) → карточка процесса → Legal/Privacy ревью → Security TOMs → публикация и версия.

16.2 Проведение DPIA

1. Скрининг риска → шаблон DPIA → консультация DPO → CAPA → решение и контроль сроков.

16.3 DSAR

1. Принять → верифицировать → собрать и отфильтровать через витрины → ответ/исполнение → логирование и закрытие.

16.4 Вендоры/передачи

1. Due diligence → DPA/SCCs/DTIA → реестр субпроцессоров → мониторинг изменений → offboarding и подтверждение удаления.

17) RACI (укрупненно)

18) Дорожная карта внедрения (8–10 недель)

Недели 1–2: Scope/контекст, роли и RACI, инвентаризация процессов/данных, черновик RoPA и ретеншн-матрицы.
Недели 3–4: политика приватности, CMP/consent-флоу, DSAR-процесс, шаблоны DPIA, обновление DPA/SCCs/DTIA с вендорами.
Недели 5–6: внедрение TOMs (маскирование, RLS/CLS, JIT/PAM), витрины для DSAR, WORM-логи, отчетность KPI/KRI.
Недели 7–8: провести DPIA по high-risk, закрыть CAPA, внутренний аудит PIMS, Management Review (PIMS).
Недели 9–10: корректировки, запуск регулярной отчетности, подготовка к внешней оценке (при необходимости).

19) Частые ошибки и как их избежать

RoPA «для галочки»: привяжите каждую запись к целям, основаниям и ретеншн; держите живую версию.
DSAR через «сырые» БД: только через витрины/экспорты с маскированием и логами.
Нет DTIA при трансграничности: оформляйте заранее, фиксируйте локацию данных/ключей.
Маркетинговые SDK без CMP: запрет до включения CMP и договорных TOMs.
Отсутствие Pbd/PbD: включайте privacy-требования в PRD и Definition of Done.

20) Поддержание соответствия (Run PIMS)

Ежемесячно: отчеты KPI/KRI, аудит изменений RoPA, мониторинг субпроцессоров, DSAR SLA.
Ежеквартально: ревью ретеншн/удалений, тематические проверки (маркетинг, SDK, KYC).
Ежегодно: внутренний аудит PIMS, обновление контекста/рисков, обучение персонала, Management Review.

TL;DR

ISO 27701 = PIMS поверх ISMS: RoPA + законные основания/согласия + DPIA/DSAR + минимизация/ретеншн + трансграничность и субпроцессоры + доказуемые TOMs. Встраиваем в существующие RBAC/ABAC/JIT/логи и TPRM — и получаем управляемую, измеримую приватность, готовую к внутренним и внешним проверкам.