Upravljanje IKT projektima prema načelu sigurnosti po dizajnu u 2026.

Projekt je bio na vrijeme, sve dok revizija nije postavila jedno pitanje

CISO brzorastuće tvrtke za platne tehnologije imao je dobre vijesti za upravu. Nova platforma za uvođenje klijenata bila je spremna za lansiranje. Produktni tim isporučio je mobilno korisničko iskustvo, inženjering je integrirao provjeru identiteta, pravni tim potpisao je ugovore s pružateljima usluga u oblaku i pružateljima API-ja, a operacije su uvježbale plan puštanja u produkciju.

Zatim je interni revizor postavio jednostavno pitanje:

„Pokažite mi gdje su sigurnost i privatnost razmatrane u svakoj fazi projekta.”

Projektna soba je utihnula.

Postojalo je izvješće o penetracijskom testiranju, ali testiranje je provedeno kasno. Postojao je dijagram arhitekture oblaka, ali nije bilo dokaza da su tokovi podataka pregledani u odnosu na načela GDPR. Postojao je upitnik za dubinsku analizu dobavljača, ali nije bio povezan s registrom rizika. Postojala je prijava promjene za uvođenje u produkcijsko okruženje, ali odobrenje nije spominjalo utjecaj na kritične usluge, prijavljivanje incidenata, testiranje otpornosti, obavješćivanje klijenata ili eskalaciju povrede osobnih podataka. Postojale su bilješke sa sprintova, ali su sigurnosni zahtjevi bili raspršeni po korisničkim pričama i porukama u chatu.

Ništa nije očito upućivalo na nemar. Sve je izgledalo kao užurban moderan IKT projekt. No za financijski subjekt na koji se primjenjuje DORA, SaaS pružatelja koji potencijalno ulazi u opseg NIS2 i voditelja obrade ili izvršitelja obrade prema GDPR, pitanje više nije bilo samo postoji li sigurnost. Pitanje je bilo može li se sigurnost po dizajnu dokazati.

To je problem 2026. godine. IKT projekti više se ne ocjenjuju samo prema brzini isporuke, kontroli troškova i tehničkoj kvaliteti. Ocjenjuju se prema dokazima upravljanja: procjenama rizika, odlukama o dizajnu, dubinskoj analizi dobavljača, zapisima sigurnog razvoja, odobrenjima promjena, odlukama o privatnosti, rezultatima testiranja i nadzoru upravljačkog tijela.

ISO/IEC 27001:2022 organizacijama daje praktičnu okosnicu sustava upravljanja za rješavanje tog problema. Pomaže CISO-ima, rukovoditeljima usklađenosti, sponzorima projekata, službenicima za zaštitu podataka, arhitektima, timovima nabave i revizorima pretvoriti značajne IKT projekte u provjerljive dokaze sigurnosti po dizajnu.

Zašto je upravljanje IKT projektima sada pitanje regulatornih dokaza

Migracija u oblak, portal za klijente, platna platforma, implementacija CRM-a, promjena pružatelja usluge identiteta, analitički cjevovod, API integracija, SaaS tijek rada, low-code aplikacija ili prijelaz na upravljanu uslugu mogu promijeniti profil rizika organizacije. U 2026. te se promjene događaju pod preklapajućim obvezama.

NIS2 se široko primjenjuje na ključne i važne subjekte u sektorima iz Annex I i Annex II, uključujući digitalnu infrastrukturu, pružatelje upravljanih usluga, pružatelje upravljanih sigurnosnih usluga i digitalne pružatelje. NIS2 Article 20 čini upravljačka tijela odgovornima za odobravanje mjera upravljanja rizicima kibernetičke sigurnosti i nadzor njihove provedbe. NIS2 Article 21 zahtijeva odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere za upravljanje rizicima, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, sigurnu nabavu, siguran razvoj, postupanje s ranjivostima, procjenu učinkovitosti, kibernetičku higijenu, kriptografiju, kontrolu pristupa, upravljanje imovinom i sigurne komunikacije.

