SaaS-договір – що має містити договір? 12 питань для врегулювання
Поділитися
Від Mallbutiken · Факти перевірено 1 жовтня 2026 р. · Час читання приблизно 9 хвилин
Хороший SaaS-договір описує більше, ніж просто право на використання програмного забезпечення. Він має чітко визначати обсяг послуг, обіцяний рівень доступності та підтримки, спосіб обробки даних клієнта, чинні вимоги безпеки, зобов'язання сторін, а також те, як клієнт може отримати свої дані після завершення договору.
Що таке SaaS-договір?
SaaS означає Software as a Service (програмне забезпечення як послуга). Зазвичай клієнт отримує доступ до програмного сервісу через інтернет, а не купує традиційну копію програми. Тому договір стає поєднанням комерційних умов, права користування, зобов'язань щодо експлуатації та підтримки, а також правил щодо даних і безпеки.
Не існує окремого шведського закону, який би виключно визначав, як має виглядати B2B SaaS-договір. Тому конкретний зміст договору стає вирішальним. Застосовується загальне договірне право, а залежно від послуги можуть бути актуальними правила захисту даних, авторського права, кібербезпеки та галузеві вимоги.
12 питань, на які має відповідати SaaS-договір
- Що входить у послугу? Опишіть модулі, функції, кількість користувачів, інтеграції, зберігання, впровадження та чіткі обмеження.
- Коли послуга вважається наданою? Якщо впровадження або міграція включені, мають бути визначені етапи, тестування та критерії прийняття.
- Який рівень обслуговування діє? Вкажіть, як вимірюється доступність, які існують виключення та що відбувається при повторюваних відхиленнях.
- Як працює підтримка? Визначте канали зв'язку, години роботи, рівні пріоритетності, час першої відповіді та процедуру ескалації.
- Хто має право на дані клієнта? Розділяйте дані клієнта та програмне забезпечення, статистику та інші нематеріальні активи постачальника.
- Як обробляються персональні дані? Визначте ролі та укладіть відповідний договір обробки даних (PUB/DPA), коли постачальник виступає в ролі обробника персональних даних.
- Які вимоги безпеки застосовуються? Зробіть вимоги щодо доступу, MFA, логування, управління вразливостями, резервного копіювання та інцидентів такими, що піддаються перевірці.
- Чи дозволено залучення субпідрядників? Вкажіть, як здійснюється управління критичними субпідрядниками та будь-якими суб-обробниками, і як повідомляється про зміни.
- Як послуга може змінюватися? Регулюйте зміну версій, виведення функцій з експлуатації та наслідки суттєвого впливу змін на використання послуги клієнтом.
- Як працює ціноутворення та коригування цін? Зазначте базовий тариф, оплату залежно від кількості користувачів, перевищення лімітів, індексацію, консультаційні години та підстави для зміни цін.
- Як розподіляється відповідальність? Визначте помилки, способи їх усунення, можливі сервісні кредити, типи збитків, ліміти відповідальності та відповідні виключення.
- Що відбувається після закінчення дії договору? Заздалегідь визначте порядок експорту даних, підтримку міграції, видалення, терміни та витрати.
- Як працює вихід із договору? Визначте експорт, підтримку міграції, видалення, дедлайни та витрати заздалегідь.
SLA: зробіть рівень обслуговування вимірюваним
«Висока доступність» — це поняття, яке важко перевірити. Корисна угода про рівень обслуговування (SLA) описує, що саме вимірюється і як. Мета щодо доступності має бути поєднана з визначеннями для планового обслуговування, помилок з боку клієнта та інших виключень.
| Елемент SLA | Питання для регулювання |
|---|---|
| Доступність | Який відсотковий рівень діє, протягом якого періоду вимірювання та для яких компонентів? |
| Клас інциденту | Що відрізняє критичну помилку P1 від менш важливої помилки? |
| Час реагування | Як швидко постачальник має почати обробку інциденту? |
| Відновлення | Чи існують цільові показники відновлення і які залежності на них впливають? |
| Сервісний кредит | Чи передбачає відхилення знижку або кредит, і чи є це єдиним заходом відшкодування для клієнта? |
RTO та RPO часто використовуються для відновлення та втрати даних, але показники повинні ґрунтуватися на конкретній послузі та потребах клієнта. Детальніше про це читайте в посібнику про SLA, доступність, RTO та RPO.
GDPR: коли потрібен договір про обробку персональних даних?
Якщо SaaS-постачальник обробляє персональні дані від імені клієнта, центральною є стаття 28 GDPR. У такому разі обробка має регулюватися договором або іншим обов'язковим правовим актом із зазначенням даних і зобов'язань, передбачених статтею.
Почніть із розподілу ролей. Постачальник не автоматично стає обробником лише тому, що в послузі є персональні дані. Прочитайте, коли потрібен договір про обробку персональних даних і що він має містити. Якщо задіяні суб-обробники або передача даних у треті країни, ці питання також потребують врегулювання.
Розділяйте комерційне питання щодо даних і роль у захисті даних
Договір також має визначати, що клієнт може експортувати та використовувати після закінчення дії договору. Комерційне питання про право на дані клієнта не є ідентичним питанню GDPR про відповідальність за персональні дані та обробку даних.
Безпека: прописуйте вимоги, які можна перевірити
Адаптуйте додаток про безпеку відповідно до чутливості даних та критичності діяльності. Приклади конкретних сфер: управління ідентифікацією та доступом, MFA, шифрування, логування, управління вразливостями та оновленнями, безпечна розробка, резервне копіювання, комунікація під час інцидентів та безперервність діяльності.
Для організацій, на які поширюється дія закону про кібербезпеку, ланцюг постачання є однією зі сфер, яку заходи безпеки мають охоплювати в першу чергу. Тому договір із постачальником може бути важливим інструментом для встановлення вимог та їх перевірки, проте договір не замінює власне управління ризиками. Читайте також посібник про NIS2 та вимоги безпеки у договорах із постачальниками.
Плануйте вихід, доки відносини ще працюють
Часто обговорення експорту даних стає дорогим, коли сторони вже вирішили припинити співпрацю. Тому регулюйте питання виходу (exit) ще на етапі підписання договору.
- У якому форматі експорту отримує дані клієнт?
- Чи включені метадані, конфігурація та додатки?
- Як довго можливий експорт після розірвання договору?
- Чи може клієнт використовувати API для міграції?
- Яка підтримка міграції включена і скільки коштує додаткова робота?
- Коли видаляються виробничі дані, тестові дані та копії?
- Чи може постачальник надати сертифікат про видалення?
Хороший пункт про вихід зменшує залежність від постачальника (vendor lock-in) і полегшує порівняння постачальників ще до купівлі. Поглибте знання у розділі SaaS-вихід та міграція даних — чек-лист договору, де розглядаються формати експорту, API, метадані, підтримка міграції, резервне копіювання та видалення.
Ліміти відповідальності: пов'язуйте рівень із реальними ризиками
Не існує універсального відсоткового показника, який підходить для всіх SaaS-угод. Обґрунтований ліміт відповідальності залежить, серед іншого, від вартості договору, чутливості даних, залежності від сервісу, страхування та можливих непрямих збитків. Також перевірте, які події виходять за межі ліміту і чи узгоджується обмеження відповідальності з сервісними кредитами, конфіденційністю, персональними даними та інтелектуальною власністю.
§ 36 Закону про договори дає можливість коригувати або ігнорувати несправедливі умови договору, проте це не замінює необхідність переговорів про зважений розподіл ризиків із самого початку.
Чек-лист перед підписанням
- Чи задокументовано обсяг послуги та всі важливі виключення?
- Чи можна виміряти значення SLA даними, які можуть перевірити обидві сторони?
- Чи є чіткими шляхи підтримки та реагування на інциденти?
- Чи оцінені ролі щодо персональних даних, суб-обробники та міжнародні потоки даних?
- Чи відповідають вимоги безпеки ризикам послуги та галузевим вимогам клієнта?
- Чи є прогнозованими зміни цін та плата за перевищення лімітів?
- Чи є чіткими правила щодо зміни функцій?
- Чи свідомо обрані ліміти відповідальності та виключення?
- Чи можна на практиці експортувати дані клієнта?
- Чи узгоджені питання розірвання, призупинення та виходу (exit)?

