Політика захисту даних

Цей документ (“DPA”, Data Processing Addendum; далі — “Угода”) є додатком до “Умов обслуговування” та/або договору між клієнтом і провайдером FinDay OS. Його мета — чітко визначити правила обробки даних у моделі B2B, де клієнт використовує FinDay OS як Operating System фінансового дня.

Навіть якщо клієнт не підпадає під регулювання ЄС, DPA робить взаємодію прозорою: хто за що відповідає, як обмежується доступ, як управляються субпроцесори, як реагуємо на інциденти і як поводимося з даними при завершенні співпраці.

Провайдер FinDay OS.

Клієнт (Контролер): юридична особа/ФОП, що підключає FinDay OS.

Дата набрання чинності: 01 лютого 2026 року.
Цей DPA застосовується з моменту акцепту оферти або підписання договору та діє протягом строку надання послуг і визначеного періоду після припинення, необхідного для процедур повернення/видалення даних.

1. Ролі сторін

У межах цієї Угоди сторони погоджуються з таким розподілом ролей:

Клієнт виступає як контролер (володілець даних у практичному сенсі): він визначає цілі обробки, які дані вносити у FinDay OS, кого підключати, які ролі призначати, які правила процесу та облікової політики застосовувати. Клієнт несе відповідальність за законність збору та внесення даних до системи, включаючи наявність правових підстав щодо персональних даних, які можуть міститися у “контенті клієнта” (наприклад, контактні особи контрагентів).

Провайдер виступає як процесор: він обробляє дані від імені клієнта і для цілей надання сервісу FinDay OS, забезпечення безпеки, підтримки, відновлення та виконання договірних зобов’язань. Провайдер не визначає самостійно, які саме операційні фінансові дані клієнт має вести у системі, і не використовує контент клієнта для власних цілей, що не пов’язані з наданням сервісу, окрім випадків, прямо дозволених договором або законом (наприклад, захист від зловживань, безпека, виконання законних вимог).

Якщо в окремих випадках провайдер і клієнт стають спільними контролерами для конкретного виду даних (наприклад, дані контактних осіб для комунікацій щодо білінгу/підтримки), це не змінює загального принципу: контент клієнта — зона відповідальності клієнта, сервісна обробка — зона відповідальності провайдера як процесора.

2. Предмет і тривалість обробки

Предмет обробки — надання FinDay OS як SaaS для ведення операційного фінансового дня: фіксація документів, рухів, платежів як фактів обліку, зобов’язань, складських операцій, довідників, аналітики та контролю процесів.

Категорії даних (типово) включають:

Дані облікового запису користувачів: email, ім’я, роль, налаштування доступу, журнали входів.
Дані компанії клієнта та контрагентів: реквізити, довідники, налаштування, контактні особи (якщо клієнт вносить).
Операційний фінансовий контент: документи та рядки документів, суми, податки, залишки, рухи, реєстри, файли-вкладення, коментарі, метадані, аудиторські події.
Технічні дані: IP, device/user-agent, логування подій, діагностичні дані, метрики стабільності.

Операції обробки включають збирання (внесення), структуроване зберігання, перегляд/витягування, модифікацію, проведення операцій (як наслідок бізнес-логіки), формування звітів/вивантажень, резервне копіювання, відновлення, видалення/знищення, а також обмежену обробку для підтримки та безпеки.

Тривалість обробки: дані обробляються протягом строку активної підписки/доступу і додатковий період після припинення, необхідний для експорту, закриття фінансових питань і завершення циклу резервних копій, відповідно до Terms of Service/Privacy Policy та розділу 8.9 цієї Угоди.

3. Інструкції клієнта

Провайдер обробляє дані відповідно до інструкцій клієнта. У практичному сенсі інструкції реалізуються через механізми FinDay OS та робочі канали підтримки:

Клієнт визначає, які компанії/організації ведуться у системі, які довідники використовуються, які документи створюються, хто має доступ до яких розділів, і як виглядає процес погодження/проведення.
Клієнт керує ролями та правами доступу користувачів (адміністратор, бухгалтер/фінансист, перегляд тощо), призначає відповідальних осіб, налаштовує внутрішні правила, політики і структуру даних у межах доступного функціоналу.
Клієнт може надавати провайдеру інструкції через підтримку: наприклад, запит на відновлення доступу, відновлення даних із резервної копії (якщо це передбачено), допомога з міграцією/експортом, уточнення конфігурації. Провайдер може запитувати підтвердження повноважень адміністратора перед виконанням чутливих операцій.
Провайдер не виконує інструкції, які є незаконними, технічно небезпечними або можуть порушити права третіх осіб, безпеку сервісу чи інших клієнтів. У таких випадках провайдер повідомляє клієнта та пропонує безпечну альтернативу.

4. Технічні та організаційні заходи (TOMs)

FinDay OS застосовує технічні та організаційні заходи для захисту конфіденційності, цілісності та доступності даних. Детальний і актуальний опис — на сторінці “Безпека” (Security). Цей розділ надає короткий перелік принципів і мінімально необхідних категорій заходів.

Типові заходи включають:

Контроль доступу та ролі: розмежування прав, принцип найменших привілеїв, контроль адміністративних доступів.
Аутентифікація: вимоги до паролів, опційна/обов’язкова 2FA для критичних ролей (за політикою), захист сесій.
Журнали подій: аудит дій у системі, логування критичних операцій, відстеження змін.
Шифрування: захист каналу передачі даних, шифрування даних у сховищі або еквівалентні механізми захисту інфраструктури (залежно від архітектури).
Резервне копіювання та відновлення: регулярні backups, контроль циклу зберігання, процедури відновлення.
Інфраструктурна безпека: сегментація середовищ, оновлення, моніторинг, обмеження доступу до середовищ, захист від типових атак.
Процеси реагування: внутрішні процедури для інцидентів, контроль змін, управління вразливостями.

