Riadenie IKT projektov s bezpečnosťou už od návrhu v roku 2026

Projekt bol načas, kým audit nepoložil jednu otázku

CISO rýchlo rastúcej spoločnosti v oblasti platobných technológií mal pre predstavenstvo dobré správy. Nová platforma na onboarding zákazníkov bola pripravená na spustenie. Produktový tím pripravil mobilnú používateľskú skúsenosť, technický tím integroval overovanie identity, právne oddelenie podpísalo zmluvy s cloudovými poskytovateľmi a poskytovateľmi API a prevádzka nacvičila plán nasadenia do produkčného prostredia.

Potom interný audítor položil jednoduchú otázku:

„Ukážte mi, kde sa v každej fáze projektu posudzovala bezpečnosť a ochrana súkromia.“

V projektovej miestnosti nastalo ticho.

Existovala správa z penetračného testovania, ale test prebehol neskoro. Existoval diagram cloudovej architektúry, ale neexistoval dôkaz, že toky údajov boli preskúmané voči zásadám GDPR. Existoval dotazník due diligence dodávateľa, ale nebol prepojený s registrom rizík. Existoval záznam požiadavky na zmenu pre nasadenie do produkčného prostredia, ale schválenie nespomínalo vplyv na kritické služby, hlásenie incidentov, testovanie odolnosti, informovanie zákazníkov ani eskaláciu porušenia ochrany osobných údajov. Existovali poznámky zo sprintov, ale bezpečnostné požiadavky boli rozptýlené v používateľských príbehoch a komunikačných správach.

Nič nepôsobilo zjavne nedbanlivo. Všetko vyzeralo ako vyťažený moderný IKT projekt. Pre finančný subjekt podliehajúci DORA, poskytovateľa SaaS potenciálne spadajúceho do rozsahu NIS2 a prevádzkovateľa alebo sprostredkovateľa podľa GDPR však už otázkou nebolo len to, či bezpečnosť existovala. Otázkou bolo, či možno preukázať bezpečnosť už od návrhu.

To je problém roku 2026. IKT projekty sa už neposudzujú iba podľa rýchlosti dodania, kontroly nákladov a technickej kvality. Posudzujú sa podľa dôkazov o správe a riadení: posúdení rizík, návrhových rozhodnutí, due diligence dodávateľov, záznamov o bezpečnom vývoji, schválení zmien, rozhodnutí v oblasti ochrany súkromia, výsledkov testovania a dohľadu manažmentu.

ISO/IEC 27001:2022 poskytuje organizáciám praktickú chrbticu systému manažérstva na riešenie tohto problému. Pomáha CISO, manažérom súladu, sponzorom projektov, DPO, architektom, tímom obstarávania a audítorom premieňať významné IKT projekty na obhájiteľné dôkazy bezpečnosti už od návrhu.

Prečo je riadenie IKT projektov dnes problémom regulačných dôkazov

Migrácia do cloudového prostredia, zákaznícky portál, platobná platforma, implementácia CRM, zmena poskytovateľa identít, analytický dátový tok, integrácia API, pracovný postup v SaaS, low-code aplikácia alebo prechod na riadenú službu môžu zmeniť rizikový profil organizácie. V roku 2026 tieto zmeny prebiehajú pod prekrývajúcimi sa povinnosťami.

NIS2 sa široko vzťahuje na základné a dôležité subjekty v sektoroch podľa Annex I a Annex II vrátane digitálnej infraštruktúry, poskytovateľov riadených služieb, poskytovateľov riadených bezpečnostných služieb a digitálnych poskytovateľov. NIS2 Article 20 ukladá riadiacim orgánom zodpovednosť za schvaľovanie opatrení riadenia kybernetických rizík a dohľad nad ich implementáciou. NIS2 Article 21 vyžaduje primerané a proporcionálne technické, prevádzkové a organizačné opatrenia pre riadenie rizík, riešenie incidentov, kontinuitu činností, bezpečnosť dodávateľského reťazca, bezpečné obstarávanie, bezpečný vývoj, riešenie zraniteľností, posudzovanie účinnosti, kybernetickú hygienu, kryptografiu, riadenie prístupu, správu aktív a bezpečnú komunikáciu.

