Искания за достъп на субектите на данни: проследим процес за отговор

Искането за достъп на субект на данни проверява дали организацията може да свърже едно лице с информацията, която съхранява за него, да обясни как се използва тази информация и да изготви защитим отговор. Трудната част рядко е експортирането на клиентски профил. Тя е в откриването на свързаните записи, разрешаването на съвпаденията на идентичността, защитата на информацията за други хора и доказването на това какво е проверено.

За технически директор това е оперативна способност с правни граници. Приложенията се нуждаят от използваеми пътища за търсене; собствениците на системи се нуждаят от ясни отговорности; проверяващите се нуждаят от контекста на източниците; а окончателното разкриване изисква сигурно предаване. Политиката за поверителност не може да замести тези механизми.

Проследимият процес свързва получаването, търсенията, решенията при прегледа и предаването. Той трябва да позволява на втори проверяващ да отговори на четири въпроса: Търсихме ли на правилните места? Идентифицирахме ли правилното лице? Предоставихме ли изискваната информация? Можем ли да обясним всичко, което е задържано?

Разберете какво трябва да съдържа отговорът

Съгласно член 15 от ОРЗД лицето може да получи потвърждение дали се обработват негови лични данни, достъп до тези данни и информация за обработването. Искането за достъп на субект на данни често се съкращава като SAR или DSAR. Не е необходимо в него да се използват тези термини.

Имейл с текст „Моля, изпратете ми всичко, което съхранявате за мен“ може да бъде валидно искане. Лицето не е длъжно да обяснява мотивите си или да използва вътрешен формуляр. Формулярът може да улесни приемането, но не бива да се превръща в пречка за упражняването на правото.

Отговорът има два отделни компонента: самите лични данни и придружаващото обяснение. Списък с категории като „данни за контакт, покупки и записи от поддръжката“ не замества копието на данните.

Тези отговори трябва да отразяват реалния контекст на обработване за лицето. Стандартното уведомление за поверителност е полезна основа, но може да не обяснява необичайна ескалация в поддръжката, оценка при подбор на персонал или конкретно разкриване.

Администраторът отговаря за отговора. Когато вашата организация действа като обработващ лични данни, пренасочете искането към администратора и оказвайте съдействие съгласно приложимите уговорки. Член 28 изисква съдействие от обработващия във връзка с правата на субектите на данни, като се отчита естеството на обработването. Едно дружество може да е администратор по отношение на администрирането на акаунти и обработващ по отношение на хоствано съдържание на клиенти, затова определете ролята за всеки релевантен набор от данни.

Изградете запис за случая, преди да събирате данни

Създайте идентификатор на случая и запазете оригиналното искане. Запишете кога то е достигнало организацията за първи път, а не само кога екипът по поверителност е отворил заявка. Обучете екипите по поддръжка, човешки ресурси, продажби и другите екипи с външен контакт да разпознават исканията и да ги препращат своевременно.

Първоначалният запис трябва да съдържа данните за контакт на заявителя, известните идентификатори, формулировката на искането, датата на получаване, изчисления срок, отговорния собственик, проверяващия и всеки представител, действащ от името на лицето. Записвайте последващата кореспонденция в същия случай.

Избягвайте да поставяте необработени разкривания в широко достъпна система за обслужване. Общата заявка може да препраща към ограничен запис за случая, без да излага чувствителни експорти пред всички, които работят по поддръжката.

Разпределете отговорностите преди първия експорт. Собственикът на случая координира сроковете и кореспонденцията; собствениците на системи установяват обхвата на търсенето; проверяващ по поверителност или правен проверяващ оценява ограниченията; а оправомощено одобряващо лице одобрява предоставянето. В малка организация едно лице може да изпълнява няколко роли, но при чувствителни предоставяния независимата проверка остава полезна. Когато е определено длъжностно лице по защита на данните, запазете неговата независима консултативна и наблюдаваща роля, вместо да го натоварвате с отговорност за всяко техническо извличане или организационно решение за обработване.

