Ваша роль і наша
Коли ви користуєтесь Zvitly, зустрічаються дві ролі. Щодо даних ваших власних клієнтів, постачальників і працівників ви є Verantwortlicher (розпорядник) у розумінні Art. 4 Z 7 DSGVO: ви вирішуєте, які дані збирати і навіщо. Zvitly щодо цих даних є Auftragsverarbeiter (обробник) за Art. 4 Z 8 DSGVO — ми зберігаємо й обробляємо їх виключно за вашими вказівками і ніколи для власних цілей.
Це розмежування — не формальність. Воно визначає, хто має відповісти на запит про доступ, хто повідомляє наглядовий орган про витік і хто за це відповідає. Коротко: щодо даних усередині вашого кабінету Zvitly за кермом ви, ми — двигун.
| Про що йдеться | Verantwortlicher (розпорядник) | Auftragsverarbeiter (обробник) |
|---|---|---|
| Дані, які ви вносите в Zvitly: клієнти, постачальники, чеки, банківські транзакції, працівники | Ви | Zvitly |
| Ваші власні дані акаунта й договору: пошта, ім'я, дані підприємства | Zvitly | — |
| Відвідування сайту zvitly.io | Zvitly | — |
Рядки 2 і 3 описує не ця сторінка, а Datenschutzerklärung (політика приватності). Datenschutzerklärung
Договір про обробку (AVV)
Art. 28 Abs 3 DSGVO вимагає, щоб будь-яка обробка за дорученням ґрунтувалась на договорі. Без нього вже саме користування є порушенням — і порушенням вашим, а не нашим, бо цей обов'язок покладено на розпорядника. Тому Auftragsverarbeitungsvertrag (AVV, у міжнародній практиці DPA) — не додаткова послуга, а передумова користування.
Як укласти його з нами
- Напишіть на вказану нижче адресу з темою «AVV» і зазначте назву компанії, адресу та e-mail вашого акаунта Zvitly.
- Ви отримаєте чинну редакцію AVV у PDF для ознайомлення. За змістом вона збігається з цією сторінкою, але сторінка договору не замінює.
- Договір укладається в текстовій формі. Art. 28 Abs 9 DSGVO прямо дозволяє електронний формат; підпис на папері не потрібен.
Укладення безкоштовне на всіх тарифах, включно з безкоштовним користуванням. Укласти договір прямо в кабінеті наразі не можна — шлях через електронну пошту.
Зміст AVV за Art. 28 Abs 3 DSGVO
Art. 28 Abs 3 DSGVO встановлює, що має бути в AVV. Дві таблиці нижче відтворюють цей перелік повністю: спершу основні параметри обробки, далі обов'язки за lit a — h.
| Що вимагає закон | Як це виглядає в Zvitly |
|---|---|
| Предмет | Надання програмного забезпечення Zvitly за моделлю software-as-a-service для бухгалтерії, виставлення рахунків і підготовки податкової звітності, включно зі зберіганням внесених вами даних. |
| Тривалість | На строк дії вашого договору користування. Далі діє концепція видалення нижче; законні строки зберігання лишаються незмінними. |
| Характер обробки | Збирання, зберігання, впорядкування, зчитування — зокрема автоматичне розпізнавання завантажених зображень чеків, — зміна, поєднання, експорт і видалення; автоматизовано, у нашій інфраструктурі та в інфраструктурі наших субпроцесорів. |
| Мета | Виключно надання обумовленої договором послуги та її технічна експлуатація. Жодного профілювання, реклами, передання чи тренування моделей ШІ на ваших даних. |
| Види персональних даних | Основні дані (ім'я, адреса, UID, контакти), дані рахунків і чеків, платіжні та банківські транзакції, за потреби — зарплатні дані працівників. Залежно від того, що ви вносите. |
| Категорії суб'єктів даних | Ваші клієнти й постачальники та їхні контактні особи, ваші працівники, ви самі та інші користувачі вашого акаунта. |
| Особливі категорії (Art. 9) | Не передбачені. Zvitly не запитує ні даних про здоров'я, ні інших особливих категорій. Якщо ви все ж внесете такі дані — наприклад, у поле вільного тексту, — це відбувається за вашим рішенням і під вашу відповідальність. |
| Літера | Чого вимагає Art. 28 | Як це виконує Zvitly |
|---|---|---|
| lit a — зв'язаність вказівками | Обробка лише за задокументованими вказівками розпорядника, зокрема й щодо передач у треті країни. | Вашими вказівками є договір користування, цей AVV і те, як ви користуєтесь продуктом. Інші вказівки приймаємо в текстовій формі. Якщо ми вважаємо вказівку протиправною, ми повідомляємо вам про це й не виконуємо її до з'ясування. |
| lit b — конфіденційність | Залучення лише осіб, зобов'язаних до конфіденційності. | Доступ має лише той, кому він потрібен для експлуатації чи підтримки; усі залучені зобов'язані до нерозголошення. Адміністративний доступ безвиключно вимагає двофакторної автентифікації та повністю протоколюється. |
| lit c — безпека | Вжити всіх заходів, яких вимагає Art. 32. | Перелічені по пунктах у розділі про технічні й організаційні заходи. |
| lit d — субпроцесори | Залучення інших обробників лише за умов Art. 28 Abs 2 і 4. | Ви надаєте загальний дозвіл; чинний перелік — нижче. Про зміни ми повідомляємо заздалегідь, і ви можете заперечити. Залучені нами постачальники зв'язані тими самими обов'язками, що й ми, і ми за них відповідаємо. |
| lit e — права суб'єктів даних | Допомога розпоряднику із запитами за главою III. | На запит ми збираємо дані, що зберігаються про конкретну особу, і виконуємо видалення й блокування, які ви не можете зробити самі в продукті. |
| lit f — допомога за Art. 32 — 36 | Допомога з безпекою, повідомленнями та оцінкою впливу. | Ми невідкладно повідомляємо вас про інциденти й надаємо дані, потрібні для вашого власного повідомлення наглядовому органу. Для оцінки впливу надаємо опис нашої обробки. |
| lit g — видалення або повернення | Після завершення надання послуги видалити або повернути дані на вибір розпорядника. | Після завершення договору ви на запит отримуєте свої дані в поширеному машинозчитуваному форматі; далі ми їх видаляємо, якщо цьому не перешкоджає законний обов'язок зберігання. |
| lit h — підтвердження й перевірка | Надати всю інформацію для підтвердження виконання обов'язків, уможливити перевірки й сприяти їм. | Ця сторінка, AVV і відповіді на запит; про право перевірки — у розділі «Підтвердження й перевірка». |
Субпроцесори
Zvitly залучає перелічених нижче субпроцесорів. Перелік повний і містить лише тих постачальників, з якими справді укладено договір за Art. 28 DSGVO.
| Постачальник | Роль | Місце обробки | Підстава за наявності третьої країни | Договір |
|---|---|---|---|---|
| Supabase Inc. (США) | База даних, автентифікація, файлове сховище | AWS eu-central-1, Франкфурт-на-Майні (Німеччина) | Стандартні договірні положення за Art. 46 Abs 2 lit c DSGVO — для адміністративного доступу американської компанії | supabase.com/legal/dpa |
| Resend (США) | Надсилання системних листів: підтвердження, скидання пароля, сповіщення | Надсилання з європейського регіону Ірландія (eu-west-1), де верифіковано домен zvitly.io. Дані акаунта, метадані доставки й журнали — у США | Рішення про адекватність за Art. 45 DSGVO — Resend сертифікований за EU-US Data Privacy Framework. Додатково DPA містить стандартні договірні положення за Art. 46 Abs 2 lit c DSGVO; право й суди — Ірландія | resend.com/legal/dpa |
| Hostinger International Ltd. (Кіпр, ЄС) | Хостинг застосунку | Європейський Союз | Передачі в треті країни немає | hostinger.com/legal/dpa |
| Amazon Web Services (Amazon Bedrock) | Автоматичне розпізнавання завантажених зображень чеків: продавець, дата, суми, ставка податку та пропозиція категорії | Дата-центри в ЄС — EU-профіль інференсу, вихідний регіон eu-central-1, Франкфурт-на-Майні (Німеччина) | Стандартні договірні положення за Art. 46 Abs 2 lit c DSGVO у договорі постачальника про обробку — щодо адміністративного доступу з боку американського концерну | d1.awsstatic.com/legal/aws-dpa/aws-dpa.pdf |
Технічні й організаційні заходи (Art. 32)
Art. 32 DSGVO вимагає заходів, співмірних із ризиком, — і вимагає, щоб вони були впроваджені, а не лише заплановані. Тому перелік нижче описує тільки те, що справді працює в продукті.
| Напрям | Захід | Як реалізовано |
|---|---|---|
| Контроль входу | Автентифікація | Вхід за поштою і паролем. Паролі зберігаються лише у вигляді хешу й нам не доступні для читання. Мінімальна довжина у вісім символів перевіряється на сервері, а не лише у формі. |
| Контроль входу | Двофакторна автентифікація | У кабінеті вмикається двофакторна автентифікація на основі TOTP. Поки вона активна, кожен вхід обов'язково вимагає другого фактора; зняти підтверджений фактор можна лише з сесії, яку саму вже підтверджено другим фактором. |
| Контроль доступу до даних | Ізоляція тенантів | Кожна таблиця прикладної схеми має ввімкнений Row Level Security — розмежування живе в самій базі даних, а не лише в коді застосунку. Доступ іде через перевірочну функцію, яка допускає лише активні членства в тенанті, що не заблокований і не видалений. Ідентифікатор тенанта завжди береться із сесії й ніколи із запиту — навіть якщо запит його містить. |
| Контроль доступу до даних | Файли | Чеки, банківські виписки, рахунки й експорти лежать у непублічних сховищах; доступ обмежено текою вашого тенанта тією самою перевіркою. Завантаження обмежені дозволеними типами файлів і розмірами. |
| Контроль адміністративного доступу | Доступ адміністратора | Доступ до внутрішньої панелі керування вимагає трьох незалежних умов: увімкненої функції, ознаки адміністратора, яку можна виставити лише безпосередньо в базі даних, і сесії, підтвердженої другим фактором. Бракує хоча б однієї — у доступі відмовлено. |
| Простежуваність | Журнал адміністративних дій | Кожна адміністративна дія фіксується з часом, особою, тенантом, IP-адресою та результатом — включно з невдалою спробою. Якщо запис у журнал не вдається, дія не виконується; обійти це неможливо. Через інтерфейс застосунку журнал не змінити й не видалити. |
| Контроль передавання | Шифрування під час передавання | Виключно TLS/HTTPS — між браузером і застосунком, між застосунком, базою даних, файловим сховищем і сервісом розпізнавання чеків, а також при надсиланні кожного листа. Для пошти транспортне шифрування переведено в режим «примусово»: якщо приймальний сервер не приймає шифрованого з'єднання, лист не доставляється, а не йде відкритим текстом. Конфіденційність тут свідомо переважає над відсотком доставки. |
| Контроль зберігання | Шифрування у спокої | База даних і файлове сховище розміщені в Supabase на AWS у регіоні eu-central-1 (Франкфурт-на-Майні) і зберігаються зашифрованими на рівні платформи. |
| Контроль введення | Перевірка вхідних даних | Усі записувальні виклики програмного інтерфейсу перевіряють тип і вміст кожного поля на сервері. Будь-який змінювальний запит додатково перевіряє своє походження й відхиляється, якщо походження чуже, — це захист від запитів, які чужий сайт ініціює від імені авторизованої людини. |
| Протидія зловживанням | Обмеження частоти запитів | Реєстрація та скидання пароля обмежені п'ятьма запитами на п'ятнадцять хвилин з однієї IP-адреси й одним запитом на шістдесят секунд на одну поштову адресу. Якщо потрібний серверний ключ відсутній, дія блокується, а не пропускається без захисту. |
| Псевдонімізація | Лічильники протидії зловживанням | Для цього обмеження ні IP-, ні поштова адреса не зберігаються у відкритому вигляді — лише як HMAC-SHA256 із серверним секретом, якого немає в базі даних. Тому із самих лише даних бази неможливо дізнатися, хто входив. |
| Захист акаунта | Захист від перехоплення акаунта | Вхід і «забули пароль» відповідають однаково незалежно від того, чи існує адреса, — з відповіді не можна дізнатися, які адреси зареєстровані. Змінити пароль, не знаючи попереднього, можна лише протягом п'ятнадцяти хвилин після переходу за посиланням із листа; старої відкритої сесії для цього недостатньо. |
| Розділення ключів | Поводження із секретами | Ключ бази даних, здатний обійти ізоляцію тенантів, існує лише на сервері й захищений від потрапляння в браузер двома незалежними бар'єрами. Використовується він виключно через шар керування, що веде журнал. |
| Доступність | Резервне копіювання й відновлення | База даних щодня автоматично резервується на рівні платформи. |
| Видалення | Анонімізація акаунтів | Для акаунтів передбачено анонімізацію: вона незворотно затирає ім'я, пошту, телефон, адресу, облікові дані до державних порталів і банківські підключення, лишаючи документи, що підлягають зберіганню, без прив'язки до особи. IP-адреси в журналах затираються разом із ними. |
Порушення захисту персональних даних
Якщо нам стане відомо про порушення захисту персональних даних, що зачіпає ваші дані, ми невідкладно повідомимо вас, як цього вимагає Art. 33 Abs 2 DSGVO. «Невідкладно» на практиці означає протягом 24 годин з моменту, коли ми дізналися, — щоб від ваших власних 72 годин лишилося достатньо.
Що робимо ми
- Локалізуємо інцидент і встановлюємо його обсяг.
- Повідомляємо вас як розпорядника — із зазначенням характеру інциденту, категорій зачеплених даних, приблизної кількості суб'єктів, ймовірних наслідків і вжитих заходів (Art. 33 Abs 3 DSGVO).
- Дописуємо відомості, яких на момент першого повідомлення ще не було: поетапне повідомлення допускається, а для великих інцидентів є звичайною практикою.
- Документуємо інцидент у себе й усуваємо причину.
Шлях подання в Австрії: онлайн-форма або PDF-форма Datenschutzbehörde, як альтернатива — лист на dsb@dsb.gv.at чи поштою на адресу Österreichische Datenschutzbehörde, Barichgasse 40–42, 1030 Wien.
Права суб'єктів даних на практиці
Запити суб'єктів даних адресовані вам, бо розпорядник — ви. Наше завдання — зробити їх виконання можливим. У таблиці для кожного права вказано, що ви можете зробити самі в кабінеті, а для чого потрібні ми.
| Право | Норма | Як ви його реалізуєте |
|---|---|---|
| Доступ | Art. 15 DSGVO | Дані клієнтів, рахунків і чеків ви бачите в кабінеті й можете зібрати їх звідти. По даних, що лежать лише в системних журналах, зверніться до нас — ми їх надамо. |
| Виправлення | Art. 16 DSGVO | Основні дані ваших клієнтів і постачальників ви редагуєте прямо в кабінеті. |
| Видалення | Art. 17 DSGVO | Записи без бухгалтерської прив'язки ви видаляєте самі. На чеки й рахунки поширюється обов'язок зберігання — див. концепцію видалення. |
| Обмеження обробки | Art. 18 DSGVO | За вашою вказівкою ми блокуємо окремі записи для подальшої обробки. |
| Переносимість даних | Art. 20 DSGVO | Експорт даних, що зберігаються про конкретну особу, у поширеному машинозчитуваному форматі ми надаємо на запит. |
| Заперечення | Art. 21 DSGVO | Заперечення адресується вам. Те, що з нього випливає — блокування чи видалення, — ми виконуємо за вашою вказівкою. |
Концепція видалення
Скільки живуть дані, вирішує не смак, а мета й закон. Для бухгалтерських даних закон суворіший за бажання видалити — і закон має перевагу.
| Категорія даних | Видалення | Підстава |
|---|---|---|
| Чеки, рахунки, проводки, подання звітності | Сім років від кінця календарного року, за який зроблено останній запис, — далі видалення. | § 132 BAO; Art. 17 Abs 3 lit b DSGVO у цій частині відступає перед обов'язком зберігання. |
| Основні дані клієнтів і постачальників без прив'язки до документа | За вашою вказівкою негайно. | Законного обов'язку зберігання немає. |
| Завантажені файли: зображення чеків, банківські виписки | Разом із бухгалтерськими даними, до яких вони належать. | Складова первинного документа. |
| Облікові дані до державних порталів, банківські підключення | Негайно при розриві підключення або анонімізації акаунта. | Обов'язку зберігання немає, а ризик високий — мінімізація даних за Art. 5 Abs 1 lit c. |
| Журнал адміністративних дій | Не видаляється; персональна складова (IP-адреса) затирається при анонімізації. | Доказова функція за Art. 28 Abs 3 lit h і підзвітність за Art. 5 Abs 2. |
| Лічильники протидії зловживанням | Ковзно, після спливу відповідного вікна; і так зберігаються лише як хеш. | Мета відпадає. |
| Акаунт після завершення договору | Анонімізація: прив'язку до особи затерто, документи з обов'язковим зберіганням лишаються без персональних даних. | Розв'язання конфлікту між Art. 17 DSGVO і § 132 BAO. |
Строки для даних, які Zvitly обробляє як розпорядник — акаунт, контакт, сайт, — наведені в Datenschutzerklärung. Datenschutzerklärung
Передача в треті країни
Ваші бухгалтерські дані не залишають Європейського Союзу. База даних і файли лежать у Франкфурті-на-Майні, застосунок працює на серверах у ЄС, автоматичне розпізнавання чеків іде через профіль інференсу Amazon Web Services, що обмежує обробку дата-центрами в ЄС, а системні листи надсилаються з європейського регіону Ірландія (eu-west-1), де верифіковано домен zvitly.io. Звʼязок із третьою країною виникає виключно щодо службових даних постачальників, які є американськими компаніями або належать до американського концерну: у Supabase та Amazon Web Services — адміністративний доступ відповідного постачальника до власної платформи, у Resend — дані акаунта, метадані доставки й журнали, тобто запис про те, ЩО лист доставлено, а не чеки, рахунки чи дані ваших клієнтів.
Ці передачі правомірні на підставі DSGVO — а не просто терпимі. Resend сертифікований за EU-US Data Privacy Framework, щодо якого Європейська Комісія 10 липня 2023 року ухвалила рішення про адекватність за Art. 45 DSGVO; передача на цій підставі не потребує додаткового дозволу наглядового органу. Незалежно від цього договори про обробку всіх трьох постачальників містять стандартні договірні положення Комісії за Art. 46 Abs 2 lit c DSGVO, доповнені технічними заходами: примусовим транспортним шифруванням, шифруванням у спокої, а також зберіганням і обробкою в ЄС. До договору з Resend застосовується ірландське право та ірландська підсудність.
Оцінка впливу на захист даних (Art. 35)
Datenschutz-Folgenabschätzung (DSFA — оцінка впливу на захист даних) за Art. 35 DSGVO потрібна не завжди. Вона обов'язкова, якщо обробка ймовірно спричинить високий ризик для прав і свобод фізичних осіб — зокрема при систематичному й усебічному оцінюванні особистих аспектів, при масштабній обробці особливих категорій за Art. 9 або при систематичному спостереженні за загальнодоступними місцями у великому обсязі.
Для типового використання Zvitly — бухгалтерії ФОП або малого підприємства — DSFA, на нашу оцінку, не потрібна:
- Немає автоматизованих рішень із правовими наслідками й немає профілювання в розумінні Art. 22 DSGVO.
- Особливі категорії за Art. 9 не передбачені й не запитуються.
- Обробка обмежена господарськими операціями одного підприємства й тому не є «масштабною» в розумінні пункту 91 преамбули.
Реєстр операцій обробки (Art. 30 Abs 2)
Як обробник ми ведемо власний реєстр усіх операцій обробки, що виконуються за дорученням розпорядників (Art. 30 Abs 2 DSGVO). Він містить:
| Що вимагає закон | Як це в Zvitly |
|---|---|
| lit a — назва й контактні дані обробника та кожного розпорядника, за дорученням якого він діє | Наші дані наведено в Impressum; розпорядники — наші клієнти, зафіксовані через дані їхніх акаунтів. |
| lit b — категорії обробки, що виконуються за дорученням | Зберігання й обробка бухгалтерських даних, рахунків, чеків і банківських операцій, автоматичне розпізнавання завантажених зображень чеків, а також надсилання системних листів. |
| lit c — передачі в треті країни разом із гарантіями | Як описано в розділі про передачу в треті країни. |
| lit d — загальний опис заходів за Art. 32 Abs 1 | Як описано в розділі про технічні й організаційні заходи. |
Виняток Art. 30 Abs 5 DSGVO для підприємств із менш ніж 250 працівниками тут не діє: обробка не є епізодичною. На запит ми надаємо реєстр наглядовому органу і вам.
Підтвердження й перевірка
Art. 28 Abs 3 lit h DSGVO дає вам право перевіряти дотримання цього договору. Ми забезпечуємо його в такій послідовності — від найлегшої форми до найбільш втручальної:
- Самозвіт: ця сторінка й AVV описують обробку та заходи. Для більшості перевірок цього достатньо.
- Письмова відповідь: на конкретні запитання відповідаємо в текстовій формі протягом 30 днів, включно з підтвердженнями щодо окремих заходів.
- Перевірка на місці: після попередження в розумний строк, у звичайні робочі години, не частіше ніж раз на рік і без порушення роботи — вами або призначеним вами аудитором, зобов'язаним до нерозголошення й таким, що не є нашим конкурентом. Перевірки, викликані інцидентом, цим обмеженням не охоплюються.
Сертифікатів третіх сторін — на кшталт ISO 27001 чи звіту SOC 2 — для самої Zvitly немає. Для залучених постачальників вони доступні через їхні портали довіри.
Ваші власні обов'язки як підприємця
AVV із нами — одна цеглина вашого комплаєнсу, а не весь він. Шість запитань нижче — це ті, які нам справді ставлять, із відповідями, що стосуються австрійського малого бізнесу й ФОП.
Чи потрібен мені як ФОП власний реєстр операцій обробки?
Чи потрібен мені уповноважений із захисту даних?
Що я маю сказати своїм власним клієнтам?
Як швидко я маю відповісти на запит про доступ?
А якщо дані загубив я сам — скажімо, ноутбук?
Чи потрібні AVV і з іншими постачальниками?
Коротка чеклиста
- AVV із Zvitly укладено.
- AVV з усіма іншими постачальниками укладено.
- Власний реєстр операцій обробки за Art. 30 Abs 1 створено.
- Власну політику приватності за Art. 13 опубліковано.
- Перевірено, чи потрібні уповноважений із захисту даних або DSFA, — і результат зафіксовано.
- Визначено, хто що робить при інциденті, і записано строк у 72 години.
Цей огляд є орієнтиром і не замінює юридичної консультації. Zvitly не є ні податковим радником, ні адвокатом.
Контакт і редакція
Питання щодо обробки за дорученням, запит AVV, повідомлення про інцидент чи допомога із запитом суб'єкта даних — на вказану нижче адресу, зі словом «Datenschutz» у темі листа. Уповноваженого із захисту даних Zvitly не призначала: умов Art. 37 Abs 1 DSGVO немає. На запити відповідає керівництво.
- Фірма
- WENEXUS Consulting GmbH
- Адреса
- Fleischmarkt 14/5a
1010 Wien
Österreich - zvitly@wenexus.at
Ця редакція діє від зазначеної вище дати й замінює всі попередні. Юридично чинною є німецька редакція.
Юридично чинною є німецька редакція цього документа. Переклади наведені для зручності й самостійної сили не мають; у разі розбіжностей діє німецький текст.