Řízení ICT projektů s bezpečností již od návrhu v roce 2026

Projekt byl v termínu, dokud se audit nezeptal na jednu věc

Ředitel informační bezpečnosti rychle rostoucí společnosti v oblasti platebních technologií měl pro správní radu dobré zprávy. Nová platforma pro onboarding zákazníků byla připravena ke spuštění. Produktový tým dodal mobilní uživatelskou zkušenost, vývojový tým integroval ověřování digitální identity, právní oddělení uzavřelo smlouvy s cloudovými poskytovateli a poskytovateli API a provozní tým nacvičil plán nasazení do produkčního prostředí.

Poté interní auditor položil jednoduchou otázku:

„Ukažte mi, kde byla v jednotlivých fázích projektu posouzena bezpečnost a ochrana soukromí.“

V projektové místnosti se rozhostilo ticho.

Existovala zpráva z penetračního testu, ale test proběhl pozdě. Existoval diagram cloudové architektury, ale chyběly důkazy, že datové toky byly přezkoumány podle zásad GDPR. Existoval dotazník prověrky dodavatelů, ale nebyl navázán na registr rizik. Existoval záznam změny pro nasazení do produkčního prostředí, ale schválení nezmiňovalo dopad na kritické služby, hlášení incidentů, testování odolnosti, informování zákazníků ani eskalaci porušení zabezpečení osobních údajů. Existovaly poznámky ze sprintů, ale bezpečnostní požadavky byly rozptýlené v uživatelských příbězích a chatových zprávách.

Nic nepůsobilo zjevně nedbale. Vše vypadalo jako vytížený moderní ICT projekt. Pro finanční subjekt podléhající DORA, poskytovatele SaaS potenciálně spadajícího do působnosti NIS2 a správce nebo zpracovatele podle GDPR však už nešlo jen o to, zda bezpečnost existovala. Šlo o to, zda lze bezpečnost již od návrhu doložit.

To je problém roku 2026. ICT projekty se již neposuzují pouze podle rychlosti dodání, kontroly nákladů a technické kvality. Posuzují se podle důkazů o řízení a dohledu: posouzení rizik, návrhových rozhodnutí, prověrky dodavatelů, záznamů o bezpečném vývoji, schválení změn, rozhodnutí v oblasti ochrany soukromí, výsledků testování a dohledu vedení.

ISO/IEC 27001:2022 poskytuje organizacím praktickou páteř systému řízení pro řešení tohoto problému. Pomáhá ředitelům informační bezpečnosti, manažerům souladu, sponzorům projektů, pověřencům pro ochranu osobních údajů, architektům, nákupním týmům a auditorům převádět významné ICT projekty do obhajitelných důkazů o bezpečnosti již od návrhu.

Proč je řízení ICT projektů nyní otázkou regulačních důkazů

Migrace do cloudu, zákaznický portál, platební platforma, implementace CRM, změna poskytovatele identit, analytická pipeline, integrace API, pracovní postup SaaS, low-code aplikace nebo přechod na řízenou službu mohou změnit rizikový profil organizace. V roce 2026 k těmto změnám dochází pod překrývajícími se povinnostmi.

NIS2 se široce vztahuje na základní a důležité subjekty v sektorech uvedených v Annex I a Annex II, včetně digitální infrastruktury, poskytovatelů řízených služeb, poskytovatelů řízených bezpečnostních služeb a digitálních poskytovatelů. NIS2 Article 20 ukládá řídicím orgánům odpovědnost za schvalování opatření k řízení kybernetických rizik a za dohled nad jejich implementací. NIS2 Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření pro řízení rizik, zvládání incidentů, kontinuitu činností, zabezpečení dodavatelského řetězce, bezpečné pořizování, bezpečný vývoj, ošetření zranitelností, posuzování účinnosti, kybernetickou hygienu, kryptografii, řízení přístupů, správu aktiv a bezpečnou komunikaci.