Третирайте управлението на сроковете като контрол

Член 12, параграф 3 изисква действие без ненужно забавяне и по правило в срок от един месец от получаването. При необходимост, като се отчитат сложността и броят на исканията, този срок може да бъде удължен с още два месеца. Заявителят трябва да бъде информиран в рамките на първия месец, като се посочат причините.

Използвайте изчисление по календара, вместо да приемате, че един месец означава 30 дни. Документирайте приложимото изчисление на срока и планирайте по-ранен вътрешен момент за решение. Практическа препоръка е да прегледате обхвата на търсенето и нуждата от удължаване доста преди изтичането на първия месец.

Удължаването не е автоматична отстъпка при недостиг на персонал. Документирайте конкретните обстоятелства, например разпръснати исторически записи, изискващи значителен преглед с оглед на трети лица. Ако организацията реши да не предприеме действия, член 12, параграф 4 изисква уведомление в срок от един месец с обяснение защо и с информация за възможността за жалба и за съдебна защита.

Проследявайте отделно въпросите за самоличността и за уточняване. Не вграждайте в процеса предполагаемо подновяване или спиране на срока, без да проверите приложимата правна позиция. Задавайте необходимите въпроси своевременно и продължавайте работата, която може безопасно да продължи.

Проверявайте самоличността пропорционално

Член 12, параграф 6 позволява искане на допълнителна информация, когато има основателни съмнения относно самоличността. Целта е да се предотврати разкриване пред измамник, а не да се събере още един ненужен набор от данни за самоличност.

Удостоверен акаунт и утвърден канал за контакт могат да осигурят достатъчна увереност за обичайните записи на акаунта. Искане от непознат адрес за чувствителна историческа информация, свързана с трудово правоотношение, може да изисква по-строги проверки. Когато е намесен представител, проверете неговите правомощия, както и съответната самоличност.

Документирайте причината за съмнението, поисканите доказателства и резултата от проверката. Предпочитайте да записвате, че проверката е успешна, вместо да съхранявате безсрочно пълен документ за самоличност. Прилагайте подходящо правило за съхранение към всеки запазен материал от проверката.

Вътрешното планиране и ограничените търсения често могат да започнат, преди самоличността да е потвърдена; разкриването – не. Поддържайте тези дейности разделени, така че проверката да защитава лицето, без да забавя ненужно идентифицирането на източниците.

Уточнявайте, без мълчаливо да стеснявате искането

Ако лицето споменава както записи за акаунта, така и трудово правоотношение, уточнете дали иска и двете. Когато организацията съхранява голям обем информация, въпрос за релевантните дейности или периоди може да направи отговора по-полезен. Обяснете какво включва предложеният обхват и запазете отговора на лицето.

Не тълкувайте мълчанието като съгласие да се търси само в най-лесната система. Ако уточнението остане нерешено, собственикът на случая се нуждае от документирано решение за обхвата и при необходимост от правно становище. Обяснението на заявителя може да насочва търсенията, но той не бива да познава имената на вашите бази данни или вътрешните идентификатори, за да упражни правото си на достъп.

Превърнете картата на данните в план за търсене

Търсенето трябва да започне от дейностите по обработване и системите, свързани с лицето, а не от бутона за експорт, който е най-лесно да се намери. Една полезна карта на данните идентифицира приложенията, хранилищата на документи, обработващите, собствеността и връзките между идентификаторите.

Клиентът може да има идентификатор на акаунт, идентификатор за фактуриране, идентификатор в поддръжката, предишен имейл адрес и псевдонимизиран аналитичен идентификатор. Служителят може да има идентификатори в системите за персонал, заплати, контрол на достъпа и устройства. Ако тези връзки не са разбрани, търсенето по име може да доведе както до пропуски, така и до грешни съвпадения.

