Управление на лични данни (PII) за ISO 27701:2025 и GDPR

Искането пристигна във входящата поща на CISO с подвеждаща простота: „Project Wellness“. Бързо растяща fintech компания искаше да анализира съществуващи данни за клиентски транзакции, за да предоставя персонализирани съвети за спестяване, продуктови препоръки и анализи на риска от отлив на клиенти. Маркетингът виждаше ангажираност на клиентите. Продуктовият екип виждаше иновация. Ръководството виждаше конкурентно предимство.

CISO видя управленска мина.

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

В мрежата нямаше нападател. Нямаше изтекла база данни. Нямаше тикет за инцидент, маркиран в червено.

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

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

Това е пропускът в контрола, който внедряванията на система за управление на информацията за поверителност по ISO/IEC 27701:2025, или PIMS, трябва да затворят. Член 5 от GDPR изисква личните данни да се обработват законосъобразно, добросъвестно и прозрачно, да се събират за конкретни, изрично указани и легитимни цели, да бъдат ограничени до необходимото, точни, съхранявани само доколкото е необходимо, защитени по подходящ начин и обработвани при отчетност на администратора. Член 6 от GDPR добавя правното основание и логиката за съвместимост при последващо обработване. Тези принципи обаче стават защитими само когато са преведени в работни потоци, регистри, одобрения, правила за достъп, контроли за доставчици, мониторинг и доказателства.

Подходът на Clarysec е прост: управлението на събирането, използването и разкриването на лични данни (PII) трябва да се третира като контролиран оперативен модел, а не като правна бележка. Моделът е разположен в основата на ISO/IEC 27001:2022 ISMS, разширява се към ролите в ISO/IEC 27701:2025 PIMS и се доказва чрез политики, регистри, Zenith Blueprint: 30-стъпкова пътна карта на одитора и Zenith Controls: ръководство за съответствие между рамки на Clarysec.

Защо управлението на лични данни (PII) се проваля дори когато има документи за поверителност

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

Типичният модел е познат:

1. Екип добавя ново поле във форма за регистрация, защото то подобрява сегментирането.
2. Никой не записва защо точно това поле е необходимо.
3. Друг екип по-късно използва данните повторно за различна цел.
4. Доставчик получава експорт по широко формулирано споразумение за услуги.
5. Регистърът на дейностите по обработване се актуализира след пускането, ако изобщо се актуализира.
6. По време на одит организацията може да покаже уведомление за поверителност, но не може да покаже доказателства за решението.

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

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

Clarysec P17 Политика за защита на данните и поверителност ясно определя очакванията за жизнения цикъл:

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

За малки и средни предприятия Clarysec Политика за защита на данните и поверителност - SME превръща същия принцип в прагматично оперативно правило:

Лични данни могат да се събират само когато това е необходимо за легитимна, законосъобразна или договорна цел

А относно свеждането на данните до минимум:

Трябва да се събират и съхраняват само минимално необходимите лични данни

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

Контролната цел: спиране на неконтролираното обработване в три контролни точки

Силната PIMS трябва да контролира решенията относно лични данни (PII) в три момента: преди събиране, преди използване и преди разкриване.

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

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

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

Clarysec PII09 Политика за събиране, използване, разкриване и споделяне на лични данни (PII) е проектирана именно за този слой на управление. Тя използва обозначаване на ролите в PIMS, особено ролята на администратор, защото решенията за събиране, използване и разкриване обикновено се вземат от организацията, която определя целите и средствата.

За ограничаване на събирането PII09 Политика за събиране, използване, разкриване и споделяне на лични данни (PII) изисква:

[Администратор] Собственикът на процеса / собственикът на бизнес процеса ТРЯБВА да запише целта на събирането, източника или канала, категориите лични данни (PII), категориите субекти на данни и минималните елементи от данни в REG02 преди започване на всяка нова дейност по събиране или съществена промяна в събирането.

След това тя прави свеждането на данните до минимум проверимо:

[Администратор] Собственикът на процеса / собственикът на бизнес процеса ТРЯБВА да запише в REG02 обосновка на необходимостта за всеки елемент от лични данни (PII), преди този елемент да бъде събран.

Изискването за „всеки елемент от лични данни (PII)“ е разликата между общ инвентар на дейностите по обработване и доказателства за отчетност на ниво поле.

За вътрешно използване същата политика изисква:

[Администратор] Собственикът на процеса / собственикът на бизнес процеса ТРЯБВА да запише одобрените правила за вътрешно използване за всяка дейност по обработване в REG02 преди започване на използването.

За вторично използване:

[Администратор] Собственикът на процеса / собственикът на бизнес процеса ТРЯБВА да запише проверка за съвместимост при вторично използване в REG02, преди личните данни (PII) да се използват за цел, която все още не е одобрена за дейността по обработване.

А за външно разкриване:

[Администратор] Собственикът на доставчика / закупуването ТРЯБВА да запише самоличността на получателя, ролята на получателя, целта на разкриването, категориите лични данни (PII), честотата на споделяне, местоположението на обработването и източника на правомощие в REG08 преди започване на периодично външно споделяне.

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

REG02 и REG08: веригата от политика към контрол в Clarysec

При внедряванията на Clarysec REG02 не е пасивен инвентар на дейностите по обработване. Той е записът на решенията за целта на събиране, правното основание, категориите лични данни (PII), необходимостта, правилата за вътрешно използване, връзката със сроковете за съхранение и съвместимостта при вторично използване.

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

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

Този модел естествено се съгласува с ISO/IEC 27001:2022. Клаузи 4 до 10 изискват организацията да разбира контекста, изискванията на заинтересованите страни, обхвата, отговорностите на ръководството, оценката на риска, третирането на риска, оперативния контрол, оценката на резултатността и подобрението. Задълженията за поверителност по GDPR и ISO/IEC 27701:2025 стават част от системата за управление, вместо отделен „остров“ на поверителността.

ISO/IEC 27002:2022 също подпомага оперативния модел. Контрол 5.31, правни, законови, регулаторни и договорни изисквания, закотвя GDPR и секторните задължения. Контрол 5.34, защита на неприкосновеността на личния живот и защита на лични данни (PII), адресира специфичната защита на поверителността. Контрол 5.9, инвентаризация на информацията и други свързани активи, подпомага осведомеността за данните. Контроли 5.12 и 5.13 подпомагат класификацията и етикетирането. Контрол 5.14 управлява предаването на информация. Контроли 5.19 до 5.23 обхващат взаимоотношенията с доставчици, споразуменията с доставчици, ИКТ веригата на доставки, мониторинга на услугите на доставчици и облачните услуги. Контрол 8.11 подпомага маскирането на данни, 8.12 подпомага предотвратяването на изтичане на данни (DLP), 8.15 регистрирането, 8.16 дейностите по мониторинг и 8.24 използването на криптография.

Zenith Blueprint поставя тези контроли в път за внедряване. В етапа „Контроли в действие“ стъпка 23 обхваща организационни контроли 5.19 до 5.37, включително контрол 5.34 за защита на неприкосновеността на личния живот и защита на лични данни (PII). Blueprint обяснява:

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

След това той дава оперативната основа:

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

Точно това предоставят REG02 и REG08, когато се третират като живи управленски записи.

Практически пример: одобряване на Project Wellness без загуба на контрол

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

Ето как Clarysec би управлявал искането.

Стъпка 1: Създаване или актуализиране на дейността по обработване в REG02

Собственикът на процеса отваря REG02 и записва дейността по обработване преди започване на работата.

Ключовият момент е времето. REG02 се актуализира преди започване на новото обработване, а не след като функцията вече е в продукционна среда.

Стъпка 2: Записване на обосновки на необходимостта на ниво поле

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

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

Стъпка 3: Класифициране и етикетиране на набора от данни

Наборът от данни се класифицира съгласно Clarysec Политика за класификация и етикетиране на данни. Версията за SME изисква:

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

Корпоративната Политика за класификация и етикетиране на данни добавя защитна мярка за чувствителна информация:

Може да се споделя външно само при наличие на NDA или еквивалентни договорни защитни мерки

На практика наборът от данни Project Wellness не може да бъде неформално експортиран към AI платформа. Необходими са одобрен запис за разкриване, договорни защитни мерки, технически контроли за предаване и журнали.

Zenith Blueprint, в стъпка 22 за контрол 5.12 Класификация на информацията, обяснява защо това е важно:

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

Без класификация ограниченията на достъпа, шифроването, DLP и правилата за съхранение се превръщат в догадки.

Стъпка 4: Определяне на правила за вътрешно използване преди пускане в продукционна среда

Собственикът на процеса записва одобрените правила за вътрешно използване в REG02. Това е мястото, където пълзящото разширяване на целите често се спира.

Защитим набор от правила може да гласи:

• Продуктовият екип може да използва агрегирани показатели за резултатността на препоръките.
• Екипът за клиентска поддръжка може да вижда дали дадена препоръка е била показана на клиент при обработване на заявка за поддръжка.
• Маркетингът не може да използва оценки за финансово благосъстояние на индивидуално ниво за сегментиране на кампании, освен ако не е извършена проверка за съвместимост при вторично използване.
• Финансовият екип не може да има достъп до подробни анализи за финансово благосъстояние, освен ако не съществува отделна одобрена цел.
• Разработчиците не трябва да използват продукционни лични данни (PII) в тестови среди.
• Оценяването на AI модели трябва да използва маскирани, псевдонимизирани или агрегирани набори от данни, когато е приложимо.

