Розбираємо ключові умови договору SaaS: модель ліцензії на доступ, рівень сервісу (SLA), обмеження відповідальності, обробку даних та порядок припинення.
Що таке SaaS-договір і чим він особливий
SaaS (Software as a Service) — це модель, за якої клієнт не отримує програму у володіння, а користується нею як хмарним сервісом через підписку. Юридично це принципово відрізняє SaaS від класичної передачі чи ліцензування коробкового ПЗ: клієнт не отримує дистрибутив і не встановлює його, а лише дістає доступ до функціоналу на сервері постачальника.
Через це SaaS-договір не є договором купівлі-продажу чи відчуження прав. Це переважно договір про надання послуг із доступу, поєднаний із ліцензійними елементами. Помилка багатьох компаній — використовувати шаблон ліцензійного договору на ПЗ там, де насправді йдеться про сервіс. У межах практики IT Law ми складаємо SaaS-угоди, що коректно описують саме модель доступу та враховують міжнародний характер клієнтів.
Для українського постачальника SaaS додається ще один шар: якщо сервіс орієнтований на клієнтів у ЄС чи США, договір має бути двомовним і враховувати застосовне право та підсудність. Резидентство в Дія.City при цьому спрощує валютні розрахунки та роботу з іноземними контрагентами.
Ліцензія на доступ та обсяг прав
Центральний елемент SaaS-договору — ліцензія на доступ і використання. Вона має чітко визначати, що саме отримує клієнт: невиключне, непередаване право користуватися сервісом протягом строку підписки в межах обумовленого функціоналу та кількості користувачів. Постачальник зберігає за собою всі майнові права на сам продукт.
Договір має фіксувати обмеження: заборону реверс-інжинірингу, перепродажу доступу третім особам без дозволу, використання понад придбаний тариф. Окремо описують модель тарифікації — за користувачів, за обсяг даних чи за функціональні модулі, а також правила зміни тарифу.
- предмет — доступ до сервісу, а не передача коду;
- обсяг — кількість користувачів, місць, обсяг запитів;
- обмеження — заборона реверс-інжинірингу та субліцензування;
- права на доопрацювання та інтеграції, якщо вони передбачені.
Якщо в межах сервісу постачальник створює для клієнта індивідуальні доопрацювання, варто окремо врегулювати права на них. Питання володіння кодом і його захисту ми розглядаємо в межах практики інтелектуальної власності.
Рівень сервісу (SLA) та доступність
Угода про рівень сервісу (Service Level Agreement, SLA) — це серце SaaS-договору з погляду клієнта. Вона визначає гарантований рівень доступності сервісу (наприклад, 99,9 відсотка часу на місяць), порядок планових технічних робіт, час реакції на інциденти та канали підтримки.
Грамотний SLA передбачає сервісні кредити — компенсацію у формі знижки чи продовження підписки, якщо постачальник не дотягнув до обіцяного рівня доступності. Важливо, щоб SLA був реалістичним: завищені обіцянки доступності, які компанія технічно не здатна виконати, перетворюються на постійне джерело претензій.
Для постачальника критично коректно розмежувати власну відповідальність і збої, спричинені третіми сторонами (хмарний провайдер, інтернет-канал клієнта, форс-мажор). Виключення з-під дії SLA мають бути прописані прозоро, інакше клієнт вимагатиме кредити навіть за події поза контролем постачальника.
Обмеження відповідальності постачальника
SaaS-сервіс часто є критичним для бізнесу клієнта, тому збій може спричинити значні непрямі збитки. Без розумного обмеження відповідальності постачальник ризикує отримати претензії, що багатократно перевищують вартість підписки.
Стандартна практика — обмежити сукупну відповідальність сумою, сплаченою клієнтом за певний період (наприклад, за останні 12 місяців), та виключити відповідальність за непрямі збитки: упущену вигоду, втрату даних через дії клієнта, репутаційні втрати. Водночас деякі види відповідальності (за порушення конфіденційності чи прав інтелектуальної власності) часто виводять з-під загального ліміту.
Важливо, щоб формулювання залишалися виконуваними за застосовним правом: надмірне повне зняття відповідальності суд може визнати недійсним. Ми балансуємо ці положення так, щоб вони реально захищали постачальника й водночас були прийнятними для корпоративних клієнтів, які перевіряють договір перед підписанням.
Обробка даних та конфіденційність
SaaS майже завжди передбачає обробку даних клієнта, зокрема персональних даних його користувачів. Тому до договору додають договір про обробку даних (Data Processing Agreement, DPA), у якому постачальник зазвичай виступає процесором, а клієнт — контролером. DPA фіксує предмет, мету, заходи безпеки та використання субпроцесорів.
Якщо серед користувачів є особи з ЄС, на обробку поширюється Загальний регламент про захист даних (GDPR), а в Україні — Закон України «Про захист персональних даних». Договір має передбачати порядок повідомлення про інциденти безпеки та допомогу клієнту в реагуванні на запити суб’єктів даних.
Окремо врегульовують конфіденційність: захист даних клієнта, заборону використовувати їх поза наданням сервісу та режим знеособлених метрик. Питання витоку даних і строків повідомлення ми детально розкрили у статті кібербезпека та реагування на витік персональних даних.
Припинення договору та повернення даних
Чи не найбільше суперечок виникає на етапі припинення. Договір має чітко визначати підстави розірвання, наслідки несплати та, найважливіше, долю даних клієнта після завершення співпраці. Клієнт має право отримати свої дані у придатному для використання форматі протягом узгодженого строку.
Прописують також перехідний період, протягом якого постачальник зберігає дані для експорту, та момент їх остаточного видалення. Відсутність цих положень створює ризик «заручника даних», коли клієнт не може мігрувати на інший сервіс, а постачальник — спір про порушення приватності.
Грамотний SaaS-договір захищає обидві сторони й прискорює продажі, бо корпоративні клієнти не витрачають місяці на узгодження. Більше матеріалів — у розділі IT-право, а угоду під ваш продукт підготуємо на консультації.
Послуги напряму: Вступ і супровід у режимі Дія.City, Договори з розробниками (B2B та гіг-контракти), Відповідність GDPR і захист персональних даних.