Карта на доказателствата за съответствие с EU Digital Identity Wallet през 2026 г.

Продуктов екип във финтех компания е две седмици преди стартирането на клиентски онбординг чрез портфейл. Новият процес ще позволи на клиентите в ЕС да доказват избрани атрибути за самоличност чрез EU Digital Identity Wallet, вместо ръчно да качват документи за самоличност. CISO вижда ползата за сигурността. DPO оценява потенциала за минимизиране на данните. Ръководителят по съответствието вижда по-малко прекъснати процеси по онбординг и по-добро клиентско изживяване.

След това одитният комитет задава въпроса, който променя разговора:

„Ако регулатор, банков партньор, клиентски одитор или надзорен орган попита как се управлява тази интеграция с портфейл, какви доказателства показваме?“

Това е реалният проблем за 2026 г.

EU Digital Identity Wallet, често съкращаван като EUDI Wallet, не е просто още една продуктова функционалност. За регулирани цифрови услуги, доставчици на плащания, екосистеми за удостоверителни услуги, интерфейси на публичния сектор и процеси за онбординг с висока степен на увереност той става част от веригата за увереност в самоличността на организацията. Той засяга лични данни, събития по автентикация, зависимости от доставчици, управление на достъпа, регистриране, криптография, докладване на инциденти и отчетност на ниво управителен орган.

Капанът е eIDAS2 и EUDI Wallet да се третират като самостоятелно правно внедряване. Практическият отговор е различен: приемането на портфейла от разчитаща страна трябва да бъде включено в същата система за доказателства, която се използва за ISO/IEC 27001:2022, GDPR, NIS2, DORA, NIST CSF 2.0 и COBIT 2019.

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

Тази статия показва как да изградите този доказателствен гръбнак чрез Zenith Blueprint: 30-стъпкова пътна карта за одитори, Zenith Controls: ръководство за кръстосано съответствие и шаблоните на политики на Clarysec за поверителност, идентичност, регистриране, управление на доставчици и регулаторно съответствие.

Проблемът с доказателствата за портфейла през 2026 г. е по-широк от eIDAS2

Повечето дискусии за EU Digital Identity Wallet се фокусират върху доверие, оперативна съвместимост и потребителско изживяване. Те са важни. Но CISO, мениджърът по съответствие, DPO или одиторът има по-оперативен въпрос: кои контроли доказват, че извлечените от портфейла атрибути за самоличност се използват сигурно, законосъобразно и пропорционално?

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

• Кои атрибути от портфейла се заявяват и защо?
• Кое правно основание подкрепя обработването?
• Могат ли потребителите, администраторите и служебните акаунти да бъдат еднозначно идентифицирани?
• Включени ли са услугите за проверка чрез портфейл, брокерите на идентичност, API шлюзовете и облачните компоненти в регистъра на доставчиците?
• Регистрират ли се събитията по автентикация и проверка по начин, който подпомага разследване, без да се събират прекомерно лични данни?
• Има ли процес за инциденти, ако онбордингът чрез портфейл бъде използван неправомерно, стане недостъпен или бъде компрометиран?
• За финансови субекти обхваната ли е интеграцията с портфейл от управлението на ИКТ риска по DORA, риска от трети страни и класификацията на инциденти?
• За субекти по NIS2 влияе ли зависимостта от портфейла върху предоставянето на съществени или важни услуги, контрола на достъпа, непрекъсваемостта на дейността или комуникациите с клиенти?

NIS2 е особено релевантна, защото обхватът ѝ включва много доставчици на цифрова инфраструктура, облачни услуги, доставчици на управлявани услуги, доставчици на управлявани услуги за сигурност и доставчици на удостоверителни услуги. Директивата също класифицира квалифицираните доставчици на удостоверителни услуги, DNS доставчиците, TLD регистрите и няколко други категории субекти като съществени при определени обстоятелства. До 2026 г. много организации вече няма да питат дали законът предстои. Те ще отговарят на надзорни, клиентски и вътрешноодитни въпроси относно внедряването.

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

Погрешният отговор е да се създаде един пакет доказателства за eIDAS2, един за GDPR, един за NIS2, един за DORA и един за ISO сертификация. Правилният отговор е СУИС да се използва като оперативен модел за доказателства.

Използвайте ISO 27001 като доказателствен гръбнак

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

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

Внедряването на портфейл от разчитаща страна засяга:

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

Корпоративната политика за съответствие на Clarysec прави този оперативен модел изричен:

„Всички правни и регулаторни задължения трябва да бъдат съпоставени с конкретни политики, контроли и собственици в рамките на Системата за управление на информационната сигурност (СУИС).“
От Политика за правно и регулаторно съответствие, раздел „Изисквания за прилагане на политиката“, клауза 6.2.1 от политиката.

