Політика конфіденційності

Хто обробляє ваші дані

Володілець персональних даних — фізична особа-підприємець Злодєєва Лілія Василівна, комерційне позначення ОРДІС. Обробку регулює Закон України «Про захист персональних даних» № 2297-VI.

Роботу з персональними даними організовую особисто я.

Місце провадження діяльності: м. Кропивницький, Кіровоградська обл. Облік веду дистанційно по всій Україні.

Пошта для будь-яких питань про дані: admin@ordisoblik.com.ua. Телефон: +380 95 890 54 09.

РНОКПП, номер і дата запису в Єдиному державному реєстрі, посилання на картку підприємця в реєстрі та банківські реквізити зібрані на сторінці Реквізити.

Повна адреса реєстрації на сайті не публікується. Ви отримуєте її до того, як щось підписуєте: вона зазначена в договорі, у рахунку та в кожному акті приймання-передачі, а також доступна в картці підприємця в Єдиному державному реєстрі.

Обслуговування веду для субʼєктів господарювання, зареєстрованих в Україні, — фізичних осіб-підприємців і юридичних осіб. Заявку приймаю і від того, хто ще не зареєстрований: у такому разі розмова йде про реєстрацію і постановку обліку.

Де проходить межа цієї системи

Це варто прочитати першим, бо від цього залежить, чого взагалі стосується решта тексту.

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

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

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

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

Заявка з сайту

Форма заявки збирає пʼять відомостей:

• імʼя, як до вас звертатися;
• телефон або пошта — той спосіб звʼязку, який ви оберете самі;
• форма бізнесу, вона ж група оподаткування, зі списку;
• код ЄДРПОУ або номер запису в ЄДР — необовʼязкове поле;
• ваше питання — необовʼязкове поле вільного тексту до 2000 знаків.

Код потрібен для одного: побачити, що по той бік зареєстрований в Україні субʼєкт господарювання, і звірити найменування з довідником ЄДР ще до розмови. Він зберігається разом із заявкою. Поле необовʼязкове: підприємець коду ЄДРПОУ не має, а той, хто ще не зареєстрований, не має жодного. РНОКПП тут не потрібен і не зберігається — на етапі, коли договору ще немає, він надмірний (стаття 6 Закону № 2297-VI), і десятизначному коду форма відмовляє окремим повідомленням.

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

Мета: відповісти вам і обговорити умови обслуговування.

Підстава: ваша згода, пункт 1 частини першої статті 11 Закону № 2297-VI. Договору між нами на цей момент ще немає, тому іншої підстави бути не може.

Джерело даних — ви самі. Ніде більше відомостей про вас я на цьому етапі не збираю.

Якщо не заповнити імʼя, контакт і форму бізнесу, форма не надішлеться: без контакту я не зможу відповісти, без форми бізнесу — назвати вартість.

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

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

Зміст заявки надходить мені листом на службову адресу через зовнішнього поштового провайдера. Це названо в переліку тих, кому передаються дані.

Заявку я не використовую для розсилки, не продаю і не обмінюю.

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

Строк зберігання: 12 місяців від дати звернення, якщо договір не укладено. Видалення за цим строком робить задача за розкладом, щодня. Винятків вона не робить: якщо я планувала звернутись до вас повторно, а рік від звернення сплив, заявка все одно прибирається.

Лист із сайту

Крім заявки, на сайті є коротка форма листа: імʼя, електронна пошта і текст повідомлення до 2000 знаків. Її відкриває натиснення на публічну адресу пошти — на сторінці контактів, у підвалі й на сторінці розмови про умови.

Мета: відповісти на ваше звернення.

Підстава: заходи, що передують укладенню правочину на вимогу субʼєкта персональних даних, — пункт 3 частини першої статті 11 Закону № 2297-VI. Позначки згоди на цій формі немає навмисно: згода за статтею 2 того самого закону — це задокументоване волевиявлення, а лист ніде не документується, тому доказу такої згоди не існувало б.

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

Строк зберігання в системі — нульовий, бо зберігання немає.

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

Відбиток редакції цієї сторінки

Разом із кожною заявкою зберігається відбиток тексту політики в редакції, що діяла на момент згоди. Стаття 2 Закону № 2297-VI визначає згоду як волевиявлення за умови поінформованості, тому має бути видно, з чим саме людина погодилась.

Відбиток — це усічена контрольна сума SHA-256 тексту сторінки: у базі лежать перші 32 знаки суми, а не вся вона і не копія тексту. Відновити текст за відбитком неможливо, контрольна сума необоротна за побудовою.

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

