Модулі

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

приклад: чому інформація про минулих працівників важлива

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

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

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

Працівники, які припинили трудові відносини та GDPR

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

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

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

Скасування облікового запису видаляє особисту інформацію

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

Нетипові примітки до об'єктів
Персональні знаки на об'єктах
Особисті кишені з предметами

Однак, скасування облікового запису не видаляє особисті дані – ім'я та електронну пошту.

Анонімізація - забуття

Виконати вимоги GDPR можна і за допомогою анонімізації. Анонімізувати можна тільки скасовані рахунки.

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

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

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

Анонімізація повністю відповідає вимогам GDPR. Він не повинен відповідати внутрішнім правилам організації, і перед його виконанням адміністратор повинен переконатися, що він виконаний відповідно до внутрішніх методик і правил.