Последните две правила се свързват с контрол 8.11 от ISO/IEC 27002:2022, маскиране на данни. Zenith Blueprint, стъпка 19, описва маскирането на данни като практически метод за предотвратяване на ненужно експониране в тестови среди, набори от данни за обучение, аналитични платформи, интеграции с трети страни и CI/CD пайплайни за тестване.

Стъпка 5: Извършване на проверката за съвместимост при вторично използване

По-късно маркетингът иска да използва оценките за финансово благосъстояние за таргетирани кампании. Това е нова цел. Съгласно клауза 4.3.1 на PII09 Политика за събиране, използване, разкриване и споделяне на лични данни (PII) собственикът на бизнес процеса трябва да запише проверка за съвместимост в REG02 преди започване на новото използване.

Проверката трябва да оцени:

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

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

Стъпка 6: Одобряване на външното разкриване чрез REG08

Ако доставчикът на AI анализи ще получи данни, собственикът на доставчика или закупуването записва в REG08:

Clarysec Политика за сигурност на трети страни и доставчици - SME подсилва минимизирания достъп на доставчици:

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

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

Стъпка 7: Добавяне на техническо прилагане

Управленските записи трябва да бъдат подкрепени с технически контроли. За Project Wellness Clarysec обичайно би препоръчал DLP правила за експорти, ограничения за достъп, базиран на роли, регистриране на събития за достъп и предаване, маскирани набори от данни за разработка, шифроване при предаване и съхранение, прегледи на достъпа на доставчици, надлежна проверка на сигурността на облачни услуги и периодично извадково сравняване на REG02 и REG08 с действителното поведение на системите.

Така отчетността по ISO/IEC 27701:2025 и GDPR се превръща в оперативни доказателства.

Съпоставяне на контролите: от решение за поверителност към техническо прилагане на сигурността

Управлението на лични данни (PII) не е един изолиран контрол. То е връзка между изискванията за поверителност, контролите за сигурност, управлението на доставчици и доказателствата за одит.

Zenith Controls третира контрол 5.34 от ISO/IEC 27002:2022, защита на неприкосновеността на личния живот и защита на лични данни (PII), като превантивен контрол, подпомагащ поверителността, цялостността и наличността, с концепции за киберсигурност Identify и Protect и оперативни способности в защитата на информацията, както и в правните въпроси и съответствието.

За 5.34 Zenith Controls картографира заобикалящата контролна екосистема, включително инвентар, класификация, предаване, достъп, идентичност, облак, сигурност на доставчиците, маскиране, предотвратяване на изтичане, регистриране, мониторинг и криптография.

За маскирането Zenith Controls посочва:

Маскирането на данни (8.11) е техника, която често се използва за защита на лични данни (PII) в непроизводствени среди или при споделяне на данни. То пряко подпомага 5.34, като намалява експозицията на реални лични данни и така понижава риска за поверителността.

За предотвратяване на загуба на данни (DLP) ръководството обяснява практическата граница:

DLP има пряка роля в защитата на лични данни. Контрол 8.12 налага граници за това как личните данни (PII) могат да бъдат достъпвани, споделяни или премествани, като гарантира, че личните данни не могат да изтекат през неоторизирани канали.

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

Стойност за съответствие между рамки: GDPR, ISO 27701, NIS2, DORA, NIST и COBIT

Управлението на събирането, използването и разкриването на лични данни (PII) се води от поверителността, но доказателствата му подпомагат по-широки задължения за киберсигурност, устойчивост и управление.

Членове 2 и 3 от GDPR определят широк материален и териториален обхват, който може да включва SaaS, fintech и доставчици на цифрови услуги извън ЕС, когато обслужват или наблюдават физически лица в ЕС. Член 5 изисква ограничаване на целите, свеждане на данните до минимум, точност, ограничаване на съхранението, цялостност, поверителност и отчетност. Член 6 изисква правно основание и оценка на съвместимостта при последващо обработване. Член 9 добавя по-строги условия за специални категории данни, приложими при профилиране, данни, близки до здравни, биометрично въвеждане или чувствителни атрибути.

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

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

NIST Cybersecurity Framework 2.0 предоставя интегриращ управленски език. Функцията GOVERN очаква правните, регулаторните и договорните изисквания, включително задълженията за поверителност, да бъдат разбрани и управлявани. Тя също обхваща стратегията за риска, ролите, политиките, надзора и управлението на риска при доставчици.