Разом це дає перевірюваність: у заявці лежить відбиток, в архіві — текст, який йому відповідає. Сам архів відкритою сторінкою сайту не є: дату й текст редакції, що діяла в день вашої згоди, я надішлю на запит — напишіть на admin@ordisoblik.com.ua. Якщо ви клієнт кабінету, дата й відбиток тієї редакції, яку ви підтвердили, стоять у вашому профілі.

Записи архіву не редагуються і не видаляються через інтерфейс системи: архів, який можна переписати, доказом не є.

Ще одне, про що варто знати. Якщо сторінки політики в базі раптом не виявиться, у заявку запишеться відбиток порожнього тексту, і жодної помилки при цьому не станеться.

Дані клієнта за договором

У картці контрагента зберігаються: назва або ПІБ, форма бізнесу, галузь, місто, контактна особа, телефон, пошта, джерело звернення.

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

У внутрішній частині картки, якої ви в кабінеті не бачите, зберігаються: стадія воронки — від звернення до обслуговування або відмови, — позначка «топклієнт», відомість про те, хто з нас веде цю картку, дата початку обслуговування, обговорювана ціна, моя внутрішня замітка, історія торкань (дата, спосіб звʼязку, короткий опис розмови, автор запису) і код відмови з поясненням, якщо співпраця не почалася. Стадія і позначка «топклієнт» — це оцінні відомості про вас, тому називаю їх нарівні з рештою. Ви маєте право знати склад зібраних даних, а не лише ту його частину, яку вам показують.

Там же стоять дві позначки: згода на нетранзакційні листи і заборона «не писати ніколи». Розсилки в системі сьогодні немає взагалі, і жодного листа за цими позначками не надсилається; вони існують, щоб заборона працювала технічно.

Реєстраційного коду в картці немає — він зберігається в анкеті належної перевірки, про яку окремий розділ. Банківських реквізитів клієнта система не зберігає взагалі: вони є в договорі й у банківській виписці.

Мета: надати послугу, за яку ви платите, і виконати власний податковий обовʼязок.

Підстава: укладення та виконання правочину, стороною якого ви є, — пункт 3 частини першої статті 11; для мого власного податкового обліку — пункт 5 тієї ж частини, тобто обовʼязок, передбачений законом.

Згода для цього не потрібна і не запитується. Це не формальність: якби підставою була згода, ви могли б її відкликати, а я була б зобовʼязана припинити обробку і не змогла б ані подати вашу звітність, ані виконати власний обовʼязок перед державою.

Джерело даних — ви самі: форма заявки, договір, документи, які ви передаєте, і листування.

Строк зберігання: не менше пʼяти років після припинення ділових відносин — так вимагає договір. Для документів, якими підтверджуються показники поданої звітності, — за строками пункту 44.3 статті 44 Податкового кодексу України, і цей строк рахується від дня подання звітності, а не від дня створення документа. Видалення після спливу строку я роблю руками.

Контактна особа і кінцевий бенефіціар

Це окремий розділ, бо тут дані фізичної особи, яку я отримую не від неї самої, і плутати цей випадок з двома сусідніми не можна.

Якщо ви вказали контактну особу — її імʼя, телефон і пошту в картці контрагента, — то щодо цих відомостей володільцем є я, а не ви. Мету обробки визначаю я, і обовʼязок повідомити цю людину лежить теж на мені. Те саме стосується короткого опису розмови в історії торкань, якщо розмова була з нею, і відомостей про кінцевого бенефіціарного власника в анкеті належної перевірки: ці дані я збираю на виконання власного обовʼязку за Законом № 361-IX.

Закон вимагає поінформувати таку особу протягом тридцяти робочих днів з дня збору даних — абзац третій частини другої статті 12 Закону № 2297-VI. Тут це роблю я, а не ви.

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

Належна перевірка клієнта

Бухгалтери та субʼєкти господарювання, що надають послуги з бухгалтерського обліку, є спеціально визначеними субʼєктами первинного фінансового моніторингу — підпункт «б» пункту 7 частини другої статті 6 Закону України № 361-IX. Тому до встановлення ділових відносин я зобовʼязана вас ідентифікувати. Це не мій вибір і не додаткова умова обслуговування.

Збираю в анкету: повне найменування, ЄДРПОУ або РНОКПП, відомості про кінцевого бенефіціарного власника, характер ділових відносин, рівень ризику і власну примітку до перевірки.

Мета: виконання обовʼязку, покладеного на мене Законом № 361-IX.

Підстава: пункт 5 частини першої статті 11 Закону № 2297-VI — обовʼязок володільця, передбачений законом.

