Upravljanje projektov IKT z varnostjo že pri načrtovanju v letu 2026

Projekt je bil pravočasen, dokler revizija ni zastavila enega vprašanja

Vodja informacijske varnosti v hitro rastočem podjetju za plačilno tehnologijo je imel za upravni odbor dobro novico. Nova platforma za uvajanje strank je bila pripravljena za produkcijsko uvedbo. Produktna ekipa je zagotovila mobilno uporabniško izkušnjo, inženiring je integriral preverjanje identitete, pravna služba je uredila pogodbe s ponudniki storitev v oblaku in ponudniki API, operativne ekipe pa so preizkusile načrt prehoda v produkcijo.

Nato je notranji revizor zastavil preprosto vprašanje:

»Pokažite mi, kje sta bili varnost in zasebnost obravnavani v posamezni fazi projekta.«

Projektna soba je utihnila.

Obstajalo je poročilo o penetracijskem testiranju, vendar je bilo testiranje izvedeno pozno. Obstajal je diagram arhitekture v oblaku, vendar ni bilo dokazil, da so bili tokovi podatkov pregledani glede na načela GDPR. Obstajal je vprašalnik skrbnega pregleda dobavitelja, vendar ni bil povezan z registrom tveganj. Obstajal je zahtevek za spremembo za produkcijsko uvedbo, vendar odobritev ni omenjala vpliva na kritične storitve, poročanja o incidentih, testiranja odpornosti, obveščanja strank ali eskalacije ob kršitvi varnosti osebnih podatkov. Obstajali so zapisi sprintov, vendar so bile varnostne zahteve razpršene po uporabniških zgodbah in sporočilih v klepetu.

Nič ni bilo očitno malomarno. Vse je bilo videti kot intenziven sodoben projekt IKT. Toda za finančni subjekt, za katerega velja DORA, za ponudnika SaaS, ki bi lahko spadal na področje uporabe NIS2, ter za upravljavca ali obdelovalca po GDPR vprašanje ni bilo več samo, ali varnost obstaja. Vprašanje je bilo, ali je varnost že pri načrtovanju mogoče dokazati.

To je izziv leta 2026. Projekti IKT se ne presojajo več samo po hitrosti dobave, obvladovanju stroškov in tehnični kakovosti. Presojajo se po dokazilih upravljanja: ocenah tveganja, odločitvah glede zasnove, skrbnem pregledu dobaviteljev, zapisih varnega razvoja, odobritvah sprememb, odločitvah glede zasebnosti, rezultatih testiranja in nadzoru vodstva.

ISO/IEC 27001:2022 organizacijam zagotavlja praktično upravljavsko hrbtenico za rešitev tega problema. Vodjem informacijske varnosti, vodjem skladnosti, pokroviteljem projektov, pooblaščenim osebam za varstvo podatkov (DPO), arhitektom, nabavnim ekipam in revizorjem pomaga pomembne projekte IKT pretvoriti v dokazljiva dokazila o varnosti že pri načrtovanju.

Zakaj je upravljanje projektov IKT postalo vprašanje regulativnih dokazil

Migracija v oblak, portal za stranke, plačilna platforma, uvedba CRM, sprememba ponudnika identitet, analitični cevovod, integracija API, delovni tok SaaS, nizkokodna aplikacija ali prehod na upravljano storitev lahko spremenijo profil tveganja organizacije. V letu 2026 se te spremembe dogajajo pod prekrivajočimi se obveznostmi.

NIS2 se široko uporablja za bistvene in pomembne subjekte v sektorjih iz Priloge I in Priloge II, vključno z digitalno infrastrukturo, ponudniki upravljanih storitev, ponudniki upravljanih varnostnih storitev in digitalnimi ponudniki. NIS2 Article 20 določa odgovornost organov vodenja za odobritev ukrepov za obvladovanje tveganj kibernetske varnosti in nadzor nad njihovim izvajanjem. NIS2 Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe za obvladovanje tveganj, obravnavanje incidentov, neprekinjeno poslovanje, varnost dobavne verige, varno nabavo, varen razvoj, obravnavo ranljivosti, ocenjevanje učinkovitosti, kibernetsko higieno, kriptografijo, nadzor dostopa, upravljanje sredstev in varne komunikacije.