DORA se primjenjuje na financijske subjekte i usmjerena je na digitalnu operativnu otpornost. DORA Article 5 dodjeljuje odgovornost za upravljanje IKT rizicima upravljačkom tijelu. DORA Article 6 zahtijeva pouzdan, sveobuhvatan i dobro dokumentiran okvir za upravljanje IKT rizicima. DORA obuhvaća i prijavljivanje incidenata povezanih s IKT-om, testiranje operativne otpornosti, IKT neprekidnost poslovanja, odgovor i oporavak, razmjenu obavještajnih podataka o kibernetičkim prijetnjama, upravljanje rizicima trećih strana u području IKT-a, ugovorne aranžmane i nadzor kritičnih pružatelja IKT usluga trećih strana.

GDPR dodaje sloj odgovornosti za osobne podatke. GDPR Article 25 zahtijeva ugrađenu i zadanu zaštitu podataka. Voditelji obrade moraju moći dokazati usklađenost s načelima kao što su zakonitost, poštenost, transparentnost, ograničenje svrhe, minimizacija podataka, ograničenje pohrane, cjelovitost, povjerljivost i odgovornost. Kada je vjerojatno da će obrada prouzročiti visok rizik, može biti potrebna i procjena učinka na zaštitu podataka prema GDPR Article 35.

Zajednički nazivnik su dokazi. Regulatori i revizori ne pitaju samo je li platforma bila šifrirana, zakrpana, skenirana ili testirana. Pitaju može li organizacija pokazati da su sigurnost, privatnost, rizik dobavljača i otpornost bili dio odlučivanja od početka.

Zato je upravljanje projektima prema ISO/IEC 27001:2022 toliko snažno. Organizaciji omogućuje upravljanje NIS2, DORA, GDPR, NIST CSF 2.0, ugovornim obvezama i programima dokazivanja sigurnosti prema zahtjevima klijenata kroz jedan ponovljiv ISMS proces, umjesto kroz više nepovezanih kontrolnih popisa.

Okosnica upravljanja projektima prema ISO 27001

ISO/IEC 27001:2022 često se pogrešno shvaća kao certifikacijska vježba. Za IKT projekte njegova je operativna vrijednost šira. Daje okosnicu upravljanja poslovnim promjenama.

Točke 4.1 do 4.4 zahtijevaju da organizacije razumiju unutarnja i vanjska pitanja, zainteresirane strane, pravne, regulatorne i ugovorne zahtjeve, opseg ISMS-a, sučelja i ovisnosti. U projektnim terminima to znači da projektna povelja treba utvrditi zahvaćene usluge, klijente, dobavljače, propise, poslovne procese, osobne podatke, kritične operacije i eksternalizirane usluge.

Točke 5.1 do 5.3 zahtijevaju predanost vodstva, usklađenost s politikama, resurse, integraciju u poslovne procese i dodijeljene odgovornosti. To je važno jer NIS2 i DORA stavljaju kibernetičku sigurnost i IKT rizik pod odgovornost upravljačkog tijela. Projekt koji mijenja kritičnu platformu za klijente ne može se osloniti na neformalni sigurnosni komentar u niti razgovora. Potrebna mu je jasna odgovornost.

Točke 6.1.1 do 6.1.3 zahtijevaju ponovljiv proces procjene i obrade rizika, kriterije rizika, vlasnike rizika, vrednovanje povjerljivosti, cjelovitosti i dostupnosti, planove obrade rizika, Izjavu o primjenjivosti i odobrenje preostalog rizika. Tu projektni rizik postaje revizijski dokaz.

Točke 7.1 do 7.5 zahtijevaju resurse, kompetencije, svijest, komunikaciju i kontrolu dokumentiranih informacija. Tako projektni zapisi postaju pouzdani dokazi, a ne raspršeni artefakti.

Točka 8.1 zahtijeva operativno planiranje i kontrolu, dokumentirane informacije koje pokazuju da su procesi provedeni kako je planirano, kontrolu planiranih promjena, pregled neželjenih promjena, ublažavanje štetnih učinaka i kontrolu eksterno pruženih procesa, proizvoda ili usluga relevantnih za ISMS. Točke 8.2 i 8.3 zahtijevaju procjene i obradu rizika informacijske sigurnosti u planiranim intervalima ili kada nastupe značajne promjene.

Prilog A zatim povezuje taj ciklus upravljanja s praktičnim kontrolama. Za sigurnost po dizajnu u IKT projektima središnje su tri kontrole iz ISO/IEC 27001:2022 Prilog A:

Clarysecov Zenith Blueprint: Revizorov plan u 30 koraka tretira informacijsku sigurnost u upravljanju projektima kao pitanje upravljanja u svim vrstama projekata, ne samo u razvoju softvera:

„Svaki projekt, migracija marketinškog sustava, preseljenje zgrade, redizajn poslovnog procesa, HR platforma za uvođenje zaposlenika, pa čak i spajanje ili preuzimanje, može utjecati na povjerljivost, cjelovitost ili dostupnost informacija. Kada se to dogodi, sigurnost mora imati mjesto za stolom.”

Isti odjeljak sažima ključnu lekciju implementacije:

„Cilj ove kontrole nije opteretiti projekte birokracijom. Cilj je osigurati da se sigurnost tretira kao ulazni element dizajna, a ne kao faza testiranja.”

Ta razlika odvaja privid usklađenosti od dokazive sigurnosti po dizajnu.

Kako sigurnost po dizajnu izgleda unutar IKT projekta

Sigurnost po dizajnu počinje prije prvog sprinta, zahtjeva za nabavu, arhitekturnog dijagrama ili operativnih uputa za migraciju. Postavlja jednostavno pitanje: što bi ovaj projekt mogao promijeniti u pogledu rizika?

Praktičan model upravljanja projektom koristi sedam dokaznih kontrolnih točaka.

Poanta nije birokracija. Poanta je učiniti sigurnost vidljivom ondje gdje se projektne odluke stvarno donose.

Clarysec Enterprise Politika informacijske sigurnosti to izravno izražava:

„Upravljanje sigurnošću mora biti integrirano s korporativnim upravljanjem, upravljanjem projektima, nabavom i funkcijama pravnog nadzora kako informacijska sigurnost ne bi bila izolirana, nego ugrađena u donošenje poslovnih odluka.”

Iz odjeljka „Zahtjevi upravljanja”, točka politike 5.5.

Također postavlja životne cikluse projekata kao pitanje implementacije:

„Životni ciklusi projekata (npr. siguran razvoj, modeliranje prijetnji)”

Iz odjeljka „Zahtjevi za provedbu politike”, točka politike 6.3.1.1.

I navodi revizijsko načelo koje mnoge organizacije otkriju prekasno:

„Sve implementirane kontrole moraju biti prikladne za reviziju, poduprte dokumentiranim postupcima i zadržanim dokazima o operativnom djelovanju.”

Iz odjeljka „Zahtjevi za provedbu politike”, točka politike 6.6.1.

Drugim riječima, sigurnosni rad koji nije uređen, zadržan i mapiran često neće proći reviziju, čak i ako su tehnički timovi donijeli razumne odluke.

Od modeliranja prijetnji do dokaza: praktičan fintech primjer

Razmotrite projekt pokretanja novog portala za uvođenje klijenata u EU za fintech društvo. Portal prikuplja identifikacijske dokumente, provodi biometrijsku provjeru putem treće strane, pohranjuje status uvođenja, integrira se s CRM-om, pokreće obavijesti klijentima i puni sustav bodovanja rizika.

Pristup sigurnosti po dizajnu gradio bi dokaze kako projekt napreduje.

Prvo, otvorite zapis sigurnosne klasifikacije projekta. Utvrdite utječe li projekt na kritične ili važne funkcije, osobne podatke, posebne kategorije osobnih podataka, autentifikaciju, dostupnost sustava dostupnih klijentima, eksternalizirane IKT usluge, regulirane procese izvješćivanja ili komunikaciju s klijentima. Prema GDPR, biometrijski podaci koji se koriste za jedinstvenu identifikaciju posebna su kategorija osobnih podataka, osim ako se primjenjuje posebno izuzeće. Time se odmah podiže potrebna razina pravne analize i zaštitnih mjera.

Drugo, izradite procjenu rizika projekta. Clarysec SME Politika upravljanja rizicima čini upravljanje rizicima dijelom planiranja, a ne tromjesečnom vježbom u proračunskoj tablici:

„1.2 Osigurava da je upravljanje rizicima aktivna sastavnica planiranja, provedbe projekta, odabira dobavljača i odgovora na incidente, u skladu s ISO 27001, ISO 31000 i primjenjivim regulatornim zahtjevima.”

Iz odjeljka „Svrha”, točka politike 1.2.