DORA se vztahuje na finanční subjekty a zaměřuje se na digitální provozní odolnost. DORA Article 5 svěřuje odpovědnost za řízení ICT rizik řídicímu orgánu. DORA Article 6 vyžaduje spolehlivý, komplexní a řádně zdokumentovaný rámec řízení ICT rizik. DORA se dále týká hlášení incidentů souvisejících s ICT, testování provozní odolnosti, kontinuity ICT činností, reakce a obnovy, sdílení informací o kybernetických hrozbách, řízení rizik třetích stran v oblasti ICT, smluvních ujednání a dohledu nad kritickými poskytovateli ICT služeb z řad třetích stran.

GDPR doplňuje vrstvu odpovědnosti za osobní údaje. GDPR Article 25 vyžaduje ochranu osobních údajů již od návrhu a ve výchozím nastavení. Správci musí být schopni doložit soulad se zásadami, jako jsou zákonnost, korektnost, transparentnost, omezení účelu, minimalizace údajů, omezení uložení, integrita, důvěrnost a odpovědnost. Pokud zpracování pravděpodobně povede k vysokému riziku, může být vyžadováno také posouzení vlivu na ochranu osobních údajů podle GDPR Article 35.

Společným jmenovatelem jsou důkazy. Regulační orgány a auditoři se neptají pouze na to, zda byla platforma šifrována, záplatována, skenována nebo testována. Ptají se, zda organizace dokáže prokázat, že bezpečnost, ochrana soukromí, rizika dodavatelů a odolnost byly součástí rozhodování od samého začátku.

Proto je projektové řízení podle ISO/IEC 27001:2022 tak účinné. Umožňuje organizaci řídit NIS2, DORA, GDPR, NIST CSF 2.0, smluvní povinnosti a programy ujištění zákazníků prostřednictvím jednoho opakovatelného procesu ISMS namísto několika odpojených kontrolních seznamů.

Páteř projektového řízení podle ISO 27001

ISO/IEC 27001:2022 bývá často nesprávně chápána jako pouhé certifikační cvičení. Pro ICT projekty má její provozní hodnota širší význam. Poskytuje páteř řízení pro změny v organizaci.

Kapitoly 4.1 až 4.4 vyžadují, aby organizace porozuměly interním a externím otázkám, zainteresovaným stranám, právním, regulačním a smluvním požadavkům, rozsahu ISMS, rozhraním a závislostem. V projektové praxi to znamená, že projektová charta má identifikovat dotčené služby, zákazníky, dodavatele, právní předpisy, obchodní procesy, osobní údaje, kritické činnosti a outsourcované služby.

Kapitoly 5.1 až 5.3 vyžadují závazek vedení, sladění s politikami, zdroje, integraci do obchodních procesů a přiřazené odpovědnosti. To je důležité, protože NIS2 i DORA staví kybernetickou bezpečnost a ICT rizika pod odpovědnost řídicích orgánů. Projekt, který mění kritickou zákaznickou platformu, se nemůže spoléhat na neformální bezpečnostní poznámku v chatovém vlákně. Potřebuje jasnou odpovědnost.

Kapitoly 6.1.1 až 6.1.3 vyžadují opakovatelný proces posouzení a ošetření rizik, kritéria rizik, vlastníky rizik, hodnocení důvěrnosti, integrity a dostupnosti, plány ošetření rizik, Prohlášení o použitelnosti a schválení zbytkového rizika. Právě zde se projektové riziko mění v auditní důkazy.

Kapitoly 7.1 až 7.5 vyžadují zdroje, kompetence, povědomí, komunikaci a řízení dokumentovaných informací. Tak se projektové záznamy stávají spolehlivými důkazy, nikoli rozptýlenými artefakty.

Kapitola 8.1 vyžaduje operativní plánování a řízení, dokumentované informace prokazující, že procesy byly provedeny podle plánu, řízení plánovaných změn, přezkum nezamýšlených změn, zmírnění nepříznivých dopadů a řízení externě poskytovaných procesů, produktů nebo služeb relevantních pro ISMS. Kapitoly 8.2 a 8.3 vyžadují posouzení a ošetření rizik bezpečnosti informací v plánovaných intervalech nebo při významných změnách.

Příloha A následně propojuje tento řídicí cyklus s praktickými opatřeními. Pro bezpečnost již od návrhu v ICT projektech jsou ústřední tři opatření ISO/IEC 27001:2022 Přílohy A:

