DSAR, изтриване и доказателства по ISO 27001 през 2026 г.

Имейлът пристигна във входящата поща на Сара в 9:03 ч.

Това не беше първата заявка за достъп от субект на данни, която бързо растящата ѝ SaaS компания беше получила. Но беше първата, която изглеждаше като публичен одит.

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

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

Часовникът вече беше започнал да отброява.

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

GDPR указва какви права имат физическите лица. ISO/IEC 27001:2022 дава на екипите по сигурност и съответствие дисциплината на системата за управление, чрез която да докажат, че тези права се обработват последователно, сигурно и повторяемо.

За CISO, мениджърите по съответствие, ръководителите по поверителност и собствениците на бизнес процеси целта не е да се създава повече документация. Целта е да се изгради един надежден процес за DSAR, изтриване и ограничаване, който генерира доказателствата, изисквани от GDPR, одитите по ISO/IEC 27001:2022 и по-широките очаквания за увереност съгласно NIS2, DORA, NIST CSF 2.0 и COBIT 2019.

Защо ad hoc обработването на DSAR се проваля под натиск

Повечето провали при DSAR не се дължат на лоши намерения. Те се дължат на фрагментация.

Една организация може да има уведомление за поверителност, пощенска кутия на длъжностното лице по защита на данните (DPO) и клауза по GDPR в договорите с доставчици, но въпреки това да се затруднява да отговори на базови оперативни въпроси:

• Кой валидира идентичността на заявителя?
• Кое юридическо лице е администратор или обработващ лични данни?
• Кои системи трябва да бъдат претърсени?
• Кой е собственик на всяка система?
• Кои данни попадат в обхвата?
• Кои данни трябва да бъдат заличени преди разкриване?
• Кои данни не могат да бъдат изтрити поради данъчни, одитни, съдебни, свързани с предотвратяване на измами или други правни задължения?
• Как ограничаването на обработването се прилага технически?
• Кои доставчици трябва да подпомогнат търсенето, експортирането, изтриването или ограничаването?
• Какви доказателства потвърждават, че заявката е обработена в срок?
• Какво се случва, ако DSAR разкрие нарушение на сигурността на личните данни?

GDPR Article 5 изисква личните данни да се обработват законосъобразно, добросъвестно и прозрачно, да се събират за конкретни цели, да бъдат ограничени до необходимото, да се поддържат точни, да не се съхраняват по-дълго от необходимото и да бъдат защитени с подходящи технически и организационни мерки. Article 5(2) изрично въвежда отчетност: администраторът трябва да може да докаже съответствие. Article 4 определя обработването широко, включително събиране, съхранение, използване, разкриване, ограничаване, изтриване и унищожаване.

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

GDPR Article 3 също е важен за облачни, SaaS, финтех и цифрови бизнеси извън ЕС. Ако предлагате стоки или услуги на физически лица в Съюза, наблюдавате тяхното поведение или обработвате лични данни в контекста на установяване в ЕС, GDPR може да се прилага дори когато операциите са възложени външно или инфраструктурата е глобална.

ISO/IEC 27001:2022 внася структура в тази реалност. Клаузи 4.1 до 4.4 изискват организацията да разбира своя контекст, заинтересованите страни, изискванията, обхвата на системата за управление на информационната сигурност (СУИС) и взаимодействащите процеси. Субектът на данни е заинтересована страна. Правата по GDPR са изисквания. SaaS приложенията, доставчиците на идентичност, платформите за анализ, инструментите за поддръжка, хранилищата за данни и облачните резервни копия са взаимодействащи процеси. Процесът за DSAR принадлежи вътре в СУИС, а не до нея.

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

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

GDPR Article 6 е централен за тази логика на вземане на решения. Не можете да обработвате, съхранявате, разкривате или отказвате изтриване, без да разбирате правното основание. Article 9 повишава изискванията за специални категории лични данни, като здравни данни, биометрични данни, използвани за уникална идентификация, или данни, разкриващи чувствителни характеристики. В SaaS среда през 2026 г. това може да засегне въвеждане на потребители, проверка на идентичността, мониторинг за измами, прикачени файлове към клиентска поддръжка и записи за служители.