Za poslovna okruženja, Clarysec Enterprise Politika upravljanja rizicima definira opseg na projektnoj i tehničkoj razini:

„Obuhvaća rizike informacijske sigurnosti na strateškoj, operativnoj, projektnoj i tehničkoj razini te je obvezna za svo osoblje, izvođače i pružatelje usluga uključene u aktivnosti sustava upravljanja informacijskom sigurnošću (ISMS).”

Iz odjeljka „Opseg”, točka politike 2.3.

Treće, provedite model prijetnji prije početka razvoja. Enterprise Politika sigurnog razvoja izričita je:

„Sve nove aplikacije i značajne promjene moraju proći pregled sigurne arhitekture i modeliranje prijetnji prije početka razvoja.”

Iz odjeljka „Zahtjevi za provedbu politike”, točka politike 6.1.1.

Za portal za uvođenje klijenata, model prijetnji treba obuhvatiti izložena sučelja, tokove identiteta, granice privilegija, slučajeve zlouporabe API-ja, lažiranje webhooka, replay napade, kompromitirane vjerodajnice, putove curenja podataka, rizik ovisnosti, zahtjeve zapisivanja događaja, pretpostavke sigurnosnog kopiranja, zahtjeve oporavka i načine otkaza pružatelja usluge.

Četvrto, ažurirajte dokaze o privatnosti. SME Politika zaštite podataka i privatnosti postavlja polaznu osnovu:

„5.3.1. Ugrađena i zadana zaštita privatnosti mora se provoditi u svim novim sustavima i uslugama”

Iz odjeljka „Zahtjevi upravljanja”, točka politike 5.3.1.

Projektni zapis treba uključivati svrhu, pravnu osnovu, ulogu voditelja obrade ili izvršitelja obrade, odluke o minimizaciji podataka, pravila zadržavanja, uloge pristupa, odabire šifriranja, razmatranja utjecaja na ispitanike, zahtjeve transparentnosti, uvjete za izvršitelje obrade i putove prijave povrede osobnih podataka.

Peto, evidentirajte dokaze sigurnog razvoja. SME Politika sigurnog razvoja daje sažet popis dokaza primjenjiv na male i srednje timove:

„5.3 Glavni direktor (GM) mora održavati zapise o: 5.3.1 svim aktivnim projektima razvoja softvera i odgovornim razvojnim inženjerima ili dobavljačima 5.3.2 sigurnosnim kontrolnim popisima korištenima za svaki projekt 5.3.3 provedenim pregledima koda i osobama koje su ih provele 5.3.4 rezultatima testiranja prije uvođenja 5.3.5 komponentama trećih strana i njihovu povezanom licencnom statusu ili statusu rizika”

Iz odjeljka „Zahtjevi upravljanja”, točka politike 5.3.

Šesto, kontrolirajte uvođenje kao promjenu. SME Politika upravljanja promjenama navodi:

„1.1 Ova politika osigurava da se sve promjene IT sustava, konfiguracija, poslovnih aplikacija ili usluga u oblaku planiraju, procjenjuju prema riziku, testiraju i odobre prije implementacije.”

Iz odjeljka „Svrha”, točka politike 1.1.

Za portal za uvođenje klijenata prijava promjene treba uključivati zahvaćene usluge, procjenu rizika, rezultate testiranja, plan povrata, plan praćenja, sigurnosna odobrenja, odobrenje privatnosti, spremnost dobavljača, ažuriranja eskalacije incidenata i okidače komunikacije s klijentima.

Na kraju, mapirajte obveze. SME Politika pravne i regulatorne usklađenosti daje operativno pravilo:

„5.2.2 Kada se propis primjenjuje na više područja (npr. GDPR se primjenjuje na zadržavanje, sigurnost i privatnost), to mora biti jasno mapirano u Registru usklađenosti i materijalima za obuku.”

Iz odjeljka „Zahtjevi upravljanja”, točka politike 5.2.2.

Taj Registar usklađenosti postaje most između kontrola ISO/IEC 27001:2022, mjera iz NIS2 Article 21, obveza IKT rizika prema DORA, odgovornosti prema GDPR i ugovornih obveza prema klijentima.

Mapiranje jednog paketa projektnih dokaza na NIS2, DORA, GDPR i NIST CSF 2.0