DORA velja za finančne subjekte in se osredotoča na digitalno operativno odpornost. DORA Article 5 odgovornost za upravljanje tveganj na področju IKT nalaga organu vodenja. DORA Article 6 zahteva trden, celovit in dobro dokumentiran okvir za upravljanje tveganj na področju IKT. DORA zajema tudi poročanje o incidentih, povezanih z IKT, testiranje operativne odpornosti, neprekinjeno poslovanje IKT, odziv in obnovitev, izmenjavo informacij o kibernetskih grožnjah, upravljanje tveganj tretjih oseb na področju IKT, pogodbene dogovore ter nadzor nad kritičnimi ponudniki storitev tretjih oseb na področju IKT.

GDPR dodaja plast odgovornosti za osebne podatke. GDPR Article 25 zahteva varstvo podatkov že pri načrtovanju in privzeto. Upravljavci morajo biti sposobni dokazati skladnost z načeli, kot so zakonitost, poštenost, preglednost, omejitev namena, minimizacija podatkov, omejitev hrambe, celovitost, zaupnost in odgovornost. Kadar je verjetno, da bo obdelava povzročila veliko tveganje, je lahko zahtevana tudi ocena učinka v zvezi z varstvom podatkov (DPIA) po GDPR Article 35.

Skupna točka so dokazila. Regulatorji in revizorji ne sprašujejo samo, ali je bila platforma šifrirana, posodobljena, skenirana ali testirana. Sprašujejo, ali lahko organizacija pokaže, da so bile varnost, zasebnost, tveganja dobaviteljev in odpornost del odločanja od samega začetka.

Zato je upravljanje projektov po ISO/IEC 27001:2022 tako učinkovito. Organizaciji omogoča, da NIS2, DORA, GDPR, NIST CSF 2.0, pogodbene obveznosti in programe zagotavljanja zaupanja naročnikov upravlja prek enega ponovljivega procesa ISMS, namesto z več nepovezanimi kontrolnimi seznami.

Upravljavska hrbtenica projektov po ISO 27001

ISO/IEC 27001:2022 se pogosto napačno razume kot vaja za certifikacijo. Pri projektih IKT je njegova operativna vrednost širša. Zagotavlja upravljavsko hrbtenico za poslovne spremembe.

Točke 4.1 do 4.4 od organizacij zahtevajo razumevanje notranjih in zunanjih vprašanj, zainteresiranih strani, pravnih, regulativnih in pogodbenih zahtev, obsega ISMS, vmesnikov in odvisnosti. V projektnem jeziku to pomeni, da mora projektna listina opredeliti prizadete storitve, stranke, dobavitelje, predpise, poslovne procese, osebne podatke, kritične operacije in zunanje izvajane storitve.

Točke 5.1 do 5.3 zahtevajo zavezanost vodstva, uskladitev politik, vire, integracijo v poslovne procese in dodeljene odgovornosti. To je pomembno, ker NIS2 in DORA kibernetsko varnost in tveganja na področju IKT umeščata v odgovornost organa vodenja. Projekt, ki spreminja kritično platformo za stranke, se ne more zanašati na neformalni varnostni komentar v pogovorni niti. Potrebuje jasno odgovornost.

Točke 6.1.1 do 6.1.3 zahtevajo ponovljiv proces ocenjevanja in obravnave tveganj, merila tveganj, lastnike tveganj, vrednotenje zaupnosti, celovitosti in razpoložljivosti, načrte obravnave tveganj, izjavo o uporabnosti (SoA) in odobritev preostalega tveganja. Tu projektno tveganje postane revizijsko dokazilo.

Točke 7.1 do 7.5 zahtevajo vire, kompetence, ozaveščenost, komuniciranje in obvladovanje dokumentiranih informacij. Tako projektni zapisi postanejo zanesljiva dokazila, ne razpršeni artefakti.

Točka 8.1 zahteva operativno načrtovanje in nadzor, dokumentirane informacije, ki dokazujejo, da so bili procesi izvedeni skladno z načrtom, nadzor načrtovanih sprememb, pregled nenamernih sprememb, ublažitev škodljivih učinkov ter nadzor nad zunanje zagotovljenimi procesi, proizvodi ali storitvami, pomembnimi za ISMS. Točki 8.2 in 8.3 zahtevata ocene tveganj informacijske varnosti in obravnavo tveganj v načrtovanih intervalih ali ob pomembnih spremembah.