Джерело: ви самі подаєте витребувані документи. Частину відомостей я звіряю з відкритими даними Єдиного державного реєстру — це моя робота поза системою сайту: інтеграції з державними реєстрами в ній немає.

Наслідки ненадання: якщо витребувані документи не подано, ділові відносини не встановлюються, а розпочаті — припиняються. Це вимога частини сьомої статті 11 Закону № 361-IX.

Строк зберігання: не менше пʼяти років після припинення ділових відносин, у тому числі щодо осіб, яким я відмовила в обслуговуванні, — пункт 18 частини другої статті 8 Закону № 361-IX. Той самий строк діє для документів, що стосуються ділових відносин, включно з листуванням і результатами аналізу.

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

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

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

Окреме застереження. Якщо я подаю відомості до Державної служби фінансового моніторингу, я не маю права повідомити вам ані зміст поданого, ані сам факт подання — пункт 16 частини другої статті 8 Закону № 361-IX. Закон № 2297-VI цей виняток визнає: пункт 1 частини другої статті 21.

Кабінет: документи, рахунки, акти, листування

Файл, завантажений у кабінет, зберігається з назвою, роком і місяцем звітного періоду, розміром і позначкою, хто його завантажив. Форма приймає pdf, jpg, jpeg, png, heic, webp, xls, xlsx, csv, doc, docx і zip розміром до 25 МБ.

Тип файла перевіряється за розширенням, і перевіряється повне імʼя, а не остання його частина, тому подвійне розширення на кшталт «звіт.pdf.exe» не пройде. Але це перевірка імені, а не вмісту: виконуваний файл, перейменований на pdf, форму пройде, і вміст архіву не перевіряється взагалі. Кажу це прямо, щоб слова «виконувані файли не приймаються» не звучали як гарантія, якою вони не є.

Файли лежать поза веброзділом. Прямої адреси до них не існує, веб-сервер на спробу відкрити файл напряму відповідає «не знайдено». Єдиний шлях до вмісту — сторінка кабінету, яка спершу перевіряє права запитом до бази, а потім віддає файл із забороною кешування. Кожне відкриття файла записується в журнал.

Строк зберігання документа система не обчислює. У картці документа є звітний період, але поля типу документа й розрахунку строку в ній немає. Строк я визначаю сама — за типом документа, звітним періодом, пунктом 44.3 статті 44 Податкового кодексу і договором.

Листування в кабінеті зберігається текстом до 4000 знаків із автором, часом і позначкою прочитання. Про нове повідомлення я дізнаюся листом на службову адресу, і текст вашого повідомлення в цьому листі наводиться повністю.

Рахунки й акти зберігаються з номером, періодом, предметом, сумою, датами виставлення і строком оплати. Чернетки рахунка й акта в кабінеті не показуються: вони зʼявляються там у момент надсилання.

Дані інших людей у ваших документах

Через первинні документи, акти й платіжні доручення в систему потрапляють відомості про третіх осіб: ПІБ і реєстраційні коди ваших контрагентів, підписантів документів, отримувачів платежів.

Щодо цих даних володільцем є ви: мету обробки визначаєте ви і ви відповідаєте перед цими людьми. Я є розпорядником — обробляю їх від вашого імені, на підставі письмового договору і лише в обсязі, потрібному для послуги. Це стаття 4 і стаття 10 Закону № 2297-VI.

Ці дані я отримую не від самих людей, а від вас. Закон вимагає поінформувати таку особу протягом тридцяти робочих днів з дня збору даних — абзац третій частини другої статті 12 Закону № 2297-VI. Договором цей обовʼязок покладено на вас як на володільця: ви знаєте цих людей і ви визначаєте, для чого їхні дані обробляються.

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

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

Журнал дій

Система веде журнал: хто, коли, яку дію і над яким обʼєктом виконав, у якого контрагента, з якої мережі і з якою короткою деталлю. Деталь зберігається обрізаною до 250 знаків.

Мережа — це адреса, з якої прийшов запит, скорочена в момент запису: від адреси виду 203.0.113.42 у журнал потрапляє 203.0.113.0/24, а від довшої адреси нового зразка лишаються перші 48 біт. Повної адреси в цьому журналі немає ніколи: скорочення стоїть у самій моделі даних, а не в тих місцях, які пишуть записи, тому обійти його не може жодне з них. Навіщо вона тут — щоб на питання «це точно був я» була відповідь: без мережі вхід із чужого підключення виглядає в журналі так само, як вхід із власного.

Мережі немає в записах, які лишає задача за розкладом: запиту в них немає взагалі. Немає її і в записах про читання рядків — їх пише сама вибірка даних, а запит до неї не доходить.