Корпоративната Политика за защита на данните и поверителност [P17] на Clarysec формулира задължението пряко. В клауза 3.6 „Цели“ тя изисква организацията да:

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

Тази цел става проверима при одит само когато е свързана със собственици, регистри, процеси, контроли и доказателства.

Започнете оттам, откъдето започват одиторите: обхват, заинтересовани страни и собственост

В Zenith Blueprint: 30-стъпкова пътна карта за одитори [ZB], фазата „Основа и лидерство на СУИС“, стъпка 2, се фокусира върху потребностите на заинтересованите страни и обхвата на СУИС. За GDPR Blueprint определя очакванията на регулаторите така:

Регулатори на ЕС
(GDPR)

Законосъобразно обработване на лични
данни, докладване на нарушения в 72 ч.,
права на субектите на данни

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

Това е правилната отправна точка. Преди да автоматизирате билети или да конфигурирате портали, определете обхвата на обработването на правата на субектите на данни:

1. Кои юридически лица действат като администратор, съвместен администратор или обработващ лични данни?
2. Кои продукти, услуги и територии са в обхвата?
3. Кои категории субекти на данни съществуват, като клиенти, служители, пробни потребители, потенциални клиенти, доставчици, посетители на уебсайт или потребители на приложение?
4. Кои системи, хранилища и доставчици съхраняват лични данни?
5. Кои роли одобряват разкриване, отказ, изтриване, ограничаване или ескалация?
6. Кои показатели се докладват на ръководството?

Клаузи 5.1 до 5.3 на ISO/IEC 27001:2022 изискват лидерство, съгласуване на политиките, ресурси и възложени отговорности. Това е пряко съгласувано с отчетността по GDPR.

Политиката за защита на данните и поверителност [P17], клауза 6.4.1 „Изисквания за внедряване на политиката“, гласи:

Длъжностното лице по защита на данните (DPO) следва да поддържа документирани процеси за приемане, валидиране, проследяване и отговор на заявки от субекти на данни (DSR).

За МСП Политиката за защита на данните и поверителност - SME [P17S] на Clarysec използва пропорционално разпределение на собствеността. Клауза 5.2.1 „Изисквания за управление“ гласи:

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

Този регистър на дейностите по обработване е оперативното ядро на готовността за DSAR. Ако е непълен, екипът по DSAR търси по памет, Slack съобщения и неформално знание. Ако е точен, екипът търси по дейност по обработване, категория данни, собственик на система, доставчик и правило за съхранение.

Процесът на Clarysec за DSAR: от приемане до приключване

Готовият за одит процес за DSAR трябва да бъде достатъчно прост, за да се изпълнява под натиск, но достатъчно контролиран, за да издържи проверка от регулатор, клиентски преглед за увереност или одит по ISO/IEC 27001:2022.

1. Приемане и потвърждение

Заявките следва да постъпват през контролиран канал, като пощенска кутия за поверителност, портал, формуляр за поддръжка или опашка за правен прием. Персоналът трябва да разпознава заявки, написани на обикновен език. Не е необходимо лицето да напише „DSAR“, за да упражни право. „Какви данни имате за мен?“ или „изтрийте профила ми“ може да е достатъчно, за да задейства процеса.

Политиката за защита на данните и поверителност - SME [P17S], клауза 6.5.2 „Изисквания за внедряване на политиката“, определя ясно ниво на обслужване:

Координаторът по поверителност трябва да потвърди получаването на заявките в срок до 3 работни дни и да отговори в срок до 30 дни

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

2. Проверка на идентичността и правомощията

DSAR може да се превърне в нарушение на сигурността на личните данни, ако информацията бъде изпратена на грешното лице. Проверката следва да бъде пропорционална и да не събира прекомерни нови лични данни. Използвайте удостоверени портали, когато е възможно. За бивши потребители валидирайте спрямо известни данни за акаунта. За служители координирайте с „Човешки ресурси“ (ЧР). За представители изисквайте доказателство за правомощия.

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

3. Класифициране на заявката

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

4. Търсене в инвентара, а не само в очевидните системи

