Управление на ИКТ проекти със сигурност по замисъл през 2026 г.

Проектът беше в срок, докато одитът не зададе един въпрос

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

Тогава вътрешният одитор зададе прост въпрос:

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

В проектната зала настъпи тишина.

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

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

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

ISO/IEC 27001:2022 дава на организациите практическа управленска основа за решаване на този проблем. Той помага на CISO, мениджъри по съответствието, спонсори на проекти, DPO, архитекти, екипи по закупуване и одитори да превърнат значимите ИКТ проекти в защитими доказателства за сигурност по замисъл.

Защо управлението на ИКТ проекти вече е въпрос на регулаторни доказателства

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

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

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

GDPR добавя слоя на отчетност за личните данни. GDPR Article 25 изисква защита на данните на етапа на проектирането и по подразбиране. Администраторите трябва да могат да докажат съответствие с принципи като законосъобразност, добросъвестност, прозрачност, ограничаване на целите, минимизиране на данните, ограничаване на съхранението, цялостност, поверителност и отчетност. Когато обработването вероятно води до висок риск, може да се изисква и оценка на въздействието върху защитата на данните (DPIA) по GDPR Article 35.

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

Затова управлението на проекти по ISO/IEC 27001:2022 е толкова силен подход. То позволява на организацията да управлява NIS2, DORA, GDPR, NIST CSF 2.0, договорни задължения и искания от клиенти за потвърждение на контролите чрез един повторяем процес на СУИС, вместо чрез множество несвързани контролни списъци.

Управленската основа на ISO 27001 за проекти

ISO/IEC 27001:2022 често погрешно се възприема като упражнение за сертификация. За ИКТ проектите неговата оперативна стойност е по-широка. Той дава управленска основа за бизнес промени.

Клаузи 4.1 до 4.4 изискват организациите да разбират вътрешните и външните фактори, заинтересованите страни, правните, регулаторните и договорните изисквания, обхвата на СУИС, интерфейсите и зависимостите. В проектен контекст това означава проектният устав да идентифицира засегнатите услуги, клиенти, доставчици, регулации, бизнес процеси, лични данни, критични операции и външно възложени услуги.

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

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

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

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

Приложение A свързва този управленски цикъл с практически контроли. За сигурността по замисъл в ИКТ проекти три контроли от ISO/IEC 27001:2022 Приложение A са централни:

Zenith Blueprint: 30-стъпкова пътна карта за одитора на Clarysec разглежда информационната сигурност при управление на проекти като управленски въпрос за всички видове проекти, не само за разработка на софтуер:

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

Същият раздел улавя основния урок за внедряване:

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

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

Как изглежда сигурността по замисъл вътре в ИКТ проект

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

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

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

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

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

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

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

„Жизнени цикли на проектите (напр. сигурна разработка, моделиране на заплахите)“

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

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

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

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

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

От моделиране на заплахите към доказателства: практически финтех пример

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

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

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

Второ, създайте оценка на риска за проекта. Политиката за управление на риска на Clarysec за SME прави управлението на риска част от планирането, а не тримесечно упражнение в електронна таблица:

„1.2 Тя гарантира, че управлението на риска е активен компонент на планирането, изпълнението на проекти, избора на доставчици и реагирането при инциденти, в съответствие с ISO 27001, ISO 31000 и приложимите регулаторни изисквания.“

От раздел „Цел“, клауза на политиката 1.2.

За корпоративни среди Политиката за управление на риска на Clarysec Enterprise дефинира обхват на проектно и техническо ниво:

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

От раздел „Обхват“, клауза на политиката 2.3.

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

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

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

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

Четвърто, актуализирайте доказателствата за защита на личните данни. Политиката за защита на данните и поверителност на Clarysec за SME задава базовото изискване:

„5.3.1. Защита на данните на етапа на проектирането и по подразбиране трябва да се прилага във всички нови системи и услуги“

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

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

Пето, запишете доказателствата за сигурна разработка. Политиката за сигурна разработка на Clarysec за SME дава кратък списък с доказателства, подходящ за малки и средни екипи:

„5.3 Управителят (GM) трябва да поддържа записи за: 5.3.1 всички активни проекти за разработка на софтуер и отговорните разработчици или доставчици 5.3.2 контролни списъци за сигурност, използвани за всеки проект 5.3.3 извършени прегледи на изходния код и лицата, които са ги извършили 5.3.4 резултати от тестване преди внедряване 5.3.5 компоненти от трети страни и свързания с тях лицензионен или рисков статус“

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

Шесто, контролирайте внедряването като промяна. Политиката за управление на промените на Clarysec за SME посочва:

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

От раздел „Цел“, клауза на политиката 1.1.

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

Накрая, съпоставете задълженията. Политиката за правно и регулаторно съответствие на Clarysec за SME дава оперативното правило:

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

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