Запис журналу не змінюється і не видаляється: заборона стоїть у самій моделі даних — і на окремий рядок, і на цілу вибірку, — тому кнопки видалення для цієї таблиці немає ні в кого, зокрема в мене. Але заборона стоїть у застосунку, а не в базі: технічного запобіжника на рівні самої бази даних немає, і той, хто дістався до бази безпосередньо, обмежений нею не буде.

Хто бачить журнал, вирішує сама вибірка даних, а не сторінка: клієнту записи не віддаються взагалі, співробітник отримує лише записи щодо контрагентів, яких веде, повний журнал — тільки я.

Є ще один випадок, про який чесно сказати краще, ніж змовчати. Запис журналу посилається на картку контрагента, і якщо картку колись знищити фізично, це посилання в записах обнулиться. Сам запис лишиться, дія і час у ньому лишаться, але привʼязка до контрагента зникне.

У полі деталей журнал містить фрагменти ваших даних. Перелічую поіменно, бо твердження «журнал не містить персональних даних» було б неточним: це назви документів, теми надісланих листів, номери рахунків і актів, назва звітного місяця в описі документів, короткий опис розмови із запису торкання, код відмови з розшифровкою, пункт договору із заперечення по акту і зміна стадії у вигляді «Звернення → Відмова».

Ось що саме потрапляє в журнал:

• створення і зміна картки контрагента в довідниках;
• зміна стадії воронки — з якої на яку;
• запис торкання разом із коротким описом розмови;
• зміна внутрішньої замітки — сам факт, без тексту замітки;
• запис відмови з кодом і розшифровкою;
• завантаження документа і його назва;
• кожне відкриття файла документа і його назва;
• завантаження опису документів за період і назва цього періоду;
• завантаження рахунка або акта в PDF і його номер;
• ваше рішення щодо акта — погоджено чи заперечення, з номером акта, а в разі заперечення ще й з пунктом договору;
• надсилання повідомлення з кабінету — факт, без тексту;
• підтвердження правил кабінету разом із відбитком тієї редакції, яку ви підтвердили;
• кожен надісланий лист і його тема;
• лист, який не пішов через відсутність адреси;
• вхід у систему і вихід із неї;
• налаштування другого фактора;
• зміна власного пароля;
• автоматичне погодження акта за спливом строку — цей запис без автора, бо його зробила не людина;
• щорічне нагадування про перерахунок показників — теж без автора;
• закриття справи з мого внутрішнього переліку робіт, з назвою справи і періодом. Вас це не стосується: справи тут про саму практику, а не про клієнтів.

Три таблиці журналюються ще й на читання: документи, надходження грошей і анкета належної перевірки. Подією тут є сам показ рядків людині, тому в записі стоїть або номер одного рядка, або кількість показаних рядків з їхніми номерами — перших двадцять. Наслідок, про який краще сказати прямо: відкриття картки контрагента, де видно надходження, теж лишає такий запис, хоч сама картка в журнал не йде. Лічильник не лишає нічого: сторінка, яка показала кількість документів, їхнього змісту не розкрила.

А ось чого в журналі немає:

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

Час останнього входу система зберігає ще й в обліковому записі, окремо від журналу, і перезаписує його щоразу.

Строк зберігання журналу дій не встановлено: механізму прибирання старих записів у системі немає — ні команди, ні задачі за розкладом. Якщо він зʼявиться, цей абзац буде переписано разом із ним, а не раніше.

Історія входів

Крім журналу дій система веде окремий перелік входів. Він відповідає на одне питання — це заходили ви чи не ви, — і несе рівно те, що на це питання відповідає.

На кожну спробу входу, вдалу й невдалу, записується: чий це обліковий запис, час, що сталось, мережа, місто, область і країна, а також сімейство пристрою і браузера — наприклад «Windows · Chrome». Точної моделі пристрою тут немає: щоб упізнати свій вхід, досить знати, телефон це чи компʼютер і чим відкрито.

«Що сталось» — це одне з семи: увійшов, вийшов, пароль не підійшов, код другого фактора не підійшов, вхід замкнувся лічильником спроб, вхід зупинився на кроці з кодом, спробували ввійти службовим імʼям.

Мережа тут та сама, що в журналі дій: адреса скорочена в момент запису, повної немає й тут.

Місто визначає файл на моєму сервері — відкрита база DB-IP City Lite, ліцензія Creative Commons Attribution 4.0, оновлюється раз на місяць. Ваша адреса для цього нікуди не надсилається: у базу йде та сама скорочена мережа, що лягає в запис, і жодного звернення до стороннього сервісу не робиться. Точність такого визначення — країна, область і місто, не вулиця й не будинок. Коли база мережі не знає або файла ще немає, у записі порожньо, і на екрані це читається як «місто невідоме»: вигаданого міста там не буде.

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

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