Тук ISO/IEC 27001:2022 става практически приложим. Zenith Blueprint [ZB], фаза „Контроли в действие“, стъпка 22, предупреждава, че обхватът на инвентара е по-широк, отколкото много организации очакват:

Обхватът на този инвентар е по-широк, отколкото повечето осъзнават. Той трябва да включва:

✓ Физически активи: лаптопи, сървъри, телефони, резервни ленти, преносими носители, печатни
записи.
✓ Цифрови активи: документи, набори от данни, хранилища, имейли, изходен код, файлове, съхранявани
в облак.
✓ Логически активи: потребителски акаунти, удостоверителни данни, ключове, софтуерни лицензи, приложно-програмни интерфейси (API).
✓ Активи, свързани с услуги: SaaS платформи, управлявани услуги по сигурност, външно възложено
съхранение.
✓ Хора като активи: не в смисъл на комодифициране, а от гледна точка на възложени отговорности,
достъп и ролево обусловена експозиция към информация.

Стъпка 22 също обяснява собствеността:

Всеки актив трябва да има определен собственик — не лицето, което го използва, а лицето, което носи отчетност за
неговото използване, защита и жизнен цикъл. Собствеността е съществена за съгласуването с контролите: кой класифицира
актива (5.10), кой определя нивото му на достъп (8.3), кой управлява неговото изтриване (8.10), кой гарантира
връщането му (5.9 се припокрива дискретно с процедурите за връщане на активи).

В Zenith Controls: Ръководството за крос-съответствие [ZC] контрол 5.9 от ISO/IEC 27002:2022, Инвентар на информацията и другите свързани активи, се разглежда като превантивен контрол, който поддържа поверителност, цялостност и наличност. Неговата концепция за киберсигурност е Identify, оперативната му способност е управление на активите, а областите му на сигурност включват управление, екосистема и защита.

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

5. Преглед, заличаване и одобрение на разкриването

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

Одобрението следва да бъде базирано на риска. Рутинни отговори за достъп могат да бъдат одобрявани от координатора по поверителност или DPO. Заявки, включващи служители, съдебно производство, специални категории данни, деца, измами, журнали за сигурност или големи експорти, следва да включват правното звено, ЧР или ръководството по сигурността.

6. Сигурно предоставяне

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

7. Приключване с доказателства

Политиката за защита на данните и поверителност [P17], клауза 6.4.3, е изрична:

Всички предприети действия следва да бъдат регистрирани за одитни цели, включително решенията за отказ на заявки.

Политиката за защита на данните и поверителност - SME [P17S], клауза 6.5.4, гласи:

Всички отговори на заявки от субекти на данни трябва да бъдат регистрирани в защитен регистър, като достъпът е ограничен до Координатора по поверителност и GM

DSAR не е приключен, когато имейлът е изпратен. Той е приключен, когато регистърът показва заявката, проверката на идентичността, решенията, претърсените системи, отговора, изключенията, одобренията, предоставянето и приключването.

Изтриването е контролирано унищожаване, не бутон „delete“

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

Корпоративната Политика за съхранение на данни и унищожаване [P14] на Clarysec, клауза 4.3.3 „Роли и отговорности“, възлага отговорност на ролята, която:

Отговаря на искания за изтриване и гарантира своевременното, проверимо изтриване на лични данни, когато това се изисква.

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

Zenith Blueprint [ZB], фаза „Контроли в действие“, стъпка 19, обяснява контрол 8.10 от ISO/IEC 27002:2022, Изтриване на информация, в оперативни термини:

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

То също предупреждава:

Не забравяйте резервните копия и архивираните системи — те често съхраняват исторически данни дълго след
оперативната им стойност. Политиките за изтриване трябва да обхващат:

✓ Настройки за съхранение на резервни копия,
✓ Жизнени цикли на моментни снимки,
✓ Архивирани хранилища за имейли или документи.

И завършва с доказателства:

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

В Zenith Controls [ZC] контрол 8.10 от ISO/IEC 27002:2022, Изтриване на информация, е съпоставен като превантивен контрол с фокус върху поверителността, съгласуван с концепцията за киберсигурност Protect и свързан с оперативните способности за защита на информацията плюс правни въпроси и съответствие.

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