Потрібен повний пакет документів для договору?
SaaS-договір від Mallbutiken для B2B містить основний договір та шість додатків, включаючи специфікацію послуг, SLA, PUB/GDPR, безпеку, вихід та ціни. Надається у форматі Word та PDF для редагування. Ціна в магазині: 149 шв. крон.
Переглянути шаблон SaaS-договоруПоширені запитання
Чи SaaS-договір — це те саме, що ліцензійний договір?
Не обов'язково. SaaS-договір зазвичай також повинен регулювати постійне надання послуг, експлуатацію, підтримку, дані, безпеку та вихід. Ліцензійна частина — це лише один із аспектів відносин.
Чи має B2B SaaS-договір бути письмовим?
Немає загальної вимоги до форми для всіх таких договорів, проте письмовий договір є важливим для доведення обсягу послуг та розподілу ризиків. Окремі частини можуть підпадати під власні вимоги, наприклад, вимоги GDPR щодо обов'язкового регулювання обробки даних.
Чи може постачальник змінювати функції протягом дії договору?
Це залежить від договору. Тому регулюйте право на внесення змін, порядок інформування клієнта та наслідки видалення чи суттєвої зміни важливих функцій.
Супутня допомога
Продовжуйте з посібником з SLA, SaaS-вихід та міграція даних, посібником з PUB/DPA та NIS2 та безпека постачальників.
Джерела та додаткова література
- Парламент Швеції: Закон про договори (1915:218)
- EUR-Lex: GDPR, особливо статті 28 та 32
- Парламент Швеції: Закон про кібербезпеку (2025:1506)
Посібник надає загальну інформацію. SaaS-договори потребують адаптації відповідно до конкретної послуги, ролей сторін, даних, ризиків та можливих галузевих вимог.