Строк зберігання — 12 місяців від дня запису. Записи, старші за цей строк, прибирає задача за розкладом, щодня. Рік узято за мінімізацією, а не навмання: він покриває і розбір інциденту, і річний цикл звітності, а тримати ці записи довше немає для чого.

Коли ви просто читаєте сайт

Кожне звернення потрапляє в журнал веб-сервера. Туди пишеться час, адреса сторінки, код відповіді, а також заголовки запиту — зокрема повний рядок браузера і сторінка, з якої ви перейшли. Раніше в цьому місці стояло «узагальнений тип браузера»; це було неточно, і я не хочу, щоб ви дізналися про різницю з чужих слів.

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

Одну діру називаю прямо. Якщо відвідувач сам надішле заголовок із адресою — а такий заголовок можна поставити вручну, — він потрапить у журнал недоторканим, бо скорочення на нього не накладене. Тому написати «повна адреса не зберігається ніде» я не можу: у звичайному відвідуванні вона не зберігається, але абсолютом це твердження не є. Коли цю ваду в браузерах виправлять, я перепишу цей абзац.

Мета: щоб сайт працював, щоб було видно помилки і щоб я бачила візити пошукових роботів.

Підстава: мій законний інтерес, пункт 6 частини першої статті 11. Сам інтерес називаю прямо — працездатність сайту і захист від перебору паролів та автоматизованих звернень.

Строк зберігання: журнали ротуються за розміром — на сервері тримаються останні приблизно 200 МБ записів. Скільки це днів, залежить від відвідуваності. Крім того, файл журналу, старший за девʼяносто днів, видаляється незалежно від розміру, і це єдина межа в днях, яку я можу назвати.

Окремої програми статистики в системі немає — ні лічильника, ні обробника журналів. За потреби я дивлюся журнал звернень сама. Cookie й коду, що виконується у вашому браузері, для цього не потрібно.

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

Вхід і сеанс

Обліковий запис — це пошта, повне імʼя, телефон, роль, хеш пароля, позначка активності, дата створення і час останнього входу. Самого пароля система не зберігає ніде.

Самостійної реєстрації немає: обліковий запис створюю я.

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

Кількість спроб входу обмежена. Лічильник живе не в оперативній памʼяті, як можна було б подумати, а в таблиці кешу тієї самої бази даних — отже, потрапляє й у резервні копії. У ключі лежить не пошта і не адреса, а їхні контрольні суми.

Строк дії ключа — двадцять хвилин, але сам рядок після цього з таблиці не зникає: він лишається там, доки його не витіснить новий запис. Тому «зберігається двадцять хвилин» — неправда, і я так не пишу.

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

Сеанс команди живе вісім годин. Сеанс клієнта — тридцять днів, щоб не входити щоразу заново.

Кому я передаю дані

Перелік вичерпний.

• Державним органам, до яких подається ваша звітність, — у складі самої звітності. Це і є послуга, за якою ви звернулися.
• Державній службі фінансового моніторингу — відомості, передбачені Законом № 361-IX.
• Суду, контролюючому або правоохоронному органу — на письмову вимогу в межах їхніх повноважень і в обсязі, визначеному законом.
• Провайдеру сервера — технічно, оскільки база даних має десь фізично працювати. Використовувати ці дані для власних цілей провайдер не має права.
• Поштовому провайдеру, через якого йдуть листи, — у складі самих листів.
• Особі, яка виконує технічне обслуговування системи. Обсяг її дій визначено письмовим договором про обробку персональних даних; у звичайному режимі роботи доступу до даних клієнтів вона не має.

Через поштового провайдера проходять такі листи. Мені на службову адресу: зміст заявки з сайту, текст листа з форми на сайті разом з імʼям і адресою відправника, текст вашого повідомлення з кабінету повністю, текст заперечення по акту разом із пунктом договору, повідомлення про те, що ви погодили акт, — із номером, періодом і сумою, — і повідомлення про те, що ви почали завантажувати документи, із назвою першого з них.

Вам: запит документів, рахунок, акт, повідомлення про нове повідомлення в кабінеті (без тексту, лише посилання), лист про відновлення доступу і запрошення до кабінету.

Рекламним мережам, аналітичним сервісам, брокерам даних і партнерам дані не передаються. Я їх не продаю і не обмінюю.