DORA sa vzťahuje na finančné subjekty a zameriava sa na digitálnu prevádzkovú odolnosť. DORA Article 5 ukladá riadiacemu orgánu zodpovednosť za riadenie rizík IKT. DORA Article 6 vyžaduje spoľahlivý, komplexný a dobre zdokumentovaný rámec riadenia rizík IKT. DORA sa týka aj hlásenia incidentov súvisiacich s IKT, testovania prevádzkovej odolnosti, kontinuity činností IKT, reakcie a obnovy, zdieľania informácií o kybernetických hrozbách, riadenia rizík externých poskytovateľov IKT, zmluvných dojednaní a dohľadu nad kritickými externými poskytovateľmi IKT.

GDPR pridáva vrstvu preukázateľnej zodpovednosti za osobné údaje. GDPR Article 25 vyžaduje ochranu údajov už od návrhu a štandardne. Prevádzkovatelia musia byť schopní preukázať súlad so zásadami, ako sú zákonnosť, spravodlivosť, transparentnosť, obmedzenie účelu, minimalizácia údajov, obmedzenie uchovávania, integrita, dôvernosť a preukázateľná zodpovednosť. Ak spracúvanie pravdepodobne povedie k vysokému riziku, môže sa vyžadovať aj posúdenie vplyvu na ochranu údajov podľa GDPR Article 35.

Spoločným menovateľom sú dôkazy. Regulátori a audítori sa nepýtajú len na to, či bola platforma šifrovaná, záplatovaná, skenovaná alebo testovaná. Pýtajú sa, či organizácia vie preukázať, že bezpečnosť, ochrana súkromia, dodávateľské riziko a odolnosť boli súčasťou rozhodovania od začiatku.

Preto je riadenie projektov podľa ISO/IEC 27001:2022 také silné. Umožňuje organizácii riadiť NIS2, DORA, GDPR, NIST CSF 2.0, zmluvné povinnosti a uistenie zákazníkov prostredníctvom jedného opakovateľného procesu ISMS namiesto viacerých oddelených kontrolných zoznamov.

Chrbtica riadenia projektov podľa ISO 27001

ISO/IEC 27001:2022 sa často nesprávne chápe ako certifikačné cvičenie. Pri IKT projektoch je jeho prevádzková hodnota širšia. Poskytuje chrbticu správy a riadenia pre organizačné zmeny.

Kapitoly 4.1 až 4.4 vyžadujú, aby organizácie rozumeli interným a externým otázkam, zainteresovaným stranám, právnym, regulačným a zmluvným požiadavkám, rozsahu ISMS, rozhraniam a závislostiam. V projektovom kontexte to znamená, že projektový zámer má identifikovať dotknuté služby, zákazníkov, dodávateľov, predpisy, obchodné procesy, osobné údaje, kritické operácie a outsourcované služby.

Kapitoly 5.1 až 5.3 vyžadujú záväzok vedenia, zosúladenie politík, zdroje, integráciu do obchodných procesov a pridelené zodpovednosti. Je to dôležité preto, že NIS2 aj DORA zaraďujú kybernetickú bezpečnosť a riziká IKT pod zodpovednosť riadiaceho orgánu. Projekt, ktorý mení kritickú zákaznícku platformu, sa nemôže spoliehať na neformálnu bezpečnostnú poznámku v komunikačnom vlákne. Potrebuje jasnú zodpovednosť za konanie.

Kapitoly 6.1.1 až 6.1.3 vyžadujú opakovateľný proces posúdenia a ošetrenia rizík, kritériá rizík, vlastníkov rizík, hodnotenie dôvernosti, integrity a dostupnosti, plány ošetrenia rizík, vyhlásenie o uplatniteľnosti a schválenie zostatkového rizika. Tu sa projektové riziko mení na auditný dôkaz.

Kapitoly 7.1 až 7.5 vyžadujú zdroje, kompetencie, povedomie, komunikáciu a riadenie zdokumentovaných informácií. Tak sa z projektových záznamov stávajú spoľahlivé dôkazy namiesto rozptýlených artefaktov.

Kapitola 8.1 vyžaduje prevádzkové plánovanie a riadenie, zdokumentované informácie preukazujúce, že procesy boli vykonané podľa plánu, riadenie plánovaných zmien, preskúmanie neúmyselných zmien, zmiernenie nepriaznivých účinkov a riadenie externe poskytovaných procesov, produktov alebo služieb relevantných pre ISMS. Kapitoly 8.2 a 8.3 vyžadujú posúdenia rizík informačnej bezpečnosti a ošetrenie rizík v plánovaných intervaloch alebo pri významných zmenách.

Príloha A následne prepája tento manažérsky cyklus s praktickými kontrolami. Pre bezpečnosť už od návrhu v IKT projektoch sú kľúčové tri kontroly ISO/IEC 27001:2022 Prílohy A:

Clarysec Zenith Blueprint: 30-kroková cestovná mapa audítora vníma informačnú bezpečnosť v riadení projektov ako otázku správy a riadenia naprieč všetkými typmi projektov, nielen pri vývoji softvéru:

„Akýkoľvek projekt – migrácia marketingového systému, sťahovanie pracoviska, redizajn obchodného procesu, platforma pre onboarding v HR, dokonca fúzia alebo akvizícia – môže ovplyvniť dôvernosť, integritu alebo dostupnosť informácií. Keď k tomu dôjde, bezpečnosť musí mať miesto pri stole.“

Tá istá časť vystihuje základnú lekciu implementácie:

„Cieľom tejto kontroly nie je zaťažiť projekty byrokraciou. Cieľom je zabezpečiť, aby sa bezpečnosť brala ako vstup do návrhu, nie ako testovacia fáza.“

Tento rozdiel oddeľuje formálnu hru na súlad od obhájiteľnej bezpečnosti už od návrhu.

Ako vyzerá bezpečnosť už od návrhu v IKT projekte

Bezpečnosť už od návrhu sa začína pred prvým sprintom, požiadavkou na obstaranie, architektonickým diagramom alebo prevádzkovou príručkou migrácie. Kladie jednoduchú otázku: čo môže tento projekt zmeniť na riziku?

Praktický model riadenia projektov používa sedem dôkazových brán.

Pointou nie je byrokracia. Pointou je zviditeľniť bezpečnosť tam, kde sa projektové rozhodnutia skutočne prijímajú.

Clarysec Enterprise Politika informačnej bezpečnosti to vyjadruje priamo:

„Správa bezpečnosti musí byť integrovaná s podnikovou správou a riadením, riadením projektov, obstarávaním a funkciami právneho dohľadu, aby informačná bezpečnosť nebola izolovaná, ale zabudovaná do rozhodovania v celej organizácii.“

Zo sekcie „Požiadavky na správu a riadenie“, bod politiky 5.5.

Zároveň stanovuje, že životné cykly projektov sú predmetom implementácie:

„Životné cykly projektov (napr. bezpečný vývoj, modelovanie hrozieb)“

Zo sekcie „Požiadavky na implementáciu politiky“, bod politiky 6.3.1.1.

A uvádza auditný princíp, ktorý mnohé organizácie objavia príliš neskoro:

„Všetky implementované kontroly musia byť overiteľné, podporené zdokumentovanými postupmi a uchovávanými dôkazmi o prevádzke.“

Zo sekcie „Požiadavky na implementáciu politiky“, bod politiky 6.6.1.

Inými slovami, bezpečnostná práca, ktorá nie je riadená, uchovávaná a mapovaná, pri audite často zlyhá, aj keď technické tímy prijali primerané rozhodnutia.

Od modelovania hrozieb k dôkazom: praktický fintech príklad

Predstavme si projekt spustenia nového portálu na onboarding zákazníkov v EÚ pre fintech spoločnosť. Portál zhromažďuje doklady totožnosti, vykonáva biometrické overenie prostredníctvom tretej strany, uchováva stav onboardingu, integruje sa s CRM, spúšťa notifikácie zákazníkov a dodáva vstupy do skórovania rizík.

Prístup bezpečnosti už od návrhu by vytváral dôkazy počas celého priebehu projektu.

Najprv otvorte záznam bezpečnostnej klasifikácie projektu. Identifikujte, či projekt ovplyvňuje kritické alebo dôležité funkcie, osobné údaje, osobitné kategórie osobných údajov, autentifikáciu, dostupnosť pre zákazníkov, outsourcované IKT služby, regulované oznamovacie procesy alebo komunikáciu so zákazníkmi. Podľa GDPR sú biometrické údaje používané na jednoznačnú identifikáciu osobitnou kategóriou osobných údajov, ak sa neuplatňuje konkrétna výnimka. To okamžite zvyšuje požadovanú úroveň právnej analýzy a ochranných opatrení.

Po druhé, vytvorte posúdenie rizík projektu. Clarysec SME Politika riadenia rizík robí z riadenia rizík súčasť plánovania, nie štvrťročné cvičenie v tabuľkovom prehľade:

„1.2 Zabezpečuje, aby riadenie rizík bolo aktívnou súčasťou plánovania, realizácie projektov, výberu dodávateľov a reakcie na incidenty, v súlade s ISO 27001, ISO 31000 a uplatniteľnými regulačnými požiadavkami.“

Zo sekcie „Účel“, bod politiky 1.2.