Уточнення: TOMs — це не перелік “обіцянок маркетингу”, а підхід. Конкретні технології можуть змінюватися з розвитком продукту без зниження рівня захисту.

5. Субпроцесори

Провайдер може залучати субпроцесорів для надання FinDay OS (наприклад, інфраструктура та хостинг, email-доставка, моніторинг/аналітика, системи підтримки, білінг). Субпроцесори отримують доступ лише в межах необхідного для надання послуг провайдеру, а провайдер несе відповідальність за їхній контроль у межах договорів і процедур.

Класи субпроцесорів (типово):

Хостинг / дата-центри / хмарна інфраструктура та сховища.
Email-провайдери для сервісних повідомлень.
Провайдери моніторингу/аналітики стабільності.
Сервіси підтримки (чат/тікети).
Провайдери білінгу/платежів за підписку (за наявності).

Про зміни у субпроцесорах провайдер повідомляє одним або кількома способами: через сторінку “Безпека/Субпроцесори”, через email адміністратора, через сервісні повідомлення в кабінеті або іншим погодженим каналом. Якщо клієнт має обґрунтовані заперечення щодо нового субпроцесора з позиції безпеки або комплаєнсу, сторони можуть погодити альтернативний шлях (якщо він технічно можливий) або клієнт може припинити використання сервісу відповідно до Terms of Service.

6. Інциденти та витоки

Провайдер підтримує процес реагування на інциденти безпеки. Якщо провайдер виявляє інцидент, який призвів або може призвести до несанкціонованого доступу, знищення, втрати, зміни або розкриття даних клієнта, провайдер повідомляє клієнта без невиправданої затримки через погоджені канали (email адміністратора/кабінет/підтримка).

Повідомлення зазвичай містить:

опис інциденту та його характер (що сталося і що підозрюється);
орієнтовний часовий проміжок події;
попередню оцінку категорій даних, яких могло стосуватися;
вжиті або заплановані заходи з локалізації/відновлення;
рекомендовані дії для клієнта (наприклад, скидання паролів, перевірка доступів, увімкнення 2FA).

Провайдер надає клієнту додаткову інформацію у міру її підтвердження, щоб клієнт міг виконати власні зобов’язання (внутрішнє повідомлення, оцінка ризиків, юридичні дії). Провайдер не розкриває інформацію, яка може створити додатковий ризик безпеці (наприклад, деталі, що дозволяють повторити атаку), але дає достатньо даних для управління ризиком клієнта.

7. Аудити

Клієнт може перевіряти відповідність провайдера базовим вимогам безпеки та захисту даних, але з урахуванням того, що FinDay OS — мультиорендний SaaS (multi-tenant), і прямий фізичний доступ до інфраструктури не є безпечним і практичним.

Типові форми аудиту:

надання політик і описів процесів (Security/Privacy/DPA), публічні сторінки “Безпека” та “Політика конфіденційності”;
відповіді на опитувальник безпеки клієнта (security questionnaire) у розумних межах;
надання узагальненого звіту або листа-підтвердження щодо впроваджених заходів (за запитом, за наявності);
за погодженням — сесія з технічним представником (Q&A) для корпоративного клієнта.

Провайдер має право відмовити у вимогах, які розкривають конфіденційну архітектуру, створюють ризик для інших клієнтів або фактично дорівнюють “пускати в датацентр”. Будь-який аудит має проводитися так, щоб не порушувати безпеку сервісу та права інших клієнтів.

8. Трансфер даних

Дані клієнта можуть зберігатися або оброблятися в інфраструктурі, яка фізично розташована в іншій країні, залежно від хостингу та субпроцесорів. У такому випадку провайдер застосовує принципи:

мінімізація і контроль доступу;
договірні зобов’язання конфіденційності із субпроцесорами;
безпекові заходи для захисту даних незалежно від локації;
прозорість щодо класів субпроцесорів та змін (див. 8.5).

Цей розділ не вводить складні юридичні механізми трансферу, якщо це не вимагається окремо договором або комплаєнсом клієнта. Для клієнтів, яким потрібні спеціальні умови (наприклад, вимога зберігання даних у конкретній країні), це узгоджується індивідуально і фіксується у договорі.

9. Видалення/повернення даних

Після припинення підписки або розірвання договору клієнт має право отримати свій контент у вигляді експорту, якщо це передбачено тарифом або узгоджено сторонами. Експорт може здійснюватися через функціонал сервісу або через підтримку у погодженому форматі.

Після завершення співпраці провайдер видаляє або знищує контент клієнта відповідно до політики зберігання даних, визначеної Terms of Service / Privacy Policy, з урахуванням “післявидаленого вікна” для відновлення 30 днів та циклу резервних копій.

Клієнт розуміє, що резервні копії можуть зберігати дані протягом певного часу до перезапису. Провайдер не відновлює і не “витягує” дані з архівних резервних копій як стандартну послугу, якщо інше не погоджено окремо (оскільки це може бути технічно складно та ризиковано). Винятки можливі в рамках інцидентів або спеціальних умов договору.

На запит клієнта провайдер може підтвердити виконання видалення в межах стандартних процедур.