Одиторите по COBIT 2019 търсят цели на управлението, права за вземане на решения, отчетност, собственост върху процеси, показатели за изпълнение и доказателства за увереност. За управлението на лични данни (PII) това означава, че изискванията за поверителност трябва да бъдат вградени в корпоративното управление, а не управлявани като страничен процес.

Как одиторите тестват същия управленски слой

Силното внедряване на PIMS трябва да издържа различни стилове на одит.

Одитор по ISO/IEC 27001:2022 и ISO/IEC 27701:2025 ще започне с обхвата, заинтересованите страни, правните и договорните изисквания, оценката на риска, Декларацията за приложимост, оперативното планиране и документираните доказателства. Той може да избере извадка от дейности по обработване от REG02 и да провери дали контроли като 5.34, 5.12, 5.14, 5.19 до 5.23, 8.11, 8.12, 8.15, 8.16 и 8.24 са внедрени и наблюдавани.

Одитор или регулатор с фокус върху GDPR ще тества отчетността. Той може да започне с уведомление за поверителност, жалба, искане от субект на данни или разкриване към доставчик и след това да проследи назад. Защо са събрани тези данни? Какво правно основание е приложено? Посочена ли е целта? Било ли е по-късното използване съвместимо? Разрешен ли е получателят? Информирани ли са физическите лица? Актуализирани ли са записите преди започване на обработването?

Надзорен орган по DORA, когато е приложимо, ще се фокусира върху бизнес функции, поддържани от ИКТ, външни доставчици на ИКТ услуги, договорни клаузи, права на одит, защита на данните, комуникация при инциденти, тестване на устойчивостта и планиране на изход. Ако клиентски лични данни (PII) се споделят с критичен доставчик на аналитични или облачни услуги, REG08, надлежната проверка на доставчика и договорните контроли стават централни доказателства.

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

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

Чести проблеми, които Clarysec открива при внедрявания

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

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

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

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

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

Шестият е липсата на техническо прилагане. Политиките може да казват, че личните данни (PII) не трябва да напускат одобрени канали, но електронната поща, експортите, споделените файлови ресурси и аналитичните инструменти често го позволяват. Тук контролите 5.14, 8.12, 8.15, 8.16 и 8.24 от ISO/IEC 27002:2022 стават съществени.

Практически 30-дневен начален план

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

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

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

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

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

В края на 30 дни ръководството трябва да разполага с конкретен пакет с доказателства: REG02, REG08, записи за класификация, матрици за достъп, DLP и доказателства от регистриране, надлежна проверка на доставчици, договорни защитни мерки, проверки за съвместимост и отворени действия за отстраняване.

От политика към доказателство

Управлението на събирането, използването и разкриването на лични данни (PII) е мястото, където поверителността става реална. То е разликата между твърдението „спазваме GDPR“ и доказването, че всяко решение за събиране, използване, повторно използване и разкриване е било контролирано преди настъпване на обработването.

Инструментариумът на Clarysec дава на екипите по поверителност, сигурност и съответствие практичен път:

• Използвайте PII09 Политика за събиране, използване, разкриване и споделяне на лични данни (PII), за да дефинирате задължителни контролни точки за одобрение.
• Използвайте P17 Политика за защита на данните и поверителност или Политика за защита на данните и поверителност - SME, за да закотвите законосъобразно, добросъвестно, прозрачно и минимизирано обработване.
• Използвайте Политика за класификация и етикетиране на данни и Политика за сигурност на трети страни и доставчици - SME, за да управлявате класификацията, споделянето и достъпа на доставчици.
• Следвайте Zenith Blueprint: 30-стъпкова пътна карта на одитора, за да внедрите контролната среда в правилната последователност.
• Използвайте Zenith Controls: ръководство за съответствие между рамки, за да разберете как контроли от ISO/IEC 27002:2022 като 5.34, 5.12, 5.14, 8.11 и 8.12 подпомагат GDPR, NIS2, DORA, NIST и очакванията при одит.

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

Започнете с една високорискова дейност. Изградете записа в REG02. Обосновете всеки елемент от данни. Дефинирайте правила за вътрешно използване. Извършете проверката за съвместимост при вторично използване. Създайте записа за разкриване в REG08. След това тествайте дали достъпът, DLP, маскирането, регистрирането, шифроването и контролите за доставчици съответстват на решението.

Така отчетността по ISO/IEC 27701:2025 и GDPR се превръща в доказателства.

Разгледайте инструментариума Clarysec PIMS, започнете с PII09 Политика за събиране, използване, разкриване и споделяне на лични данни (PII) и използвайте Zenith Blueprint, за да превърнете управлението на поверителността от намерение в политика в готово за одит доказателство.