Опубликовано: 14.01.2026

Какие доступы должны быть у заказчика (и почему “у подрядчика всё” — опасно)


Иногда проект стартует “по-быстрому”: подрядчик сам заводит аккаунты, подключает сервисы, настраивает всё у себя. На старте это удобно. Но позже выясняется, что бизнес не контролирует критичные вещи. Любая проблема превращается в ожидание “когда подрядчик посмотрит”, а смена исполнителя выглядит как катастрофа.

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

Почему “всё у подрядчика” опасно

1) Риски остановки бизнеса
Если подрядчик недоступен (болезнь, перегруз, отпуск), вы не можете оперативно решать критичные вопросы: доступы сотрудникам, срочные настройки, восстановление.

2) Невозможность быстро сменить исполнителя
Даже если вы хотите продолжить развитие другим составом, без доступов и материалов переход становится дорогим и долгим.

3) Финансовые и репутационные риски
Когда внешние сервисы оформлены на подрядчика, вы зависите от него юридически и операционно: платежи, рассылки, телефония, аналитика — всё может быть заблокировано или потеряно при смене команды.

Какие доступы должны быть у заказчика (по смыслу)

1) Административный доступ к системе
Чтобы вы могли управлять пользователями, ролями, базовыми настройками и не “просить включить сотрудника”.

2) Владение аккаунтами внешних сервисов
Все сервисы, которые важны для бизнеса (платежи, рассылки, CRM, телефония и т.д.), должны быть оформлены на компанию заказчика. Подрядчику можно выдавать доступ “как исполнителю”.

3) Доступ к материалам проекта
Документы, список задач, принятые решения, инструкции — это ваши активы. Без них любая доработка превращается в “разбираемся заново”.

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

5) Управляемые доступы подрядчика
Подрядчик должен получать доступы персонально, по роли и на нужный объем. И у вас должна быть возможность ограничить доступ при завершении работ или смене команды.

Как закрепить это спокойно

  • Зафиксируйте список доступов до старта: кто владелец, кто исполнитель, где хранятся.
  • Сделайте передачу доступов условием приемки этапа (или проекта).
  • Договоритесь, что доступы выдаются персонально и контролируемо, без “общих логинов”.

Это не усложнение. Это базовая безопасность и независимость бизнеса.


← К списку статей "Безопасность проекта"
Ссылка скопирована