Clarysec Zenith Blueprint: 30krokový plán auditora pojímá bezpečnost informací v projektovém řízení jako otázku řízení napříč všemi typy projektů, nikoli pouze jako záležitost vývoje softwaru:

„Jakýkoli projekt – migrace marketingového systému, stěhování budovy, redesign obchodního procesu, onboardingová platforma HR, dokonce i fúze nebo akvizice – může ovlivnit důvěrnost, integritu nebo dostupnost informací. A pokud k tomu dochází, bezpečnost musí mít místo u stolu.“

Stejná část vystihuje hlavní implementační poučení:

„Cílem tohoto opatření není zatížit projekty byrokracií. Cílem je zajistit, aby se s bezpečností pracovalo jako se vstupem návrhu, nikoli jako s testovací fází.“

Toto rozlišení odděluje formální soulad bez skutečného obsahu od obhajitelné bezpečnosti již od návrhu.

Jak vypadá bezpečnost již od návrhu uvnitř ICT projektu

Bezpečnost již od návrhu začíná dříve než první sprint, požadavek na nákup, architektonický diagram nebo migrační runbook. Klade jednoduchou otázku: co může tento projekt změnit na riziku?

Praktický model projektového řízení používá sedm důkazních bran.

Smyslem není byrokracie. Smyslem je zviditelnit bezpečnost tam, kde se projektová rozhodnutí skutečně dělají.

Clarysec Enterprise Politika informační bezpečnosti to vyjadřuje přímo:

„Správa a řízení bezpečnosti musí být integrována se správou a řízením podniku, projektovým řízením, nákupem a funkcemi právního dohledu tak, aby bezpečnost informací nebyla izolovaná, ale začleněná do rozhodování napříč obchodními procesy.“

Z části „Požadavky na správu a řízení“, ustanovení politiky 5.5.

Z projektových životních cyklů také činí otázku implementace:

„Životní cykly projektů (např. bezpečný vývoj, modelování hrozeb)“

Z části „Požadavky na implementaci politiky“, ustanovení politiky 6.3.1.1.

A stanoví auditní zásadu, kterou mnoho organizací objeví příliš pozdě:

„Všechna implementovaná opatření musí být auditovatelná, podložená dokumentovanými postupy a uchovávanými důkazy o provozu.“

Z části „Požadavky na implementaci politiky“, ustanovení politiky 6.6.1.

Jinými slovy, bezpečnostní práce, která není řízená, uchovaná a namapovaná, při auditu často neobstojí, i když technické týmy přijaly rozumná rozhodnutí.

Od modelování hrozeb k důkazům: praktický fintech příklad

Uvažujme projekt spuštění nového portálu pro onboarding zákazníků v EU pro fintech společnost. Portál shromažďuje doklady totožnosti, provádí biometrické ověření prostřednictvím třetí strany, ukládá stav onboardingu, integruje se s CRM, spouští zákaznická oznámení a předává data do skórování rizik.

Přístup založený na bezpečnosti již od návrhu by vytvářel důkazy průběžně s postupem projektu.

Nejprve založte záznam bezpečnostní klasifikace projektu. Určete, zda projekt ovlivňuje kritické nebo důležité funkce, osobní údaje, zvláštní kategorie osobních údajů, autentizaci, dostupnost pro zákazníky, outsourcované ICT služby, regulované reportovací procesy nebo komunikaci se zákazníky. Podle GDPR jsou biometrické údaje používané k jednoznačné identifikaci zvláštní kategorií osobních údajů, pokud se neuplatní konkrétní výjimka. To okamžitě zvyšuje požadovanou úroveň právní analýzy a ochranných opatření.

Za druhé vytvořte projektové posouzení rizik. Clarysec SME Politika řízení rizik činí řízení rizik součástí plánování, nikoli čtvrtletním cvičením v tabulkovém procesoru:

„1.2 Zajišťuje, že řízení rizik je aktivní součástí plánování, realizace projektu, výběru dodavatelů a reakce na incidenty, v souladu s ISO 27001, ISO 31000 a příslušnými regulačními požadavky.“

Z části „Účel“, ustanovení politiky 1.2.

Pro podniková prostředí Clarysec Enterprise Politika řízení rizik vymezuje rozsah napříč projektovou a technickou úrovní:

„Vztahuje se na rizika bezpečnosti informací na strategické, provozní, projektové a technické úrovni a je závazná pro veškerý personál, dodavatele a poskytovatele služeb zapojené do činností Systému řízení bezpečnosti informací (ISMS).“

Z části „Rozsah“, ustanovení politiky 2.3.

Za třetí proveďte modelování hrozeb před zahájením vývoje. Enterprise Politika bezpečného vývoje je výslovná:

„Všechny nové aplikace a významné změny musí před zahájením vývoje projít přezkumem bezpečnostní architektury a modelováním hrozeb.“

Z části „Požadavky na implementaci politiky“, ustanovení politiky 6.1.1.

U onboardingového portálu má model hrozeb pokrýt exponovaná rozhraní, toky identity, hranice oprávnění, scénáře zneužití API, podvržení webhooků, replay útoky, kompromitované přihlašovací údaje, cesty úniku dat, riziko závislostí, požadavky na protokolování, předpoklady zálohování, požadavky obnovy a režimy selhání poskytovatele.

Za čtvrté aktualizujte důkazy k ochraně soukromí. SME Politika ochrany dat a soukromí stanoví základní požadavek:

„5.3.1. Ochrana soukromí již od návrhu a ve výchozím nastavení musí být vynucována ve všech nových systémech a službách“

Z části „Požadavky na správu a řízení“, ustanovení politiky 5.3.1.

Projektový záznam má obsahovat účel, právní základ, roli správce nebo zpracovatele, rozhodnutí o minimalizaci údajů, pravidla uchovávání, přístupové role, volby šifrování, posouzení dopadů na subjekty údajů, požadavky na transparentnost, podmínky zpracovatele a postupy oznamování porušení zabezpečení osobních údajů.

Za páté zaznamenejte důkazy bezpečného vývoje. SME Politika bezpečného vývoje poskytuje stručný seznam důkazů vhodný pro malé a střední týmy:

„5.3 Generální ředitel (GM) musí vést záznamy o: 5.3.1 všech aktivních projektech vývoje softwaru a odpovědných vývojářích nebo dodavatelích 5.3.2 bezpečnostních kontrolních seznamech použitých pro každý projekt 5.3.3 provedených přezkumech kódu a osobách, které je provedly 5.3.4 výsledcích testování před nasazením 5.3.5 komponentách třetích stran a jejich souvisejícím licenčním nebo rizikovém stavu“

Z části „Požadavky na správu a řízení“, ustanovení politiky 5.3.

Za šesté řiďte nasazení jako změnu. SME Politika řízení změn stanoví:

„1.1 Tato politika zajišťuje, že všechny změny IT systémů, konfigurací, podnikových aplikací nebo cloudových služeb jsou před implementací naplánovány, posouzeny z hlediska rizik, otestovány a schváleny.“

Z části „Účel“, ustanovení politiky 1.1.

U onboardingového portálu má záznam změny obsahovat dotčené služby, posouzení rizik, výsledky testů, plán vrácení změny, plán monitorování, bezpečnostní schválení, schválení z hlediska ochrany soukromí, připravenost dodavatele, aktualizace eskalace incidentů a spouštěče komunikace se zákazníky.

Nakonec namapujte povinnosti. SME Politika právního a regulačního souladu poskytuje provozní pravidlo:

„5.2.2 Pokud se právní předpis vztahuje na více oblastí (např. GDPR se vztahuje na uchovávání, bezpečnost a ochranu soukromí), musí to být jasně namapováno v registru souladu a ve školicích materiálech.“

Z části „Požadavky na správu a řízení“, ustanovení politiky 5.2.2.

Tento registr souladu se stává mostem mezi opatřeními ISO/IEC 27001:2022, opatřeními NIS2 Article 21, povinnostmi DORA v oblasti ICT rizik, odpovědností podle GDPR a závazky ze zákaznických smluv.

Mapování jednoho projektového balíčku důkazů na NIS2, DORA, GDPR a NIST CSF 2.0

Nejúčinnější strategií souladu není duplikovat práci. Je jí namapovat jeden kvalitní soubor důkazů na více povinností.