Priloga A nato ta upravljavski cikel poveže s praktičnimi kontrolami. Za varnost že pri načrtovanju v projektih IKT so osrednje tri kontrole iz Priloge A ISO/IEC 27001:2022:

Clarysecov Zenith Blueprint: An Auditor’s 30-Step Roadmap obravnava informacijsko varnost pri vodenju projektov kot vprašanje upravljanja v vseh vrstah projektov, ne samo pri razvoju programske opreme:

»Vsak projekt – migracija marketinškega sistema, selitev poslovnih prostorov, prenova poslovnega procesa, kadrovska platforma za uvajanje zaposlenih, celo združitev ali prevzem – lahko vpliva na zaupnost, celovitost ali razpoložljivost informacij. Ko se to zgodi, mora imeti varnost svoje mesto za mizo.«

Isti razdelek povzema ključno lekcijo za izvedbo:

»Cilj te kontrole ni obremeniti projekte z birokracijo. Cilj je zagotoviti, da se varnost obravnava kot vhod v zasnovo, ne kot faza testiranja.«

Ta razlika ločuje navidezno skladnost od dokazljive varnosti že pri načrtovanju.

Kako je varnost že pri načrtovanju videti znotraj projekta IKT

Varnost že pri načrtovanju se začne pred prvim sprintom, zahtevkom za nabavo, arhitekturnim diagramom ali operativnim priročnikom za migracijo. Zastavi preprosto vprašanje: kaj bi ta projekt lahko spremenil v zvezi s tveganjem?

Praktičen model upravljanja projektov uporablja sedem dokaznih kontrolnih točk.

Cilj ni birokracija. Cilj je narediti varnost vidno tam, kjer projektne odločitve dejansko nastajajo.

Clarysecova Enterprise Politika informacijske varnosti to izrazi neposredno:

»Upravljanje varnosti mora biti integrirano s korporativnim upravljanjem, vodenjem projektov, nabavo in funkcijami pravnega nadzora, da se zagotovi, da informacijska varnost ni izolirana, temveč vgrajena v poslovno odločanje.«

Iz razdelka »Zahteve upravljanja«, klavzula politike 5.5.

Prav tako projektne življenjske cikle opredeli kot vprašanje izvedbe:

»Projektni življenjski cikli (npr. varen razvoj, modeliranje groženj)«

Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.3.1.1.

In določa revizijsko načelo, ki ga številne organizacije odkrijejo prepozno:

»Vse implementirane kontrole morajo biti preverljive, podprte z dokumentiranimi postopki in ohranjenimi dokazili o delovanju.«

Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.6.1.

Z drugimi besedami: varnostno delo, ki ni upravljano, ohranjeno in preslikano, pogosto ne prestane revizije, tudi če so tehnične ekipe sprejele razumne odločitve.

Od modeliranja groženj do dokazil: praktičen primer iz finančne tehnologije

Predstavljajmo si projekt uvedbe novega portala za uvajanje strank v EU za finančnotehnološko podjetje. Portal zbira identifikacijske dokumente, izvaja biometrično preverjanje prek tretje osebe, hrani status uvajanja, se integrira s CRM, sproža obvestila strankam in napaja točkovanje tveganj.

Pristop varnosti že pri načrtovanju bi dokazila gradil sproti, ko projekt napreduje.

Najprej odprite zapis o varnostni razvrstitvi projekta. Ugotovite, ali projekt vpliva na kritične ali pomembne funkcije, osebne podatke, posebne vrste osebnih podatkov, avtentikacijo, razpoložljivost za stranke, zunanje izvajane storitve IKT, regulirane procese poročanja ali komunikacije s strankami. Po GDPR so biometrični podatki, uporabljeni za enolično identifikacijo, posebna vrsta osebnih podatkov, razen če velja posebna izjema. To takoj zviša zahtevano raven pravne analize in varoval.

Drugič, pripravite projektno oceno tveganja. Clarysecova SME Politika upravljanja tveganj upravljanje tveganj umešča v načrtovanje, ne v četrtletno preglednico:

»1.2 Zagotavlja, da je upravljanje tveganj aktiven del načrtovanja, izvedbe projektov, izbire dobaviteljev in odzivanja na incidente, v skladu z ISO 27001, ISO 31000 in veljavnimi regulativnimi zahtevami.«

Iz razdelka »Namen«, klavzula politike 1.2.