За МСП същият принцип е мащабиран до практически регистър на съответствието:

„Когато дадена регулация се прилага в няколко области (напр. GDPR се прилага към съхранение, сигурност и поверителност), това трябва да бъде ясно съпоставено в Регистъра на съответствието и материалите за обучение.“
От Политика за правно и регулаторно съответствие - МСП, раздел „Изисквания за управление“, клауза 5.2.2 от политиката.

Организацията не трябва да пита: „Кой отдел притежава eIDAS2?“ Тя трябва да пита: „Кои рискове, контроли, политики, собственици и доказателствени записи в СУИС са засегнати от зависимостта от портфейл?“

В Zenith Blueprint, във фазата Управление на риска, стъпка 14, се посочва:

„За всяка регулация, ако е приложимо, можете да създадете проста таблица за съпоставяне (например приложение към доклад), която изброява ключовите изисквания за сигурност на регулацията и съответните контроли/политики във вашия ISMS. Това не е задължително по ISO 27001, но е полезно вътрешно упражнение, което гарантира, че нищо не е пропуснато. То също прави добро впечатление на одитори/оценители, защото показва, че не управлявате сигурността във вакуум, а сте наясно с правния контекст.“

Това е основата: изградете една таблица за съпоставяне, която свързва задълженията на разчитаща страна за портфейл с GDPR, NIS2, DORA, контролите от Приложение A на ISO/IEC 27001:2022, политиките на Clarysec и доказателствените записи.

Практическа карта на доказателствата за разчитащи страни по EU Digital Identity Wallet

EUDI Wallet става управляем, когато се третира като дефиниран бизнес процес в рамките на СУИС, с картографирани данни, идентичности, доставчици, журнали, инциденти и собственици.

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

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

За разчитаща страна по портфейл идентичността е очевидната група контроли. Но управлението на идентичности не е същото като автентикация. Управлението на идентичности отговаря на въпроса „кой съществува в системата и как се управлява тази идентичност?“ Автентикацията отговаря на въпроса „как заявената идентичност се проверява в момента на достъп?“

В Zenith Controls контрол 5.16 по ISO/IEC 27002:2022, Управление на идентичности, се третира като превантивен контрол, който подпомага поверителността, целостта и наличността. Той е пряко свързан с контрол на достъпа, информация за автентикация, права за достъп, взаимоотношения с доставчици, мониторинг на съответствието и привилегирован достъп. Съпоставянето за кръстосано съответствие свързва тази област със сигурността и отчетността по GDPR, контрола на достъпа и управлението на активите по NIS2, управлението на идентичността и достъпа по DORA, управлението на идентификатори по NIST SP 800-53 и управлението на жизнения цикъл на идентичността по COBIT 2019.

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

• идентичностите на клиенти и служители не се смесват;
• административните идентичности са уникални и проследими;
• идентичностите на доставчици се управляват със същата дисциплина като тези на служителите;
• нечовешките идентичности, като API клиенти и служебни акаунти, имат собственици;
• идентичностите се отнемат, когато вече не са необходими;
• изключенията, аварийните акаунти тип break-glass и привилегированите идентичности са контролирани.

Политиката за акаунти на Clarysec за МСП формулира принципа ясно:

„Всеки акаунт трябва да бъде уникален, проследим до конкретно лице и свързан с бизнес роля.“
От Политика за управление на потребителски акаунти и привилегии - МСП, раздел „Изисквания за прилагане на политиката“, клауза 6.1.2 от политиката.

За корпоративни среди изискването е по-строго по отношение на споделените акаунти:

„Всички потребителски идентичности трябва да бъдат свързани с уникален идентификатор. Използването на споделени или общи акаунти е забранено, освен за одобрени break-glass или аварийни акаунти, подлежащи на строги контроли.“
От Политика за управление на потребителски акаунти и привилегии, раздел „Изисквания за управление“, клауза 5.3 от политиката.

Поддържащите стандарти засилват същата логика за доказателствата. ISO/IEC 24760-1:2019 предоставя концепции за жизнения цикъл на идентичността, като регистрация, обвързване, използване и дерегистрация. ISO/IEC 29115:2013 подпомага риск-базирана увереност в идентичността. ISO/IEC 27005:2024 третира слабостите в идентичността и достъпа като теми за третиране на риска. ISO/IEC 27018:2020 разширява очакванията за управление на идентичности при обработване на PII в публичен облак. ISO/IEC 29100:2011 добавя призмата на поверителността, като свързва идентифицируемостта с боравенето с лична информация.

При приемане на EUDI Wallet одитният въпрос е прост: можете ли да проследите всяко привилегировано действие, промяна в конфигурацията, промяна в интеграцията за проверка чрез портфейл и събитие за достъп на доставчик до уникална идентичност с одобрена роля?