Zenith Blueprint ve fázi Řízení rizik, kroku 14, doporučuje tento typ křížového odkazování:

„Pro každý právní předpis, pokud je použitelný, můžete vytvořit jednoduchou mapovací tabulku (například jako přílohu zprávy), která uvede klíčové bezpečnostní požadavky daného předpisu a odpovídající opatření/politiky ve vašem ISMS.“

Dodává, že je to užitečné, protože to auditorům a hodnotitelům ukazuje, „že bezpečnost neřídíte ve vakuu, ale se znalostí právního kontextu.“

Clarysec Zenith Controls: Průvodce křížovým souladem podporuje stejný integrovaný přístup mapováním opatření ISO/IEC 27001:2022 na další rámce, auditní očekávání a potřeby souladu. Pro řízení ICT projektů rámuje A.5.8, A.8.25 a A.8.32 jako preventivní kontroly, které chrání důvěrnost, integritu a dostupnost v oblastech správy a řízení, zabezpečení aplikací, ekosystému, ochrany a zabezpečení systémů a sítí.

Tato tabulka nenahrazuje právní analýzu. Je akcelerátorem řízení. Zajišťuje, že ředitel informační bezpečnosti, pověřenec pro ochranu osobních údajů, sponzor projektu, vedoucí nákupu, vlastník systému a interní auditor pracují se stejnými důkazy.

Do tohoto modelu přirozeně zapadá také NIST CSF 2.0. Jeho funkce GOVERN pomáhá organizacím stanovit politiky, role, ochotu podstupovat riziko, dohled a povědomí o právních nebo smluvních požadavcích. Funkce IDENTIFY, PROTECT, DETECT, RESPOND a RECOVER pomáhají týmům diskutovat o aktivech, dodavatelských službách, řízení přístupů, zabezpečení dat, zabezpečení platformy, bezpečném vývoji softwaru, monitorování, reakci na incidenty a obnově ve sdíleném provozním jazyce.

Jediný proces sladěný s ISO 27001 a soustředěný na Přílohu A.5.8 může vytvářet obhajitelné důkazy pro všechna tato očekávání.

Bezpečný vývoj je širší než psaní kódu

Mnoho selhání ICT projektů vzniká proto, že organizace považuje bezpečný vývoj za činnost, kterou vykonávají pouze vývojáři. V roce 2026 zahrnuje bezpečný vývoj také konfiguraci SaaS, automatizaci pracovních postupů, infrastrukturu jako kód, integrace API, pravidla identit, cloudové landing zóny, analytické pipeline, robotickou automatizaci procesů a low-code podnikové aplikace.

Zenith Blueprint ve fázi Opatření v praxi, kroku 20, se zabývá opatřením ISO/IEC 27002:2022 8.25 Životní cyklus bezpečného vývoje:

„Toto opatření se uplatní bez ohledu na to, zda píšete vlastní aplikace, konfigurujete platformy, jako jsou systémy ERP nebo CRM, upravujete pracovní postupy SaaS nebo spravujete prostředí infrastruktury jako kódu.“

Také vysvětluje, že bezpečnostní požadavky musí stát vedle funkčních požadavků a že modelování hrozeb pomáhá identifikovat exponované části systému, rizikové uživatelské role a datové toky vyžadující vyšší ochranu.

U moderního projektu mohou důkazy bezpečného vývoje zahrnovat:

• bezpečnostní požadavky navázané na obchodní požadavky,
• model hrozeb nebo přezkum bezpečnostní architektury,
• kontrolní seznam bezpečného kódování nebo bezpečné konfigurace,
• záznamy o přezkumu kódu nebo kolegiálním přezkoumání,
• evidenci komponent a stav rizik závislostí,
• rozhodnutí o správě tajemství,
• návrh řízení přístupů a zásady minimálních oprávnění,
• požadavky na protokolování a monitorování,
• výsledky skenů zranitelností a záznamy o nápravě,
• bezpečnostní testování předprodukčního prostředí,
• testování zálohování, obnovy a odolnosti tam, kde je relevantní,
• důkazy o schválení nasazení a plánu vrácení změny.

