За годы практики мы сталкивались с ситуациями, когда IT-аутсорсинг — казалось бы, выгодное решение, которое снимает головную боль с содержания целого отдела, оплаты оборудования и контроля обновлений — превращался в источник проблем. Ведь вместе с задачами бизнес передаёт подрядчику доступ к своей инфраструктуре, данным клиентов и внутренним системам.
В этой статье мы разберём, как должен быть выстроен контроль IT подрядчика, чтобы минимизировать риски.
Почему вообще аутсорсинг IT может нести скрытые угрозы
Когда мы говорим об IT-аутсорсинге, мы в первую очередь говорим об управляемости: системами, данными, инфраструктурой. А управляемость — это всегда про менеджмент и ответственность: кто принимает решения и кто отвечает, когда что-то идёт не так.
На самом деле большинство проблем — не в аутсорсинге как таковом, а в договорённостях. Если компания изначально не прописала зоны ответственности, не определила критичные данные, не разграничила доступы и не зафиксировала требования к сервису — она теряет управляемость ИТ. И тогда при инциденте окажется, что никто ни за что не отвечает. А если подрядчик недобросовестный — уйти от него будет непросто: системы настроены под него, документации нет, бизнес заперт.
Важно понимать: подрядчик не будет сам себе прописывать ограничения и ответственность. Добросовестный подрядчик предложит какие-то стандартные условия — но стандарт составляется под среднего клиента, а не под ваш бизнес. Поэтому важно искать партнёра с консультационным подходом — того, кто сначала разбирается в процессах и задачах компании, и только потом предлагает решение. Мы в Aiston предлагаем начать с обследования ИТ, чтобы сформировать требования к подрядчику осознанно. |
Основные риски IT-подрядчиков
Разберём основные риски работы с подрядчиками IT:
- Утечка данных. Подрядчик может работать с клиентской базой, финансовыми системами и внутренней информацией компании. Если процессы защиты данных выстроены недостаточно чётко, это повышает вероятность утечек.
- Зависимость от подрядчика. Когда системы настроены под конкретную команду, а документация и знания не передаются, смена подрядчика может занять время и потребовать дополнительных ресурсов.
- Срыв сроков и слабый сервис. Если заранее не определены KPI и SLA, сложнее контролировать сроки выполнения задач и оценивать качество оказанных услуг.
- Лишние доступы к системам. Доступ к инфраструктуре могут сохранять бывшие сотрудники, привлечённые специалисты или сторонние сервисы. Без регулярного контроля это создаёт дополнительные риски безопасности.
- Размытая ответственность. Если в договоре не закреплены зоны ответственности и порядок действий при сбоях, решение спорных ситуаций может затянуться.
Приведём классический кейс. К нам обратилась компания, чья IT-инфраструктура находилась под управлением внешнего подрядчика. Запрос был простой — провести аудит. В ходе обследования выяснилось: у компании не было прямого доступа к собственным системам, документация устарела, а при любом сбое или разрыве отношений с подрядчиком бизнес рисковал просто встать. По итогам аудита компания приняла решение сменить модель управления и перенести инфраструктуру в облако. Нам пришлось вынужденно пришлось завершить миграцию — подрядчик уведомил об отключении серверов фактически в последний момент. |
Как организовать контроль IT-подрядчика
Для безопасности при аутсорсинге IT все договорённости оформляются через договоры и акты — либо на бумаге с живыми подписями, либо электронно через систему ЭДО с квалифицированной электронной подписью (КЭП). Оба варианта имеют равную юридическую силу. Подписывает руководитель или уполномоченное лицо по доверенности — с обеих сторон.
1. NDA и соглашение о конфиденциальности.
Подписывается до начала любых работ и до того, как подрядчик получил доступ к системам или увидел внутренние процессы. В документе фиксируется, какие данные считаются конфиденциальными, как они могут использоваться и что происходит при нарушении.
Например, если подрядчик работает с базой клиентов — это должно быть явно прописано, включая запрет на передачу данных третьим лицам.
2. SLA (Service Level Agreement).
Соглашение об уровне обслуживания — это конкретные цифры ожиданий.
Например: время реакции на угрозу ИБ — не более 2 часов, доступность систем — 99,9%.
С помощью SLA бизнес исключает субъективность в претензиях.
3. Разграничение и мониторинг доступов.
Подрядчик должен получать только те доступы, которые необходимы для выполнения конкретных задач. К примеру, администратор баз данных не должен видеть почтовый сервер, а техподдержка — финансовые системы.
Действия внешних пользователей должны фиксироваться и контролироваться через журналы событий и системы мониторинга.
4. Регулярный аудит.
Раз в квартал или полгода стоит проверять, как подрядчик соблюдает договорённости на практике. Это необязательно масштабная проверка — иногда достаточно просмотреть журналы доступов, убедиться в актуальности документации и сверить реальные показатели с SLA.
5. Документация и передача знаний
Все настройки, архитектура систем и учётные данные должны храниться у вас, а не только в голове у инженера подрядчика. Это страховка на случай, если подрядчик сменится или ключевой специалист уйдёт. Требуйте документацию как часть договора.
Чек-лист: что проверить до подписания договора с IT-подрядчиком
Используйте этот список на этапе выбора и переговоров для обеспечения контроля IT-подрядчика и минимизации рисков:
- NDA подписан до предоставления любого доступа к данным и системам.
- SLA закреплён в договоре с конкретными метриками и сроками реакции.
- Зафиксирована ответственность за инциденты, утечки данных и нарушение сроков.
- Определён перечень данных и систем, к которым получает доступ подрядчик.
- Права доступа разграничены по ролям, действия пользователей журналируются.
- Описан порядок завершения сотрудничества: отзыв доступов, передача документации и закрытие задач.
- Подрядчик ведёт документацию и обеспечивает передачу знаний заказчику.
- Закреплён порядок аудита, контроля качества и регулярной отчётности.
Если подрядчик отказывается подписывать NDA, фиксировать SLA или ссылается на «доверие» вместо документов — это красный флаг. О том, как выбрать IT-партнёра правильно, рассказывали в статье. |
Когда аутсорсинг безопасен, а когда лучше выбрать инхаус или гибрид
Может возникнуть логичный вопрос: безопасность при аутсорсинге IT — невозможна?
Это вовсе не так. Аутсорсинг IT — отличная модель, если:
- инфраструктуру нужно регулярно развивать — появляются новые сервисы, филиалы, интеграции, требования по безопасности;
- бизнес растёт и нужно быстро подключать компетенции под новые задачи, не расширяя штат.
Здесь нужно понимать, что для здоровых отношений с подрядчиком внутри компании должен быть человек, который понимает задачи бизнеса и выстраивает коммуникацию с ним. Без этого задачи теряются, как и контроль.
У компании должны быть свои доступы, актуальная документация, зафиксированные SLA и понятная процедура смены подрядчика. Если этого нет, то появляется риск зависимости.
Об инхаусе или гибридной модели стоит задуматься, когда: IT-инфраструктура — ядро бизнеса, и любой сбой критичен или вам нужен полный контроль без внешних зависимостей.
Если хотите понять, есть ли у вас зависимость от подрядчика и насколько защищена ваша инфраструктура — обратитесь в Aiston. Мы проводим независимое обследование и даём конкретные рекомендации, исходя из задач вашего бизнеса.