Юридично обов'язковою є німецька версія.

Угода про обробку даних за дорученням (ст. 28 GDPR)

Редакція 2026-10, станом на 13 жовтня 2026 року.

Ця угода (далі — «ADV») діє між Клієнтом і зазначеним у вихідних даних (Impressum) Постачальником todo.monster. Клієнт є контролером (ст. 4 п. 7 GDPR — Загального регламенту про захист даних): він вирішує, які дані потрапляють у todo.monster і для чого. Постачальник є обробником (ст. 4 п. 8 GDPR): він зберігає та обробляє ці дані лише для Клієнта. Хто є сторонами і хто їх представляє, випливає з договору про користування todo.monster (далі — «Основний договір»: Загальні умови надання послуг із замовленим тарифом або пілотна угода).

Сфера застосування та порядок пріоритету

(1) todo.monster призначений лише для підприємців (§ 14 BGB — Цивільного кодексу Німеччини). Ця ADV укладається під час реєстрації разом із Загальними умовами надання послуг. Вона набирає дії, щойно в проєктах, розділах фірми, поштових скриньках або календарях Клієнта з'являються дані інших осіб, наприклад ім'я потенційного клієнта в завданні, постачальниця як відправниця електронного листа або учасники зустрічі. Якщо Клієнт обробляє там лише власні дані, ця ADV не породжує жодних обов'язків.

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

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

(4) Обов'язковою є лише німецька редакція. Переклади допомагають зрозуміти текст; у разі розбіжностей діє німецький текст.

(5) Клієнт укладає цю ADV в електронній формі (ст. 28 абз. 9 GDPR), підтверджуючи її під час реєстрації. Якщо згодом він замовляє тариф для фірми або укладає пілотну угоду, він повторно підтверджує чинну на той момент редакцію. Для кожного підтвердження Постачальник зберігає редакцію, момент часу та контрольну суму підтвердженого тексту.

§ 1 Предмет і тривалість

(1) Постачальник надає Клієнту todo.monster як програмне забезпечення через Інтернет. До цього належать: завдання та проєкти, облік часу, коментарі та вкладення, поштові скриньки фірми, а також поштові скриньки та календарі, які підключають Клієнт або його користувачі, сповіщення, перетворення електронного листа на завдання за допомогою ШІ (лише якщо його запускає користувач) і повідомлення про помилки зі знімком екрана. Обробка при цьому означає: зберігати, відображати, передавати на обрані Клієнтом зовнішні сторони (наприклад, надсилати відповідь через підключену поштову скриньку), створювати резервні копії, переміщувати в кошик і допомагати в підтримці. Що саме відбувається з якими даними, описано в Додатку A.

(2) Ця ADV діє стільки ж, скільки й Основний договір. Вона припиняється лише тоді, коли дані повернуто або видалено згідно з § 11.

§ 2 Характер і мета обробки, види даних, суб'єкти даних

Що Постачальник робить з якими даними, з якою метою, про які види даних ідеться і яких осіб це стосується, описано в Додатку A, упорядкованому за функціями Сервісу.

§ 3 Вказівки

(1) Постачальник обробляє дані Клієнта лише для надання Сервісу відповідно до договору і лише так, як Клієнт розпоряджається через цю угоду, Загальні умови та користування Сервісом. Кожне введення, налаштування та запуск функції в Сервісі вважається вказівкою. Лише якщо закон ЄС або Німеччини зобов'язує Постачальника до іншої обробки, наприклад до передачі даних органу влади або до зберігання даних рахунків, він може від цього відступити. У такому разі він попередньо інформує Клієнта, якщо закон цього не забороняє.

(2) Вказівками є, наприклад: створити, змінити або видалити завдання; запросити учасника або гостя; підключити поштову скриньку або календар стороннього провайдера; запустити функцію ШІ для окремого електронного листа; надіслати повідомлення про помилку зі знімком екрана; запустити експорт даних. Постачальник тоді робить саме те, що обіцяє функція, і нічого понад це.

