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

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

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 / соглашение о конфиденциальности

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

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