Управление на жизнения цикъл на данните по ISO 27001 за 2026 г.

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

Компанията току-що беше навлязла на нови пазари в ЕС. Приходите растяха, онбордингът на клиенти се ускоряваше, а всяка седмица се добавяха нови SaaS инструменти. След това почти едновременно пристигнаха три съобщения.

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

След това клиент поиска изтриване на акаунта си и всички свързани с него лични данни.

На пръв поглед простото искане се превърна в спешна междуфункционална координация. Правният екип заяви, че някои записи може да са необходими за договорен спор. Финансовият екип посочи, че законово изискуеми записи трябва да бъдат съхранени. Продуктовият екип потвърди, че данните на клиента съществуват в продукционната база данни, аналитичната платформа, тикетите за поддръжка, обектното хранилище, Kubernetes журналите, моментните снимки на бази данни и инструмент на трета страна за управление на клиентския успех. Облачният инженеринг попита кои резервни копия съдържат данните. Длъжностното лице по защита на данните (DPO) попита дали някое копие все още се обработва извън ЕС. Мария поиска доказателства.

Накрая някой каза изречението, което разкри реалния проблем:

„Нямаме едно място, на което този жизнен цикъл да е видим.“

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

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

Зряла програма за управление на жизнения цикъл на данните по ISO 27001 превръща тази спешна координация в контролиран работен поток.

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

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

GDPR член 5 изисква личните данни да се обработват законосъобразно, добросъвестно и прозрачно, да се събират за конкретни цели, да бъдат сведени до необходимото, точни, съхранявани само толкова дълго, колкото е необходимо, и защитени срещу неразрешено или незаконосъобразно обработване, случайна загуба, унищожаване или повреждане. Член 5(2) добавя отчетност, което означава, че администраторът трябва да може да докаже съответствие. Затова управлението на сроковете за съхранение по GDPR не е упражнение с електронна таблица. То изисква оперативни доказателства.

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

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

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

ISO/IEC 27001:2022 е системата за управление, която може да обедини тези задължения. Клаузи 4.1 до 4.4 изискват организацията да разбира своя контекст, заинтересованите страни, правните и договорните изисквания и обхвата на системата за управление на информационната сигурност (ISMS). Клаузи 5.1 до 5.3 изискват лидерство, роли и отговорности. Клаузи 6.1.2 и 6.1.3 изискват оценка на риска за информационната сигурност, третиране на риска, избор на контроли, сравнение с Приложение A и съхраняване на документирана информация.

Именно тази структура показва защо ISO 27001 не е „още един контролен списък“. Тя е оперативната система за управление на жизнения цикъл на данните.

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

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

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

Подходът на Clarysec свързва тези въпроси с контролите по ISO 27001 и оперативните доказателства. В Zenith Blueprint: An Auditor’s 30-Step Roadmap фазата „Контроли в действие“ разглежда инвентаризацията на активите и класификацията като оперативни основи, а не като документация заради самата документация. Стъпка 22 обяснява, че инвентарът трябва да включва физически активи, цифрови активи, логически активи, активи, свързани с услуги, и хора от гледна точка на отговорности, достъп и експозиция.

Zenith Blueprint посочва:

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

Това изречение е повратната точка. Управлението на жизнения цикъл на данните се проваля, когато собствеността е възложена на „ИТ“ или „бизнеса“. То работи, когато конкретно посочен отговорен собственик може да одобри класификация, срокове за съхранение, достъп, решения за правно задържане, преглед на архиви и доказателства за изтриване.

Политика за управление на активи — МСП на Clarysec подсилва същата дисциплина:

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

Това изискване се съдържа в Политика за управление на активи — МСП, раздел „Изисквания за внедряване на политиката“, клауза 6.6.2. Без собственост и цел сроковете за съхранение се превръщат в предположения, а изтриването става рисковано.

Класификацията е първият контрол за съхранението

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

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

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

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

Това се съдържа в Политика за класификация и етикетиране на данни — МСП, раздел „Изисквания за внедряване на политиката“, клауза 6.1.1.

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

„Цялата работа с данни, предаване, достъп, съхранение и унищожаване на информация трябва да съответства на нейното ниво на класификация. Като минимум:“

Това се съдържа в Политика за класификация и етикетиране на данни, раздел „Изисквания за внедряване на политиката“, клауза 6.3.1.

Zenith Blueprint добавя насоки за внедряване за контрола 5.12 по ISO/IEC 27002:2022, Класификация на информацията. Схемата за класификация трябва да дефинира нива като Публична, За вътрешно ползване, Поверителна и Ограничена, да включва критерии въз основа на вредата от неразрешен достъп, загуба или изменение, да се прилага към всички форми на информация и да остава независима от формата или местоположението на съхранение.

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