Pre podnikové prostredia Clarysec Enterprise Politika riadenia rizík definuje rozsah naprieč projektovou a technickou úrovňou:

„Vzťahuje sa na riziká informačnej bezpečnosti na strategickej, prevádzkovej, projektovej a technickej úrovni a je povinná pre všetok personál, dodávateľov a poskytovateľov služieb zapojených do činností systému manažérstva informačnej bezpečnosti (ISMS).“

Zo sekcie „Rozsah“, bod politiky 2.3.

Po tretie, vykonajte modelovanie hrozieb pred začiatkom vývoja. Enterprise Politika bezpečného vývoja je explicitná:

„Všetky nové aplikácie a významné zmeny musia pred začiatkom vývoja prejsť preskúmaním bezpečnej architektúry a modelovaním hrozieb.“

Zo sekcie „Požiadavky na implementáciu politiky“, bod politiky 6.1.1.

Pre portál onboardingu má model hrozieb pokrývať vystavené rozhrania, toky identity, hranice oprávnení, prípady zneužitia API, podvrhnutie webhookov, replay útoky, kompromitované poverenia, cesty úniku údajov, riziko závislostí, požiadavky na logovanie, predpoklady zálohovania, požiadavky na obnovu a režimy zlyhania poskytovateľov.

Po štvrté, aktualizujte dôkazy ochrany súkromia. SME Politika ochrany údajov a súkromia stanovuje základnú úroveň:

„5.3.1. Ochrana súkromia už od návrhu a štandardne musí byť vynucovaná vo všetkých nových systémoch a službách“

Zo sekcie „Požiadavky na správu a riadenie“, bod politiky 5.3.1.

Projektový záznam má obsahovať účel, právny základ, rolu prevádzkovateľa alebo sprostredkovateľa, rozhodnutia o minimalizácii údajov, pravidlá uchovávania, prístupové roly, voľby šifrovania, zohľadnenie vplyvu na dotknuté osoby, požiadavky na transparentnosť, podmienky sprostredkovateľa a postupy oznámenia porušenia ochrany osobných údajov.

Po piate, zaznamenajte dôkazy bezpečného vývoja. SME Politika bezpečného vývoja poskytuje stručný zoznam dôkazov použiteľný pre malé a stredne veľké tímy:

„5.3 Generálny manažér (GM) musí uchovávať záznamy o: 5.3.1 všetkých aktívnych projektoch vývoja softvéru a zodpovedných vývojároch alebo dodávateľoch 5.3.2 bezpečnostných kontrolných zoznamoch použitých pre každý projekt 5.3.3 vykonaných preskúmaniach kódu a osobách, ktoré ich vykonali 5.3.4 výsledkoch testovania pred nasadením 5.3.5 komponentoch tretích strán a ich príslušnom licenčnom alebo rizikovom stave“

Zo sekcie „Požiadavky na správu a riadenie“, bod politiky 5.3.

Po šieste, riaďte nasadenie ako zmenu. SME Politika riadenia zmien uvádza:

„1.1 Táto politika zabezpečuje, aby všetky zmeny IT systémov, konfigurácií, podnikových aplikácií alebo cloudových služieb boli pred implementáciou naplánované, posúdené z hľadiska rizík, otestované a schválené.“

Zo sekcie „Účel“, bod politiky 1.1.

Pre portál onboardingu má záznam požiadavky na zmenu obsahovať dotknuté služby, posúdenie rizík, výsledky testov, plán vrátenia zmeny, plán monitorovania, bezpečnostné schválenia, schválenie ochrany súkromia, pripravenosť dodávateľov, aktualizácie eskalácie incidentov a spúšťače komunikácie so zákazníkmi.

Napokon mapujte povinnosti. SME Politika právneho a regulačného súladu stanovuje prevádzkové pravidlo:

„5.2.2 Ak sa predpis vzťahuje na viacero oblastí (napr. GDPR sa vzťahuje na uchovávanie, bezpečnosť a ochranu súkromia), musí to byť jasne namapované v registri súladu a školiacich materiáloch.“

Zo sekcie „Požiadavky na správu a riadenie“, bod politiky 5.2.2.

Tento register súladu sa stáva mostom medzi kontrolami ISO/IEC 27001:2022, opatreniami NIS2 Article 21, povinnosťami v oblasti rizík IKT podľa DORA, preukázateľnou zodpovednosťou podľa GDPR a záväzkami zo zákazníckych zmlúv.

Mapovanie jedného projektového balíka dôkazov na NIS2, DORA, GDPR a NIST CSF 2.0