Za Enterprise okolja Clarysecova Enterprise Politika upravljanja tveganj opredeljuje področje uporabe na strateški, operativni, projektni in tehnični ravni:

»Zajema tveganja informacijske varnosti na strateški, operativni, projektni in tehnični ravni ter je obvezna za vse osebje, pogodbene izvajalce in ponudnike storitev, vključene v dejavnosti sistema upravljanja informacijske varnosti (ISMS).«

Iz razdelka »Področje uporabe«, klavzula politike 2.3.

Tretjič, pred začetkom razvoja izvedite modeliranje groženj. Enterprise Politika varnega razvoja je izrecna:

»Vse nove aplikacije in večje spremembe morajo pred začetkom razvoja opraviti pregled varne arhitekture in modeliranje groženj.«

Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.1.1.

Za portal za uvajanje strank mora model groženj zajeti izpostavljene vmesnike, tokove identitete, meje privilegijev, primere zlorabe API, ponarejanje webhookov, ponovitvene napade, kompromitirane poverilnice, poti uhajanja podatkov, tveganje odvisnosti, zahteve glede beleženja, predpostavke varnostnega kopiranja, zahteve za obnovitev in načine odpovedi ponudnika.

Četrtič, posodobite dokazila o zasebnosti. SME Politika varstva podatkov in zasebnosti določa osnovo:

»5.3.1. Vgrajeno in privzeto varstvo zasebnosti mora biti uveljavljeno v vseh novih sistemih in storitvah«

Iz razdelka »Zahteve upravljanja«, klavzula politike 5.3.1.

Projektni zapis mora vključevati namen, pravno podlago, vlogo upravljavca ali obdelovalca, odločitve o minimizaciji podatkov, pravila hrambe, vloge dostopa, izbire šifriranja, premisleke o vplivu na posameznike, zahteve glede preglednosti, določila za obdelovalca in poti obveščanja o kršitvi varnosti osebnih podatkov.

Petič, evidentirajte dokazila varnega razvoja. SME Politika varnega razvoja podaja jedrnat seznam dokazil, primeren za majhne in srednje velike ekipe:

»5.3 Generalni direktor (GM) mora vzdrževati zapise o: 5.3.1 vseh aktivnih projektih razvoja programske opreme in odgovornih razvijalcih ali dobaviteljih 5.3.2 varnostnih kontrolnih seznamih, uporabljenih za posamezen projekt 5.3.3 izvedenih pregledih izvorne kode in osebah, ki so jih izvedle 5.3.4 rezultatih testiranja pred uvedbo 5.3.5 komponentah tretjih oseb in njihovem povezanem licenčnem ali tveganjskem statusu«

Iz razdelka »Zahteve upravljanja«, klavzula politike 5.3.

Šestič, uvedbo obravnavajte kot spremembo. SME Politika upravljanja sprememb določa:

»1.1 Ta politika zagotavlja, da so vse spremembe IT-sistemov, konfiguracij, poslovnih aplikacij ali storitev v oblaku načrtovane, predmet ocene tveganja, testirane in odobrene pred implementacijo.«

Iz razdelka »Namen«, klavzula politike 1.1.

Za portal za uvajanje strank mora zahtevek za spremembo vključevati prizadete storitve, oceno tveganja, rezultate testiranja, načrt povrnitve, načrt spremljanja, varnostne odobritve, odobritev z vidika zasebnosti, pripravljenost dobavitelja, posodobitve eskalacije incidentov in sprožilce komunikacije s strankami.

Nazadnje preslikajte obveznosti. SME Politika pravne in regulativne skladnosti določa operativno pravilo:

»5.2.2 Kadar se predpis uporablja na več področjih (npr. GDPR se uporablja za hrambo, varnost in zasebnost), mora biti to jasno preslikano v evidenci skladnosti in gradivih za usposabljanje.«

Iz razdelka »Zahteve upravljanja«, klavzula politike 5.2.2.

Ta evidenca skladnosti postane most med kontrolami ISO/IEC 27001:2022, ukrepi NIS2 Article 21, obveznostmi upravljanja tveganj na področju IKT po DORA, odgovornostjo po GDPR in pogodbenimi zavezami do strank.

Preslikava enega projektnega svežnja dokazil na NIS2, DORA, GDPR in NIST CSF 2.0

Najučinkovitejša strategija skladnosti ni podvajanje dela. Je preslikava enega kakovostnega nabora dokazil na več obveznosti.

