Готова за одит защита на информацията, позволяваща идентифициране на физическо лице (PII), за GDPR, NIS2 и DORA

Предупреждението пристигна във входящата поща на Сара във вторник в 22:00 ч.

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

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

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

Компанията вече беше сертифицирана по ISO/IEC 27001:2022. Съветът на директорите изискваше увереност за съответствие с GDPR преди навлизане на пазара на ЕС. Клиенти от сектора на финансовите услуги изпращаха въпросници за надлежна проверка по DORA. Взаимоотношенията с доставчици на облачни и управлявани услуги повдигаха въпроси за веригата на доставки по NIS2. Правният екип можеше да обясни задълженията. Инженерният екип можеше да посочи криптирането. Продуктовият екип имаше намерения за защита на личните данни още при проектирането. Декларацията за приложимост споменаваше поверителност и защита на PII.

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

Точно затова ISO/IEC 27701:2025 и ISO/IEC 29151:2022 са важни. Те не са просто етикети за поверителност. Те помагат на организациите да превърнат обещанията за защита на личните данни в готови за одит контроли за защита на PII. ISO/IEC 27701:2025 разширява система за управление на информационната сигурност по ISO/IEC 27001:2022 към управление на информацията за поверителност. ISO/IEC 29151:2022 добавя практически насоки за защита на информацията, позволяваща идентифициране на физическо лице (PII), през целия ѝ жизнен цикъл.

Подходът на Clarysec е да се изгради един основан на доказателства оперативен модел за поверителност и сигурност, а не отделни силози за съответствие. Този модел комбинира Zenith Blueprint: 30-стъпкова пътна карта за одитора Zenith Blueprint, Zenith Controls: ръководство за кръстосано съответствие Zenith Controls и политиките на Clarysec в една проследима система за GDPR, ISO/IEC 27001:2022, ISO/IEC 27701:2025, ISO/IEC 29151:2022, NIS2, DORA, подход за увереност по NIST и управленските очаквания по COBIT 2019.

Защо защитата на PII вече е одитен въпрос на ниво управителен орган

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

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

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

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

ISO/IEC 27001:2022 предоставя гръбнака на системата за управление. Той изисква контекст, заинтересовани страни, обхват, отчетност на ръководството, политики, роли, оценка на риска, третиране на риска, Декларация за приложимост, вътрешен одит, преглед от ръководството и непрекъснато подобрение. Приложение A включва контроли, пряко свързани със защитата на PII, включително 5.34 Поверителност и защита на PII, 5.18 права за достъп, 8.11 маскиране на данни, 5.23 информационна сигурност при използване на облачни услуги, 8.15 журналиране, 8.33 тестова информация, 8.24 използване на криптография и 8.10 изтриване на информация.

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

ISO/IEC 27701:2025 и ISO/IEC 29151:2022 помагат тези доказателства да се обединят около управлението на информацията за поверителност и практиките за защита на PII. Clarysec превръща тази структура в оперативен модел.

От ISMS към PIMS: интегрираната верига от контроли за поверителност

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

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

ISO/IEC 27701:2025 разширява ISMS към управление на поверителността. ISO/IEC 29151:2022 го допълва с практически насоки за защита на PII, включително ограничаване на събирането, управление на разкриването, прилагане на маскиране или псевдонимизация, защита на трансферите, ограничаване на достъпа и съгласуване на контролите с риска за поверителността.

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

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

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

Zenith Blueprint започва тази работа рано във фазата Управление на риска. В стъпка 9, Идентифициране на активи, заплахи и уязвимости, той указва на организациите да инвентаризират информационните активи и изрично да маркират личните данни:

„За всеки актив запишете ключови данни: име/описание, собственик, местоположение и класификация (чувствителност). Например актив може да бъде „Клиентска база данни – собственост на ИТ отдела – хоствана в AWS – съдържа лични и финансови данни (висока чувствителност).“

Той също добавя: „Уверете се, че активите с лични данни са маркирани (за релевантност към GDPR), а критичните активи за услуги са отбелязани (за потенциална приложимост на NIS2, ако сте в регулиран сектор).“

Това е основата за приемане на ISO/IEC 27701:2025 и ISO/IEC 29151:2022. Практическата последователност е проста:

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

Политиките на Clarysec правят това изпълнимо. Политиката за защита на данните и поверителност за МСП Политика за защита на данните и поверителност - МСП посочва:

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

От раздел „Изисквания за управление“, клауза на политиката 5.2.1.

За корпоративни организации Политиката за защита на данните и поверителност Политика за защита на данните и поверителност установява строго правило за минимизиране:

„Могат да се събират и обработват само данни, необходими за конкретна, легитимна служебна цел.“

От раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.2.1.

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

Трите контрола, които правят защитата на PII реална