Cílem není nutit každý projekt do stejně těžkopádného procesu. Cílem je přiměřenost. Menší změna interního pracovního postupu nevyžaduje stejné důkazy jako migrace klíčové platební platformy. Každý projekt by však měl být klasifikován, posouzen z hlediska rizik a řízen podle dopadu.

Řízení změn chrání projekt před ním samotným

Nejrizikovějším okamžikem mnoha projektů není návrh ani kódování. Je jím nasazení.

Tým může provést modelování hrozeb, přezkum kódu, posouzení dodavatele i přezkum ochrany soukromí, a přesto způsobit výpadek nebo porušení zabezpečení uspěchanou produkční změnou. Ladicí příznak zůstane povolen. Pravidlo firewallu je širší, než bylo schváleno. Migrační skript zkopíruje osobní údaje do neprodukčního prostředí. Endpoint webhooku třetí strany je nasazen bez autentizace. Změna protokolování zaznamenává čísla dokladů totožnosti. Zálohovací úloha po přepnutí tiše selže.

Zenith Blueprint ve fázi Opatření v praxi, kroku 21, popisuje opatření ISO/IEC 27002:2022 8.32 Řízení změn přímo:

„Změna je nevyhnutelná, ale v kybernetické bezpečnosti je neřízená změna nebezpečná.“

Pokračuje:

„Ve svém jádru je účinné řízení změn opakovatelným pracovním postupem. Začíná jasným návrhem, který popisuje, co se mění, proč, kdy a jaká jsou potenciální rizika.“

Kvalitní záznam o ICT změně má odpovědět na tyto otázky:

• Jaký systém, služba, datový tok, dodavatel nebo konfigurace se mění?
• Která rizika byla identifikována a kdo je vlastní?
• Ovlivňuje změna osobní údaje, kritické služby, autentizaci, protokolování, zálohy nebo reakci na incidenty?
• Jaké bezpečnostní kontroly, kontroly ochrany soukromí, odolnosti a dodavatelů byly provedeny?
• Jaké testy byly dokončeny před nasazením?
• Jaké monitorování potvrdí očekávané chování?
• Jaký existuje plán vrácení změny nebo obnovy?
• Kdo schválil zbytkové riziko?
• Jaké důkazy budou uchovány?

Pro DORA to podporuje zdokumentované řízení ICT rizik, odolnost, kontinuitu, klasifikaci incidentů a získané poznatky. Pro NIS2 to podporuje opatření k řízení rizik, bezpečný vývoj, prevenci incidentů a kontinuitu. Pro GDPR to pomáhá doložit, že změny ovlivňující osobní údaje byly přezkoumány podle zásad účelu, minimalizace, uchovávání, přístupu a bezpečnosti.

Rozhodnutí o dodavatelích a cloudu musí být součástí návrhu projektu

V moderních ICT projektech je nejrizikovějším návrhovým rozhodnutím často „koupit“, nikoli „vyvinout“. Cloudové služby, poskytovatelé API, platformy pro ověřování identity, zpracovatelé plateb, dodavatelé analytiky, poskytovatelé řízených služeb a poskytovatelé řízených bezpečnostních služeb se stávají součástí rizikové plochy.

NIS2 výslovně zahrnuje zabezpečení dodavatelského řetězce, zranitelnosti přímých dodavatelů a poskytovatelů služeb, postupy kybernetické bezpečnosti dodavatelů, postupy bezpečného vývoje a výsledky koordinovaného posouzení rizik dodavatelského řetězce. DORA jde u finančních subjektů hlouběji. Vyžaduje řízení rizik třetích stran v oblasti ICT jako součást rámce řízení ICT rizik, pokračující odpovědnost i při outsourcingu ICT služeb, informační registry, posouzení před uzavřením smlouvy, analýzu rizika koncentrace, smluvní kontroly, práva na audit a inspekci, spouštěče ukončení a otestované výstupní strategie pro kritické nebo důležité funkce.

U onboardingového portálu nelze poskytovatele biometrického ověřování schválit jen proto, že se nákupu líbí cena a dokumentace API je kvalitní. Projekt potřebuje důkazy o bezpečnostní náležité péči, roli při zpracování, umístění dat, subdodavatelích, závazcích dostupnosti, podpoře při incidentech, právech na audit, podpoře při ukončení, proveditelnosti ukončení a monitorovacích povinnostech.