Изградете регистър на източниците за случая. Всеки ред трябва да посочва източник, неговия собственик, метода на търсене, набора от идентификатори, местоположението на резултатите, ограниченията и проверяващия. Документирайте и търсенията без резултати, а не само успешните.

Търсете отвъд основния запис

Личните данни могат да включват мнения, оценки, изведени предпочитания, вътрешни бележки и записи за дейност. Те не се ограничават до информацията, която лицето само е въвело. Също така не всеки документ, в който се споменава име, непременно представлява изцяло подлежащи на разкриване лични данни за това лице.

Включете релевантните прикачени файлове, архивираните заявки, споделените файлове и спомагателните системи, използвани от бизнеса. Търсете по исторически идентификатори, когато те остават свързани с лицето. При имейлите идентифицирайте релевантните отговорници и контекст, вместо сляпо да експортирате всяко съобщение, съдържащо често срещана фамилия.

Техническите журнали изискват тълкуване. Времевата отметка на вход, идентификаторът на устройство или събитие за достъп от поддръжката могат да бъдат лични данни, когато са свързани със заявителя. Документирайте какво означават полетата и дали времевата отметка е в UTC или в местно време. Самоличността на служителите в журналите за достъп изисква отделна оценка; не приемайте, че всяко име на оператор трябва да бъде разкрито само защото се появява до дадено събитие.

Резервните копия също изискват изрична оценка. Документирайте тяхната цел, достъпност, срок на съхранение и дали релевантна информация съществува само там. Не третирайте всяко резервно копие като автоматично изключено и не възстановявайте цяла производствена среда в неконтролирано работно пространство за преглед. Ескалирайте въпросите за възстановяването и обхвата, когато е необходимо.

Направете резултатите от търсенето възпроизводими

Запазете достатъчно подробности, за да може друг оправомощен проверяващ да разбере как е извършено търсенето. Това може да включва текста на заявката, настройките на инструмента, обхванатия период, версията на експорта и известните ограничения. Не копирайте идентификационни данни или тайни в записа за случая.

Използвайте обща крайна дата за извличане и документирайте промените, настъпили по време на обработката. Определете как ще се третира по-късната дейност, вместо да позволявате на различни собственици да експортират непоследователни моментни снимки без обяснение.

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

Празно търсене не е доказателство за липса, ако заявката е използвала грешен идентификатор или експортът е пропуснал архивирани елементи. Изисквайте от собствениците да потвърдят обхвата, а не само че са натиснали „експорт“.

Ескалирайте липсващите източници, докато има време за действие

Обработващ, който не е отговорил, недостъпен архив и неуспешен експорт са различни проблеми. Документирайте всеки от тях изрично, с отговорник и следващо действие. Неуспешно търсене не бива да се появява в регистъра като „не са намерени данни“.

При искане за съдействие от обработващ посочете идентификаторите, исканите данни, релевантния период и формата на отговора, след което проверете дали върнатият материал обхваща искането. Договорните уговорки за съдействие трябва да осигуряват използваем контакт и път за ескалация. Задължението на администратора да отговори не се прехвърля на доставчика само защото събирането зависи от него.

Ако пропуск застрашава пълнотата или срока, ескалирайте преди предоставянето. Оценете допълнителните търсения, евентуално законосъобразно удължаване и обяснението, което е необходимо за заявителя. Не прикривайте нерешения въпрос с обхвата зад общо твърдение, че всички системи са проверени.

Прегледайте релевантността, контекста и правата на трети лица

Събирането създава набор от данни-кандидати, а не пакет за отговор. Човешкият преглед трябва да определи дали всеки елемент засяга заявителя, дали е разбираем и дали разкриването му засяга правата на някой друг.

Използвайте прост регистър на решенията: разкриване, разкриване със заличавания, изключване като несвързано или задържане въз основа на приложимо ограничение. Документирайте препратката към източника, проверяващия, причината и всяка ескалация. За рутинни повтарящи се решения може да е подходящо документирано групово правило, при условие че изключенията остават видими.

