Как согласовать доступ к маркетинговым данным со службой безопасности

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

Материал входит в раздел Сквозная аналитика: что это, как работает и зачем нужна бизнесу. Он объясняет, как связать расходы на рекламу, заявки, CRM, продажи и выручку. Это статья следующего уровня: какие доступы к маркетинговым данным нужны для такой системы и как согласовать их со службой безопасности.

Как желание обезопасить данные приводит к тому, что компании месяцами согласовывают проекты

1. Безопасность превыше всего

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

2. Риск более чем реален

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

3. Как это выглядит на практике

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

Любая инициатива, связанная с доступом к данным, попадает в зону интересов службы безопасности. А там до полугода согласований, анкет, протоколов, проверок и юридических итераций. И это если повезёт.

Почему? Ответ один: «Не дай бог данные утекут»
Мотивы СБ понятны: суть их работы в предотвращении инцидентов. Если случится утечка, виноваты будут они. Поэтому логика простая: лучше вообще не открывать доступ, чем разбираться, какие данные давать можно, а какие нельзя. Руки продакта остаются связанными по локоть.

Остаётся одно решение: «сделаем сами»
А как иначе, если любая интеграция с подрядчиками требует долгих согласований: службы безопасности, юристов, ИБ-комитетов, внутреннего аудита. Чтобы не застревать в этих процессах, команды выбирают работать своими силами, даже если это медленнее и дороже.

Есть и другие, не менее важные причины:

• боимся нарушить закон
• боимся отдать подрядчику лишнее
• боимся потерять премию или получить выговор
• боимся, что «нас потом спросят»

В некоторых проектах третьим лицам действительно нужен доступ к внутренним данным, иначе просто не собрать полную картину. Но это не означает, что любой доступ автоматически ведёт к утечке.

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

Миф №1. Все данные – чувствительные

Это не так. Закон 152-ФЗ выделяет разные категории персональных данных, и только часть из них действительно считается чувствительной.

Чувствительными в узком юридическом смысле считаются

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

Есть и другие персональные данные

Такие как ФИО, email, номер телефона. Они тоже под защитой, но во многих задачах аналитики они не требуются. Достаточно обезличенных технических идентификаторов – например, client_id из Яндекс.Метрики.

Также в компаниях есть внутренние списки ограниченных данных

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

Важно понимать

Данные, формирующиеся внутри компании (first-party data) – это одно. Но часто СБ действует с такой осторожностью и гиперопекой, что мешает бизнесу развиваться и зарабатывать. И даже такой подход не гарантирует 100% защиты от взломов и утечек – вспомним пример «Аэрофлота».

Вступайте в дискуссию

Практика показывает: вы в силах доказать, что можно полезно и безопасно использовать данные, которые возникают во внешних системах (Яндекс.Метрика, AppsFlyer). С внутренними это сложнее, но тоже реально.

Миф №2. Если дать доступ подрядчику, данные утекут

Риск утечки связан не с фактом сотрудничества, а с тем, насколько корректно настроен доступ.

• Мы не запрашиваем доступ к хранилищам и серверам.
• Интеграция идёт через внешние системы, где вы сами настраиваете уровень доступа.
• На выходе – отчёты на основе агрегированных данных, а не сырого массива из внутренней инфраструктуры.

Как делают крупнейшие компании

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

📌 Как устроен безопасный обмен данными через внешний контур

Миф №3. Чтобы сохранить безопасность, надо всё делать внутри – самим

Одна организация не может быть экспертной во всём.

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

Абсолютная закрытость = максимум защиты,
но и серьёзный тормоз для бизнеса.

Когда к вам не могут подключиться профи по A/B-тестам, рекламе или аналитике, приходится делать всё своими силами. Это снижает и скорость, и качество продукта.

Вывод

Разделяйте чувствительные и обезличенные данные и стройте понятные правила доступа. Это позволяет:

• подключать внешние команды там, где это безопасно и эффективно
• сокращать сроки согласований
• развивать бизнес без лишних рисков

Памятка: как согласовать доступ к данным

Если вы запускаете проект с внешними командами, важно говорить с СБ на одном языке. Ниже пример корректного и понятного набора документов от команды продукта.

Цель запроса

Получить финальное одобрение от службы безопасности на предоставление доступа к данным в согласованном формате и объёме.

Рекомендуемый список предварительных согласований

• Директор – экономическое обоснование утверждено (ФИО, должность).
• Юридическая служба – подтверждено, что передача персональных и чувствительных данных не требуется; согласованы формулировки по конфиденциальности.
• ИТ-служба – согласованы архитектура обмена, источники, каналы передачи, техническая схема и обоснование (см. Приложение 1).
• Служба ИБ – предварительная оценка рисков проведена, замечаний нет.

Проектная справка

• Экономическое обоснование есть: согласованы эффект, бюджет, сроки и метрики.
• Оценка рисков ИБ проведена.
• Передача персональных или чувствительных данных не требуется.

Данные из систем web и app-аналитики (Яндекс.Метрика и др.)

• Технические ID сессий / устройств (токены)
• UTM-метки: источник, канал, кампания
• Тип устройства, ОС, браузер
• Геоданные (город, регион)
• Дата и время визитов

Из рекламных кабинетов

• ID кампаний, групп, объявлений
• Эффективность: показы, клики, расходы, конверсии (агрегировано)
• Таргетинг: агрегированные срезы, без профилей

Из CRM / офлайн-источников (если нужно)

• Агрегированные данные по «канал / кампания / дата»: лиды, заказы, выручка, маржа

Полностью исключаются

• ФИО, телефоны, e-mail, адреса
• Платёжные реквизиты, номера договоров
• Специальные и биометрические данные

Рекомендуемый перечень требований

1. Персональные данные по 152-ФЗ – не требуются
2. Специальные / биометрические данные – не используются
3. Используются только данные, не позволяющие идентифицировать пользователя
4. Финансовая информация – в агрегированном виде
5. Подрядчик не получает доступ к внутренним базам
6. Доступ предоставляется на ограниченный срок и по регламенту
7. Принцип минимально необходимого доступа
8. Работа с данными – строго по ТЗ
9. Не передаём пароли, ключи, доступ к инфраструктуре
10. Нет долговременного хранения – только временный кэш
11. Запрет передачи данных третьим лицам
12. Подписано NDA / соглашение о конфиденциальности

Финальное напутствие

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