Три контрола от Приложение A на ISO/IEC 27001:2022 често определят дали защитата на PII е обоснована при одит: 5.34 Поверителност и защита на PII, 8.11 Маскиране на данни и 5.18 права за достъп.

5.34 Поверителност и защита на PII

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

Zenith Controls прави зависимостта ясна:

„Инвентарът на информационните активи (5.9) трябва да включва масиви с PII данни (клиентски бази данни, HR файлове). Това подпомага 5.34, като гарантира, че организацията знае какви PII има и къде се намират, което е първата стъпка към тяхната защита.“

Контрол 5.34 зависи от 5.9 Инвентар на информацията и други свързани активи, защото PII не могат да бъдат защитени, ако не могат да бъдат открити. Той също се свързва с 5.23 Информационна сигурност при използване на облачни услуги, защото повечето PII вече се намират в облачни платформи, SaaS инструменти, аналитични среди и управлявани услуги.

За обработване с висок риск корпоративната Политика за защита на данните и поверителност изисква:

„Моделиране на заплахите и оценки на въздействието върху защитата на данните (DPIA) са задължителни за системи за обработване с висок риск.“

От раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.3.4.

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

8.11 Маскиране на данни

Контрол 8.11 е директният отговор на изложената тестова база данни на Сара. Zenith Controls описва 8.11 като превантивен контрол за поверителност в рамките на защитата на информацията. Той свързва 8.11 с 5.12 Класификация на информацията, защото решенията за маскиране зависят от чувствителността, с 5.34, защото маскирането подпомага защитата на поверителността, и с 8.33 Тестова информация, защото тестовите среди не трябва да излагат реални PII.

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

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

От раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.3.

За МСП Политиката за маскиране на данни и псевдонимизация за МСП Политика за маскиране на данни и псевдонимизация - МСП добавя ключово изискване за сигурност и доказателства:

„Достъпът до ключове трябва да бъде криптиран, контролиран чрез права за достъп и журнализиран.“

От раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.2.1.3.

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

5.18 Права за достъп

Контрол 5.18 е оперативното ядро на минимално необходимия достъп. Zenith Controls го разглежда като превантивен, свързан с поверителност, целост и наличност, и поставен в областта на управлението на идентичността и достъпа. Той свързва 5.18 с 5.15 Контрол на достъпа, 5.16 Управление на идентичности и 8.2 Привилегировани права за достъп.

Политиката за класификация и етикетиране на данни за МСП Политика за класификация и етикетиране на данни - МСП посочва:

„Достъпът трябва да бъде ограничен до изрично оторизирани потребители със служебна необходимост.“

От раздел „Изисквания за управление“, клауза на политиката 5.2.1.

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

„Всички информационни активи трябва да имат ясно присвоена класификация към момента на създаване или въвеждане. При липса на изрична класификация активите трябва по подразбиране да се третират като „Поверителна“ до формален преглед.“

От раздел „Изисквания за управление“, клауза на политиката 5.4.

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

Изградете проследимост чрез Декларацията за приложимост

Система за управление на поверителността става готова за одит, когато може да докаже проследимост. Zenith Blueprint, фаза Управление на риска, стъпка 13, Планиране на третирането на риска и Декларация за приложимост, описва Декларацията за приложимост като свързващ документ:

„SoA на практика е свързващ документ: той свързва вашата оценка/третиране на риска с реалните контроли, които имате. Чрез попълването му също проверявате дали не сте пропуснали някои контроли.“

Тази концепция е централна за готовността по ISO/IEC 27701:2025, ISO/IEC 29151:2022, GDPR, NIS2 и DORA. Всеки контрол за PII трябва да бъде проследим от изискване към риск, от риск към контрол, от контрол към собственик, от собственик към доказателство и от доказателство към преглед.

ISO/IEC 27005:2022 подпомага този риск-базиран подход, като акцентира върху изискванията на заинтересованите страни, общите критерии за риск, отговорните собственици на риска, повторяемата оценка на риска, третирането на риска, избора на контроли, съгласуването с Декларацията за приложимост, одобрението на остатъчния риск, мониторинга и непрекъснатото подобрение. Защитата на PII трябва да бъде жив цикъл на риска, а не еднократно упражнение по документация за GDPR.

Отстранете риска в електронната таблица и предпроизводствената база данни

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

Политиката за одит и мониторинг на съответствието за МСП Политика за одит и мониторинг на съответствието - МСП посочва:

„Всички доказателства трябва да се съхраняват в централизирана одитна папка.“

От раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.2.1.

Политиката за информационна сигурност Политика за информационна сигурност прави по-широкото очакване за одит изрично:

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

От раздел „Изисквания за внедряване на политиката“, клауза на политиката 6.6.1.

Тези две клаузи са разликата между това да имате контрол и да можете да го докажете.

Съпоставяне за кръстосано съответствие за един набор от контроли за PII

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

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