Ve vyspělém důkazním modelu jsou rozhodnutí o dodavatelích a cloudových službách součástí projektového balíčku důkazů, nikoli odpojené složky dodavatelů. Když se auditor zeptá, proč byla třetí strana přijata, odpověď má zahrnovat obchodní potřebu, posouzení rizik, smluvní ochranná opatření, přezkum ochrany údajů, dopad na odolnost a průběžné monitorování.

Jak budou auditoři přezkoumávat důkazy o bezpečnosti již od návrhu

Různí auditoři přistupují ke stejnému ICT projektu z různých úhlů. Certifikační auditor, interní auditor, hodnotitel DORA, příslušný orgán podle NIS2, auditor ochrany soukromí, hodnotitel orientovaný na NIST nebo auditor ve stylu COBIT či ISACA mohou požadovat podobné důkazy, ale interpretovat je odlišně.

Auditoři nechtějí krásnou projektovou prezentaci. Chtějí dohledatelnost. Chtějí vidět, že požadavky vedly k rizikům, rizika k opatřením, opatření k důkazům o implementaci a implementace k přezkumu.

Právě proto jsou Zenith Controls užitečné při přípravě na audit. Pomáhají týmům vysvětlit, proč jsou Příloha A.5.8, A.8.25 a A.8.32 preventivní kontroly, které chrání důvěrnost, integritu a dostupnost dříve, než předvídatelná selhání doputují do produkčního prostředí.

Minimální projektový balíček důkazů Clarysec

Silný balíček důkazů pro bezpečnost již od návrhu nemusí být rozsáhlý. Musí být konzistentní, přiměřený a namapovaný.

Pro ICT projekt se středním rizikem Clarysec obvykle doporučuje tento minimální balíček:

1. Záznam bezpečnostní klasifikace projektu
2. Poznámka k použitelnosti právních předpisů pokrývající NIS2, případně DORA, GDPR a smluvní povinnosti
3. Mapa datových toků a dopadu na aktiva
4. Projektové posouzení rizik a plán ošetření rizik
5. Model hrozeb nebo přezkum bezpečnostní architektury
6. Posouzení dodavatele a cloudové služby tam, kde je použitelné
7. Kontrolní seznam bezpečného vývoje nebo konfigurace
8. Výsledky bezpečnostních testů a důkazy o nápravě
9. Schválení změny s plánem vrácení změny a monitorování
10. Záznam ochrany soukromí již od návrhu, včetně právního základu a uchovávání tam, kde se zpracovávají osobní údaje
11. Aktualizace reakce na incidenty a monitorování
12. Přezkum po implementaci a získané poznatky
13. Mapování registru souladu na opatření a povinnosti

Zenith Blueprint poskytuje logiku roadmapy. Krok 22 přináší bezpečnost informací do všech fází projektu. Krok 20 začleňuje bezpečný vývoj do plánování, návrhu, kódu, testování a nasazení. Krok 21 činí řízení změn strukturovaným, dohledatelným a přezkoumatelným. Krok 14 doporučuje křížové odkazování GDPR, NIS2, DORA a dalších povinností, aby požadavky na soulad nezapadly mezi organizační mezery.

Politiky poskytují provozní pravidla. Politika informační bezpečnosti integruje bezpečnost s projektovým řízením, nákupem a právním dohledem. Politika řízení rizik činí projektová rizika součástí činnosti ISMS. Politika bezpečného vývoje vyžaduje modelování hrozeb. Politika řízení změn vyžaduje plánované, z hlediska rizik posouzené, otestované a schválené změny. Politika ochrany dat a soukromí vyžaduje ochranu soukromí již od návrhu a ve výchozím nastavení. Politika právního a regulačního souladu vyžaduje, aby předpisy zasahující více oblastí byly namapovány v registru souladu.

Společně tyto nástroje mění bezpečnost již od návrhu z ambice na auditovatelný provozní model.

Časté vzorce selhání v ICT projektech

Selhání jsou obvykle předvídatelná.

