# Як перевірити IT-підрядника перед передачею доступу до корпоративних систем Компанія вирішує модернізувати CRM, розробити новий вебсервіс або передати технічну підтримку зовнішній команді. Підрядник демонструє досвід, пропонує зрозумілий бюджет і переконує, що проєкт можна запустити швидко. Проте перед початком роботи виникає важливе питання: які ризики створює доступ сторонньої компанії до бізнес-систем? IT-підрядник може працювати з клієнтськими даними, програмним кодом, платіжними інтеграціями, внутрішніми документами й адміністративними обліковими записами. Тому його перевірка повинна охоплювати юридичну надійність, інформаційну безпеку та практичні можливості команди. ## Чому технічної експертизи недостатньо Компанія може мати сильних розробників, але не мати належно організованих процесів доступу, резервного копіювання та передачі результатів роботи. Наприклад, підрядник створює важливу інтеграцію, але документація залишається лише у внутрішніх матеріалах його команди. Через рік клієнт вирішує змінити виконавця й виявляє, що самостійно підтримувати систему майже неможливо. Інший сценарій — програмний продукт працює, але права на його компоненти належним чином не врегульовані. Такі проблеми не завжди помітні на етапі презентації. Тому оцінювати потрібно не лише портфоліо, а й спосіб організації роботи. ## Юридична перевірка IT-компанії Перед укладенням договору варто звірити офіційну назву підприємства, реєстраційні реквізити та повноваження особи, яка підписує документи. Для значного контракту корисно дослідити доступні відомості про судові спори, особливо пов'язані з порушенням договірних зобов'язань. Початковий алгоритм можна знайти в матеріалі про [юридичну перевірку контрагента](https://bip.net.ua/services/perevirka-kontragenta-yak-pereviryty-svogo-dilovogo-partnera/). Однак юридична реєстрація не доводить відповідності підрядника конкретним вимогам безпеки. Для критичних систем потрібні додаткові запитання про процеси, працівників, субпідрядників та управління доступами. ## Що запитати про інформаційну безпеку Важливо з'ясувати, як компанія організовує доступ співробітників до систем замовника. Чи використовуються персональні облікові записи? Чи застосовується багатофакторна автентифікація? Як відкликаються доступи після завершення роботи співробітника? Окремо потрібно обговорити порядок зберігання паролів, роботи з тестовими даними та використання зовнішніх сервісів. Для систем із персональними даними, фінансовою інформацією або іншими чутливими відомостями вимоги можуть бути значно суворішими. Корисно попросити підрядника пояснити, як він реагує на інциденти безпеки. Наприклад, хто повідомлятиме клієнта про можливий витік даних і які дії виконуватимуться першими? ## Хто володітиме програмним кодом Питання інтелектуальної власності потрібно вирішувати до початку розробки. Сам факт оплати послуг не завжди дає замовнику всі права, які він очікує отримати. Договір має визначати права на створені результати, порядок передачі вихідного коду та умови використання сторонніх компонентів. Якщо проєкт передбачає open-source бібліотеки, варто оцінити відповідність їхніх ліцензій запланованому використанню. Для довгострокових систем корисно передбачити документацію, доступ до репозиторіїв та правила передачі проєкту іншій команді. ## Чому важливо уникати залежності від одного виконавця Іноді IT-підрядник стає єдиною стороною, яка розуміє архітектуру створеної системи. Це може ускладнити підтримку, зміну постачальника або розширення функціональності. Щоб зменшити ризик, потрібно погодити мінімальні вимоги до документації. Наприклад, опис ключових компонентів, порядок розгортання, перелік інтеграцій і правила резервного відновлення. Також важливо, щоб критичні облікові записи та основні договори із хмарними постачальниками перебували під належним контролем замовника. Звичайно, конкретна модель залежить від послуги. Але розподіл відповідальності має бути зрозумілим. ## Як перевірити реальний досвід команди Портфоліо допомагає сформувати початкове враження, проте варто уточнювати деталі. Яку саме частину проєкту виконувала компанія? Які технології використовувалися? Хто відповідав за архітектуру, тестування та підтримку? Корисно обговорити реалістичні сценарії проблем. Наприклад, що робитиме команда, якщо після оновлення перестане працювати критична інтеграція? Відповідь покаже більше, ніж загальна обіцянка високої якості. Для складного проєкту іноді доцільно почати з обмеженого технічного етапу. Це дозволяє оцінити якість комунікації та виконання домовленостей до масштабних інвестицій. ## Що потрібно погодити перед запуском Договір має містити зрозумілий опис послуг, етапи, порядок приймання, вимоги до безпеки та відповідальність сторін. Окремо варто врегулювати використання субпідрядників і порядок роботи з конфіденційною інформацією. Для підтримки критичних систем можуть бути потрібні погоджені показники доступності, строки реагування на інциденти та процедура ескалації. Також необхідно визначити, що відбуватиметься після завершення контракту: передача документації, облікових записів, даних і технічних матеріалів. ## Висновок Вибір IT-підрядника впливає не лише на бюджет розробки, а й на безперервність бізнесу, захист інформації та можливість підтримувати систему в майбутньому. Тому юридична перевірка має поєднуватися з технічним оцінюванням, аналізом процесів безпеки та чітким договором. Чим важливіша система для компанії, тим більше уваги потрібно приділити тому, як її створюватимуть, підтримуватимуть і передаватимуть після завершення співпраці.