Набор от данни с ниво „Ограничена“ не става с по-нисък риск само защото е преместен от база данни в SaaS аналитичен инструмент. Запис под правно задържане не губи статуса си, защото е експортиран в CSV. Личните данни не престават да бъдат регулирани, защото се появяват в съобщение в журнал.

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

Контролната ос по ISO 27001 за управление на жизнения цикъл

Най-ефективните програми за жизнения цикъл на данните имат контролна ос. Тази ос свързва контролите по ISO/IEC 27002:2022 с оперативни доказателства.

Zenith Controls: The Cross-Compliance Guide на Clarysec предоставя ръководството за междурегулаторно съответствие за тази работа. За управлението на жизнения цикъл на данните централни са три контрола: 5.33 Защита на записи, 5.34 Неприкосновеност на личния живот и защита на PII и 8.10 Изтриване на информация.

В Zenith Controls контролът 5.33 по ISO/IEC 27002:2022, Защита на записи, е описан чрез превантивни атрибути на контролите, които поддържат поверителност, цялост и наличност, с оперативни способности в областта на правните въпроси и съответствието, управлението на активи и защитата на информацията. Той се свързва с резервно копиране, класификация, сигурно унищожаване на оборудване, правни и регулаторни изисквания, съответствие с политики, контрол на достъпа и реагиране при инциденти.

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

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

Заедно тези контроли създават веригата на жизнения цикъл.

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

Изградете регистъра на съхранението преди процеса за изтриване

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

Политика за съхранение на данни и сигурно унищожаване — МСП на Clarysec определя базовото изискване:

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

Това се съдържа в Политика за съхранение на данни и сигурно унищожаване — МСП, раздел „Изисквания за управление“, клауза 5.1.1.

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

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

Това се съдържа в Политика за съхранение на данни и унищожаване, раздел „Цели“, клауза 3.3.

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

Регистърът на съхранението в малка финтех компания може да включва:

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

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

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

Политика за съхранение на данни и сигурно унищожаване — МСП е изрична:

„Нито един запис, предмет на правно задържане и спиране на изтриването, не може да бъде унищожаван или изменян, дори ако срокът му за съхранение е изтекъл.“

Това се съдържа в Политика за съхранение на данни и сигурно унищожаване — МСП, раздел „Изисквания за внедряване на политиката“, клауза 6.3.4.

Корпоративната Политика за съхранение на данни и унищожаване прилага същия управленски принцип:

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

Това се съдържа в Политика за съхранение на данни и унищожаване, раздел „Изисквания за внедряване на политиката“, клауза 6.4.1.

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

Доказуемият работен поток за правно задържане включва:

• Тригер, като съдебно производство, регулаторно запитване, инцидент по сигурността, одит или вътрешно разследване
• Собственик на задържането, обичайно правен отдел или съответствие
• Засегнати категории записи, системи и отговорници
• Инструкции за спиране на задачи за изтриване, изтичане на резервни копия и прочистване на архиви
• Ограничения на достъпа за запазване на целостта
• Периодичен преглед на задържането
• Одобрение за освобождаване и документирано връщане към нормално съхранение
• Доказателства какво е запазено, от кого и кога

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

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

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

Zenith Blueprint, фазата „Контроли в действие“, Стъпка 23, обхващаща контрола 5.23 по ISO/IEC 27002:2022, Информационна сигурност при използване на облачни услуги, предупреждава, че доставчиците на облачни услуги защитават инфраструктурата, но клиентът остава отговорен за данните, конфигурациите, политиките за достъп и готовността за реагиране при инциденти. Неправилно конфигурирани хранилища, публични информационни табла и прекомерни cloud IAM разрешения са управленски откази, а не откази на доставчика.

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

Политика за използване на облачни услуги — МСП на Clarysec превръща това в изисквания при извеждане:

„Потвърждение на процедурите за сигурно изтриване преди закриване на акаунт“

Това се съдържа в Политика за използване на облачни услуги — МСП, раздел „Изисквания за внедряване на политиката“, клауза 6.3.5.

Корпоративната Политика за използване на облачни услуги изисква управление върху:

„Собственост върху данните и връщане или изтриване при прекратяване“

Това се съдържа в Политика за използване на облачни услуги, раздел „Изисквания за управление“, клауза 5.4.1.

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

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

Едноседмичен спринт за създаване на пакет от контроли за жизнения цикъл

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

Ден 1: Изберете един високорисков поток от данни

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

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

Ден 2: Изградете миниинвентар на активите и данните

Използвайте Zenith Blueprint, фазата „Контроли в действие“, Стъпка 22, контрола 5.9 по ISO/IEC 27002:2022, за да обхванете физически, цифрови, логически, свързани с услуги и основани на отговорности активи.

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

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