Следователно готовността на приложенията е съществена. Политиката за изискванията за сигурност на приложенията - SME [P09S] на Clarysec, клауза 6.5.1.3, изисква приложенията да:

позволяват сигурен експорт и изтриване на лични данни, когато това се изисква по закон (напр. GDPR Article 17 – право на изтриване).

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

Задържане за правни цели и спиране на изтриването

Зрелият процес за изтриване трябва да включва път „да не се изтрива“. Това не е оправдание да се игнорира изтриването. Това е контролирано изключение.

Политиката за съхранение на данни и сигурно унищожаване - SME [P14S] на Clarysec за МСП, клауза 5.4 „Изисквания за управление“, гласи:

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

Политиката за съхранение на данни и унищожаване [P14], клауза 6.4.1, отразява същия принцип:

Ако е издадено правно задържане и спиране на изтриването (напр. при висящо съдебно производство, разследване или одит), данните, които иначе подлежат на унищожаване, трябва да бъдат запазени след нормалния им срок за съхранение.

Одиторите искат и двете страни на историята: доказателства за своевременно изтриване и доказателства за обосновано съхранение.

Ограничаване на обработването: подценяваното право

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

Чести примери включват:

• Клиент оспорва точността и иска да спрете да използвате данните, докато тя се проверява.
• Бивш служител възразява срещу обработването, но записът е необходим за правни претенции.
• Потребител иска изтриване, но минимални данни трябва да бъдат запазени за поддържане на списък за потискане.
• Разследване за измама изисква съхранение, но не и нормална оперативна употреба.

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

В Zenith Controls [ZC] контрол 5.34 от ISO/IEC 27002:2022, Поверителност и защита на PII, се разглежда като превантивен контрол, който поддържа поверителност, цялостност и наличност. Той се съпоставя с Identify и Protect, с оперативни способности за защита на информацията и правни въпроси и съответствие.

Zenith Blueprint [ZB], фаза „Контроли в действие“, стъпка 23, обобщава одитния тест:

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

Ключовата фраза е „поддържат се оперативно, а не само чрез политика“.

Съпоставяне на процесите за DSAR с доказателства по ISO/IEC 27001:2022

ISO/IEC 27001:2022 не замества GDPR. Той организира доказателствата.

Клаузи 6.1.1 до 6.1.3 изискват оценка на риска, третиране на риска, критерии за приемане на риск, собственици на риска, избор на контроли, Декларация за приложимост и План за третиране на риска. Рисковете при DSAR включват неоторизирано разкриване, пропуснати срокове, непълно изтриване, незаконосъобразно съхранение, прекомерна проверка на идентичността, липса на съдействие от доставчик и невъзможност за ограничаване на обработването.

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

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

Практичен процес за достъп, изтриване и ограничаване

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

Стойност за крос-съответствие отвъд GDPR

Процесът за DSAR е вкоренен в GDPR, но същите контроли поддържат по-широки рамки.

NIS2 Article 20 прави киберсигурността отговорност на управлението за съществени и важни субекти. Article 21 изисква подходящи и пропорционални технически, оперативни и организационни мерки, включително анализ на риска, обработване на инциденти, непрекъсваемост на дейността, сигурност на веригата на доставки, оценка на ефективността, киберхигиена, обучение, контрол на достъпа, управление на активите, автентикация и сигурни комуникации. DSAR разчита на много от същите способности.

DORA се прилага от 17 януари 2025 г. за много финансови субекти и установява единни изисквания за управление на ИКТ риска, докладване на инциденти, тестване на устойчивостта и риск от трети страни в областта на ИКТ. Articles 5 и 6 изискват управление и документирано управление на ИКТ риска. Articles 17 до 20 разглеждат откриване, класификация, ескалация, комуникация и приключване на инциденти. Articles 24 до 30 разглеждат тестване на устойчивостта, риск от трети страни в областта на ИКТ, регистри на услуги, права на одит, местонахождение на данните, съдействие при инциденти и стратегии за изход. Финтех организация, която обработва DSAR чрез облачни платформи, следва да съгласува обработването на заявки за поверителност със своя регистър на ИКТ услугите.