(3) Якщо Клієнт бажає чогось, що не охоплене жодною функцією Сервісу, наприклад відновлення проєкту, якого він більше не знаходить у кошику, він надсилає вказівку в текстовій формі на support@todo.monster. Вказівки надає сам Клієнт; для фірми в todo.monster — її власник та призначені в управлінні фірмою адміністратори. Постачальник підтверджує отримання та фіксує, що і коли він виконав.

(4) Відновлення: видалені проєкти, модулі, завдання, поштові скриньки та календарі зберігаються в кошику протягом строку, зазначеного в Додатку B, пункт 3. Там Клієнт і його уповноважені користувачі відновлюють їх самостійно. Якщо Клієнт просить Постачальника про відновлення, це є вказівкою згідно з абзацом 3. Постачальник виконує її, якщо дані технічно ще наявні; строку або результату він обіцяти не може. Які дані Постачальник при цьому бачить, описано в Додатку B, пункт 5.

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

§ 4 Обов'язки Клієнта

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

(2) Якщо Клієнт веде фірму в todo.monster, він сам призначає ролі (власник, адміністратор, учасник, гість) і відкликає їх, коли хтось вибуває. Він повідомляє своїм користувачам, що їхній вміст у розділах фірми належить фірмі.

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

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

(5) Не призначені для todo.monster особливі категорії даних (ст. 9 GDPR, наприклад дані про здоров'я), дані про кримінальні правопорушення (ст. 10 GDPR) та дані, що підпадають під професійну таємницю (§ 203 StGB — Кримінального кодексу Німеччини, наприклад справи клієнтів адвокатської контори). Якщо Клієнт усе ж бажає обробляти такі дані, він попередньо погоджує це з Постачальником у текстовій формі.

(6) Клієнт підтримує адресу електронної пошти свого облікового запису в актуальному стані, для фірми — адресу власника фірми. На цю адресу надходять повідомлення згідно з § 7 та § 10.

§ 5 Конфіденційність

Усі особи, які у Постачальника можуть мати справу з даними Клієнта, письмово зобов'язані дотримуватися конфіденційності або підпадають під законний обов'язок збереження таємниці (ст. 28 абз. 3 літ. b GDPR). Цей обов'язок діє й після закінчення їхньої діяльності. До вмісту Клієнта вони й так отримують доступ лише у випадках, вичерпно зазначених у Додатку B, пункт 5.

§ 6 Технічні та організаційні заходи

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

(2) Постачальник може розвивати заходи далі, доки захист від цього не погіршується. Істотні зміни він фіксує; актуальна редакція Додатка B розміщена на цій сторінці.

§ 7 Субобробники

(1) Постачальник може залучати компанії, зазначені в Додатку C, розділ 1, наприклад хостера, на якому працює база даних. Реєструючись, Клієнт схвалює цей перелік (загальний дозвіл, ст. 28 абз. 2 GDPR).

(2) Якщо Постачальник бажає додати ще одну компанію або замінити одну з них, він попередньо надсилає Клієнту системний електронний лист на адресу згідно з § 4 абз. 6 та оновлює Додаток C. Клієнт має 30 днів з моменту отримання, щоб заперечити з міркувань захисту даних у текстовій формі. До того зміна для нього не набирає чинності.

(3) Якщо Клієнт заперечує, він може розірвати Основний договір на момент набрання зміною чинності. Повернення та видалення регулюються § 11.

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

(5) На кожного субобробника Постачальник за договором покладає ті самі обов'язки щодо захисту даних, які він сам має за цією ADV, насамперед достатні захисні заходи (ст. 28 абз. 4 GDPR). Якщо субобробник щось не виконує, Постачальник відповідає за це перед Клієнтом як за власне невиконання.

(6) Субобробниками не є одержувачі, зазначені в Додатку C, розділ 2, які не отримують даних з доручення, та сервіси, зазначені в Додатку C, розділ 3, які Клієнт або його користувачі підключають самостійно.

§ 8 Сприяння у реалізації прав суб'єктів даних

(1) Якщо особа звертається до Клієнта з проханням про доступ, виправлення, видалення, обмеження або перенесення своїх даних або заперечує проти обробки (глава III GDPR), Постачальник допомагає Клієнту відповісти на запит (ст. 28 абз. 3 літ. e GDPR). Першим засобом є функції Сервісу: пошук і відображення, редагування та видалення вмісту, видалення учасників і гостей та експорт даних (§ 11 абз. 3). Приклад: якщо колишній діловий партнер вимагає доступу, Клієнт сам шукає його ім'я у своїх проєктах і поштових скриньках. Якщо цього недостатньо, Постачальник допомагає за запитом у текстовій формі; за це він може вимагати розумну винагороду залежно від витрат, крім випадків, коли запит зумовлений помилкою Постачальника.

(2) Якщо особа звертається безпосередньо до Постачальника і йдеться про дані, які Постачальник обробляє для Клієнта, Постачальник негайно пересилає запит Клієнту і не відповідає на нього сам. Особі він повідомляє, що переслав запит.

§ 9 Сприяння у виконанні обов'язків за ст. 32–36 GDPR

Постачальник допомагає Клієнту виконувати його обов'язки за ст. 32–36 GDPR (ст. 28 абз. 3 літ. f GDPR): щодо безпеки обробки — заходами, описаними в Додатку B, щодо порушень захисту даних — повідомленням згідно з § 10, а також наданням інформації про обробку, якщо Клієнт проводить оцінку впливу на захист даних або має попередньо консультуватися зі своїм наглядовим органом. При цьому він враховує, що йому відомо про обробку і як вона відбувається. Запити надсилаються в текстовій формі на support@todo.monster.

§ 10 Повідомлення про порушення захисту персональних даних

(1) Якщо Постачальнику стає відомо про порушення захисту персональних даних, яке стосується даних Клієнта, наприклад про несанкціонований доступ до бази даних або витік із резервної копії, він невідкладно повідомляє про це Клієнта на адресу згідно з § 4 абз. 6 (ст. 33 абз. 2 GDPR). Він повідомляє настільки швидко, щоб Клієнт міг дотримати власного строку в 72 години перед наглядовим органом (ст. 33 абз. 1 GDPR).

(2) Повідомлення містить, наскільки Постачальнику вже відомо: що сталося, які види даних і приблизно скільки осіб та записів зачеплено, які наслідки ймовірні, що Постачальник зробив і пропонує, а також хто є контактною особою у Постачальника (ст. 33 абз. 3 GDPR). Те, чого він ще не знає, він надає додатково, щойно дізнається.

(3) Постачальник негайно убезпечує дані, обмежує шкоду та узгоджує подальші кроки з Клієнтом.

§ 11 Закінчення доручення, повернення та видалення

(1) Для фірми доручення закінчується, коли тариф для фірми або пілотну угоду розірвано чи іншим чином припинено без безпосереднього переходу в інший тариф для фірми, або коли фірму ліквідовано (далі — «закінчення договору»). Перехід між тарифами для фірми або з пілотної угоди в тариф для фірми доручення не припиняє. Для Клієнта без фірми доручення закінчується, коли він видаляє свій обліковий запис; цей порядок описаний у Політиці конфіденційності.

(2) Після закінчення договору власник фірми ще 30 днів може читати та експортувати дані фірми. Протягом цього часу він самостійно повертає дані через експорт фірми. Якщо Клієнт натомість бажає негайного видалення даних, він повідомляє про це Постачальника в текстовій формі; Постачальник тоді видаляє невідкладно. Так Клієнт має вибір між поверненням і видаленням (ст. 28 абз. 3 літ. g GDPR).

(3) Експорт фірми є способом повернення: власник фірми завантажує архів у поширених машиночитаних форматах (JSON, CSV) з проєктами, модулями, завданнями, коментарями, записами часу, призначеннями, тегами, правилами повторення, історією змін і вкладеннями. Не входять вміст поштових скриньок фірми та підключених поштових скриньок, календарі та зустрічі, рахунки та квитанції, а також профілі інших осіб. Якщо Клієнту потрібен вміст поштових скриньок або календарів, він запитує його в текстовій формі протягом 30 днів згідно з абзацом 2; Постачальник надає його протягом 30 днів після отримання запиту, якщо він ще наявний. Клієнти без фірми користуються персональним експортом даних у тому самому обсязі для своїх власних проєктів.

(4) Рахунки та квитанції, які Постачальник виставив Клієнту як контролер, залишаються доступними в обліковому записі в будь-який час; вони не належать до доручення.

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

(6) Особисті облікові записи учасників і гостей закінчення договору не зачіпає; їхні власні дані поза фірмою залишаються в їхніх облікових записах. Не видаляються дані, які Постачальник як контролер зобов'язаний зберігати: рахунки та квитанції (§ 147 AO, § 257 HGB), протоколи про надані згоди та журнали аудиту без даних вмісту. Щодо цих даних після закінчення договору діє вже не ця ADV, а Політика конфіденційності.

(7) На запит Постачальник підтверджує видалення в текстовій формі. Доки повернення та видалення не завершено, ця ADV продовжує діяти.

§ 12 Підтвердження та сприяння перевіркам

(1) Клієнт може перевіряти, чи дотримується Постачальник цієї ADV (ст. 28 абз. 3 літ. h GDPR). Постачальник надає йому для цього всю необхідну інформацію та сприяє перевіркам, які проводить сам Клієнт або уповноважений ним аудитор, зобов'язаний дотримуватися конфіденційності.

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

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

§ 13 Місце обробки та треті країни

(1) Постачальник і його субобробники, зазначені в Додатку C, розділ 1, обробляють дані Клієнта виключно в Німеччині.

(2) До країни за межами ЄС та Європейського економічного простору Постачальник за власним рішенням нічого не передає. Якби він колись забажав цього, це було б зміною згідно з § 7 абз. 2, і мали б бути виконані умови ст. 44 і наступних GDPR.

(3) Інакше є із сервісами, які Клієнт або його користувачі самостійно підключають до todo.monster (Додаток C, розділ 3): поштові скриньки через IMAP і SMTP, календарі через CalDAV, а також календарі Google і Microsoft. Туди Постачальник передає лише те, що потрібно для функції, наприклад створену в Сервісі зустріч до підключеного календаря. Чи обробляє такий сервіс дані за межами Європейського економічного простору, залежить від обраного сервісу; у випадку Google і Microsoft слід очікувати обробки в США. За те, що ця передача є допустимою і що існують необхідні гарантії, відповідає Клієнт (§ 4 абз. 3).

§ 14 Відповідальність і прикінцеві положення

(1) До відповідальності сторін застосовується положення про відповідальність Загальних умов надання послуг. Законна відповідальність перед суб'єктами даних згідно зі ст. 82 GDPR залишається без змін.

(2) Зміни цієї ADV потребують текстової форми. Постачальник може змінювати її, якщо змінюються обробка, субобробники або правова ситуація; він інформує Клієнта системним електронним листом щонайменше за 30 днів. Для Додатка C діє § 7 абз. 2.

(3) Застосовується німецьке право. Місцем розгляду спорів є Берлін, якщо Клієнт є комерсантом (Kaufmann), юридичною особою публічного права або публічно-правовим відокремленим фондом.

(4) Якщо якесь положення цієї ADV є недійсним, решта залишаються чинними; замість нього застосовується законодавче регулювання.

Додаток A: Предмет обробки

1. Функції та цілі

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

2. Категорії суб'єктів даних

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

3. Тривалість

Обробка триває стільки ж, скільки й Основний договір, до повернення або видалення згідно з § 11. Протягом строку дії застосовуються строки, зазначені в Додатку B, пункт 3, для кошика та для протоколів.

Додаток B: Технічні та організаційні заходи (ст. 32 GDPR)

Заходи описані за місцем їх застосування: у Сервісі (розроблені та експлуатовані Постачальником), у хостера (через субобробника, зазначеного в Додатку C, розділ 1) або організаційно у Постачальника. Постачальник гарантує лише ті заходи, які впроваджено.

1. Конфіденційність

• Фізичний доступ і доступ у хостера: сервери розміщені в центрах обробки даних хостера в Німеччині із захистом від фізичного проникнення та контролем доступу відповідно до його концепції безпеки; Постачальник надає її на запит як підтвердження (§ 12). Сам Постачальник фізичного доступу не має.
• Доступ до Сервісу: вхід за адресою електронної пошти та паролем або за посиланням для входу, надісланим на збережену адресу електронної пошти. Паролі зберігаються лише у вигляді хешу; нові паролі мають відповідати мінімальним вимогам і перевіряються на наявність у відомих витоках даних, при цьому пароль не залишає Сервіс. Спроби входу обмежені для кожної адреси відправника та кожного облікового запису. Сесії завершуються після двох годин без активності; cookie сесії діють лише через HTTPS і недоступні для скриптів. Токени доступу мобільного застосунку та програмного інтерфейсу спливають через 30 днів і можуть бути відкликані в будь-який час.
• Доступ усередині Сервісу: рольова модель для кожної фірми (власник, адміністратор, учасник, гість) і для кожного проєкту; кожен доступ на читання та запис до завдань, проєктів і фірм сервер перевіряє за централізованими правилами авторизації. Адміністративний обліковий запис Постачальника не може читати описи, коментарі, вкладення, вміст поштових скриньок і календарів; що він бачить, вичерпно зазначено в пункті 5.
• Розділення: дані всіх клієнтів зберігаються в спільній базі даних і логічно розділені через прив'язку до фірми та проєкту; цю прив'язку встановлює сервер і ніколи не бере її із запиту. Розробка, тестування та продуктивна експлуатація — це окремі системи; середовище розробки додатково захищене блокуванням доступу і не містить продуктивних даних.
• Шифрування збережених даних: назви та описи проєктів і завдань, коментарі, тема та текст електронних листів, вміст зустрічей, а також дані доступу до підключених поштових скриньок і календарів зберігаються на сервері в зашифрованому вигляді (AES-256); паролі зберігаються лише у вигляді хешу Argon2id. Це шифрування на стороні сервера, а не наскрізне шифрування: Постачальник технічно може отримати доступ до даних; коли він це робить, зазначено в пункті 5.
• Шифрування передачі: Сервіс доступний лише через HTTPS (переспрямування та HSTS); з'єднання з поштовими скриньками, календарями, мовною моделлю, сервером звітів і платіжним сервісом зашифровані на транспортному рівні.
• Конфіденційність осіб: усі особи, які у Постачальника мають доступ до продуктивних систем, письмово зобов'язані дотримуватися конфіденційності.

2. Цілісність

• Контроль введення: зміни завдань фіксуються в історії з виконавцем, моментом часу, старим і новим значенням. Адміністративні дії у фірмі (ролі, запрошення, поштові скриньки, ліквідація) відображаються в журналі аудиту фірми. Входи фіксуються з моментом часу, адресою відправника та клієнтом. Доступи Постачальника згідно з пунктом 5 протоколюються.
• Захист застосунку: захист від підроблених запитів (CSRF) за допомогою токена сесії; очищення форматованих введень на стороні сервера; наскрізне екранування виведення; заголовки безпеки проти вбудовування в сторонні сторінки та проти вгадування типу вмісту, а також для керування реферером. Вкладення приймаються лише тоді, коли розширення файлу та розпізнаний тип вмісту збігаються; вони зберігаються під випадковими іменами поза вебкоренем і віддаються з ізолюючою політикою безпеки. Фотографії профілю перекодовуються без метаданих.
• Контроль передачі: дані залишають Сервіс лише до зазначених у Додатку C одержувачів і лише в описаному там обсязі; мовній моделі не передаються вкладення, платіжному сервісу — дані вмісту; бухгалтерські та банківські дані Постачальника не залишають систему. Адміністративні доступи та доступи до бази даних Постачальника здійснюються через панель керування хостера та зашифровані з'єднання.
• Процес розробки: кожна зміна Сервісу перед розгортанням проходить автоматизовані тести, зокрема контрактні тести правил авторизації, шифрування та меж модулів, і об'єднується з можливістю відстеження. Розгортання здійснюється відтворювано у вигляді образу контейнера; повідомлення про помилки в продуктивному середовищі ніколи не виводяться в браузері.

3. Доступність, стійкість і видалення

• Резервне копіювання: базу даних і файлове сховище резервує хостер; резервні копії зберігаються до 30 днів, а потім перезаписуються.
• Відновлення: застосунок працює як стек контейнерів з окремими процесами для вебу, планувальника та фонових робіт; режим технічного обслуговування контрольовано зупиняє Сервіс на час відновлення. Кінцева точка перевірки стану дає змогу здійснювати моніторинг.
• Стійкість: обмеження кількості запитів на адресу відправника та обліковий запис для входу, реєстрації, запрошень, доступів на запис через програмний інтерфейс та адміністративних функцій; обмеження розміру, кількості та сховища для вкладень; місячні квоти для функції ШІ.
• Кошик: видалені проєкти, модулі, завдання, поштові скриньки та календарі спочатку лише позначаються як видалені й остаточно знищуються після налаштованого строку (за замовчуванням 30 днів, нижня межа — один день); видалені електронні листи залишаються 45 днів у кошику поштової скриньки. До того часу уповноважені користувачі відновлюють їх самостійно. Осиротілі файли вкладень видаляються щодня.
• Строки зберігання протоколів і видалення: сповіщення — 30 днів; протоколи синхронізації поштових скриньок і календарів — три дні, у разі помилок — сім днів; архіви експорту — 24 години; протоколи входу — 90 днів; журнал використання функції ШІ — 90 днів; журнали аудиту фірми та відновлення — три роки, журнал аудиту розрахунків — десять років (податкове зберігання); IP-адреса наданих згод — до закінчення договору плюс три роки; знімки екрана з повідомлень про помилки — 90 днів; журнали застосунку — 30 днів.
• Гарантія доступності: доступність Сервісу регулюють Загальні умови надання послуг, а не ця ADV.

4. Процедури регулярної перевірки

• Регулярна автоматична перевірка того, що дані, які мають зберігатися в зашифрованому вигляді, зберігаються зашифрованими, та регулярне звіряння сховища вкладень із базою даних.
• Автоматизовані тести при кожній зміні; задокументовані інструкції щодо розгортання, ротації ключів, режиму технічного обслуговування та збоїв.
• Зміни заходів цього Додатка документуються (§ 6 абз. 2).
• Захист даних за замовчуванням: функція ШІ працює лише тоді, коли користувач запускає її для електронного листа, і може бути вимкнена кожним користувачем; повідомлення про помилки зі знімком екрана надсилаються лише за ініціативою користувача; поштові скриньки та календарі підключені лише тоді, коли користувач їх підключає; фотографії профілю бачать лише особи зі спільним проєктом або спільною фірмою.

5. Доступ Постачальника до даних Клієнта (правило доступу)

Працівники Постачальника не переглядають вміст Клієнта в плановому порядку. Людина отримує доступ лише за наявності підстави (вказівка Клієнта або інцидент безпеки чи експлуатації), лише в необхідному обсязі, і кожен доступ протоколюється. Автоматична обробка Сервісом згідно з Додатком A цим не зачіпається. Інших доступів, крім наведених нижче, не існує:

• Відновлення (§ 3 абз. 4): за запитом Клієнта адміністративний обліковий запис Постачальника з правом на відновлення бачить ім'я користувача, адресу електронної пошти, статус і момент видалення відповідного користувача, а також назви його проєктів і модулів, назви його завдань і моменти видалення видалених записів. Не видно описи, коментарі, вкладення, записи часу, а також вміст поштових скриньок і календарів. Кожне відновлення протоколюється із зазначенням виконавця та моменту часу.
• Діагностика підтримки: за запитом Клієнта адміністративний обліковий запис Постачальника бачить участь, запрошення та підключення поштових скриньок фірми (імена хостів, статус, момент останнього отримання), але не вміст повідомлень. Кожна діагностика перед відображенням фіксується в журналі аудиту фірми.
• Повідомлення про помилки: знімки екрана та описи, які користувач надсилає через функцію повідомлення про помилки, Постачальник бачить, щоб усунути повідомлену помилку; вони видаляються після строку, зазначеного в пункті 3.
• Експлуатація та безпека: доступ до бази даних, файлового сховища та протоколів для усунення збою, розслідування інциденту безпеки або виконання вказівки. Підстава документується; вміст Клієнта Постачальник при цьому бачить лише настільки, наскільки цього вимагає підстава.

Додаток C: Субобробники та інші одержувачі

1. Субобробники (§ 7 абз. 1)

2. Одержувачі поза дорученням

Наведені нижче організації не отримують даних з доручення Клієнта. Постачальник залучає їх як контролер для власних цілей; тут вони наведені лише для розмежування, деталі викладені в Політиці конфіденційності. Бухгалтерські та банківські дані Постачальника обробляються всередині Сервісу і не передаються жодному іншому одержувачу.

• Mollie B.V., Keizersgracht 126, 1015 CW Amsterdam, Нідерланди: обробка платежів за платними тарифами. Mollie отримує ім'я та адресу електронної пошти розрахункового рахунку і платіжні дані, без даних вмісту; при обробці платежів Mollie діє як самостійний контролер.
• EU-Captcha (Myra Security GmbH, Мюнхен): захист від ботів під час реєстрації та в контактній формі; передаються IP-адреса, ідентифікатор браузера та токен капчі особи, що реєструється або пише. Перевірка є обробкою Постачальника як контролера.
• Have I Been Pwned (api.pwnedpasswords.com, оператор Troy Hunt, Австралія): під час встановлення пароля передається короткий фрагмент хеш-значення, ніколи не пароль і жоден ідентифікатор особи; віднесення до особи неможливе.

3. Сторонні сервіси, залучені Клієнтом

Якщо Клієнт або користувач Клієнта підключає до todo.monster один із наведених нижче сервісів, Клієнт сам обрав цей сервіс і перебуває з ним у власних договірних відносинах. Такий сервіс не є субобробником Постачальника; Постачальник передає туди лише те, що потрібно для функції, і отримує звідти те, що користувач дозволив (§ 13 абз. 3).

• Поштові скриньки через IMAP і SMTP у провайдера електронної пошти Клієнта або користувача: отримання та надсилання повідомлень з даними доступу, які зберігає користувач.
• Календарі через CalDAV (наприклад, Nextcloud або Fastmail): синхронізація зустрічей з даними доступу, які зберігає користувач.
• Google Календар (Google LLC або Google Ireland Limited): користувач входить безпосередньо в Google і надає там дозвіл; Постачальник читає зустрічі з обраних календарів і передає створені або змінені в Сервісі зустрічі до Google. Обробка, як правило, також у США. Доступно лише тоді, коли Постачальник увімкнув цю функцію.
• Календар Microsoft (Microsoft Corporation або Microsoft Ireland Operations Limited) для приватних облікових записів Microsoft: користувач входить безпосередньо в Microsoft і надає там дозвіл; Постачальник читає зустрічі з обраних календарів і передає створені або змінені в Сервісі зустрічі разом з їхніми учасниками до Microsoft, який може розсилати запрошення. Обробка, як правило, також у США.

Для Google і Microsoft діє таке: які гарантії убезпечують передачу до США, визначається договірними відносинами, які Клієнт або його користувач сам має з відповідним сервісом (§ 4 абз. 3).

Якщо користувач від'єднує підключення, Постачальник видаляє дані доступу та токени доступу; вже отримані повідомлення та зустрічі залишаються в Сервісі, доки користувач їх не видалить або доки не буде видалено обліковий запис чи фірму.