Najučinkovitija strategija usklađenosti nije dupliciranje posla. To je mapiranje jednog kvalitetnog skupa dokaza na više obveza.

Zenith Blueprint, u fazi upravljanja rizicima, Step 14, preporučuje ovu vrstu unakrsnog referenciranja:

„Za svaki propis, ako je primjenjivo, možete izraditi jednostavnu tablicu mapiranja (može biti prilog izvješću) koja navodi ključne sigurnosne zahtjeve propisa i odgovarajuće kontrole/politike u vašem ISMS-u.”

Dodaje da je to korisno jer revizorima i procjeniteljima pokazuje „da sigurnošću ne upravljate u vakuumu, nego ste svjesni pravnog konteksta.”

Clarysecov Zenith Controls: Vodič za višestruku usklađenost podržava isti integrirani pristup mapiranjem kontrola ISO/IEC 27001:2022 na druge okvire, revizijska očekivanja i potrebe usklađenosti. Za upravljanje IKT projektima, A.5.8, A.8.25 i A.8.32 postavlja kao preventivne kontrole koje štite povjerljivost, cjelovitost i dostupnost u područjima upravljanja, sigurnosti aplikacija, ekosustava, zaštite te sigurnosti sustava i mreža.

Ova tablica nije zamjena za pravnu analizu. Ona je akcelerator upravljanja. Osigurava da CISO, DPO, sponzor projekta, voditelj nabave, vlasnik sustava i interni revizor gledaju iste dokaze.

NIST CSF 2.0 također se prirodno uklapa u ovaj model. Njegova funkcija GOVERN pomaže organizacijama uspostaviti politike, uloge, apetit za rizik, nadzor i svijest o pravnim ili ugovornim obvezama. Njegove funkcije IDENTIFY, PROTECT, DETECT, RESPOND i RECOVER pomažu timovima raspravljati o imovini, uslugama dobavljača, kontroli pristupa, sigurnosti podataka, sigurnosti platforme, sigurnom razvoju softvera, praćenju, odgovoru na incidente i oporavku zajedničkim operativnim jezikom.

Jedinstveni proces usklađen s ISO 27001, usredotočen na Prilog A.5.8, može generirati provjerljive dokaze za sva ta očekivanja.

Siguran razvoj širi je od pisanja koda

Mnogi neuspjesi IKT projekata nastaju zato što organizacija siguran razvoj tretira kao nešto što rade samo razvojni inženjeri. U 2026. siguran razvoj obuhvaća i SaaS konfiguraciju, automatizaciju tijekova rada, infrastrukturu kao kod, API integracije, pravila identiteta, cloud landing zone, analitičke cjevovode, robotsku automatizaciju procesa i low-code poslovne aplikacije.

Zenith Blueprint, u fazi Kontrole u praksi, Step 20, obrađuje kontrolu ISO/IEC 27002:2022 8.25 Secure Development Life Cycle:

„Ova se kontrola primjenjuje neovisno o tome pišete li vlastite aplikacije, konfigurirate platforme poput ERP ili CRM sustava, prilagođavate SaaS radne tokove ili upravljate okruženjima infrastrukture kao koda.”

Također objašnjava da sigurnosni zahtjevi moraju stajati uz funkcionalne zahtjeve i da modeliranje prijetnji pomaže identificirati izložene dijelove sustava, rizične korisničke uloge i tokove podataka koji zahtijevaju višu razinu zaštite.

Za moderan projekt dokazi sigurnog razvoja mogu uključivati:

• Sigurnosne zahtjeve povezane s poslovnim zahtjevima
• Model prijetnji ili pregled sigurne arhitekture
• Kontrolni popis sigurnog kodiranja ili sigurne konfiguracije
• Zapise pregleda koda ili stručnog pregleda
• Popis komponenti i status rizika ovisnosti
• Odluke o upravljanju tajnama
• Dizajn kontrole pristupa i načela najmanjih ovlasti
• Zahtjeve za zapisivanje događaja i praćenje
• Rezultate skeniranja ranjivosti i zapise korektivnih radnji
• Sigurnosno testiranje prije produkcije
• Testiranje sigurnosnog kopiranja, oporavka i otpornosti gdje je relevantno
• Dokaze odobrenja uvođenja i povrata

