Какво всъщност е DSAR

Искането за достъп до лични данни (DSAR) е моментът, в който потребител упражнява правата, които GDPR му предоставя върху неговите лични данни. За мобилния издател този “субект на данни” е един от вашите играчи или потребители, а искането може да пристигне по имейл, чрез заявка за поддръжка, ревю в магазина за приложения или формуляр в приложението. Поводът е прост: някой иска да знае какво съхранявате за него — или иска да предприемете действие по него.

От ключово значение е, че DSAR не е нужно да споменава GDPR, да използва думата “DSAR” или да следва някакъв образец. Едноредово съобщение като “изпратете ми моите данни” или “изтрийте акаунта ми” стартира часовника също толкова сигурно, колкото и официално юридическо писмо. Третирането само на официално изглеждащите искания като валидни е бърз начин да пропуснете срок.

Правата зад искането

DSAR обединява няколко отделни права, а едно и също съобщение може да задейства повече от едно. Да знаете кое от кое определя какво всъщност трябва да направите.

• Достъп — потребителят може да поиска копие от личните си данни плюс контекст: какво събирате, защо, с кого го споделяте и колко дълго го пазите.
• Изтриване (“право да бъдеш забравен”) — заличаване на данните му, включително копията, предадени на рекламни и аналитични партньори, при ограничени правни изключения.
• Преносимост — данните, които ви е предоставил, върнати в структуриран, машинночетим формат като JSON или CSV, за да могат да бъдат пренесени другаде.
• Коригиране — поправка на неточни или непълни данни, например грешен имейл или регион.

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

Сроковете са строги

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

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

Изграждане на работен процес, който се мащабира

Издателите, които се справят с DSAR спокойно, са ги превърнали в повторим процес, а не в авариен режим. Работещ процес изглежда така:

• Приемане. Публикувайте един-единствен, обявен канал — формуляр в приложението или специален адрес privacy@ — и насочвайте всичко през него, така че нищо да не се загуби в опашките за поддръжка.
• Проверка на самоличността. Потвърдете, че заявителят е собственик на акаунта, но искайте само това, което ви е нужно. Изискването на сканиран паспорт, за да намерите идентификатор в играта, само по себе си е проблем със съответствието.
• Запис и времеви печат. Запишете датата на пристигане незабавно; това е вашата отправна точка за срока.
• Намерете данните. Поддържайте карта на данните за всяко хранилище — вашия бекенд, логовете за сривове, аналитиката, рекламните SDK, CRM — което обработва потребителски данни, индексирана по стабилен идентификатор.
• Изпълнение и отговор. Експортирайте, изтрийте или коригирайте според искането, разпространете изтриванията до обработващите лица и отговорете на ясен език.
• Затворете цикъла. Архивирайте искането и отговора си като доказателство, че сте действали навреме.

Често срещани капани

Повечето провали са оперативни, а не правни. Внимавайте за следните:

• Забравени хранилища на данни. Рекламните и атрибуционните SDK, доставчиците на push известия и докладчиците за сривове съхраняват потребителски данни. Изтриване, което ги пропуска, е непълно.
• Свръхсъбиране по време на проверката, превръщащо искане за поверителност в риск за поверителността.
• Третиране на неформалните съобщения като не-искания и оставяне на месеца да изтече.
• Липса на доказателство за съгласие. Ако потребител оспори, че изобщо сте имали законно основание да обработвате данните му за реклами, трябва да покажете с какво се е съгласил и кога.

Как един CMP прави DSAR управляеми

Тук вашият слой за съгласие си заслужава. На DSAR се отговаря много по-лесно, когато можете незабавно да покажете с какво се е съгласил потребител, кога и в рамките на коя рамка. FlexyConsent — сертифициран от Google CMP, поддържащ IAB TCF 2.3 и Google Consent Mode v2 — съхранява запис на съгласието с времеви печат и одитна следа за всеки потребител. Когато пристигне искане за достъп, този запис се превръща в готова част от вашия отговор: приетите цели, участващите доставчици и версията на показаното известие. Когато пристигне искане за изтриване или възражение, същият запис доказва, че сте спрели персонализираните рекламни сигнали в точния момент. Съчетаването на тази история на съгласието с вашата карта на данните превръща DSAR от паника в обикновена справка.

Тази статия е обща информация за издатели и не представлява правен съвет; консултирайте се с квалифициран специалист за вашата конкретна ситуация.

Ключови изводи

• Всяко искане — колкото и неформално — може да бъде DSAR, а едномесечният, обикновено безплатен срок започва в деня, в който пристигне.
• Картографирайте всяко хранилище на данни, включително рекламните и аналитичните SDK, така че достъпът и изтриването да са наистина пълни.
• Проверявайте самоличността пропорционално и записвайте всяко искане, за да докажете, че сте отговорили навреме.
• Записите на съгласие и одитната следа на FlexyConsent ви дават незабавно, защитимо доказателство за изпълнение на искания за достъп, изтриване и възражение.