П'ять бухгалтерів і один спільний логін у систему клієнтів — так на практиці виглядає доступ до даних у багатьох невеликих бухгалтерських бюро. Будь-хто з команди може відкрити картку будь-якого клієнта, навіть того, з ким ніколи не працював, а сказати точно, хто і коли туди заходив, не може ніхто. Річ не в довірі до команди — це прогалина в тому, як бюро виконує обов'язок зі ст. 29 RODO.
З цього тексту ти дізнаєшся: що саме вимагає ст. 29 RODO від адміністратора і від людей із доступом до даних, чим роль адміністратора відрізняється від ролі процесора у щоденній роботі бюро, як обмежити доступ картками «своїх» клієнтів замість усієї бази і коли список уповноважень варто переглянути заново.
Один спільний логін на картки всіх клієнтів
Команда з 3–8 бухгалтерів зазвичай росте швидше, ніж система прав доступу. Спочатку є одна бухгалтерська програма і двоє людей, які в курсі всіх справ. Потім приходять нові бухгалтери, клієнтів ділять між ними, але логін у системі лишається один спільний, або кожному дають повний доступ «про всяк випадок» — щоб можна було підмінити колегу у відпустці.
Результат: бухгалтерка, яка два роки веде виключно будівельні компанії, технічно має доступ і до кадрових документів клієнта з зовсім іншої галузі, яким ніколи не займалася. Ніхто не планував це як порушення — це просто найзручніший спосіб зробити так, щоб ніхто ніколи не залишився без доступу. Проблема в тому, що RODO питає не про наміри, а про те, чи адміністратор реально контролює, хто і в якому обсязі має доступ до даних. Той самий принцип розбираємо у статті про те, що реально можна передати системі, а що ні — доступ до даних клієнта якраз із тих речей, які не можна віддавати на відкуп зручності.
Що вимагає ст. 29 RODO: уповноваження — не формальність для папки
Ст. 29 RODO вказує, що процесор і будь-яка людина, яка діє за уповноваженням адміністратора або процесора і має доступ до персональних даних, обробляють їх виключно за вказівкою адміністратора. Саме на це звертає увагу Управління із захисту персональних даних Польщі (UODO), відповідаючи на питання, чи має адміністратор і надалі видавати уповноваження за чинного RODO (UODO про обов'язки адміністратора). Відповідь: має, бо це один із конкретних способів показати, що доступ реально контролюється, а не що в кожного є ключ від усього.
Що саме означає «уповноваження»
UODO звертає увагу на мовний нюанс: польське слово «upoważnienie» за словником — це формальне доручення, але англійська версія RODO говорить про людину, яка «acting under the authority of the controller» — діє під владою адміністратора. Іншими словами, річ не так у папірці, як у тому, щоб адміністратор реально контролював, хто, в якому обсязі і на яких умовах обробляє дані. Уповноваження — один з інструментів, яким цю владу можна показати.
Кого стосується обов'язок: не лише штатних співробітників
З тексту UODO випливає також, що йдеться не лише про постійних співробітників, а й про кожного, кому бюро доручило роботу, яка вимагає доступу до даних клієнтів, — включно з практикантами і стажистами. Виняток — люди, які самі є процесором або його співробітником: там обов'язок регулює договір доручення обробки, а не внутрішнє уповноваження.
Адміністратор має контролювати, хто і в якому обсязі має доступ
UODO формулює це прямо: суть у тому, щоб адміністратор контролював, хто і в якому обсязі має доступ до персональних даних та на яких умовах їх обробляє. Заходи, які для цього вживає адміністратор, мають запобігати неправомірному внесенню, перегляду, зміні чи видаленню даних, а уповноважені люди мають мати доступ лише до тих даних, які охоплює їхнє уповноваження, — не до всієї бази автоматично.
Видача уповноважень — один із таких організаційних заходів. На його основі потім застосовують механізми контролю доступу в самій інформаційній системі: конкретній людині дають конкретний обсяг прав, а не логін адміністратора для всіх.
Адміністратор і процесор: дві ролі одного й того ж бюро
Бухгалтерське бюро рідко буває лише тим чи лише іншим. Щодо даних власних співробітників — кадри, зарплата, облік робочого часу — бюро є адміністратором і само вирішує цілі та способи обробки. Щодо даних клієнта, які воно обробляє за його дорученням у межах бухгалтерської послуги, бюро найчастіше виступає процесором — тобто виконує вказівки адміністратора, яким у цьому разі є сам клієнт.
Чому це розрізнення щось змінює на практиці
Якщо бюро виступає процесором щодо даних клієнта, правила доступу всередині команди все одно мають відповідати тій самій вимозі ст. 29 RODO — кожен бухгалтер, який діє за уповноваженням бюро, обробляє дані клієнта виключно за його вказівкою, в обсязі, що випливає з договору. Роль адміністратора чи процесора не звільняє від контролю за тим, хто реально що бачить.
Відповідальність не зникає після підписання договору
Один із комунікатів UODO добре показує механізм, хоча стосується зовсім іншої галузі, ніж бухгалтерія: у справі про штрафи для McDonald's Polska голова UODO прямо вказав, що за захист персональних даних відповідають і адміністратор, і процесор (комунікат UODO, 21.07.2025). У цій справі, серед іншого, бракувало належного договору доручення обробки, хоча обов'язок його укласти випливав зі ст. 28 п. 4 і 9 RODO ще до перевірки.
Суми штрафів і сама галузь громадського харчування не мають стосунку до бухгалтерського бюро — переносити їх сюди було б нечесно. Але механізм універсальний: те, що дані обробляє субпідрядник або окремий співробітник, не знімає відповідальності з адміністратора, і навпаки. Уповноваження всередині команди і договір доручення обробки з клієнтом — це два окремі обов'язки, які треба виконати обидва одночасно, а не замість одне одного.
Доступ за клієнтом, а не доступ до всієї бази
Практичний наслідок простий: доступ має бути прив'язаний до конкретних клієнтів, з якими людина реально працює, а не до бази цілком. У великій бухгалтерській системі це зазвичай налаштовується на рівні ролей — бухгалтер бачить своїх клієнтів, керівник команди бачить команду, власник бачить усе, а не в кожного той самий обліковий запис із повним доступом.
Обмеження доступу клієнтами, з якими людина реально працює, — це на практиці принцип мінімізації даних зі ст. 5 RODO: дані мають бути адекватними, доречними і обмеженими тим, що необхідно для мети обробки (посібник UODO, що цитує ст. 5 RODO). У бухгалтерському бюро «метою» окремого бухгалтера є обслуговування своїх клієнтів, а не перегляд усієї бази на випадок, якщо колись знадобиться.
Приклад на умовних числах — підстав свої: бюро з 5 бухгалтерами і 60 активними клієнтами, де кожен бухгалтер технічно має доступ до всіх карток, дає 5 × 60 = 300 можливих комбінацій «співробітник–клієнт», хоча реально обґрунтована лише частина з них. Після рівного розподілу клієнтів між бухгалтерами (60 ÷ 5 = 12 клієнтів на людину) кількість обґрунтованих комбінацій падає до 5 × 12 = 60 — решта це доступ без причини, яку ніхто не зможе пояснити перевіряючому.
Як це виглядає на рівні ролей у системі
На практиці це три рівні: у бухгалтера є доступ до призначених клієнтів, у людини, яка підмінює колегу у відпустці, — тимчасовий доступ із терміном дії, а у власника чи керівника — доступ до всього, бо це випливає з його ролі, а не зі зручності входу в систему. Що більше людей ділять один обліковий запис «про всяк випадок», то важче будь-кому показати, хто реально обробляв дані конкретного клієнта.
Що не вирішує саме лише уповноваження
Уповноваження наводить лад усередині команди бюро. Воно не замінює договір доручення обробки даних, який бюро зобов'язане підписати з кожним клієнтом, якщо обробляє його дані за його дорученням. Це два різні документи, два різні обов'язки і дві різні сторони — один регулює відносини бюро–співробітник, інший — відносини бюро–клієнт. Про те, де фізично опиняються дані клієнтів, коли задіяно кілька систем і субпідрядників, ми пишемо окремо у статті автоматизація і RODO.
Коли переглядати список уповноважень
Список уповноважень — не документ, який підписують раз і кладуть у папку. Природні моменти для перегляду: закінчення трудового договору чи договору підряду, зміна ролі в команді — наприклад, підвищення до керівника, якому потрібен ширший доступ, — і завершення співпраці з конкретним клієнтом, після якого доступ до його картки має зникнути, а не залишитися «на потім».
| Ситуація | Що зробити з доступом |
|---|---|
| Новий бухгалтер приєднується до команди | Надати доступ лише до призначених йому клієнтів |
| Практикант або стажист працює над конкретною справою | Уповноваження на термін практики й обсяг цієї справи |
| Співробітник змінює роль (наприклад, підвищення) | Оновити обсяг уповноваження під нову роль |
| Договір із співробітником закінчується | Забрати доступ у день закінчення, а не «колись» |
| Клієнт завершує співпрацю з бюро | Закрити доступ команди до його картки |
Зроби сам за тиждень: список доступів
- Випиши всіх, хто має будь-який доступ до системи з даними клієнтів, — включно з практикантами і людьми на підміні.
- Біля кожного познач, з якими клієнтами він реально працює цього місяця.
- Порівняй це з тим, до чого він реально має доступ у системі, — різниця і є доступ без обґрунтування.
- Перевір, чи є в кожного з них письмове або електронне уповноваження, а не просто логін, переданий на словах.
- Познач у календарі, коли закінчуються договори, практики і співпраця з клієнтами, — це природні моменти для відкликання доступу.
Для команди з восьми людей цей список займає один вечір і показує саме ті випадки, які важко пояснити під час перевірки: «чому ця людина взагалі це бачить». Якщо це перша така ревізія даних у бюро, стаття з чого почати автоматизацію в малому бізнесі: чотири пороги замість загального аналізу показує, з чого починати.
Як це виглядає, коли доступами керує система
Вручну вести список уповноважень у таблиці зручно, поки команда не виросте або хтось не забуде оновити запис. Система, де доступ прив'язаний до клієнта, а не до спільного облікового запису, веде цю бухгалтерію сама:
- 01співробітник
- →02призначені клієнти
- →03журнал відкриттів картки
- →04сигнал по чужому клієнту
Хто саме має доступ до яких клієнтів, вирішує власник бюро — система Aura не вирішує це сама, а лише стежить за вже встановленими правилами. У послузі CRM та автоматизації дані клієнтів і відповідальні за них люди зберігаються в одному місці замість розрізнених файлів, а Інтеграції стежать, яке джерело даних справжнє, а яке лише копія, — не треба гадати, де картку клієнта оновлювали востаннє. Програмний доступ до самих даних — якщо бюро користується власними інструментами — надається і відкликається на стороні прав в API, а не розсиланням пароля поштою. Перегляд уповноважень після закінчення договору чи зміни ролі можна перетворити на звичайне Завдання з терміном і відповідальною людиною, щоб це не залежало від чиєїсь пам'яті. Доступи — один з елементів ладу в компанії: поруч із CRM, інтеграціями, API та завданнями в тій самій системі стоять Дашборди з показниками продажів і фінансів та щотижневі AI-звіти, схожі на ті, що описані у статті про автоматизацію звітності, які самі приходять до команди, замість того щоб чекати, поки хтось відкриє панель.
Часті питання
Чи потрібне уповноваження практиканту в бухгалтерському бюро?
Так. UODO прямо вказує, що обов'язок стосується не лише штатних співробітників, а й кожного, кому адміністратор доручив роботу, яка вимагає доступу до персональних даних, — включно з практикантами і стажистами. Виняток — люди, які самі є процесором або його співробітниками: для них діє договір доручення обробки.
Чим уповноваження відрізняється від договору доручення обробки даних?
Уповноваження регулює доступ усередині команди бюро — які співробітники і в якому обсязі можуть обробляти дані. Договір доручення обробки — окремий документ між бюро і клієнтом, обов'язковий, серед іншого, за ст. 28 RODO, і це зовсім інший обов'язок — одне не замінює інше.
Чи відповідає адміністратор, якщо помилку припустився процесор?
Так. У справі про штрафи для McDonald's Polska, на яку посилається UODO, відомство підтвердило, що за захист персональних даних відповідають і адміністратор, і процесор, — одна сторона не бере на себе всю відповідальність за іншу.
Що саме означає, що адміністратор має «контролювати» доступ?
За формулюванням UODO йдеться про реальний контроль над тим, хто і в якому обсязі має доступ до даних та на яких умовах їх обробляє, — а не про наявність одного документа. Уповноваження — один з інструментів, яким цю владу можна показати, поряд із механізмами контролю доступу в самій системі.
Чи обов'язково оформлювати уповноваження письмово?
Залежить від того, з якої норми випливає обов'язок у конкретному випадку. UODO вказує, що багато галузевих законів — наприклад, Кодекс праці — прямо вимагають письмового уповноваження. Яка форма потрібна саме твоєму бюро, варто уточнити в юриста або інспектора із захисту даних, оскільки це залежить від галузі й підстави обробки.
Коли потрібно забирати в людини доступ до даних клієнтів?
Природні моменти — закінчення трудового договору чи підряду, зміна ролі в команді і завершення співпраці з конкретним клієнтом. Жодного разу доступ не повинен залишатися «про всяк випадок» — саме такі забуті облікові записи найважче пояснити під час перевірки.