Предоставяйте разбираеми данни, а не необяснен масив

Копието трябва да позволява на лицето да разбере своите данни. Структурираните експорти могат да работят добре, ако имената на колоните, кодовете, връзките и времевите отметки са обяснени. Файл с база данни, пълен с недокументирани кодове на статус, е технически четим, но може да не е разбираем.

Понякога извлечението е достатъчно; понякога е необходим контекстът на документа, за да се разбере информацията. Например „оценка на риска: 42“ казва малко без значението на оценката и релевантния контекст на оценяването. Преценете дали са необходими допълнителни откъси или документи, вместо да приемате, че трябва да се изпратят всички оригинални документи или че обобщението винаги е достатъчно.

При приложимо автоматизирано вземане на решения обяснете на разбираем език съответната логика, значението и предвидените последици. Необработен алгоритъм или неясно твърдение, че „ИИ оценява риска“, може да не отговаря на въпроса. Включете собственика на системата и правния проверяващ, за да установите какво изисква член 15, параграф 1, буква з) за този случай на употреба.

Заличавайте избирателно и проверявайте резултата

Член 15, параграф 4 защитава правата и свободите на други лица. Един споделен разговор може да съдържа информация за заявителя, данни за акаунта на друг клиент и лични обстоятелства на служител. Оценявайте всеки елемент, вместо по подразбиране да задържате целия разговор.

Заличаването трябва, доколкото е възможно, да запазва значимия за заявителя контекст. Поверителността, интелектуалната собственост или неприкосновеността на личния живот на друго лице може да изискват защита, но общият етикет „поверително“ не е пълен анализ. Може да се прилагат и ограничения по националното право; документирайте действителното правно основание и мотивите.

Техническото заличаване изисква собствена проверка на качеството. Премахнете скрития текст, коментарите, проследените промени, метаданните на документите, разделите в електронните таблици и вградените прикачени файлове, когато е необходимо. Проверете дали черните полета не могат да бъдат премахнати и дали текстът под тях не може да бъде копиран. Отворете отново окончателните файлове с програма за преглед, независима от инструмента за редактиране.

При чувствителни случаи разделете подготовката от одобрението. Едно лице извършва заличаванията; друго проверява както за случайно разкриване, така и за прекомерно премахване. Поддържайте незаличения източник с ограничен достъп и ясно го разграничавайте от копието за предоставяне.

Сглобете и предайте пълен отговор

Създайте пакет за отговор с придружително обяснение, личните данни, ръководство за форматите или кодовете и изискваната информация за обработването. Обяснете съществените ограничения или решенията за задържане на език, който заявителят може да разбере, без да разкривате самата защитена информация.

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

Преди одобрението извършете проверка за предоставяне:

• Получателят и каналът за предаване съответстват на проверения заявител или на оправомощения представител.
• Всички планирани източници имат резултат, включително нерешените ограничения.
• Копието съдържа данните на заявителя, а не подобен запис за друго лице.
• Информацията по член 15 е пълна и съответства на събраните записи.
• Заличаванията, прикачените файлове, имената на файловете и скритото съдържание са проверени.
• Отговорът обяснява приложимите пътища за жалба и съществените решения.
• Уговорките за предаване и достъп съответстват на чувствителността на информацията.

Член 32 изисква сигурност, съответстваща на риска; той не предписва един универсален метод за предаване. Удостоверено изтегляне с ограничен достъп може да е подходящо. При някои обстоятелства може да е уместно криптирано прехвърляне или друг контролиран канал. Избягвайте да поставяте чувствителни експорти в обикновен прикачен файл към имейл само защото това е удобно.