Про зміну, видалення чи знищення ваших даних або обмеження доступу до них повідомляю протягом десяти робочих днів — частина третя статті 21 Закону № 2297-VI. Якщо умови вашої згоди вимагають повідомити про передання даних третій особі, повідомляю в той самий строк — частина перша тієї ж статті.

Виняток один, і він не в моїй владі: про подання відомостей до Державної служби фінансового моніторингу я не повідомляю. Це заборонено пунктом 16 частини другої статті 8 Закону № 361-IX, а пункт 1 частини другої статті 21 Закону № 2297-VI знімає з мене обовʼязок повідомлення в цьому випадку.

Резервні копії і ключ до них

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

Резервні копії бази і файлів зберігаються поза сервером, у зашифрованому вигляді.

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

Глибина копій: сім щоденних, пʼять тижневих і дванадцять місячних. Це означає, що дані, видалені з бази сьогодні, лишаються в копіях ще до дванадцяти місяців. На самому сервері незашифрований дамп живе не довше трьох діб, після чого його прибирає наступний запуск копіювання. Якщо запуск не відбувся, дамп лежить далі — прибирання привʼязане до нього, а не до окремого розкладу.

Скільки все це зберігається

• Заявка, за якою договір не укладено, — 12 місяців від дати звернення. Прибирає задача за розкладом, щодня.
• Дані клієнта за договором, первинні документи і складена звітність — не менше 5 років після припинення ділових відносин.
• Документи на підтвердження показників поданої звітності — за строками пункту 44.3 статті 44 Податкового кодексу України, від дня подання звітності.
• Анкета належної перевірки і документи ділових відносин — не менше 5 років після припинення відносин, зокрема щодо осіб, яким відмовлено в обслуговуванні.
• Запис про надану згоду — увесь строк обробки і три роки після його закінчення. Три роки — загальна позовна давність, стаття 257 Цивільного кодексу України.
• Історія входів — 12 місяців від дня запису. Прибирає задача за розкладом, щодня.
• Журнал дій — строк не встановлено.
• Журнали веб-сервера — останні приблизно 200 МБ записів, і не довше девʼяноста днів.
• Лічильник спроб входу — ключ діє 20 хвилин, рядок у таблиці лишається до витіснення.
• Запис про видане посилання для відновлення доступу — строк не встановлено.
• Резервні копії — до 12 місяців.

Механізм називаю прямо, бо тут текст і система вже розходились. Автоматично за строком прибираються два класи записів: заявка, за якою договір не укладено, і історія входів. Це робить задача за розкладом, щодня о 04:40.

Строк заявки я витримую без винятків. Якщо я планувала звернутись до людини повторно, а рік від її звернення сплив, заявка все одно прибирається — строк названий тут числом, і застережень до нього немає. Задача при цьому окремо називає таку заявку у своєму звіті, щоб я про неї знала.

Решту строків я витримую переглядом бази. Причина не в ліні: строки клієнтських даних, первинки, звітності й анкети належної перевірки — мінімальні, закон каже «не менше пʼяти років», а не «рівно пʼять». Задача, яка стирала б за такими строками, порушувала б закон, а не виконувала його. Строк запису про згоду відлічується від закінчення обробки, а дати закінчення ділових відносин система сама не проставляє.

Видалення в системі буває двох видів, і різниця між ними принципова.

Мʼяко — тобто запис зникає з роботи і з усіх переліків, але фізично лишається в базі з позначкою дати видалення, а файл лишається на диску — видаляються: картка контрагента, договір, рахунок, акт і документ.

Фізично — тобто запис зникає з бази остаточно — видаляються: торкання, відмови, надходження, запити документів, листування, слід виконання задач за розкладом, заявка з сайту і запис про видане посилання для входу.

Трьох винятків не має ніхто, зокрема я: анкету належної перевірки, записи журналу дій і історію входів видалити через інтерфейс неможливо.

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

Автоматична обробка і автоматизовані рішення

Ви маєте право знати механізм автоматичної обробки — пункт 12 частини другої статті 8. Ось він повністю.

