Проверки доступа третьих сторон до запроса отдела закупок

Почему это превращается в проблему в последний момент

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

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

Отдел продаж часто добавляет давление невольно. Результат: представитель говорит потенциальному клиенту «да, мы ответим на вопросы по поставщикам и безопасности», ещё до того как кто‑нибудь проверит, что компания действительно может доказать.

Детали обычно лежат в четырёх разных местах. У продуктовой команды есть пометка про SDK. У опериций — документ по настройке. У юристов — подписанный контракт в глубине почты. У финансов — счёт. Каждая часть реальна, но никто не видел полной картины.

Маленькие команды чаще всего пропускают тихие инструменты. Кто‑то настраивает session replay, плагин поддержки или аккаунт для передачи файлов в загруженную неделю и никогда не добавляет это в общую запись. Через месяцы этот человек в отпуске или ушёл, и все начинают гадать.

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

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

Покупатели не хотят уверенной реплики в Slack. Им нужны ясные ответы: кто поставщик, какие данные он получает, куда эти данные идут дальше, как контролируется доступ и что происходит, если вы перестаёте пользоваться сервисом.

Что спрашивают покупатели

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

Они также хотят простое объяснение объёма доступа. Может ли поставщик читать только имена и почты? Может ли он хранить файлы, логи, тикеты поддержки или платёжные данные? Может ли он передавать данные в другой сервис? «Они занимаются аналитикой» — слишком расплывчато. Покупателям нужно знать, что именно поставщик может прочитать, что он хранит и что отправляет дальше.

Местоположение данных всплывает постоянно. Закупки и команды безопасности часто спрашивают, где хранится информация, в каком регионе и пересекает ли она границы. Если ваш продукт работает в ЕС, а инструмент логирования или поддержки отправляет данные в США — скажите об этом сразу. Явно описанное перемещение данных объяснить проще, чем скрытое.

Им важно и окончание отношений. Если контракт прекратится завтра, кто закроет аккаунт, экспортирует нужные данные, удалит остальное и подтвердит удаление? План выхода не обязан быть длинным. Он должен содержать имена, шаги, сроки и доказательства, что команда может это выполнить.

Бумажки по безопасности тоже значимы. Держите актуальные документы и контактные данные в одном месте. Когда покупатель просит SOC 2, DPA, сводку пентеста или контакт на случай инцидента, продажам не должно требоваться дни на поиск по старым письмам.

Рабочий реестр поставщиков должен включать:

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

Если вы можете ответить на эти пункты по каждому поставщику, дью‑дилижанс проходит быстрее и у закупок меньше причин останавливать сделку.

Перечислите всех поставщиков и внешних участников

Большинство команд думают, что знают, кто имеет доступ, пока не попытаются всё записать. Тогда всплывает инструмент поддержки, фрилансер со стейджинг‑логином, аналитический скрипт с прошлого года и общий диск с файлами клиентов.

Начните с сервисов, за которые команда платит ежемесячно, и людей вне компании, которые могут войти, просматривать данные или менять настройки. Платёжные записи помогают, но не показывают полной картины. Спросите лидов команд, finance, IT и всех, кто управляет операциями с клиентами.

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

Не останавливайтесь на очевидных приложениях. Расширения браузера могут читать содержимое страниц, данные форм и учетные данные. Важны и админ‑инструменты: менеджеры паролей, дашборды мониторинга, ПО для удалённого доступа и системы флагов функций. Команды пропускают их, потому что в спешке не думают об этих инструментах как о поставщиках.

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

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

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

Проследите путь данных от начала до конца

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

Запишите каждое место, куда попадает запись с момента отправки до окончательного удаления. Если запись меняет форму по пути, зафиксируйте это тоже. Имя и почта в приложении могут превратиться в профиль оплаты в одном инструменте, контакт поддержки в другом и строку в таблице, которую кто‑то экспортировал для отчёта.

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

• Какие данные туда поступают?
• Зачем этой системе они нужны?
• Кто может их просматривать?
• Где система размещена?
• Как долго данные там хранятся?

Не ограничивайтесь основными поставщиками. Ручная работа создаёт одни из худших незаметных путей. Команды экспортируют CSV, вставляют списки пользователей в общие документы, отправляют скриншоты в чат или сохраняют бэкапы в папках, которые никто не проверяет. Покупатели спрашивают о таких путях, потому что они часто обходят задокументированные контроли.

Особое внимание уделяйте сменам региона. Если данные начинаются в ЕС, а затем движутся в американский облачный сервис — скажите об этом прямо. Если у поставщика есть subprocessors, отметьте их место в цепочке. То же относится к хранилищам данных, инструментам логирования, отдельным облакам и сервисам ИИ, которые обрабатывают тикеты поддержки или данные продукта.

Если команда не может объяснить один шаг, пометьте его. Не догадайтесь. Неизвестные пути нормальны на старте. Реальная ошибка — скрывать их. Запись вроде «инженеры проверяют, включают ли логи почты клиентов» гораздо лучше аккуратной схемы, где этот сложный кусок пропущен.

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

Напишите план выхода, который можно применить

План выхода должен отвечать на один прямой вопрос: если нужно уйти в течение 30 дней, что происходит сначала, потом и в конце?

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

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

Будьте практичны. «CSV‑экспорт доступен» — недостаточно, если CSV не содержит вложений, истории аудита или прав пользователей. Запишите, что экспорт включает, чего не хватает и что вашей команде придётся воссоздавать в новом инструменте.

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