Zenith Blueprint v fazi upravljanja tveganj, korak 14, priporoča takšno navzkrižno sklicevanje:

»Za vsak predpis, če je uporaben, lahko ustvarite preprosto preslikovalno tabelo (lahko kot prilogo poročilu), ki navaja ključne varnostne zahteve predpisa in ustrezne kontrole/politike v vašem ISMS.«

Dodaja, da je to koristno, ker revizorjem in presojevalcem pokaže, »da varnosti ne upravljate v vakuumu, temveč poznate pravni kontekst«.

Clarysecov Zenith Controls: The Cross-Compliance Guide podpira isti integrirani pristop s preslikavo kontrol ISO/IEC 27001:2022 na druge okvire, revizijska pričakovanja in potrebe skladnosti. Pri upravljanju projektov IKT A.5.8, A.8.25 in A.8.32 obravnava kot preventivne kontrolne ukrepe, ki varujejo zaupnost, celovitost in razpoložljivost na področjih upravljanja, varnosti aplikacij, ekosistema, zaščite ter varnosti sistemov in omrežij.

Ta tabela ni nadomestilo za pravno analizo. Je pospeševalnik upravljanja. Zagotavlja, da vodja informacijske varnosti, DPO, pokrovitelj projekta, vodja nabave, lastnik sistema in notranji revizor gledajo ista dokazila.

NIST CSF 2.0 se v ta model naravno vključi. Njegova funkcija GOVERN pomaga organizacijam vzpostaviti politike, vloge, apetit po tveganju, nadzor in zavedanje pravnih ali pogodbenih obveznosti. Funkcije IDENTIFY, PROTECT, DETECT, RESPOND in RECOVER ekipam pomagajo razpravljati o sredstvih, storitvah dobaviteljev, nadzoru dostopa, varnosti podatkov, varnosti platform, varnem razvoju programske opreme, spremljanju, odzivanju na incidente in obnovitvi v skupnem operativnem jeziku.

En sam proces, usklajen z ISO 27001 in osredotočen na kontrolo A.5.8 iz Priloge A, lahko ustvari dokazljiva dokazila za vsa ta pričakovanja.

Varen razvoj je širši od pisanja kode

Veliko neuspehov projektov IKT nastane, ker organizacija varen razvoj obravnava kot nekaj, kar počnejo samo razvijalci. V letu 2026 varen razvoj vključuje tudi konfiguracijo SaaS, avtomatizacijo delovnih tokov, infrastrukturo kot kodo, integracije API, pravila identitet, pristajalne cone v oblaku, analitične cevovode, robotsko avtomatizacijo procesov in nizkokodne poslovne aplikacije.

Zenith Blueprint v fazi Controls in Action, korak 20, obravnava kontrolo ISO/IEC 27002:2022 8.25 Secure Development Life Cycle:

»Ta kontrola se uporablja ne glede na to, ali razvijate lastne aplikacije, konfigurirate platforme, kot so sistemi ERP ali CRM, prilagajate delovne tokove SaaS ali upravljate okolja infrastrukture kot kode.«

Pojasnjuje tudi, da morajo varnostne zahteve stati ob funkcionalnih zahtevah ter da modeliranje groženj pomaga prepoznati izpostavljene dele sistema, tvegane uporabniške vloge in tokove podatkov, ki zahtevajo višjo raven zaščite.

Za sodoben projekt lahko dokazila varnega razvoja vključujejo:

• Varnostne zahteve, povezane s poslovnimi zahtevami
• Model groženj ali pregled varne arhitekture
• Kontrolni seznam varnega kodiranja ali varne konfiguracije
• Zapise pregleda izvorne kode ali medsebojnega strokovnega pregleda
• Popis komponent in status tveganj odvisnosti
• Odločitve o upravljanju skrivnosti
• Zasnovo nadzora dostopa in načela najmanjših privilegijev
• Zahteve glede beleženja in spremljanja
• Rezultate skeniranja ranljivosti in zapise sanacijskih ukrepov
• Varnostno testiranje v predprodukcijskem okolju
• Testiranje varnostnega kopiranja, obnovitve in odpornosti, kjer je ustrezno
• Dokazila o odobritvi uvedbe in načrtu povrnitve