• 25 числа система створює запит документів за звітний місяць усім клієнтам на обслуговуванні і надсилає його листом. Лист транзакційний: це виконання договору, а не розсилка.
• 1 числа система створює чернетки рахунків за абонплату. Автоматично вони не надсилаються — рахунок надсилаю я.
• Акти система теж створює чернетками, раз на місяць, за минулий місяць. Надсилаю їх я.
• Коли я записую відмову, система сама обчислює дату, коли до вас звернуться знову, — за кодом відмови, а не на мій розсуд. «Дорого» — через 90 днів, «уже є бухгалтер» — через 120, «веду сам» — через 60, «немає довіри» — через 180, «немає грошей, не сезон» — через 60, «не відповів після трьох спроб» — через 180. Для «не наш профіль» повернення не планується. Для «просив не писати» дата не ставиться взагалі, а натомість вмикається технічна заборона на будь-які нетранзакційні листи і знімається згода на них. Картка при цьому переводиться в стадію «Відмова».
• Щодня система збирає перелік прострочених торкань для моєї роботи і водночас проставляє дату сьогоднішнього дня тим карткам, у яких строк повернення після відмови вже настав, а дата наступного торкання порожня. Тобто задача не лише читає, а й змінює запис. Клієнтам вона при цьому нічого не надсилає.
• Акт, який вам надіслано і на який не надійшло заперечень, система переводить у стан «погоджено автоматично» і записує це в журнал без автора.
• Позначка «не писати ніколи» технічно вимикає нетранзакційні листи: система відмовляється їх надсилати.

Про строк автоматичного погодження акта скажу точно, бо тут текст і код розходилися. Строк на заперечення — пʼять робочих днів від дня надсилання, і він установлений договором. Але переводить акт у погоджений стан місячна задача, яка виконується 5 числа і за побудовою не може відпрацювати двічі за місяць. Тому фактична дата — не раніше спливу пʼяти робочих днів, але й не в день їх спливу: акт, надісланий 6 числа, буде погоджено автоматично 5 числа наступного місяця. Це на вашу користь, бо часу на заперечення виходить більше, ніж мінімальний строк, але описувати це як «через пʼять днів» було б неправдою. Заперечити можна в кабінеті, доки акт не переведено.

Це вся автоматика. Строків зберігання система не обчислює, профілювання не веде, оцінок вам не виставляє.

Рішення щодо обслуговування — взяти клієнта, яку призначити ціну, чи відмовити — ухвалюю особисто я. Автоматизованих рішень із правовими наслідками в розумінні пункту 13 частини другої статті 8 я не ухвалюю. Єдиний автоматичний механізм із наслідками — погодження акта за спливом строку, і він передбачений договором, який ви підписали.

Ваші права

Частина друга статті 8 Закону № 2297-VI дає вам тринадцять прав. Наводжу всі, а не лише ті, якими користуються найчастіше. Скористатися кожним можна листом на admin@ordisoblik.com.ua.

• Знати про джерела збирання своїх даних, їх місцезнаходження, мету обробки, місцезнаходження або місце проживання володільця чи розпорядника — або доручити отримати цю інформацію іншій особі.
• Отримувати інформацію про умови надання доступу до своїх даних, зокрема про третіх осіб, яким вони передаються.
• На доступ до своїх персональних даних.
• Отримати відповідь про те, чи обробляються ваші дані, і зміст цих даних — не пізніш як за тридцять календарних днів з дня надходження запиту.
• Предʼявити вмотивовану вимогу із запереченням проти обробки своїх даних.
• Предʼявити вмотивовану вимогу про зміну або знищення своїх даних, якщо вони обробляються незаконно або є недостовірними.
• На захист своїх даних від незаконної обробки, від випадкової втрати, знищення чи пошкодження, а також від надання відомостей, що є недостовірними або ганьблять честь, гідність і ділову репутацію.
• Звертатися зі скаргами на обробку своїх даних до Уповноваженого Верховної Ради України з прав людини або до суду.
• Застосовувати засоби правового захисту в разі порушення законодавства про захист персональних даних.
• Вносити застереження щодо обмеження права на обробку своїх даних під час надання згоди.
• Відкликати згоду на обробку персональних даних.
• Знати механізм автоматичної обробки своїх даних.
• На захист від автоматизованого рішення, яке має для вас правові наслідки.

Відкликати згоду можна там, де підставою є саме згода: це заявка з сайту. Для даних, які я обробляю за договором і за обовʼязком, передбаченим законом, відкликання згоди нічого не змінює, бо згода там не є підставою.

Право вимагати знищення обмежене самим законом: воно діє, якщо дані обробляються незаконно або є недостовірними. Документи, які я зобовʼязана зберігати за Податковим кодексом і за Законом № 361-IX, на вимогу я не видалю, бо не маю на це права. На запит відповім письмово: що видалено, що не видалено, на підставі якої норми і коли буде видалено те, що зараз зберігається за обовʼязком.

Як я захищаю дані

Абсолютної безпеки не існує, тому нижче не обіцянка, а перелік зробленого.