Ден 3: Приложете логика за класификация и достъп

Приложете Политика за класификация и етикетиране на данни и класифицирайте всяка категория данни. След това проверете дали разрешенията за достъп отразяват класификацията.

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

Ден 4: Създайте записи за съхранение и правно задържане

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

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

Ден 5: Проверете изтриването при облачни услуги и доставчици

Използвайте Политика за използване на облачни услуги и Политика за използване на облачни услуги — МСП, за да проверите всеки облачен или SaaS доставчик в потока.

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

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

Ден 6: Определете доказателствата и мониторинга

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

Политика за съхранение на данни и унищожаване изисква унищожаването да бъде:

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

Това се съдържа в Политика за съхранение на данни и унищожаване, раздел „Изисквания за внедряване на политиката“, клауза 6.5.3.2.

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

Ден 7: Актуализирайте рисковете и Декларацията за приложимост

Актуализирайте регистъра на риска по ISO 27001 и Декларацията за приложимост. Ако прегледът на жизнения цикъл е установил неуправлявани SaaS експорти, безсрочно съхранение на резервни копия, прекомерен достъп, неясни условия за изтриване или липсваща собственост, това са рискове, изискващи третиране.

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

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

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

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

COBIT 2019 добавя управленски език за съвети и одитни комитети. Zenith Controls съпоставя Защита на записи с процеси на COBIT като управление на резервни копия и възстановяване, управление на сигурността на информацията в покой и управление на записи. Той съпоставя Неприкосновеност на личния живот и защита на PII с неприкосновеност на личния живот, защита на информацията и управление на програма за неприкосновеност на личния живот. Той съпоставя Изтриване на информация с целите за риск и операции, като утвърждава изтриването като управляван процес, а не като ad hoc задача за почистване.

Какво реално ще тестват одиторите

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

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

Използвайки одиторската перспектива в Zenith Controls за Защита на записи, одиторите проверяват дали записите в обхвата са идентифицирани, дали съществуват графици за съхранение, как се съхраняват записите, как се контролира достъпът и как се защитава целостта.

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

Одитор по неприкосновеност на личния живот или PII ще прегледа политиките за неприкосновеност на личния живот, инвентарите на данни, DPIA или PIA, журналите за обучения и технически мерки като шифроване на данни в покой и при пренос. Той може да вземе извадка от искане на субект на данни, да потвърди къде съществуват релевантните данни, да провери дали е приложено изтриване или ограничение и да провери дали изключения като правно задържане са обосновани.

Оценител, ориентиран към NIST, може да разгледа съгласуването с резултатите на NIST CSF и технически контроли като NIST SP 800-53 AU-11 Audit Record Retention, както и практики за саниране на носители, основани на NIST SP 800-88. Той може да тества възстановяване от резервно копие, да прегледа правилата за съхранение на журнали, да провери шифроването и да провери дали ненужната PII е минимизирана.

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

Чести модели на провал в управлението на жизнения цикъл

Clarysec често вижда едни и същи модели в МСП и регулирани организации.

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

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

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

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

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

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

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

Оперативният модел на Clarysec за управление на жизнения цикъл на данните

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

Контролната ос включва:

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

Zenith Blueprint предоставя пътната карта за внедряване чрез стъпките „Контроли в действие“ за инвентар, класификация, управление на облачни услуги и изтриване на информация. Zenith Controls предоставя ръководството за междурегулаторно съответствие, което показва как контролите по ISO/IEC 27002:2022 се свързват с GDPR, NIS2, DORA, NIST, COBIT, ISO/IEC 27701, ISO/IEC 27018, ISO/IEC 27017, ISO/IEC 27040, ISO 15489 и ISO 22301. Политиките на Clarysec предоставят оперативните клаузи, които екипите могат да внедрят незабавно.

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

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

Започнете с един високорисков поток от данни. Използвайте Zenith Blueprint: An Auditor’s 30-Step Roadmap, за да изградите основата за инвентар и класификация. Използвайте Zenith Controls: The Cross-Compliance Guide, за да съпоставите Защита на записи, Неприкосновеност на личния живот и защита на PII и Изтриване на информация спрямо GDPR, NIS2, DORA, NIST и COBIT. След това внедрете релевантните политики на Clarysec, включително Политика за класификация и етикетиране на данни, Политика за съхранение на данни и унищожаване, Политика за използване на облачни услуги и техните еквиваленти за МСП, когато е приложимо.

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

Изтеглете комплектите политики на Clarysec, съпоставете контролите си с Zenith Controls или използвайте Zenith Blueprint, за да проведете първия си контролен спринт за жизнения цикъл, преди следващото искане за изтриване да се превърне в одитна констатация.