Cilj ni prisiliti vsakega projekta skozi enak težek proces. Cilj je sorazmernost. Manjša sprememba notranjega delovnega toka ne zahteva enakih dokazil kot migracija ključne plačilne platforme. Vendar mora biti vsak projekt razvrščen, predmet ocene tveganja in upravljan skladno z vplivom.

Upravljanje sprememb varuje projekt pred njim samim

Najbolj tvegan trenutek v številnih projektih ni zasnova ali kodiranje. Je uvedba.

Ekipa lahko izvede modeliranje groženj, pregled izvorne kode, presojo dobavitelja in pregled zasebnosti, nato pa z naglo produkcijsko spremembo še vedno povzroči izpad ali kršitev. Zastavica za odpravljanje napak ostane omogočena. Pravilo požarnega zidu je širše od odobrenega. Migracijska skripta kopira osebne podatke v neprodukcijsko okolje. Končna točka webhooka tretje osebe je uvedena brez avtentikacije. Sprememba beleženja evidentira številke identifikacijskih dokumentov. Opravilo varnostnega kopiranja po preklopu tiho odpove.

Zenith Blueprint v fazi Controls in Action, korak 21, neposredno opisuje kontrolo ISO/IEC 27002:2022 8.32 Change Management:

»Spremembe so neizogibne, vendar so v kibernetski varnosti nenadzorovane spremembe nevarne.«

Nadaljuje:

»V svojem jedru je učinkovito upravljanje sprememb ponovljiv delovni tok. Začne se z jasnim predlogom, ki opiše, kaj se spreminja, zakaj, kdaj in kakšna so možna tveganja.«

Dober zapis o spremembi IKT mora odgovoriti na naslednja vprašanja:

• Kateri sistem, storitev, tok podatkov, dobavitelj ali konfiguracija se spreminja?
• Katera tveganja so bila opredeljena in kdo je njihov lastnik?
• Ali sprememba vpliva na osebne podatke, kritične storitve, avtentikacijo, beleženje, varnostne kopije ali odziv na incidente?
• Katera preverjanja varnosti, zasebnosti, odpornosti in dobaviteljev so bila izvedena?
• Kateri testi so bili dokončani pred uvedbo?
• Katero spremljanje bo potrdilo pričakovano vedenje?
• Kakšen načrt povrnitve ali obnovitve obstaja?
• Kdo je odobril preostalo tveganje?
• Katera dokazila bodo ohranjena?

Za DORA to podpira dokumentirano upravljanje tveganj na področju IKT, odpornost, neprekinjeno poslovanje, razvrščanje incidentov in pridobljene izkušnje. Za NIS2 podpira ukrepe za obvladovanje tveganj, varen razvoj, preprečevanje incidentov in neprekinjeno poslovanje. Za GDPR pomaga dokazati, da so bile spremembe, ki vplivajo na osebne podatke, pregledane glede na namen, minimizacijo, hrambo, dostop in varnostna načela.

Odločitve o dobaviteljih in oblaku morajo biti del projektne zasnove

V sodobnih projektih IKT je najbolj tvegana odločitev glede zasnove pogosto »kupiti« in ne »zgraditi«. Storitve v oblaku, ponudniki API, platforme za preverjanje identitete, plačilni obdelovalci, analitični dobavitelji, ponudniki upravljanih storitev in ponudniki upravljanih varnostnih storitev postanejo del površine tveganja.

NIS2 izrecno vključuje varnost dobavne verige, ranljivosti neposrednih dobaviteljev in ponudnikov storitev, prakse kibernetske varnosti dobaviteljev, postopke varnega razvoja ter rezultate usklajenih ocen tveganja dobavne verige. DORA gre pri finančnih subjektih globlje. Upravljanje tveganj tretjih oseb na področju IKT zahteva kot del okvira upravljanja tveganj na področju IKT, ohranja odgovornost tudi pri zunanjem izvajanju storitev IKT, zahteva evidence informacij, predpogodbene presoje, analizo tveganja koncentracije, pogodbene kontrole, pravice do revizije in pregleda, sprožilce za prenehanje ter preizkušene strategije izstopa za kritične ali pomembne funkcije.

Pri portalu za uvajanje strank ponudnik biometričnega preverjanja ne more biti odobren samo zato, ker je nabavi všeč cena in je dokumentacija API dobra. Projekt potrebuje dokazila o skrbnem varnostnem pregledu, vlogi pri obdelavi, lokaciji podatkov, podizvajalcih, zavezah glede razpoložljivosti, podpori pri incidentih, pravicah do revizije, pomoči ob prenehanju, izvedljivosti izstopa in obveznostih spremljanja.