Cilj nije prisiliti svaki projekt kroz isti opsežan proces. Cilj je razmjernost. Manja interna promjena tijeka rada ne zahtijeva iste dokaze kao migracija temeljne platne platforme. No svaki projekt treba biti klasificiran, procijenjen prema riziku i vođen u skladu s utjecajem.

Upravljanje promjenama štiti projekt od njega samog

Najrizičniji trenutak u mnogim projektima nije dizajn ni kodiranje. To je uvođenje.

Tim može provesti modeliranje prijetnji, pregled koda, procjenu dobavljača i pregled privatnosti, a zatim ipak prouzročiti prekid usluge ili povredu zbog užurbane produkcijske promjene. Debug zastavica ostaje uključena. Pravilo vatrozida šire je od odobrenog. Migracijska skripta kopira osobne podatke u neprodukcijsko okruženje. Webhook krajnja točka treće strane uvodi se bez autentifikacije. Promjena zapisivanja događaja bilježi brojeve identifikacijskih dokumenata. Posao sigurnosnog kopiranja tiho ne uspije nakon prelaska.

Zenith Blueprint, u fazi Kontrole u praksi, Step 21, opisuje kontrolu ISO/IEC 27002:2022 8.32 Change Management izravno:

„Promjena je neizbježna, ali u kibernetičkoj sigurnosti nekontrolirana promjena je opasna.”

Nastavlja:

„U svojoj biti, učinkovito upravljanje promjenama ponovljiv je radni tok. Počinje jasnim prijedlogom koji opisuje što se mijenja, zašto, kada i koji su mogući rizici.”

Snažan zapis IKT promjene treba odgovoriti na sljedeće:

• Koji se sustav, usluga, tok podataka, dobavljač ili konfiguracija mijenja?
• Koji su rizici identificirani i tko je njihov vlasnik?
• Utječe li promjena na osobne podatke, kritične usluge, autentifikaciju, zapisivanje događaja, sigurnosne kopije ili odgovor na incidente?
• Koje su sigurnosne provjere, provjere privatnosti, otpornosti i dobavljača provedene?
• Koja su testiranja dovršena prije uvođenja?
• Koje će praćenje potvrditi očekivano ponašanje?
• Koji plan povrata ili oporavka postoji?
• Tko je odobrio preostali rizik?
• Koji će se dokazi zadržati?

Za DORA to podržava dokumentirano upravljanje IKT rizicima, otpornost, kontinuitet, klasifikaciju incidenata i naučene lekcije. Za NIS2 podržava mjere upravljanja rizicima, siguran razvoj, sprječavanje incidenata i kontinuitet. Za GDPR pomaže dokazati da su promjene koje utječu na osobne podatke pregledane u odnosu na načela svrhe, minimizacije, zadržavanja, pristupa i sigurnosti.

Odluke o dobavljačima i oblaku moraju biti dio dizajna projekta

U modernim IKT projektima najrizičnija odluka o dizajnu često je „kupiti”, a ne „izgraditi”. Usluge u oblaku, pružatelji API-ja, platforme za provjeru identiteta, procesori plaćanja, analitički dobavljači, pružatelji upravljanih usluga i pružatelji upravljanih sigurnosnih usluga postaju dio površine rizika.

NIS2 izričito uključuje sigurnost opskrbnog lanca, ranjivosti izravnih dobavljača i pružatelja usluga, prakse kibernetičke sigurnosti dobavljača, postupke sigurnog razvoja i rezultate koordiniranih procjena rizika opskrbnog lanca. DORA ide dublje za financijske subjekte. Zahtijeva upravljanje rizicima IKT trećih strana kao dio okvira za upravljanje IKT rizicima, stalnu odgovornost čak i kada su IKT usluge povjerene vanjskim pružateljima, registre informacija, procjene prije sklapanja ugovora, analizu rizika koncentracije, ugovorne kontrole, prava na reviziju i inspekciju, okidače za raskid i testirane izlazne strategije za kritične ili važne funkcije.

Za portal za uvođenje klijenata pružatelj biometrijske provjere ne može biti odobren samo zato što nabava prihvaća cijenu i API dokumentacija je dobra. Projekt treba dokaze o sigurnosnoj dubinskoj analizi, ulozi u obradi, lokaciji podataka, podizvršiteljima, obvezama dostupnosti, podršci za incidente, pravima na reviziju, pomoći pri raskidu, izvedivosti izlaska i obvezama praćenja.