Тествайте преживяването на получателя. Може ли да отвори формата, да разбере съдържанието и да изтегли пакета, преди достъпът да изтече? Запазете доказателства за изпращането или за предоставянето на отговора и ги разграничавайте от доказателството, че той действително е бил отворен.

Случаят трябва да съхранява оригиналното искане, кореспонденцията, търсенията, мотивите от прегледа, одобрения отговор и записа за предаването съгласно подходяща политика за съхранение. Сглобеният пакет създава концентриран риск за поверителността: ограничете достъпа, премахнете временните копия и избягвайте безсрочното съхранение на всеки необработен експорт само за да докажете отчетност.

Третирайте таксите, отказите и изтриването като отделни решения

Исканията по правило са безплатни. Съгласно член 12, параграф 5 явно неоснователно или прекомерно искане може да обоснове разумна такса въз основа на административните разходи или отказ да се предприемат действия. Тежестта на доказване на това условие е на администратора. Член 15, параграф 3 също позволява разумна такса за административни разходи за допълнителни копия.

Широко искане, трудов спор или неудобна натовареност сами по себе си не са достатъчни. Ескалирайте предлаганите такси и откази за правен преглед, документирайте доказателствата и предоставете изискваното обяснение и информация за средствата за защита. Не карайте служителите от първа линия на поддръжката да решават дали мотивите на дадено лице са приемливи.

Достъпът и изтриването също изискват различни оценки. Ако някой поиска копие и след това изтриване, проследявайте изрично и двете права. Не изтривайте доказателствата, необходими за отговора на искането за достъп, без да вземете предвид взаимодействието между тях.

Член 17 съдържа изключения, включително когато обработването е необходимо за спазване на правно задължение или за правни претенции. Посочете действителното задължение, засегнатите записи и приложимия срок на съхранение. Сроковете се различават в зависимост от юрисдикцията и вида на записа; „финансовият отдел го изисква“ не е достатъчно обяснение.

Задълженията за съхранение могат да ограничат изтриването, но сами по себе си не премахват правото на достъп. Изтрийте онова, което трябва да бъде изтрито, запазете онова, което има валидно основание, и контролирайте последващото използване. Всяко решение за ограничаване на обработването трябва да се оценява по приложимите за него правила, а не да се третира като автоматична последица от всеки отказ за изтриване.

Неправилното третиране на правото на достъп може да доведе до жалби, принудителни мерки и потенциални искове за обезщетение. Член 83, параграф 5 поставя нарушенията на правата на субектите на данни в по-високата степен на административни глоби – до 20 милиона евро или 4% от общия световен годишен оборот, като се прилага по-високата сума. Действителните последици зависят от фактите; оперативният урок е да се запазят както своевременното действие, така и доказателствата за пълен отговор.

Практически пример: клиент с исторически идентификатори

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

Искането пристига чрез поддръжката на 4 май. Собственикът на случая веднага документира получаването и изчислява обичайния срок. Подателят използва нов адрес, затова екипът задава пропорционални въпроси за проверка чрез утвърден канал за контакт с акаунта. Той не изисква по подразбиране паспорт.

Лицето потвърждава предишен имейл адрес. Записите в приложението свързват двата адреса с един идентификатор на акаунт; фактурирането използва отделен идентификатор на клиента. Регистърът за търсене документира тези връзки, така че собствениците да не търсят само по новия адрес.

Поддръжката открива заявки и прикачени файлове. Фактурирането предоставя фактури и записи за статуса на плащанията, но не и несвързани данни за картодържатели. Търсенето в имейлите обхваща мениджъра на акаунта и отговорника за ескалация в поддръжката. От обработващия аналитичните данни се изискват релевантните записи и приложимите съпоставки на идентификатори.

При прегледа се открива вътрешна бележка, описваща оплакването на клиента, и прикачен файл, съдържащ информация за друг клиент. Бележката е оценена като лични данни за заявителя. В прикачения файл се правят целеви заличавания. Експорт на събития се предоставя с речник на полетата и обяснение за часовата зона.