• Доступ розмежовано за роллю на рівні вибірки даних, а не на рівні сторінки. Запис, до якого немає доступу, відсутній у вибірці, а не прихований у шаблоні.
• Клієнт бачить лише свої документи, рахунки, акти й листування. Чернетки рахунка й акта він не бачить: вони зʼявляються в кабінеті в момент надсилання.
• Співробітник бачить лише тих контрагентів, яких веде, — і в довідниках, і в робочому місці.
• Надходження грошей проходять через ту саму перевірку, що й решта: я бачу всі, співробітник — лише надходження контрагентів, яких веде, клієнт не бачить надходжень узагалі, бо стан розрахунків це мій внутрішній облік. Раніше обмеження стояло тільки в довідниках, а робоче місце брало суми повз нього; тепер обмеження стоїть у самій вибірці, і воно одне на всі місця, де гроші показуються.
• Анкету належної перевірки бачить лише власниця, і це закріплено трьома незалежними способами: вибіркою даних, окремою перевіркою на сторінці і переліком прав групи співробітника. Видалити її не може ніхто.
• Файли клієнтів лежать поза веброзділом; прямої адреси до них не існує, віддає їх лише сторінка кабінету після перевірки прав, і кожне відкриття записується в журнал.
• Права співробітника задані закритим переліком, і права на видалення в ньому немає.
• Нові й змінені паролі зберігаються хешами Argon2id. Пароль, заданий до переходу на цей алгоритм, лежить у старішому вигляді до першого успішного входу, після якого перераховується сам. Мінімальна довжина пароля — дванадцять символів.
• Кількість спроб входу обмежена одночасно за поштою і за мережею; ключі лічильника зберігаються контрольними сумами, а не відкритим текстом.
• Форма входу відповідає однаково на невірний пароль і на неіснуючу пошту, тому за нею не можна дізнатися, хто є клієнтом.
• Адреса скорочується до мережі і в базі, і в журналі веб-сервера — із застереженням, названим вище.
• Зʼєднання лише захищене, стороннього коду на сторінках сайту немає, вбудовування сайту в чужу сторінку заборонене.
• Сторінки кабінету і внутрішньої частини не кешуються і не індексуються пошуковими системами.
• Резервні копії шифруються — з тим застереженням про ключ, яке я зробила вище.
• Твердження про те, що сайт зберігає у браузері, перевіряються автотестом: сторінка, яка перелічує неіснуючий механізм або пропускає наявний, роняє перевірку. Тест запускається сам перед кожним записом змін у код — це налаштовано і працює. Двох речей він не дає: серверної збірки, яка перевіряла б те саме незалежно від мого компʼютера, немає, а саму перевірку можна свідомо обійти окремою командою. Тому це механізм, а не гарантія.

Чого я не роблю — і не приховую цього. Шифрування окремих полів у базі, зокрема реєстраційних номерів і сум, я не впроваджую свідомо. База і застосунок працюють на одній машині, тому від того, хто отримав доступ до машини, таке шифрування не захищає: ключ довелося б тримати поруч із даними. Ціна такого шифрування — втрачений пошук за реєстраційним номером і ризик втратити дані разом із ключем. Тому фрази про зашифровані поля ви в цьому тексті не знайдете: немає механізму — немає і твердження.

Якщо станеться інцидент

Для розбору в мене є журнал дій системи, журнал веб-сервера і слід виконання задач за розкладом.

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

Задокументованої процедури реагування з фіксованими строками в мене поки немає. Коли вона зʼявиться, вона буде описана тут — з датою.

Зміни до цієї сторінки

Дата останнього оновлення вказана внизу сторінки.

Разом із кожною заявкою зберігається відбиток тексту політики в редакції, що діяла на момент згоди. Що цей відбиток дозволяє перевірити і чого він не відновлює — описано вище, в окремому розділі. Редакції зберігаються, і текст тієї, що діяла в день вашої згоди, я надішлю на запит; обіцяти більше, ніж відбиток дає, я не буду.

Якщо ви є клієнтом і зміни суттєві, я повідомлю вас у погодженому каналі звʼязку, а не мовчки заміню сторінку.

Як звернутися

admin@ordisoblik.com.ua — на звичайні питання відповідаю до кінця наступного робочого дня, на запит щодо персональних даних — не пізніш як за тридцять календарних днів з дня його надходження.

Телефон: +380 95 890 54 09.

Якщо моя відповідь вас не влаштувала, ви маєте право звернутися зі скаргою до Уповноваженого Верховної Ради України з прав людини або до суду. Контроль за додержанням законодавства про захист персональних даних здійснюють саме вони — стаття 22 Закону № 2297-VI.

Тексти норм: Закон № 2297-VI, Закон № 361-IX, Податковий кодекс України.