Ако отговорът е не, проектът за портфейл не е готов за одит.

Сигурна автентикация: доверието в портфейла не премахва вашите контролни задължения

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

В Zenith Blueprint, фаза „Контроли в действие“, стъпка 19, Clarysec посочва:

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

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

В Zenith Controls контрол 8.5 по ISO/IEC 27002:2022, Сигурна автентикация, е съпоставен като превантивен контрол в способността за управление на идентичността и достъпа. Той е свързан с управление на идентичности, информация за автентикация, привилегирован достъп, ограничаване на достъпа до информация, дейности по мониторинг, управление на инциденти и защита на поверителността на PII. Той също се съпоставя със сигурността и защитата на данните още при проектиране по GDPR, управлението на риска за киберсигурността и MFA или непрекъсната автентикация по NIS2, когато е подходящо, управлението на ИКТ риска по DORA, семействата IA и AC по NIST SP 800-53 и управлението на логическия достъп по COBIT 2019.

За разчитаща страна по портфейл доказателствата за сигурна автентикация трябва да включват:

• автентикация и оторизация на крайната точка за проверка чрез портфейл;
• MFA за администратори на панелите за конфигурация на портфейла;
• сигурна API автентикация между услугите за онбординг;
• съхранение в хранилище за тайни на ключове или сертификати за интеграция с портфейла;
• таймаути на сесиите и защита на токени, когато е подходящо;
• предупреждения при неуспешна автентикация и защита срещу опити за brute-force атака;
• отделни контроли за клиентско вписване, достъп на служители и достъп машина-към-машина.

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

„Журнали за автентикация: успешни и неуспешни опити за вписване, продължителност на сесията, използване на MFA“
От Политика за регистриране и мониторинг - МСП, раздел „Изисквания за управление“, клауза 5.4.2 от политиката.

За корпоративни среди одитната надеждност става централна:

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

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

GDPR: обещанието на портфейла е минимизиране, но трябва да го докажете

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

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

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

Корпоративната политика за поверителност на Clarysec посочва:

„Могат да се събират и обработват само данни, необходими за конкретна, легитимна бизнес цел.“
От Политика за защита на данните и поверителност, раздел „Изисквания за прилагане на политиката“, клауза 6.2.1 от политиката.

Версията за МСП е умишлено кратка:

„Трябва да се събират и съхраняват само минимално необходимите лични данни“
От Политика за защита на данните и поверителност - МСП, раздел „Изисквания за прилагане на политиката“, клауза 6.2.1 от политиката.

В Zenith Controls контрол 5.34 по ISO/IEC 27002:2022, Поверителност и защита на PII, е съпоставен с инвентар на активите, маскиране на данни, управление на облачни услуги, класификация на информацията, сигурно прехвърляне, контрол на достъпа, управление на идентичности и преглед на проектни промени. Той също се свързва с ISO/IEC 27701:2021 за управление на поверителността, ISO/IEC 27018 за обработване на PII в облак и принципите за поверителност на ISO/IEC 29100.

За приемане на портфейл пакетът доказателства за поверителност трябва да включва:

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

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

NIS2 и DORA: отчетността на управителния орган среща устойчивостта на портфейла

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

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

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

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

За онбординг чрез портфейл във финансови услуги доказателствата трябва да показват, че:

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

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

Зависимости от доставчици и облак: процесът с портфейл е толкова силен, колкото е силна веригата

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

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

В Zenith Blueprint, фаза „Контроли в действие“, стъпка 23, Clarysec инструктира екипите да съставят пълен списък на доставчиците, да класифицират доставчиците според достъпа им до системи, данни или оперативен контрол, да включат очакванията в договорите, да идентифицират подизпълнители, да дефинират тригери за промени и да изградят процес за оценка на облачни услуги. Същата стъпка препоръчва оценяване на местонахождението на данните, модела на достъп, регистрирането и шифроването, преди бъдещи облачни услуги да бъдат одобрени.

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

„На доставчиците трябва да се предоставя достъп само до минималните системи и данни, необходими за изпълнение на тяхната функция.“
От Политика за сигурност на трети страни и доставчици - МСП, раздел „Изисквания за прилагане на политиката“, клауза 6.2.1 от политиката.

NIST CSF 2.0 подкрепя този интегриран поглед. Неговата функция GOVERN включва правни, регулаторни, договорни и свързани с поверителността задължения, апетит за риск, отчетност, политика, ресурсно обезпечаване и надзор. Резултатите за веригата на доставки изискват роли на доставчици, приоритизация по критичност, договорни изисквания за киберсигурност, комплексна проверка, мониторинг, планиране на инциденти и разпоредби след прекратяване на взаимоотношението.