Простой пример: команда поддержки использует тикетную систему, где хранятся сообщения клиентов и прикреплённые файлы. При тесте вы выясняете, что тикеты экспортируются в JSON, вложения приходят в отдельном архиве, закрытие аккаунта занимает 14 дней после письменного уведомления, а бэкапы хранятся ещё 30 дней. Такой уровень деталей хотят видеть покупатели.

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

Проведите простую проверку в шесть шагов

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

Используйте записи в первую очередь. Память слишком часто ошибается.

1. Выгрузите недавние платёжные записи, отчёты по расходам и логи SSO или идентификации. Такая комбинация обычно находит платные сервисы, пробные аккаунты и старые учётки.
2. Спросите лидов команд, какие инструменты ещё используются, кто имеет доступ и какие данные туда попадают. Сделайте запрос коротким, чтобы люди действительно ответили.
3. Поместите всё в одну общую таблицу. Дайте каждой строке владельца, короткое назначение, тип данных и документы, которые у вас уже есть — DPA, сводка по безопасности или отчёт SOC 2.
4. Закройте инструменты, которые никому не нужны. Удалите аккаунт, отключите доступ и зафиксируйте дату, чтобы позже никто не гадал.
5. Исправьте самые большие пробелы в первую очередь. Если поставщик работает с данными клиентов, но у него нет владельца, нет документов или неясны шаги отписки — решите это сейчас. Мелкие пробелы зафиксируйте и назначьте дату исправления.
6. Просмотрите весь пакет с отделом продаж до того, как придут закупки. Продажи должны знать, какие поставщики могут вызвать дополнительные вопросы, какие ответы уже готовы и кто будет отвечать, если покупатель запросит подробности.

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

Один человек должен поддерживать таблицу актуальной. В маленькой компании это обычно operations lead, finance lead или фракционный/внештатный CTO. Быстрая ревизия раз в квартал не даст списку снова превратиться в срочный проект.

Ошибки, которые тормозят сделки

Сделки замедляются, когда команда делает утверждения, которые не может доказать. Самый быстрый способ потерять время — пометить поставщика «низкорисковым», потому что он кажется маленьким или знакомым. Покупатель спросит почему. Если никто не сможет показать вовлечённые данные, уровень доступа, условия контракта и влияние на бизнес — такая пометка ничего не значит.

Команды также забывают боковые системы вокруг основного приложения. Они проверяют основной продукт и затем забывают про бэкапы, инструменты логирования, почтовые ящики поддержки, общие диски и историю чатов по инцидентам. Эти каналы часто содержат те же данные клиентов, что и основная система, и покупатели быстро замечают разрыв.

Один отчёт по безопасности редко решает все вопросы. SOC 2, пентест или стандартная анкета помогают, но закупки обычно спрашивают больше: куда движутся данные, кто может их экспортировать, какие подрядчики с ними работают и как сотрудники поддержки могут просматривать записи клиентов. Если команда считает один отчёт исчерпывающим, сделка застынет, пока люди ищут остальное.

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

Обещания об удалении данных тоже могут подвести. Команды часто говорят «мы можем удалить все данные клиентов по запросу», но никогда не тестировали процесс. Затем они обнаруживают, что записи остались в бэкапах, логах, потоках поддержки или экспортированных файлах другого инструмента. Лучше ответить проще: протестировать удаление, зафиксировать, что удаляется, отметить, что остаётся в бэкапах на фиксированный период и держать этот отчёт в готовности.

Эти ошибки скучны. Именно поэтому они происходят так часто. И именно они тормозят сделки сильнее большинства технических проблем.

Быстрые проверки до того, как придёт письмо от закупок

Команды обычно знают продукт лучше, чем следы поставщиков. Этот разрыв остаётся скрытым, пока закупки не вышлют длинную анкету и не потребуют ответы к пятнице.

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

Быстрая самопроверка выглядит так:

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

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

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

Если вы сегодня не можете ответить на два‑три пункта — исправьте это до следующего запроса. Работа небольшая, а задержка из‑за её отсутствия обычно значительна.

Простой пример из жизни растущей команды

Маленькая B2B‑компания казалась лёгкой для объяснения. Она продавала небольшим клиентам, использовала короткий список поставщиков и закрывала сделки без особой проверки. Отдел продаж отвечал на большинство вопросов по безопасности по памяти, поэтому никто не документировал детали.

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

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

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

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

Заметка по выходу оказалась важнее, чем они ожидали. Покупатель хотел понимать, что произойдёт, если фирма перестанет пользоваться поставщиком в следующем квартале. Команда зафиксировала, кто будет вытягивать данные, сколько займёт передача и какой сервис заменит текущий.

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

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

Следующие шаги для небольшой команды

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

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

Назначьте одного владельца и одного запасного. Проверьте топ‑5 поставщиков на этой неделе. Запишите, какие данные получает каждый поставщик и куда они идут. Сохраните контракты, анкеты и заметки в одном общем месте. Добавьте короткий план выхода для каждого поставщика.

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

Если команда очень занята и некому собрать всё это — внешняя помощь может пригодиться. Oleg Sotnikov at oleg.is работает со стартапами и малыми компаниями как фракционный CTO и советник, и такой обзор естественно вписывается в его работу. Фокусный проход по списку поставщиков, путям данных и шагам отписки может выявить слабые места до того, как это сделает отдел закупок.