NIST CSF 2.0 помага същата работа да бъде преведена в резултати за киберсигурността. GOVERN обхваща правни, регулаторни и договорни изисквания, стратегия за риска, роли, политика и надзор. IDENTIFY и PROTECT се съгласуват силно с видимостта на активите, класификацията на данни, контрола на достъпа, изтриването, управлението на доставчици и защитата на поверителността.

COBIT 2019 поставя управленски въпроси. Кой е собственик на процеса? Какви цели са дефинирани? Как се измерва изпълнението? Как се одобряват изключенията? Как се получава увереност? Доказателствата по DSAR могат да поддържат цели като APO13 Managed Security, APO14 Managed Data и DSS06 Managed Business Process Controls.

Одиторската перспектива

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

Показатели за DSAR, които ръководството трябва да вижда

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

Тези показатели показват дали правата на субектите на данни са оперативно устойчиви или зависят от героични усилия.

Чести пропуски в готовността за DSAR

Clarysec често наблюдава едни и същи слабости в SaaS, финтех, професионални услуги и МСП с приоритетно използване на облачни услуги:

• Няма собственик за всяка система, съдържаща лични данни
• Регистърът на обработването не е съгласуван с действителното използване на SaaS
• Маркетинговите, аналитичните и платформите тип хранилище за данни са изключени от търсенията
• Няма документиран стандарт за проверка на идентичността
• Няма преглед за заличаване преди разкриване
• Изтриване в продукционна среда се извършва без третиране на резервните копия
• Няма проверка за задържане за правни цели преди изтриване
• Ограничаването се обработва ръчно без системен флаг
• В договорите с доставчици липсват условия за съдействие при DSAR
• Отказите и частичните откази не се документират
• Няма извадкова проверка от вътрешен одит на приключени DSAR
• Персоналът на първа линия не е обучен да разпознава заявки

Контролен списък за готовност за DSAR през 2026 г.

Използвайте това като тест за зрялост:

• Имаме ли документиран процес за приемане, валидиране, проследяване и отговор на DSR?
• Потвърждаваме ли получаването на заявки в рамките на дефиниран вътрешен SLA?
• Поддържаме ли защитен регистър за DSR с ограничен достъп?
• Имаме ли актуален регистър на дейностите по обработване с категории, цели, правни основания и срокове за съхранение?
• Знаем ли всяка система, SaaS платформа, хранилище и доставчик, които може да съхраняват лични данни?
• Има ли всеки релевантен актив собственик с отчетност?
• Можем ли да експортираме лични данни сигурно?
• Можем ли да изтриваме лични данни сигурно, когато това се изисква по закон?
• Можем ли да ограничаваме обработването технически или процедурно?
• Проверяваме ли за задържане за правни цели преди изтриване?
• Документираме ли решенията за отказ, частичен отказ и изключение?
• Поддържат ли договорите с доставчици съдействие при DSAR?
• Тестваме ли процеса чрез вътрешен одит или настолни упражнения?
• Докладваме ли резултатността на DSAR на ръководството?
• Съпоставяме ли контролите за DSAR с третирането на риска по ISO/IEC 27001:2022 и Декларацията за приложимост?

Ако няколко отговора са „не последователно“, следващата заявка може да разкрие пропуска.

Превърнете правата на субектите на данни в готови за одит доказателства

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

Clarysec помага на организациите да изградят този процес, без да създават паралелна бюрокрация по съответствие. Започнете с Zenith Blueprint, за да поставите правата на субектите на данни в правилната фаза и стъпки на СУИС. Използвайте Политиката за защита на данните и поверителност, Политиката за защита на данните и поверителност - SME, Политиката за съхранение на данни и унищожаване, Политиката за съхранение на данни и сигурно унищожаване - SME и Политиката за изискванията за сигурност на приложенията - SME на Clarysec, за да дефинирате собствеността и оперативните правила.

След това използвайте Zenith Controls, за да съпоставите контролите 5.9, 5.34 и 8.10 от ISO/IEC 27002:2022 с доказателства за крос-съответствие за увереност по GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 и COBIT 2019.

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