U zrelom modelu dokaza odluke o dobavljačima i oblaku nalaze se unutar paketa projektnih dokaza, a ne u nepovezanoj mapi dobavljača. Kada revizor pita zašto je treća strana prihvaćena, odgovor treba uključivati poslovnu potrebu, procjenu rizika, ugovorne zaštitne mjere, pregled zaštite podataka, utjecaj na otpornost i kontinuirano praćenje.

Kako će revizori pregledavati dokaze sigurnosti po dizajnu

Različiti revizori pristupaju istom IKT projektu iz različitih kutova. Certifikacijski revizor, interni revizor, DORA pregledavatelj, nadležno tijelo za NIS2, revizor privatnosti, procjenitelj usmjeren na NIST ili revizor u COBIT/ISACA stilu mogu tražiti slične dokaze, ali ih tumačiti drukčije.

Revizori ne žele lijepu projektnu prezentaciju. Žele sljedivost. Žele vidjeti da su zahtjevi doveli do rizika, rizici do kontrola, kontrole do dokaza implementacije, a implementacija do pregleda.

Zato je Zenith Controls koristan u pripremi za reviziju. Pomaže timovima objasniti zašto su Prilog A.5.8, A.8.25 i A.8.32 preventivne kontrole koje štite povjerljivost, cjelovitost i dostupnost prije nego što predvidivi neuspjesi dođu do produkcije.

Minimalni Clarysec paket projektnih dokaza

Snažan paket dokaza za sigurnost po dizajnu ne mora biti golem. Mora biti dosljedan, razmjeran i mapiran.

Za IKT projekt srednjeg rizika Clarysec obično preporučuje sljedeći minimalni paket:

1. Zapis sigurnosne klasifikacije projekta
2. Bilješka o primjenjivosti propisa koja obuhvaća NIS2, DORA gdje je relevantno, GDPR i ugovorne obveze
3. Mapa toka podataka i utjecaja na imovinu
4. Procjena rizika projekta i plan obrade rizika
5. Model prijetnji ili pregled sigurne arhitekture
6. Procjena dobavljača i usluga u oblaku gdje je primjenjivo
7. Kontrolni popis sigurnog razvoja ili kontrolni popis konfiguracije
8. Rezultati sigurnosnog testiranja i dokazi korektivnih radnji
9. Odobrenje promjene s planom povrata i praćenja
10. Zapis ugrađene zaštite privatnosti, uključujući pravnu osnovu i zadržavanje kada su uključeni osobni podaci
11. Ažuriranja odgovora na incidente i praćenja
12. Postimplementacijski pregled i naučene lekcije
13. Mapiranje Registra usklađenosti na kontrole i obveze

Zenith Blueprint daje logiku plana. Step 22 uvodi informacijsku sigurnost u sve faze projekta. Step 20 ugrađuje siguran razvoj u planiranje, dizajn, kod, testiranje i uvođenje. Step 21 čini upravljanje promjenama strukturiranim, sljedivim i pregledljivim. Step 14 preporučuje unakrsno referenciranje GDPR, NIS2, DORA i drugih obveza kako zahtjevi usklađenosti ne bi propali kroz pukotine.

Politike daju operativna pravila. Politika informacijske sigurnosti integrira sigurnost s upravljanjem projektima, nabavom i pravnim nadzorom. Politika upravljanja rizicima čini projektne rizike dijelom ISMS aktivnosti. Politika sigurnog razvoja zahtijeva modeliranje prijetnji. Politika upravljanja promjenama zahtijeva planirane, procijenjene prema riziku, testirane i odobrene promjene. Politika zaštite podataka i privatnosti zahtijeva ugrađenu i zadanu zaštitu privatnosti. Politika pravne i regulatorne usklađenosti zahtijeva da se propisi koji obuhvaćaju više područja mapiraju u Registar usklađenosti.

Zajedno, ti alati pretvaraju sigurnost po dizajnu iz aspiracije u operativni model prikladan za reviziju.

Uobičajeni obrasci neuspjeha u IKT projektima

Neuspjesi su obično predvidivi.

