Вопрос часто ставят слишком жёстко: оставить своего системного администратора или передать всё подрядчику. На практике между этими вариантами есть несколько рабочих конфигураций. Выбор зависит не от модного названия, а от того, какие системы есть у компании, кто принимает решения и какая компетенция должна оставаться внутри.
Сначала разделите четыре вещи
1. Владение решением
Кто определяет допустимый риск, бюджет, приоритеты и правила доступа? Эти полномочия нельзя незаметно передать вместе с очередью заявок. Даже при полном внешнем сопровождении компания сохраняет владельцев бизнеса, данных и ключевых решений.
2. Ежедневная работа
Кто принимает обращения, меняет учётные записи, обновляет системы, следит за копиями, связывается с провайдером и документирует изменения? Это можно распределить между внутренней командой и подрядчиком по зонам.
3. Специализированная экспертиза
Сеть, серверы, облака, информационная безопасность, телефония, видеонаблюдение и производственные системы требуют разных знаний. Необязательно держать каждую компетенцию в штате, но нужно понимать, кто и на каких условиях подключается.
4. Отдельные изменения
Миграция, модернизация, новая площадка или внедрение системы — не то же самое, что регулярная эксплуатация. Для проекта обычно нужен отдельный объём, результат, план перехода и решение о приёмке.
Три основных формата
Внешний ИТ-контур
Подходит, когда полноценной внутренней ИТ-службы нет, а компании нужен единый канал обращений и согласованная поддержка выбранных систем.
Внутри компании всё равно остаются:
- человек, который задаёт приоритет бизнеса;
- владельцы данных и приложений;
- полномочия согласовать доступ и изменение;
- решение о бюджете и принятии риска.
Подрядчик может вести очередь обращений, выбранные части инфраструктуры, документацию и взаимодействие с другими поставщиками — только в согласованной границе.
Совместно управляемая поддержка
Подходит компаниям с внутренним ИТ-специалистом или небольшой командой. Внутренняя сторона сохраняет контекст и решения, а внешний контур берёт часть эксплуатации, вторую линию, наблюдение или отдельные технологии.
Примеры разделения:
- внутренняя команда отвечает за бизнес-приложения, подрядчик — за сети и серверы;
- внутренний специалист принимает решения и изменения, подрядчик ведёт Service Desk и типовые работы;
- подрядчик наблюдает инфраструктуру и готовит предложения, а внедрение согласуется и выполняется отдельным проектом;
- внутренний ИТ координирует поставщиков, внешний контур подключается к сложным инцидентам.
Проектное подключение
Подходит, когда текущая эксплуатация остаётся у компании или её подрядчика, но требуется ограниченное изменение: перенести сервер, развернуть сеть, настроить телефонию, изменить защиту, проверить сценарий ИИ-агента.
Здесь особенно важно заранее записать, что будет передано после завершения: конфигурации, схема, инструкции, учётные записи, протокол проверки, список ограничений. Выполнение работ ещё не означает, что желаемый бизнес-результат достигнут; это проверяется отдельно.
Матрица, которая помогает выбрать
Заполните строки по ключевым зонам:
| Зона | Кто решает | Кто выполняет | Кто проверяет | Кто нужен при аварии |
|---|---|---|---|---|
| Пользователи и рабочие места | ||||
| Сеть и связь | ||||
| Серверы и облака | ||||
| Резервное копирование | ||||
| Бизнес-системы | ||||
| Доступ и безопасность | ||||
| Поставщики и лицензии |
В одной строке могут участвовать несколько сторон. Это нормально, если границы и порядок эскалации понятны.
Что проверить до предложения
- Площадки и рабочие часы.
- Критичные процессы и периоды повышенной нагрузки.
- Текущая очередь обращений и повторные проблемы.
- Состав внутренней команды и её реальная загрузка.
- Поставщики, договоры и точки контакта.
- Административные доступы и ограничения безопасности.
- Документация и известные неизвестные.
- Ожидаемый режим реагирования, включая географию очных выездов.
- Какие работы точно должны остаться у клиента.
Без этих данных фиксированная схема и цена могут быть только предварительными.
Как начать без резкой передачи
Практичный переход можно разбить на этапы:
- Собрать системы, участников, доступы и открытые вопросы.
- Определить одну–две зоны для первого периода.
- Согласовать канал обращений, приоритеты и эскалацию.
- Проверить документацию и резервные сценарии.
- Провести ограниченный период совместной работы.
- По фактам решить, расширять, сужать или оставлять формат без изменений.
Такой маршрут сохраняет возможность остановиться или изменить границу. Он не обещает, что одна модель подойдёт любой компании.
Короткий вывод
Хороший формат поддержки отвечает не на вопрос «кто отвечает за всё», а на четыре вопроса: кто принимает решение, кто выполняет работу, кто проверяет результат и что происходит при исключении. Если ответы записаны по ключевым системам, внешний и внутренний контуры могут усиливать друг друга без потери контроля.
Источники и границы материала
- NIST Cybersecurity Framework 2.0 — отдельное внимание к управлению, ролям, ответственности и цепочке поставщиков.
- NIST SP 1305: Cybersecurity Supply Chain Risk Management — определение и коммуникация требований поставщикам и распределение ролей.
- NIST SP 800-161 Rev. 1 — управление рисками продуктов и услуг на протяжении их жизненного цикла.
Источники проверены 30 августа 2026 года. Статья не выбирает модель за конкретную компанию и не заменяет договорное, техническое и правовое согласование ролей.