Najúčinnejšou stratégiou súladu nie je duplicitná práca. Je ňou mapovanie jedného kvalitného súboru dôkazov na viaceré povinnosti.

Zenith Blueprint vo fáze riadenia rizík, krok 14, odporúča tento typ krížového odkazovania:

„Pre každý predpis, ak je uplatniteľný, môžete vytvoriť jednoduchú mapovaciu tabuľku (napríklad ako prílohu správy), ktorá uvádza kľúčové bezpečnostné požiadavky predpisu a zodpovedajúce kontroly/politiky vo vašom ISMS.“

Dodáva, že je to užitočné, pretože audítorom a posudzovateľom ukazuje, „že bezpečnosť neriadite vo vákuu, ale ste si vedomí právneho kontextu“.

Clarysec Zenith Controls: Sprievodca viacnásobným súladom podporuje rovnaký integrovaný prístup mapovaním kontrol ISO/IEC 27001:2022 na iné rámce, auditné očakávania a potreby súladu. Pri riadení IKT projektov rámcuje A.5.8, A.8.25 a A.8.32 ako preventívne kontroly, ktoré chránia dôvernosť, integritu a dostupnosť naprieč oblasťami správy a riadenia, bezpečnosti aplikácií, ekosystému, ochrany a bezpečnosti systémov a sietí.

Táto tabuľka nenahrádza právnu analýzu. Je akcelerátorom správy a riadenia. Zabezpečuje, aby CISO, DPO, sponzor projektu, vedúci obstarávania, vlastník systému a interný audítor pracovali s rovnakými dôkazmi.

NIST CSF 2.0 prirodzene zapadá do tohto modelu. Jeho funkcia GOVERN pomáha organizáciám stanovovať politiky, roly, apetít na riziko, dohľad a povedomie o právnych alebo zmluvných povinnostiach. Funkcie IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER pomáhajú tímom diskutovať o aktívach, službách dodávateľov, riadení prístupu, bezpečnosti údajov, bezpečnosti platforiem, bezpečnom vývoji softvéru, monitorovaní, reakcii na incidenty a obnove v spoločnom prevádzkovom jazyku.

Jeden proces zosúladený s ISO 27001 a sústredený na Prílohu A, kontrolu A.5.8 dokáže vytvoriť obhájiteľné dôkazy pre všetky tieto očakávania.

Bezpečný vývoj je viac než písanie kódu

Mnohé zlyhania IKT projektov vznikajú preto, že organizácia považuje bezpečný vývoj za niečo, čo robia iba vývojári. V roku 2026 bezpečný vývoj zahŕňa aj konfiguráciu SaaS, automatizáciu pracovných postupov, infraštruktúru ako kód, integrácie API, pravidlá identít, cloudové landing zóny, analytické dátové toky, robotickú automatizáciu procesov a low-code podnikové aplikácie.

Zenith Blueprint vo fáze Controls in Action, krok 20, sa venuje kontrole ISO/IEC 27002:2022 8.25 Secure Development Life Cycle:

„Táto kontrola sa uplatňuje bez ohľadu na to, či píšete vlastné aplikácie, konfigurujete platformy ako ERP alebo CRM systémy, prispôsobujete pracovné toky SaaS alebo spravujete prostredia infraštruktúry ako kódu.“

Zároveň vysvetľuje, že bezpečnostné požiadavky musia stáť vedľa funkčných požiadaviek a že modelovanie hrozieb pomáha identifikovať vystavené časti systému, rizikové používateľské roly a toky údajov vyžadujúce vyššiu ochranu.

Pri modernom projekte môžu dôkazy bezpečného vývoja zahŕňať:

• bezpečnostné požiadavky prepojené s obchodnými požiadavkami,
• model hrozieb alebo preskúmanie bezpečnej architektúry,
• kontrolný zoznam bezpečného programovania alebo bezpečnej konfigurácie,
• záznamy o preskúmaní kódu alebo vzájomnom hodnotení,
• evidenciu komponentov a stav rizika závislostí,
• rozhodnutia o správe tajomstiev,
• návrh riadenia prístupu a zásady minimálnych oprávnení,
• požiadavky na logovanie a monitorovanie,
• výsledky skenov zraniteľností a dôkazy o nápravných opatreniach,
• bezpečnostné testovanie v predprodukčnom prostredí,
• testovanie zálohovania, obnovy a odolnosti, kde je relevantné,
• dôkazy o schválení nasadenia a pláne vrátenia zmeny.