Този Регистър на съответствието се превръща в мост между контролите по ISO/IEC 27001:2022, мерките по NIS2 Article 21, задълженията за ИКТ риск по DORA, отчетността по GDPR и ангажиментите по договори с клиенти.

Съпоставяне на един проектен пакет с доказателства към NIS2, DORA, GDPR и NIST CSF 2.0

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

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

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

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

Zenith Controls: Ръководството за многорежимно съответствие на Clarysec поддържа същия интегриран подход чрез съпоставяне на контролите по ISO/IEC 27001:2022 с други рамки, одитни очаквания и нужди за съответствие. За управлението на ИКТ проекти то разглежда A.5.8, A.8.25 и A.8.32 като превантивни контроли, които защитават поверителността, цялостността и наличността в областите на управление, сигурност на приложенията, екосистема, защита и сигурност на системи и мрежи.

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

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

Един процес, съгласуван с ISO 27001 и центриран върху Приложение A.5.8, може да генерира защитими доказателства за всички тези очаквания.

Сигурната разработка е по-широка от писането на код

Много неуспехи в ИКТ проекти възникват, защото организацията третира сигурната разработка като нещо, което правят само разработчиците. През 2026 г. сигурната разработка включва също SaaS конфигурация, автоматизация на работни процеси, инфраструктура като код, интеграции на приложно-програмни интерфейси (API), правила за идентичност, зони за разполагане в облака, потоци за аналитична обработка, роботизирана автоматизация на процеси и бизнес приложения с минимално програмиране.

Zenith Blueprint, във фазата „Контроли в действие“, Step 20, разглежда контрол 8.25 Secure Development Life Cycle от ISO/IEC 27002:2022:

„Този контрол се прилага независимо дали разработвате собствени приложения, конфигурирате платформи като ERP или CRM системи, персонализирате SaaS работни процеси или управлявате среди за инфраструктура като код.“

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

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

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

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

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

Най-рисковият момент в много проекти не е проектирането или програмирането. Това е внедряването.

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

Zenith Blueprint, във фазата „Контроли в действие“, Step 21, описва контрол 8.32 Change Management от ISO/IEC 27002:2022 директно:

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

Продължава така:

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

Силен запис за ИКТ промяна трябва да отговаря на следното:

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

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

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

В съвременните ИКТ проекти най-рисковото проектно решение често е „купуване“, а не „изграждане“. Облачни услуги, доставчици на приложно-програмни интерфейси (API), платформи за проверка на идентичност, обработващи платежни операции, доставчици на аналитични услуги, доставчици на управлявани услуги и доставчици на управлявани услуги за сигурност стават част от рисковата повърхност.

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

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

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

Как одиторите ще преглеждат доказателствата за сигурност по замисъл

Различните одитори подхождат към един и същ ИКТ проект от различни ъгли. Одитор по сертификация, вътрешен одитор, преглеждащ по DORA, компетентен орган по NIS2, одитор по защита на личните данни, оценител, ориентиран към NIST, или одитор в стил COBIT/ISACA могат да поискат сходни доказателства, но да ги интерпретират различно.

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

Затова Zenith Controls е полезен при подготовка за одит. Той помага на екипите да обяснят защо Приложение A.5.8, A.8.25 и A.8.32 са превантивни контроли, които защитават поверителност, цялостност и наличност преди предвидими откази да достигнат продукционна среда.

Минималният проектен пакет с доказателства на Clarysec

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

За ИКТ проект със среден риск Clarysec обичайно препоръчва следния минимален пакет:

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

Zenith Blueprint дава логиката на пътната карта. Step 22 въвежда информационната сигурност във всички етапи на проекта. Step 20 вгражда сигурна разработка в планирането, дизайна, кода, тестването и внедряването. Step 21 прави управлението на промените структурирано, проследимо и годно за преглед. Step 14 препоръчва кръстосано съпоставяне на GDPR, NIS2, DORA и други задължения, така че изискванията за съответствие да не останат извън процеса.

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

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

Често срещани модели на неуспех в ИКТ проекти

Неуспехите обикновено са предвидими.

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

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

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

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

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

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

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

Изводът за CISO през 2026 г.

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

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

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

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

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

Ако вашите ИКТ проекти се движат по-бързо от модела ви за доказателства, започнете с един пилотен проект. Използвайте Zenith Blueprint на Clarysec, за да дефинирате проектни контролни точки по сигурността, приложете политиките на Clarysec за управление на риска, сигурна разработка, управление на промените и защита на личните данни и използвайте Zenith Controls, за да съпоставите управлението на ИКТ проекти по ISO/IEC 27001:2022 към NIS2, DORA, GDPR и NIST CSF 2.0.

Clarysec може да ви помогне да изградите преизползваем проектен пакет с доказателства за сигурност по замисъл, да го съгласувате с вашата СУИС и да го подготвите за вътрешен одит, сертификационен одит, готовност за DORA, управление по NIS2 и отчетност по GDPR.

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