Prvi je kasno uključivanje sigurnosti. Sigurnosni pregledi događaju se nakon što su arhitektura fiksirana, ugovori potpisani, a rokovi isporuke javno objavljeni. U tom trenutku sigurnost postaje blokator, a ne ulazni element dizajna.

Drugi su fragmentirani dokazi. Projekt ima rezultate testiranja u jednom alatu, pregled dobavljača u drugom, komentare o privatnosti u e-pošti, prihvaćanje rizika u snimci sastanka i odobrenje promjene u tiketu. Nijedna jedinstvena nit ne dokazuje upravljanje.

Treći su slijepe točke kod dobavljača. Projekt se oslanja na uslugu u oblaku ili pružatelja API-ja, ali nitko ne provjerava podizvršitelje, lokaciju podataka, prava na reviziju, podršku za incidente, izlazne planove ili rizik koncentracije.

Četvrti je pomak privatnosti. Sustav izgrađen za jednu svrhu počinje podržavati analitiku, AI eksperimente, marketinške izvoze ili operativno praćenje bez ponovnog razmatranja pravne osnove, transparentnosti, minimizacije ili zadržavanja.

Peti je nepregledana promjena. Uvođenje u produkciju odobreno je zbog funkcionalnosti, ali nije procijenjeno u pogledu pristupa, zapisivanja događaja, šifriranja, sigurnosnog kopiranja, otpornosti, osobnih podataka ili utjecaja na izvješćivanje.

Šesti je slab nadzor upravljačkog tijela. Projektni rizici visokog utjecaja prihvaćaju se na preniskoj razini, bez dokaza da je odgovorni vlasnik rizika razumio regulatorne posljedice.

Ti se problemi ne rješavaju kupnjom još jednog skenera. Rješavaju se integriranjem upravljanja sigurnošću u način na koji se projekti predlažu, dizajniraju, nabavljaju, grade, testiraju, mijenjaju i pregledavaju.

Poruka za CISO-e u 2026.

Sigurnost po dizajnu u IKT projektima sada je pitanje upravljačkog tijela, revizije i regulatora. NIS2 čini upravljanje rizicima kibernetičke sigurnosti odgovornošću upravljačkog tijela. DORA čini IKT rizik, testiranje otpornosti, upravljanje incidentima i nadzor trećih strana strukturiranom obvezom financijskog sektora. GDPR zahtijeva odgovornost za obradu osobnih podataka i odgovarajuću sigurnost. ISO/IEC 27001:2022 daje strukturu sustava upravljanja za operativnu provedbu tih obveza.

Za CISO-e, prilika je prestati se boriti s projektnim timovima na kraju isporuke. Ugradite sigurnost u pokretanje, zahtjeve, dizajn, odabir dobavljača, izgradnju, testiranje, odobrenje promjene i postimplementacijski pregled.

Za rukovoditelje usklađenosti, prilika je zamijeniti raspršene dokaze jednim mapiranim paketom projektnih dokaza.

Za revizore, prilika je testirati životni ciklus projekta, a ne samo završni sustav.

Za vlasnike poslovanja, prilika je brža i sigurnija isporuka. Sigurnost po dizajnu smanjuje ponovni rad, sprječava iznenađenja u usklađenosti, poboljšava odluke o dobavljačima i vodstvu daje dokazivu priču o riziku.

Ako se vaši IKT projekti kreću brže od vašeg modela dokaza, započnite s jednim pilot projektom. Upotrijebite Clarysecov Zenith Blueprint za definiranje projektnih sigurnosnih kontrolnih točaka, primijenite Clarysec politike za upravljanje rizicima, siguran razvoj, upravljanje promjenama i privatnost te upotrijebite Zenith Controls za mapiranje upravljanja projektima prema ISO/IEC 27001:2022 na NIS2, DORA, GDPR i NIST CSF 2.0.

Clarysec vam može pomoći izgraditi višekratno upotrebljiv paket projektnih dokaza za sigurnost po dizajnu, uskladiti ga s vašim ISMS-om i pripremiti za internu reviziju, certifikacijsku reviziju, spremnost za DORA, upravljanje prema NIS2 i odgovornost prema GDPR.

Počnite sa svojim sljedećim značajnim IKT projektom. Ako mijenja sustave, dobavljače, podatke, pristup, otpornost ili povjerenje klijenata, zaslužuje sigurnost po dizajnu od prvog dana.