Cieľom nie je nútiť každý projekt do rovnako ťažkopádneho procesu. Cieľom je proporcionalita. Menšia interná zmena pracovného postupu nevyžaduje rovnaké dôkazy ako migrácia kľúčovej platobnej platformy. Každý projekt však má byť klasifikovaný, posúdený z hľadiska rizík a riadený podľa dopadu.

Riadenie zmien chráni projekt pred ním samým

Najrizikovejším momentom mnohých projektov nie je návrh ani kódovanie. Je ním nasadenie.

Tím môže vykonať modelovanie hrozieb, preskúmanie kódu, posúdenie dodávateľa a preskúmanie ochrany súkromia, a napriek tomu spôsobiť výpadok alebo porušenie ochrany údajov unáhlenou produkčnou zmenou. Debug príznak zostane povolený. Pravidlo firewallu je širšie, než bolo schválené. Migračný skript skopíruje osobné údaje do neprodukčného prostredia. Endpoint webhooku tretej strany je nasadený bez autentifikácie. Zmena logovania zaznamenáva čísla dokladov totožnosti. Zálohovacia úloha po preklopení zlyhá bez upozornenia.

Zenith Blueprint vo fáze Controls in Action, krok 21, opisuje kontrolu ISO/IEC 27002:2022 8.32 Change Management priamo:

„Zmena je nevyhnutná, ale v kybernetickej bezpečnosti je neriadená zmena nebezpečná.“

Pokračuje:

„Vo svojej podstate je účinné riadenie zmien opakovateľným pracovným tokom. Začína jasným návrhom, ktorý uvádza, čo sa mení, prečo, kedy a aké sú potenciálne riziká.“

Silný záznam IKT zmeny má odpovedať na tieto otázky:

• Aký systém, služba, tok údajov, dodávateľ alebo konfigurácia sa mení?
• Ktoré riziká boli identifikované a kto ich vlastní?
• Ovplyvňuje zmena osobné údaje, kritické služby, autentifikáciu, logovanie, zálohy alebo reakciu na incidenty?
• Aké kontroly bezpečnosti, ochrany súkromia, odolnosti a dodávateľov boli vykonané?
• Aké testy boli dokončené pred nasadením?
• Aké monitorovanie potvrdí očakávané správanie?
• Aký plán vrátenia zmeny alebo obnovy existuje?
• Kto schválil zostatkové riziko?
• Aké dôkazy sa budú uchovávať?

Pre DORA to podporuje zdokumentované riadenie rizík IKT, odolnosť, kontinuitu, klasifikáciu incidentov a poučenia. Pre NIS2 to podporuje opatrenia riadenia rizík, bezpečný vývoj, prevenciu incidentov a kontinuitu. Pre GDPR to pomáha preukázať, že zmeny ovplyvňujúce osobné údaje boli preskúmané voči zásadám účelu, minimalizácie, uchovávania, prístupu a bezpečnosti.

Rozhodnutia o dodávateľoch a cloude musia byť súčasťou návrhu projektu

V moderných IKT projektoch je najrizikovejším návrhovým rozhodnutím často „kúpiť“ namiesto „vybudovať“. Cloudové služby, poskytovatelia API, platformy overovania identity, platobní sprostredkovatelia, analytickí dodávatelia, poskytovatelia riadených služieb a poskytovatelia riadených bezpečnostných služieb sa stávajú súčasťou rizikovej plochy.

NIS2 výslovne zahŕňa bezpečnosť dodávateľského reťazca, zraniteľnosti priamych dodávateľov a poskytovateľov služieb, kybernetickobezpečnostné postupy dodávateľov, postupy bezpečného vývoja a výsledky koordinovaných posúdení rizík dodávateľského reťazca. DORA ide pri finančných subjektoch hlbšie. Vyžaduje riadenie rizík externých poskytovateľov IKT ako súčasť rámca riadenia rizík IKT, pretrvávajúcu zodpovednosť aj pri outsourcingu IKT služieb, informačné registre, predzmluvné posúdenia, analýzu rizika koncentrácie, zmluvné kontroly, práva na audit a kontrolu, spúšťače ukončenia a otestované exit stratégie pre kritické alebo dôležité funkcie.

Pre portál onboardingu nemožno poskytovateľa biometrického overenia schváliť len preto, že obstarávaniu vyhovuje cena a dokumentácia API je dobrá. Projekt potrebuje dôkazy o bezpečnostnej due diligence, role pri spracúvaní, umiestnení údajov, subdodávateľoch, záväzkoch dostupnosti, podpore pri incidentoch, právach na audit, pomoci pri ukončení, realizovateľnosti exitu a monitorovacích povinnostiach.