Отговорът обяснява целите на обработването, релевантните получатели, сроковете на съхранение за отделните набори от данни, правата, източниците и приложимите гаранции при предаване. Проверяващият потвърждава, че търсенето обхваща архивираните заявки за поддръжка. Одобреният пакет се предава чрез удостоверен канал, а събитието по предаването се документира.

Възниква едно подобрение: идентификаторът за фактуриране е липсвал в картата на данните. Екипът възлага коригираща задача за актуализиране на тази връзка и за тестването ѝ при следващата репетиция. Искането е довело както до отговор, така и до измеримо подобрение на бъдещия обхват.

Използвайте автоматизация в изрични граници на прегледа

Автоматизацията може да подпомага насочването на входящите искания, напомнянията, търсенето на идентификатори, подготовката на експорти, премахването на дубликати и предложенията за заличаване. Стойността ѝ зависи от обхвата на източниците и правата за достъп. Конектор, който търси само в активни записи, не може да обоснове твърдението, че е претърсен и архив.

Подготовката с помощта на ИИ трябва да остава чернова. Валидирайте съвпаденията на идентичността, пропуснатия материал, обобщенията, заличаванията и правните заключения. Не подавайте пакет за разкриване към неодобрена среда на модел. Прилагайте най-малките привилегии, подходящи оценки на обработващите и на предаванията, както и контроли върху съхранението и по-нататъшното използване.

Документираният модел на Secani за доказателства и собственост може да подпомогне управлението около тази работа: моделирайте релевантните системи и доставчици, определете собственици и проверяващи и свържете доказателствата с изискванията и решенията. Ограниченията на търсенето и липсващата собственост могат да се превърнат в задачи, а връзките към източниците, коментарите, одобренията и времевите отметки запазват следата от прегледа. Самите търсения, правните оценки и сигурното предаване все пак изискват подходящо внедрен оперативен процес.

Въпроси, които възникват след предаването

Какво да направим, ако заявителят посочи липсващ запис?

Отворете отново оценката на обхвата, вместо да приемате предаването като доказателство за пълнота. Проверете идентификатора, източника и ограниченията на първоначалното търсене. Ако отговорът е бил непълен, организирайте своевременно подходяща корекция и запазете обяснението заедно с първоначалния запис за решението. Актуализирайте метода на търсене, ако пропускът разкрива повтарящ се дефект.

Какво да направим, ако организацията не съхранява лични данни?

След подходящи търсения отговорете с потвърждение, че не се обработват лични данни, вместо да оставяте искането без отговор. Поддържайте доказателствата от търсенето пропорционални на обстоятелствата. Разграничавайте истинския отрицателен резултат от невъзможността да се намери акаунт с предоставените идентификатори.

Какво да направим, ако пакетът достигне до грешно лице?

Ограничете достъпа незабавно, когато е възможно, и започнете оценка за нарушение на сигурността на личните данни. Не приемайте, че всяко погрешно предаване автоматично подлежи на уведомяване или че искането за връщане решава проблема. Оценете разкритата информация, получателите и рисковете съгласно членове 33 и 34 и документирайте решението за уведомяване отделно от коригирането на отговора на искането за достъп.

Репетирайте преди следващото реално искане

Започнете с контролиран пример и известен набор от предварително подготвени записи. Включете стар идентификатор, препратка към трето лице, архивиран елемент и запис, съхраняван от обработващ. Проверете дали процесът открива всеки от тях и създава разбираем, безопасно заличен отговор.

Измервайте непокритите източници, нерешената собственост, неуспешните идентификатори, повторната работа при прегледа и проблемите при предаването – а не само колко бързо се затваря една заявка. Актуализирайте картата на данните и инструкциите за търсене въз основа на резултатите. Полезната репетиция завършва с проверен обхват, посочени отговорници за корекциите и запис за отговора, който друг проверяващ може да проследи.