Prvním je pozdní zapojení bezpečnosti. Bezpečnostní přezkumy probíhají až poté, co je architektura pevně daná, smlouvy podepsané a termíny dodání veřejně oznámené. V tu chvíli se bezpečnost stává blokátorem, nikoli vstupem návrhu.

Druhým jsou roztříštěné důkazy. Projekt má výsledky testů v jednom nástroji, přezkum dodavatele v jiném, komentáře k ochraně soukromí v e-mailu, přijetí rizika v zápisu ze schůzky a schválení změny v ticketu. Žádné jednotné vlákno neprokazuje řízení a dohled.

Třetím jsou slepá místa u dodavatelů. Projekt spoléhá na cloudovou službu nebo poskytovatele API, ale nikdo neověří subdodavatele, umístění dat, práva na audit, podporu při incidentech, plány ukončení ani riziko koncentrace.

Čtvrtým je posun v ochraně soukromí. Systém vytvořený pro jeden účel začne podporovat analytiku, experimenty s AI, marketingové exporty nebo provozní monitorování, aniž by se znovu přezkoumal právní základ, transparentnost, minimalizace nebo uchovávání.

Pátým je nepřezkoumaná změna. Nasazení do produkčního prostředí je schváleno z hlediska funkcionality, ale není posouzeno z hlediska přístupu, protokolování, šifrování, zálohování, odolnosti, osobních údajů nebo dopadu na oznamování.

Šestým je slabý dohled vedení. Projektová rizika s vysokým dopadem jsou přijímána na příliš nízké úrovni a chybí důkazy, že odpovědný vlastník rizika pochopil regulační důsledky.

Tyto problémy se nevyřeší nákupem dalšího skeneru. Řeší se integrací správy a řízení bezpečnosti do způsobu, jakým jsou projekty navrhovány, projektovány, pořizovány, budovány, testovány, měněny a přezkoumávány.

Shrnutí pro ředitele informační bezpečnosti pro rok 2026

Bezpečnost již od návrhu v ICT projektech je nyní tématem pro řídicí orgány, audit i regulační orgány. NIS2 činí řízení kybernetických rizik otázkou řídicího orgánu. DORA činí ICT rizika, testování odolnosti, řízení incidentů a dohled nad třetími stranami strukturovanou povinností finančního sektoru. GDPR vyžaduje odpovědnost za zpracování osobních údajů a odpovídající bezpečnost. ISO/IEC 27001:2022 poskytuje strukturu systému řízení, která tyto povinnosti převádí do provozu.

Pro ředitele informační bezpečnosti je příležitostí přestat bojovat s projektovými týmy na konci dodávky. Vložte bezpečnost do zahájení, požadavků, návrhu, výběru dodavatelů, vývoje, testování, schválení změny a přezkumu po implementaci.

Pro manažery souladu je příležitostí nahradit roztříštěné důkazy jedním namapovaným projektovým balíčkem důkazů.

Pro auditory je příležitostí testovat životní cyklus projektu, nikoli jen finální systém.

Pro vlastníky obchodních procesů je příležitostí rychlejší a bezpečnější dodávka. Bezpečnost již od návrhu snižuje přepracování, předchází překvapením v oblasti souladu, zlepšuje rozhodování o dodavatelích a dává vedení obhajitelný rizikový příběh.

Pokud se vaše ICT projekty pohybují rychleji než váš důkazní model, začněte jedním pilotním projektem. Použijte Clarysec Zenith Blueprint k definování projektových bezpečnostních bran, uplatněte politiky Clarysec pro řízení rizik, bezpečný vývoj, řízení změn a ochranu soukromí a použijte Zenith Controls k namapování projektového řízení podle ISO/IEC 27001:2022 na NIS2, DORA, GDPR a NIST CSF 2.0.

Clarysec vám může pomoci vytvořit opakovaně použitelný projektový balíček důkazů pro bezpečnost již od návrhu, sladit jej s vaším ISMS a připravit jej pro interní audit, certifikační audit, připravenost na DORA, řízení podle NIS2 a odpovědnost podle GDPR.

Začněte u svého příštího významného ICT projektu. Pokud mění systémy, dodavatele, data, přístup, odolnost nebo důvěru zákazníků, zaslouží si bezpečnost již od návrhu od prvního dne.