V zrelom dôkazovom modeli sú rozhodnutia o dodávateľoch a cloudových službách súčasťou projektového balíka dôkazov, nie oddeleného priečinka dodávateľa. Keď sa audítor opýta, prečo bola tretia strana akceptovaná, odpoveď má obsahovať obchodnú potrebu, posúdenie rizík, zmluvné ochranné opatrenia, preskúmanie ochrany údajov, vplyv na odolnosť a priebežné monitorovanie.

Ako audítori preskúmajú dôkazy bezpečnosti už od návrhu

Rôzni audítori pristupujú k rovnakému IKT projektu z rôznych uhlov. Certifikačný audítor, interný audítor, hodnotiteľ DORA, príslušný orgán NIS2, audítor ochrany súkromia, posudzovateľ orientovaný na NIST alebo audítor v štýle COBIT/ISACA môžu požadovať podobné dôkazy, ale interpretovať ich odlišne.

Audítori nechcú peknú projektovú prezentáciu. Chcú sledovateľnosť. Chcú vidieť, že požiadavky viedli k rizikám, riziká ku kontrolám, kontroly k dôkazom implementácie a implementácia k preskúmaniu.

Preto je Zenith Controls užitočný pri príprave na audit. Pomáha tímom vysvetliť, prečo sú Príloha A, kontroly A.5.8, A.8.25 a A.8.32 preventívne kontroly, ktoré chránia dôvernosť, integritu a dostupnosť skôr, než predvídateľné zlyhania zasiahnu produkčné prostredie.

Minimálny projektový balík dôkazov Clarysec

Silný balík dôkazov bezpečnosti už od návrhu nemusí byť rozsiahly. Musí byť konzistentný, proporcionálny a namapovaný.

Pre IKT projekt so stredným rizikom Clarysec zvyčajne odporúča tento minimálny balík:

1. Záznam bezpečnostnej klasifikácie projektu
2. Poznámka k uplatniteľnosti predpisov pokrývajúca NIS2, DORA tam, kde je relevantná, GDPR a zmluvné povinnosti
3. Mapa vplyvu tokov údajov a aktív
4. Posúdenie rizík projektu a plán ošetrenia rizík
5. Model hrozieb alebo preskúmanie bezpečnej architektúry
6. Posúdenie dodávateľa a cloudovej služby, ak je uplatniteľné
7. Kontrolný zoznam bezpečného vývoja alebo konfigurácie
8. Výsledky bezpečnostných testov a dôkazy o nápravných opatreniach
9. Schválenie zmeny s plánom vrátenia zmeny a plánom monitorovania
10. Záznam ochrany súkromia už od návrhu vrátane právneho základu a uchovávania, ak ide o osobné údaje
11. Aktualizácie reakcie na incidenty a monitorovania
12. Preskúmanie po implementácii a poučenia
13. Mapovanie registra súladu na kontroly a povinnosti

Zenith Blueprint poskytuje logiku cestovnej mapy. Krok 22 prináša informačnú bezpečnosť do všetkých projektových fáz. Krok 20 zabudúva bezpečný vývoj do plánovania, návrhu, kódu, testovania a nasadenia. Krok 21 robí riadenie zmien štruktúrovaným, sledovateľným a preskúmateľným. Krok 14 odporúča krížové odkazovanie GDPR, NIS2, DORA a ďalších povinností, aby požiadavky súladu neprepadli medzi oblasťami.

Politiky poskytujú prevádzkové pravidlá. Politika informačnej bezpečnosti integruje bezpečnosť s riadením projektov, obstarávaním a právnym dohľadom. Politika riadenia rizík robí z projektových rizík súčasť činnosti ISMS. Politika bezpečného vývoja vyžaduje modelovanie hrozieb. Politika riadenia zmien vyžaduje plánované, rizikovo posúdené, testované a schválené zmeny. Politika ochrany údajov a súkromia vyžaduje ochranu súkromia už od návrhu a štandardne. Politika právneho a regulačného súladu vyžaduje mapovanie predpisov s viacerými oblasťami v registri súladu.

Spoločne tieto nástroje premieňajú bezpečnosť už od návrhu z ambície na auditovateľný prevádzkový model.

Bežné vzorce zlyhania v IKT projektoch

Zlyhania sú zvyčajne predvídateľné.