V zrelem modelu dokazil so odločitve o dobaviteljih in oblaku del projektnega svežnja dokazil, ne ločene mape dobavitelja. Ko revizor vpraša, zakaj je bila tretja oseba sprejeta, mora odgovor vključevati poslovno potrebo, oceno tveganja, pogodbena varovala, pregled varstva podatkov, vpliv na odpornost in stalno spremljanje.

Kako bodo revizorji pregledovali dokazila o varnosti že pri načrtovanju

Različni revizorji isti projekt IKT obravnavajo iz različnih zornih kotov. Certifikacijski presojevalec, notranji revizor, pregledovalec po DORA, pristojni organ po NIS2, revizor zasebnosti, presojevalec z usmeritvijo v NIST ali revizor po pristopu COBIT lahko zahtevajo podobna dokazila, vendar jih razlagajo drugače.

Revizorji ne želijo lepe predstavitve projekta. Želijo sledljivost. Želijo videti, da so zahteve vodile do tveganj, tveganja do kontrol, kontrole do dokazil o implementaciji, implementacija pa do pregleda.

Zato je Zenith Controls uporaben pri pripravi na revizijo. Ekipam pomaga pojasniti, zakaj so A.5.8, A.8.25 in A.8.32 iz Priloge A preventivni kontrolni ukrepi, ki varujejo zaupnost, celovitost in razpoložljivost, preden predvidljive odpovedi dosežejo produkcijo.

Minimalni projektni sveženj dokazil Clarysec

Dober sveženj dokazil o varnosti že pri načrtovanju ni nujno obsežen. Biti mora dosleden, sorazmeren in preslikan.

Za projekt IKT srednjega tveganja Clarysec običajno priporoča naslednji minimalni sveženj:

1. Zapis varnostne razvrstitve projekta
2. Opomba o uporabljivosti predpisov, ki zajema NIS2, DORA, kjer je relevantno, GDPR in pogodbene obveznosti
3. Zemljevid vpliva tokov podatkov in sredstev
4. Projektna ocena tveganja in načrt obravnave tveganja
5. Model groženj ali pregled varne arhitekture
6. Presoja dobavitelja in storitve v oblaku, kjer je uporabno
7. Kontrolni seznam varnega razvoja ali konfiguracije
8. Rezultati varnostnega testiranja in dokazila o sanacijskih ukrepih
9. Odobritev spremembe z načrtom povrnitve in spremljanja
10. Zapis vgrajenega varstva zasebnosti, vključno s pravno podlago in hrambo, kadar so vključeni osebni podatki
11. Posodobitve odziva na incidente in spremljanja
12. Pregled po uvedbi in pridobljene izkušnje
13. Preslikava evidence skladnosti na kontrole in obveznosti

Zenith Blueprint daje logiko časovnega načrta. Korak 22 vnaša informacijsko varnost v vse faze projekta. Korak 20 vgrajuje varen razvoj v načrtovanje, zasnovo, kodo, testiranje in uvedbo. Korak 21 naredi upravljanje sprememb strukturirano, sledljivo in primerno za pregled. Korak 14 priporoča navzkrižno sklicevanje GDPR, NIS2, DORA in drugih obveznosti, da zahteve skladnosti ne padejo skozi razpoke.

Politike določajo operativna pravila. Politika informacijske varnosti integrira varnost z vodenjem projektov, nabavo in pravnim nadzorom. Politika upravljanja tveganj uvršča projektna tveganja med dejavnosti ISMS. Politika varnega razvoja zahteva modeliranje groženj. Politika upravljanja sprememb zahteva načrtovane, tveganjsko ocenjene, testirane in odobrene spremembe. Politika varstva podatkov in zasebnosti zahteva vgrajeno in privzeto varstvo zasebnosti. Politika pravne in regulativne skladnosti zahteva, da se predpisi z več področji uporabe preslikajo v evidenco skladnosti.

Skupaj ta orodja varnost že pri načrtovanju spremenijo iz cilja v preverljiv operativni model.

Pogosti vzorci neuspehov v projektih IKT

Neuspehi so običajno predvidljivi.

