Подрядчик просит доступ к CRM, выгрузку клиентской базы или права администратора на сайте. На вид это обычная рабочая задача. Но как только внешний исполнитель видит имена, телефоны, адреса или другие персональные данные, она становится ещё и задачей управления риском.
Договор о конфиденциальности полезен, но сам по себе не отвечает на главный вопрос: что именно подрядчик сможет сделать с данными и когда этот доступ закончится.
Сначала определите роль внешней компании
Не каждый контрагент, который видит сведения о человеке, работает в одной и той же роли. Полезно остановиться на минуту и отделить простую техническую услугу от ситуации, когда подрядчик действительно обрабатывает данные по вашим инструкциям.
Данные не получает
Например, поставщик заменяет оборудование и не видит базы, заявки или личные дела.
Работает по вашим правилам
Настраивает CRM, делает рассылку или помогает с обращениями от имени компании.
Сам решает цель обработки
Оказывает человеку самостоятельную услугу или исполняет собственную обязанность.
Во втором случае особенно важно письменно описать рамки работы. Закон требует определить цель, перечень данных, разрешённые действия, обязанности по конфиденциальности и безопасности.[1]
Пять вопросов до выдачи доступа
01 Зачем подрядчику эти данные?
Начинайте не с фразы «нужен доступ», а с конкретной задачи. Цель определяет, какие данные нужны, кому именно и на какой срок.
02 Какой минимум данных необходим?
Если без конкретного поля можно выполнить работу, его лучше не передавать. Данные «на всякий случай» почти всегда создают лишний риск.
03 Что именно сможет делать подрядчик?
Просмотр, выгрузка, изменение, рассылка или удаление — это разные действия. Их стоит заранее назвать и ограничить.
04 Получит ли доступ кто-то ещё?
Уточните, где хранятся данные, использует ли исполнитель субподрядчиков и кто подключается к поддержке.
05 Как и когда доступ закончится?
Заранее определите, что происходит после завершения задачи: блокировка учётной записи, возврат или уничтожение копий и закрытие удалённого доступа.
Что должно быть в рабочем поручении
Не нужно превращать договор в техническое руководство. Но у команды должны быть ясные ответы на базовые вопросы. Это защищает и компанию, и исполнителя: обе стороны понимают границы работы.
Договор без настроек доступа не работает
Юридическая формулировка не заменит ежедневную техническую дисциплину. Ограниченный, персональный и проверяемый доступ помогает воплотить договорённости в работу системы.
Пример реестра внешних доступов
| Сценарий | Ограничение | Контроль |
|---|---|---|
| CRM / клиентская база | Только нужный раздел | Персональная учётная запись |
| Тестовая среда | Синтетические данные | Временный доступ |
| Техподдержка | Доступ по заявке | Журналирование действий |
Внешняя команда исправляет форму обратной связи. Ей не нужен архив заявок за несколько лет. Достаточно тестовой среды и, если потребуется, минимального фрагмента данных для проверки одной ошибки. После работы доступ закрывается.
Проверка за 20 минут
Откройте список подрядчиков, которые видят данные в CRM, на сайте, в почте или в кадровой системе. По каждому отметьте:
- Понятна конкретная цель доступа
- Зафиксирован минимальный набор данных
- Есть договорная модель для работы с ПДн
- Известно, кто у подрядчика имеет доступ
- Определён способ и дата отзыва доступа
- Назначен человек для регулярной проверки
Если хотя бы на один из первых пяти вопросов нет ответа, доступ стоит пересмотреть до следующей передачи данных.
Контроль начинается не с запрета, а с ясности
Хорошая модель работы с подрядчиком держится на простой связке: цель — минимальный набор данных — ограниченный доступ — понятное завершение.
Нужна помощь с доступами?
Проверьте, кто и на каких условиях получает доступ к персональным данным в вашей компании.
Проверить доступы