Prvým je neskoré zapojenie bezpečnosti. Bezpečnostné preskúmania prebiehajú po tom, čo je architektúra pevne daná, zmluvy podpísané a termíny dodania verejné. Vtedy sa bezpečnosť stáva blokátorom namiesto vstupu do návrhu.

Druhým sú fragmentované dôkazy. Projekt má výsledky testov v jednom nástroji, preskúmanie dodávateľa v inom, komentáre k ochrane súkromia v e-maile, akceptáciu rizika v nahrávke zo stretnutia a schválenie zmeny v zázname požiadavky. Žiadna jednotná niť nepreukazuje správu a riadenie.

Tretím sú slepé miesta pri dodávateľoch. Projekt sa spolieha na cloudovú službu alebo poskytovateľa API, ale nikto neoverí subdodávateľov, umiestnenie údajov, práva na audit, podporu pri incidentoch, exit plány ani riziko koncentrácie.

Štvrtým je odklon v oblasti ochrany súkromia. Systém vybudovaný na jeden účel začne podporovať analytiku, experimentovanie s AI, marketingové exporty alebo prevádzkové monitorovanie bez opätovného posúdenia právneho základu, transparentnosti, minimalizácie alebo uchovávania.

Piatym je nepreskúmaná zmena. Produkčné nasadenie je schválené z hľadiska funkčnosti, ale nie je posúdené z hľadiska prístupu, logovania, šifrovania, zálohovania, odolnosti, osobných údajov alebo vplyvu na oznamovanie.

Šiestym je slabý dohľad manažmentu. Projektové riziká s vysokým dopadom sa akceptujú na príliš nízkej úrovni bez dôkazu, že zodpovedný vlastník rizika rozumel regulačným dôsledkom.

Tieto problémy nevyrieši kúpa ďalšieho skenera. Riešia sa integráciou správy bezpečnosti do spôsobu, akým sa projekty navrhujú, plánujú, obstarávajú, vyvíjajú, testujú, menia a preskúmavajú.

Zhrnutie pre CISO v roku 2026

Bezpečnosť už od návrhu v IKT projektoch je dnes témou pre predstavenstvo, audit aj reguláciu. NIS2 robí z riadenia kybernetických rizík záležitosť riadiaceho orgánu. DORA robí z rizík IKT, testovania odolnosti, riadenia incidentov a dohľadu nad tretími stranami štruktúrovanú povinnosť finančného sektora. GDPR vyžaduje preukázateľnú zodpovednosť za spracúvanie osobných údajov a primeranú bezpečnosť. ISO/IEC 27001:2022 poskytuje štruktúru systému manažérstva, ktorá tieto povinnosti premieňa na prevádzkovú prax.

Pre CISO je príležitosťou prestať bojovať s projektovými tímami na konci dodania. Vložte bezpečnosť do iniciácie, požiadaviek, návrhu, výberu dodávateľov, vývoja, testovania, schválenia zmien a preskúmania po implementácii.

Pre manažérov súladu je príležitosťou nahradiť rozptýlené dôkazy jedným namapovaným projektovým balíkom dôkazov.

Pre audítorov je príležitosťou testovať životný cyklus projektu, nielen finálny systém.

Pre vlastníkov organizácie je príležitosťou rýchlejšie a bezpečnejšie dodanie. Bezpečnosť už od návrhu znižuje prepracovanie, predchádza prekvapeniam v oblasti súladu, zlepšuje rozhodnutia o dodávateľoch a poskytuje vedeniu obhájiteľný príbeh o riziku.

Ak sa vaše IKT projekty pohybujú rýchlejšie než váš dôkazový model, začnite jedným pilotným projektom. Použite Clarysec Zenith Blueprint na definovanie projektových bezpečnostných brán, uplatnite politiky Clarysec pre riadenie rizík, bezpečný vývoj, riadenie zmien a ochranu súkromia a použite Zenith Controls na mapovanie riadenia projektov podľa ISO/IEC 27001:2022 na NIS2, DORA, GDPR a NIST CSF 2.0.

Clarysec vám môže pomôcť vybudovať opakovane použiteľný projektový balík dôkazov bezpečnosti už od návrhu, zosúladiť ho s vaším ISMS a pripraviť ho na interný audit, certifikačný audit, pripravenosť na DORA, správu a riadenie podľa NIS2 a preukázateľnú zodpovednosť podľa GDPR.

Začnite pri najbližšom významnom IKT projekte. Ak mení systémy, dodávateľov, údaje, prístupy, odolnosť alebo dôveru zákazníkov, zaslúži si bezpečnosť už od návrhu od prvého dňa.