Одиторите по COBIT 2019 ще търсят зрялост на управлението. Те ще питат дали отговорностите на доставчиците, жизненият цикъл на идентичността, контролите за поверителност и мониторингът са вградени в бизнес процесите, а не само в контролните списъци на екипа по сигурност. За идентичността и логическия достъп COBIT 2019 DSS05.04, Manage user identity and logical access, е особено релевантен при оценка дали собствеността върху акаунти, одобренията, присвояването на привилегии и премахването им са контролирани.

Изградете пакет доказателства за разчитаща страна по портфейл за един следобед

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

Запишете:

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

След това добавете сценария на използване в регистъра на съответствието.

След това прегледайте Декларацията за приложимост и плана за третиране на риска. За сценарии на използване на EUDI Wallet обичайно са релевантни следните области на контрол по ISO/IEC 27002:2022.

Накрая извършете миниодит. Изберете една транзакция за онбординг чрез портфейл и проследете:

1. обосновката на заявката за атрибут;
2. стъпката за прозрачност или записа за съгласие, когато е приложимо;
3. системния журнал за събития;
4. доказателствата за API автентикация;
5. записа за контрол на достъпа за персонала, който вижда резултата от онбординга;
6. участващия доставчик;
7. правилото за съхранение;
8. маршрута за класификация на инцидент, ако тази транзакция е измамна или изложена.

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

Как различните одитори ще тестват един и същ процес с портфейл

Различните одитори подхождат към EU Digital Identity Wallet през различни професионални призми. Едни и същи доказателства могат да отговорят на множество въпроси, ако са добре структурирани.

Zenith Controls предоставя полезни подробности за одитната методология в тези области. За управление на идентичности одиторите обичайно проследяват потребителски идентичности през въвеждане, промяна и прекратяване, съпоставят записи от ЧР със списъци на акаунти, проверяват акаунти на външен персонал и служебни акаунти и търсят използване на споделени администраторски акаунти. За сигурна автентикация одиторите сравняват политики с технически конфигурации, преглеждат покритието на MFA, проверяват контролите за пароли и сесии и разглеждат журналите за успешни и неуспешни вписвания. За поверителност и защита на PII одиторите извадково проверяват DPIA, процеси за искания от субекти на данни, обучение за поверителност, инвентари на PII, шифроване, журнали за достъп и контроли за съхранение.

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

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

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

Често срещани капани в проекти за готовност за портфейл

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

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

Третият капан е третирането на доставчиците като документация за снабдяване. Съгласно NIS2 и DORA сигурността на доставчиците е оперативна. Необходими са комплексна проверка, договорни клаузи, мониторинг, сътрудничество при инциденти, права на одит и планове за изход. За субекти, регулирани по DORA, регистърът на ИКТ трети страни е основно доказателство за съответствие.

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

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

Превърнете приемането на EUDI Wallet в доказателства, готови за одит

EU Digital Identity Wallet ще промени онбординга и цифровото доверие в Европа. Но за CISO, DPO, мениджърите по съответствие, одиторите и собствениците на бизнес правилният ход не е създаването на още една изолирана програма за съответствие. Правилният ход е приемането на портфейла да се въведе в СУИС и да се съпоставят поверителността, идентичността, автентикацията, доставчиците, регистрирането, устойчивостта и реагирането при инциденти.

Clarysec може да ви помогне да направите това структурирано:

1. Използвайте Zenith Blueprint, за да поставите приемането на портфейл във фазата Управление на риска, стъпка 14 за регулаторни кръстосани препратки, стъпка 19 за сигурна автентикация и стъпка 23 за внедряване на контроли за доставчици, поверителност и правни изисквания.
2. Използвайте Zenith Controls, за да съпоставите контролите по ISO/IEC 27002:2022 за управление на идентичности, сигурна автентикация и поверителност с доказателства по GDPR, NIS2, DORA, NIST и COBIT 2019.
3. Използвайте шаблони на политики на Clarysec, като Политика за правно и регулаторно съответствие, Политика за защита на данните и поверителност, Политика за управление на потребителски акаунти и привилегии, Политика за регистриране и мониторинг, Политика за сигурност на трети страни и доставчици - МСП и Политика за одит и мониторинг на съответствието, за да превърнете задълженията в практики със собственик, които могат да бъдат тествани.
4. Изградете пакет доказателства за разчитаща страна по портфейл преди старта, а не след първото одитно искане.

Ако вашата организация планира да разчита на EU Digital Identity Wallet през 2026 г., сега е моментът да зададете един въпрос: можем ли да докажем, с юридически издържани доказателства, че този процес на идентичност е сигурен, законосъобразен, устойчив и управляван?

Отговорът на Clarysec е практичен: съпоставете го, определете собствеността, тествайте го и поддържайте доказателствата готови.