Prvi je pozna vključitev varnosti. Varnostni pregledi se zgodijo po tem, ko je arhitektura že določena, pogodbe podpisane in datumi dobave javno objavljeni. Takrat varnost postane ovira, ne vhod v zasnovo.

Drugi je razdrobljenost dokazil. Projekt ima rezultate testiranja v enem orodju, pregled dobavitelja v drugem, komentarje glede zasebnosti v e-pošti, sprejem tveganja v zapisniku sestanka in odobritev spremembe v zahtevku. Nobena enotna nit ne dokazuje upravljanja.

Tretji so slepe pege pri dobaviteljih. Projekt se zanaša na storitev v oblaku ali ponudnika API, vendar nihče ne preveri podizvajalcev, lokacije podatkov, pravic do revizije, podpore pri incidentih, načrtov izstopa ali tveganja koncentracije.

Četrti je odmik zasebnosti. Sistem, zgrajen za en namen, začne podpirati analitiko, eksperimente z umetno inteligenco, marketinške izvoze ali operativno spremljanje, ne da bi se ponovno pregledali pravna podlaga, preglednost, minimizacija ali hramba.

Peti je nepregledana sprememba. Produkcijska uvedba je odobrena zaradi funkcionalnosti, vendar ni ocenjena glede dostopa, beleženja, šifriranja, varnostnega kopiranja, odpornosti, osebnih podatkov ali vpliva na poročanje.

Šesti je šibek nadzor vodstva. Tveganja projektov z velikim vplivom so sprejeta na prenizki ravni, brez dokazil, da je odgovorni lastnik tveganja razumel regulativne posledice.

Teh težav ne rešimo z nakupom še enega skenerja. Rešimo jih z integracijo upravljanja varnosti v način, kako so projekti predlagani, zasnovani, nabavljeni, zgrajeni, testirani, spreminjani in pregledani.

Ključno sporočilo za vodjo informacijske varnosti v letu 2026

Varnost že pri načrtovanju v projektih IKT je zdaj vprašanje upravnega odbora, revizije in regulatorjev. NIS2 upravljanje tveganj kibernetske varnosti postavlja v pristojnost organa vodenja. DORA tveganja na področju IKT, testiranje odpornosti, upravljanje incidentov in nadzor tretjih oseb spreminja v strukturirano obveznost finančnega sektorja. GDPR zahteva odgovornost za obdelavo osebnih podatkov in ustrezno varnost. ISO/IEC 27001:2022 zagotavlja strukturo sistema upravljanja, s katero te obveznosti postanejo operativne.

Za vodje informacijske varnosti je priložnost v tem, da se prenehajo boriti s projektnimi ekipami na koncu dobave. Varnost je treba vključiti v začetek projekta, zahteve, zasnovo, izbiro dobaviteljev, razvoj, testiranje, odobritev spremembe in pregled po uvedbi.

Za vodje skladnosti je priložnost v tem, da razpršena dokazila nadomestijo z enim preslikanim projektnim svežnjem dokazil.

Za revizorje je priložnost v tem, da testirajo življenjski cikel projekta, ne samo končnega sistema.

Za lastnike poslovanja je priložnost hitrejša in varnejša dobava. Varnost že pri načrtovanju zmanjšuje predelave, preprečuje presenečenja pri skladnosti, izboljšuje odločitve o dobaviteljih in vodstvu daje dokazljivo zgodbo o tveganjih.

Če se vaši projekti IKT premikajo hitreje kot vaš model dokazil, začnite z enim pilotnim projektom. Uporabite Clarysecov Zenith Blueprint za opredelitev projektnih varnostnih kontrolnih točk, uporabite politike Clarysec za upravljanje tveganj, varen razvoj, upravljanje sprememb in zasebnost ter uporabite Zenith Controls za preslikavo upravljanja projektov po ISO/IEC 27001:2022 na NIS2, DORA, GDPR in NIST CSF 2.0.

Clarysec vam lahko pomaga zgraditi ponovno uporabljiv projektni sveženj dokazil o varnosti že pri načrtovanju, ga uskladiti z vašim ISMS in pripraviti za notranjo revizijo, certifikacijsko presojo, pripravljenost na DORA, upravljanje po NIS2 in odgovornost po GDPR.

Začnite z naslednjim pomembnim projektom IKT. Če spreminja sisteme, dobavitelje, podatke, dostop, odpornost ali zaupanje strank, si zasluži varnost že pri načrtovanju od prvega dne.