Как различните одитори тестват един и същ контрол за PII

Един контрол, например 8.11 Маскиране на данни, ще бъде проверяван по различен начин според одитната перспектива.

Одитор по ISO/IEC 27001:2022 започва с логиката на системата за управление. Включени ли са PII в обхвата? Идентифицирани ли са изискванията на заинтересованите страни? Оценени ли са рисковете за поверителността по дефинирани критерии? Избрани ли са контролите чрез третиране на риска? Точна ли е SoA? Покриват ли вътрешните одити и прегледите от ръководството контролите, свързани с PII?

Проверяващ по поверителност започва с отчетността. Какви лични данни се обработват? Какво е правното основание? Информирани ли са субектите на данни? Ограничено ли е обработването до конкретна цел? Оценени ли са дейностите с висок риск? Управлявани ли са обработващите лични данни?

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

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

Проверяващ по COBIT 2019 или в стил ISACA тества съгласуването на управлението. Кой притежава риска за PII? Кой управленски орган получава докладването? Разпределени ли са отговорностите? Наблюдават ли се доставчиците? Проследяват ли се отклоненията? Използват ли се показатели за вземане на решения? Формално ли е приет остатъчният риск?

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

Чести одитни констатации в програмите за защита на PII

Организациите, които подхождат към готовност по ISO/IEC 27701:2025 или ISO/IEC 29151:2022 без интегриран инструментариум, често виждат едни и същи констатации.

Тези констатации не са проблеми с документацията. Те са проблеми на оперативния модел. ISO/IEC 27701:2025 и ISO/IEC 29151:2022 няма да ги отстранят, освен ако управлението на поверителността, контролите за сигурност и управлението на доказателства не бъдат вградени в нормалните работни потоци.

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

Преди да се преследва готовност по ISO/IEC 27701:2025, внедряване на ISO/IEC 29151:2022 или клиентска оценка по GDPR, NIS2 или DORA, ръководството трябва да зададе десет директни въпроса:

1. Имаме ли пълен регистър на дейностите по обработване на PII, включително категории данни, цел, правно основание и срок за съхранение?
2. Маркирани ли са PII активите в инвентара на активите, включително журнали, резервни копия, експорти, аналитични инструменти и прикачени файлове от поддръжката?
3. Присвояват ли се класификации на данните при създаване или въвеждане, като непрегледаните активи по подразбиране се третират като Поверителна?
4. Можем ли да докажем, че достъпът до PII е ограничен до оторизирани потребители със служебна необходимост?
5. Използват ли средите за разработка, тестване и предпроизводствените среди маскирани или псевдонимизирани данни вместо реални лични данни?
6. Одобрени ли са шаблоните за маскиране, защитени ли са ключовете и контролирани и журнализирани ли са правата за достъп?
7. Свързва ли SoA рисковете за PII с контролите и регулаторните задължения?
8. Преглеждат ли се договорите за облачни услуги и доставчици по отношение на местоположение на данните, сигурност, съдействие при инциденти, права на одит, възстановяване и изход?
9. Може ли процесът ни за инциденти да класифицира нарушения на сигурността на личните данни по GDPR, значителни инциденти по NIS2 и съществени инциденти, свързани с ИКТ, по DORA?
10. Съхраняват ли се доказателствата централно и по начин, който одиторът може да проследи?

Ако отговорът на някой от тези въпроси е неясен, организацията все още не е готова за одит.

Направете защитата на PII доказуема

Късният инцидент на Сара можеше да се превърне във фрагментирана надпревара за съответствие. Вместо това той може да стане отправна точка за по-силен оперативен модел: ISMS по ISO/IEC 27001:2022, разширена към поверителност чрез ISO/IEC 27701:2025, подсилена с практиките на ISO/IEC 29151:2022 и съпоставена с GDPR, NIS2, DORA, подход за увереност по NIST и управленските очаквания по COBIT 2019.

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

Започнете с Zenith Blueprint: 30-стъпкова пътна карта за одитора Zenith Blueprint, за да структурирате внедряването си. Използвайте Zenith Controls: ръководство за кръстосано съответствие Zenith Controls, за да съпоставите защитата на PII между ISO/IEC 27001:2022, GDPR, NIS2, DORA, подход за увереност по NIST и управленските очаквания по COBIT 2019. Превърнете работата в оперативна практика с политиките на Clarysec, включително Политика за защита на данните и поверителност Политика за защита на данните и поверителност, Политика за маскиране на данни и псевдонимизация Политика за маскиране на данни и псевдонимизация, Политика за класификация и етикетиране на данни Политика за класификация и етикетиране на данни, Политика за одит и мониторинг на съответствието за МСП Политика за одит и мониторинг на съответствието - МСП и Политика за информационна сигурност Политика за информационна сигурност.

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