Turvalisus kavandamisest alates IKT-projektide juhtimises 2026. aastal
Projekt oli graafikus, kuni audit esitas ühe küsimuse
Kiiresti kasvava maksetehnoloogia ettevõtte infoturbejuht sai juhatusele häid uudiseid edastada. Uus klientide liitumisplatvorm oli käivitamiseks valmis. Tootemeeskond oli mobiilikogemuse valmis saanud, arendus oli integreerinud identiteedikontrolli, õigusosakond oli sõlminud lepingud pilve- ja API-pakkujatega ning käitlusmeeskond oli tootmiskeskkonda juurutamise plaani läbi harjutanud.
Seejärel esitas siseaudiitor lihtsa küsimuse:
„Näidake, kus käsitleti projekti igas etapis turvalisust ja privaatsust.”
Projektiruum jäi vaikseks.
Olemas oli penetratsioonitestimise aruanne, kuid see koostati hilises etapis. Olemas oli pilvearhitektuuri skeem, kuid puudus tõendusmaterjal selle kohta, et andmevooge oleks GDPR põhimõtete suhtes läbi vaadatud. Olemas oli tarnija hoolsuskontrolli küsimustik, kuid seda ei olnud seotud riskiregistriga. Olemas oli muudatuse pilet tootmiskeskkonda juurutamiseks, kuid heakskiit ei käsitlenud mõju kriitilistele teenustele, intsidentidest teavitamisele, toimepidevuse testimisele, klientide teavitamisele ega isikuandmetega seotud rikkumise eskaleerimisele. Olemas olid sprindi märkmed, kuid turbenõuded olid hajutatud kasutajalugude ja vestlussõnumite vahel.
Miski ei viidanud ilmselgele hooletusele. Kõik nägi välja nagu tegus tänapäevane IKT-projekt. Kuid DORA kohaldamisalasse kuuluva finantsüksuse, võimaliku NIS2 kohaldamisalasse kuuluva SaaS-pakkuja ning GDPR alusel vastutava töötleja või volitatud töötleja jaoks ei olnud küsimus enam ainult selles, kas turvalisus oli olemas. Küsimus oli selles, kas turvalisust kavandamisest alates saab tõendada.
See on 2026. aasta probleem. IKT-projekte ei hinnata enam ainult tarnekiiruse, kulukontrolli ja tehnilise kvaliteedi järgi. Neid hinnatakse juhtimise tõendusmaterjali järgi: riskihindamised, disainiotsused, tarnija hoolsuskontroll, turvalise arenduse kirjed, muudatuste heakskiidud, privaatsusotsused, testitulemused ja juhtkonna järelevalve.
ISO/IEC 27001:2022 annab organisatsioonidele selle probleemi lahendamiseks praktilise juhtimissüsteemi selgroo. See aitab infoturbejuhtidel, vastavusjuhtidel, projekti sponsoritel, andmekaitseametnikel, arhitektidel, hankemeeskondadel ja audiitoritel muuta olulised IKT-projektid kaitstavaks turvalisuse kavandamisest alates tõendusmaterjaliks.
Miks IKT-projektide juhtimine on nüüd regulatiivse tõendusmaterjali küsimus
Pilvemigreerimine, kliendiportaal, makseplatvorm, CRM-i juurutamine, identiteedipakkuja muutmine, analüütikatorustik, API-integratsioon, SaaS-töövoog, low-code-rakendus või hallatud teenuse üleminek võivad kõik muuta organisatsiooni riskipositsiooni. 2026. aastal toimuvad need muudatused kattuvate kohustuste tingimustes.
NIS2 kohaldub laialdaselt olulistele ja tähtsatele üksustele Annex I ja Annex II sektorites, sealhulgas digitaalsele taristule, hallatud teenusepakkujatele, hallatud turvateenuste pakkujatele ja digiteenuste pakkujatele. NIS2 Article 20 paneb juhtorganitele vastutuse küberturbe riskijuhtimise meetmete heakskiitmise ja nende rakendamise järelevalve eest. NIS2 Article 21 nõuab asjakohaseid ja proportsionaalseid tehnilisi, operatiivseid ja korralduslikke meetmeid riskijuhtimiseks, intsidentide käsitlemiseks, talitluspidevuseks, tarneahela turvalisuseks, turvaliseks hankimiseks, turvaliseks arenduseks, haavatavuste käsitlemiseks, tõhususe hindamiseks, küberhügieeniks, krüptograafiaks, juurdepääsukontrolliks, varahalduseks ja turvaliseks sideks.
DORA kohaldub finantsüksustele ja keskendub digitaalsele operatsioonilisele toimepidevusele. DORA Article 5 paneb vastutuse IKT-riski juhtimise eest juhtorganile. DORA Article 6 nõuab usaldusväärset, terviklikku ja hästi dokumenteeritud IKT-riski juhtimise raamistikku. DORA hõlmab ka IKT-ga seotud intsidentidest teatamist, operatsioonilise toimepidevuse testimist, IKT talitluspidevust, reageerimist ja taastet, küberohtude teabe jagamist, IKT kolmandate osapoolte riskijuhtimist, lepingulisi kokkuleppeid ning kriitiliste IKT kolmandast osapoolest teenuseosutajate järelevalvet.
GDPR lisab isikuandmete jaoks vastutuse kihi. GDPR Article 25 nõuab lõimitud andmekaitset ja vaikimisi andmekaitset. Vastutavad töötlejad peavad suutma tõendada vastavust sellistele põhimõtetele nagu seaduslikkus, õiglus, läbipaistvus, eesmärgi piirang, andmete minimaalsus, säilitamise piirang, terviklus, konfidentsiaalsus ja vastutus. Kui töötlemine põhjustab tõenäoliselt kõrget riski, võib olla nõutav ka andmekaitsealane mõjuhinnang GDPR Article 35 alusel.
Ühine nimetaja on tõendusmaterjal. Regulaatorid ja audiitorid ei küsi ainult seda, kas platvorm oli krüpteeritud, paigatud, skannitud või testitud. Nad küsivad, kas organisatsioon saab näidata, et turvalisus, privaatsus, tarnijarisk ja toimepidevus olid otsustamise osa algusest peale.
Seetõttu on ISO/IEC 27001:2022 projektijuhtimine nii mõjus. See võimaldab organisatsioonil hallata NIS2, DORA, GDPR, NIST CSF 2.0, lepingulisi kohustusi ja klientidele kindluse andmise eesmärke ühe korratava ISMS-protsessi kaudu, mitte mitme eraldiseisva kontrollnimekirjaga.
ISO 27001 projektijuhtimise selgroog
ISO/IEC 27001:2022 peetakse sageli ekslikult üksnes sertifitseerimisharjutuseks. IKT-projektide puhul on selle operatiivne väärtus palju laiem. See annab ärimuudatustele juhtimise selgroo.
Punktid 4.1 kuni 4.4 nõuavad, et organisatsioonid mõistaksid sisemisi ja väliseid teemasid, huvitatud osapooli, õiguslikke, regulatiivseid ja lepingulisi nõudeid, ISMS-i kohaldamisala, liideseid ja sõltuvusi. Projekti mõistes tähendab see, et projekti põhikiri peab tuvastama mõjutatud teenused, kliendid, tarnijad, regulatsioonid, äriprotsessid, isikuandmed, kriitilised tegevused ja allhanke korras osutatavad teenused.
Punktid 5.1 kuni 5.3 nõuavad juhtkonna pühendumust, poliitikaga kooskõla, ressursse, lõimimist äriprotsessidesse ja määratud vastutusi. See on oluline, sest NIS2 ja DORA seavad küberturbe ja IKT-riski juhtorgani vastutuse alla. Projekt, mis muudab kriitilist kliendiplatvormi, ei saa tugineda mitteametlikule turvakommentaarile vestluslõimes. Vaja on selget vastutust.
Punktid 6.1.1 kuni 6.1.3 nõuavad korratavat riskihindamise ja riskikäsitluse protsessi, riskikriteeriume, riskiomanikke, konfidentsiaalsuse, tervikluse ja käideldavuse hindamist, riski käsitlemise plaane, kohaldatavusavaldust ja jääkriski heakskiitu. Siin muutub projektirisk auditi tõendusmaterjaliks.
Punktid 7.1 kuni 7.5 nõuavad ressursse, pädevust, teadlikkust, suhtlust ja dokumenteeritud teabe ohjet. Nii saavad projekti kirjetest usaldusväärne tõendusmaterjal, mitte hajutatud artefaktid.
Punkt 8.1 nõuab tegevuse planeerimist ja ohjet, dokumenteeritud teavet, mis näitab, et protsessid viidi läbi plaanipäraselt, kavandatud muudatuste ohjet, kavandamata muudatuste läbivaatamist, kahjulike mõjude leevendamist ning ISMS-i seisukohast asjakohaste väljastpoolt pakutavate protsesside, toodete või teenuste ohjet. Punktid 8.2 ja 8.3 nõuavad infoturbe riskihindamisi ja riskikäsitlust kavandatud ajavahemike järel või oluliste muudatuste korral.
Seejärel seob lisa A selle juhtimistsükli praktiliste kontrollimeetmetega. IKT-projektides turvalisuse kavandamisest alates on kesksed kolm ISO/IEC 27001:2022 lisa A kontrollimeedet:
| ISO/IEC 27001:2022 kontrollimeede | Kontrollimeetme nimetus | Miks see on IKT-projektide jaoks oluline |
|---|---|---|
| A.5.8 | Infoturve projektijuhtimises | Lõimib turvalisuse kõigisse projektietappidesse ja loob juhtimise tõendusmaterjali enne riskipositsiooni tekkimist |
| A.8.25 | Turvaline arenduse elutsükkel | Lõimib turbenõuded, turvalise disaini, turvalise programmeerimise, testimise ja juurutusdistsipliini |
| A.8.32 | Muudatuste juhtimine | Tagab, et tootmiskeskkonna muudatused on kavandatud, riskihinnatud, testitud, heaks kiidetud, seiratud ja läbivaadatavad |
Clarysec Zenith Blueprint: audiitori 30-sammuline teekaart käsitleb infoturvet projektijuhtimises juhtimisküsimusena kõigi projektitüüpide puhul, mitte ainult tarkvaraarenduses:
„Iga projekt – turundussüsteemi migreerimine, hoone kolimine, äriprotsessi ümberkujundamine, HR-i sisseelamisplatvorm või isegi ühinemine või omandamine – võib mõjutada teabe konfidentsiaalsust, terviklust või käideldavust. Kui see juhtub, peab turvalisusel olema koht otsustuslaua taga.”
Sama jaotis võtab kokku rakendamise põhitunni:
„Selle kontrollimeetme eesmärk ei ole koormata projekte bürokraatiaga. Eesmärk on tagada, et turvalisust käsitletakse disainisisendina, mitte testimisetapina.”
See eristus lahutab vastavusteatri kaitstavast turvalisusest kavandamisest alates.
Kuidas turvalisus kavandamisest alates IKT-projektis välja näeb
Turvalisus kavandamisest alates algab enne esimest sprinti, hanketaotlust, arhitektuuriskeemi või migratsiooni tööjuhist. See esitab lihtsa küsimuse: mida võib see projekt riskis muuta?
Praktiline projektijuhtimise mudel kasutab seitset tõendusmaterjali väravat.
| Projekti värav | Turvalisuse kavandamisest alates tõendusmaterjal | Tüüpiline omanik | Ristvastavuse väärtus |
|---|---|---|---|
| Algatamine | Projekti turvaklassifikatsioon, mõjutatud teenused, regulatiivne kohaldatavus, andmekategooriad, kriitilisus | Projekti sponsor ja CISO | Toetab ISO kohaldamisala, NIS2 riskimeetmeid, DORA kriitilise funktsiooni analüüsi, GDPR vastutust |
| Nõuded | Turbenõuded, privaatsusnõuded, toimepidevuse nõuded, tarnijanõuded | Tooteomanik, turbejuht, DPO, hange | Toetab turvalist hankimist, lõimitud andmekaitse põhimõtet ja kolmandate osapoolte klausleid |
| Disain | Arhitektuuri ülevaatus, ohumudel, andmevoogude kaart, usalduspiirid, krüptograafiaotsused | Arhitektuuri- ja turbemeeskonnad | Toetab turvalist arendust, GDPR andmekaitset ja DORA IKT-riski kontrollimeetmeid |
| Arendus või konfiguratsioon | Turvalise programmeerimise kirjed, komponentide register, sõltuvusrisk, konfiguratsiooni lähtealused | Arendus- või platvormimeeskond | Toetab haavatavuste käsitlemist ja tarkvara tarneahela turvalisust |
| Testimine | Turbetestide tulemused, kuritarvituse juhtumid, haavatavuse skannimised, vajaduse korral varundus- ja taastamistestid | QA, turbe- ja käitlusmeeskonnad | Toetab DORA testimist, NIS2 tõhususe hindamist ja ISO tõendusmaterjali |
| Muudatuse heakskiit | Riski aktsepteerimine, tagasipööramiskava, seireplaan, intsidentide eskaleerimise uuendused | Muudatuste nõukogu või delegeeritud heakskiitjad | Toetab ISO muudatuste ohjet, DORA juhtimisaruandlust ja talitluspidevust |
| Rakendamisjärgne etapp | Õppetunnid, jääkriski ülevaatus, tarnijate seire, kontrollimeetmete tõhususe ülevaatus | Teenuseomanik ja ISMS-i juht | Toetab pidevat täiustamist ja auditivalmidust |
Eesmärk ei ole bürokraatia. Eesmärk on teha turvalisus nähtavaks seal, kus projektiotsused tegelikult tehakse.
Clarysec Enterprise Infoturbepoliitika sõnastab selle otse:
„Turbejuhtimine tuleb lõimida ettevõtte valitsemise, projektijuhtimise, hanke ja õigusliku järelevalve funktsioonidega, et tagada, et infoturve ei oleks eraldiseisev, vaid lõimitud kogu ärilisse otsustamisse.”
Jaotisest „Juhtimisnõuded”, poliitika punkt 5.5.
Samuti käsitleb see projekti elutsükleid rakendamise osana:
„Projekti elutsüklid (nt turvaline arendus, ohumudeldamine)”
Jaotisest „Poliitika rakendamise nõuded”, poliitika punkt 6.3.1.1.
Ning see sõnastab auditi põhimõtte, mille paljud organisatsioonid avastavad liiga hilja:
„Kõik rakendatud kontrollimeetmed peavad olema auditeeritavad, toetatud dokumenteeritud protseduuridega ja säilitatud toimimise tõendusmaterjaliga.”
Jaotisest „Poliitika rakendamise nõuded”, poliitika punkt 6.6.1.
Teisisõnu: turvatöö, mida ei juhita, säilitata ega kaardistata, kukub auditis sageli läbi isegi siis, kui tehnilised meeskonnad tegid mõistlikke otsuseid.
Ohumudeldamisest tõendusmaterjalini: praktiline fintech-näide
Kujutlege projekti, mille eesmärk on käivitada fintech-ettevõttele uus EL-i klientide liitumisportaal. Portaal kogub isikut tõendavaid dokumente, teeb kolmanda osapoole kaudu biomeetrilist kontrolli, talletab liitumisstaatust, integreerub CRM-iga, käivitab klienditeavitusi ja edastab andmeid riskiskoorimiseks.
Turvalisuse kavandamisest alates lähenemine looks tõendusmaterjali projekti edenemise käigus.
Esiteks avage projekti turvaklassifikatsiooni kirje. Tuvastage, kas projekt mõjutab kriitilisi või olulisi funktsioone, isikuandmeid, isikuandmete eriliike, autentimist, kliendile suunatud käideldavust, allhangitud IKT-teenuseid, reguleeritud aruandlusprotsesse või kliendisuhtlust. GDPR kohaselt on unikaalseks tuvastamiseks kasutatavad biomeetrilised andmed isikuandmete eriliik, välja arvatud juhul, kui kohaldub konkreetne erand. See tõstab kohe nõutava õigusliku analüüsi ja kaitsemeetmete taset.
Teiseks koostage projekti riskihindamine. Clarysec SME Riskijuhtimise poliitika muudab riskijuhtimise planeerimise osaks, mitte kvartalipõhiseks tabeliharjutuseks:
„1.2 See tagab, et riskijuhtimine on aktiivne osa planeerimisest, projekti elluviimisest, tarnija valikust ja intsidentidele reageerimisest kooskõlas ISO 27001, ISO 31000 ja kohaldatavate regulatiivsete nõuetega.”
Jaotisest „Eesmärk”, poliitika punkt 1.2.
Ettevõtte keskkondade jaoks määratleb Clarysec Enterprise Riskijuhtimise poliitika kohaldamisala projekti- ja tehnilistel tasanditel:
„See hõlmab infoturberiske strateegilisel, operatiivsel, projekti- ja tehnilisel tasandil ning on kohustuslik kogu personalile, töövõtjatele ja teenuseosutajatele, kes osalevad Infoturbe juhtimissüsteemi (ISMS) tegevustes.”
Jaotisest „Kohaldamisala”, poliitika punkt 2.3.
Kolmandaks tehke ohumudel enne arenduse algust. Enterprise Turvalise arenduse poliitika on selgesõnaline:
„Kõik uued rakendused ja olulised muudatused peavad enne arenduse algust läbima turvalise arhitektuuri ülevaatuse ja ohumudeldamise.”
Jaotisest „Poliitika rakendamise nõuded”, poliitika punkt 6.1.1.
Liitumisportaali puhul peab ohumudel hõlmama avatud liideseid, identiteedivooge, privileegipiire, API kuritarvituse juhtumeid, webhook’i võltsimist, kordusründeid, kompromiteeritud autentimisandmeid, andmelekke teid, sõltuvusriski, logimisnõudeid, varundamise eeldusi, taastenõudeid ja teenuseosutaja tõrkerežiime.
Neljandaks ajakohastage privaatsuse tõendusmaterjal. SME Andmekaitse ja privaatsuspoliitika määrab baastaseme:
„5.3.1. Kõigis uutes süsteemides ja teenustes tuleb rakendada lõimitud andmekaitset ja vaikimisi andmekaitset”
Jaotisest „Juhtimisnõuded”, poliitika punkt 5.3.1.
Projekti kirje peab sisaldama eesmärki, õiguslikku alust, vastutava töötleja või volitatud töötleja rolli, andmete minimaalsuse otsuseid, säilitamisreegleid, juurdepääsurolle, krüptimisvalikuid, andmesubjekti mõju kaalutlusi, läbipaistvusnõudeid, volitatud töötleja tingimusi ja isikuandmetega seotud rikkumisest teavitamise teid.
Viiendaks registreerige turvalise arenduse tõendusmaterjal. SME Turvalise arenduse poliitika annab lühikese tõendusmaterjali loetelu, mis sobib väikestele ja keskmise suurusega meeskondadele:
„5.3 Tegevjuht (GM) peab säilitama kirjed järgmise kohta: 5.3.1 kõik aktiivsed tarkvaraarenduse projektid ja vastutavad arendajad või tarnijad 5.3.2 iga projekti puhul kasutatud turbekontrollnimekirjad 5.3.3 tehtud koodi läbivaatused ja neid teinud isikud 5.3.4 testitulemused enne juurutamist 5.3.5 kolmandate osapoolte komponendid ja nendega seotud litsentsimis- või riskistaatus”
Jaotisest „Juhtimisnõuded”, poliitika punkt 5.3.
Kuuendaks juhtige juurutamist muudatusena. SME Muudatuste haldamise poliitika sätestab:
„1.1 See poliitika tagab, et kõik IT-süsteemide, konfiguratsioonide, ärirakenduste või pilveteenuste muudatused on enne rakendamist kavandatud, riskihinnatud, testitud ja heaks kiidetud.”
Jaotisest „Eesmärk”, poliitika punkt 1.1.
Liitumisportaali puhul peab muudatuse pilet sisaldama mõjutatud teenuseid, riskihindamist, testitulemusi, tagasipööramiskava, seireplaani, turbe heakskiite, privaatsuse kinnitust, tarnija valmisolekut, intsidentide eskaleerimise uuendusi ja kliendisuhtluse käivitajaid.
Lõpuks kaardistage kohustused. SME Õigusnormidele vastavuse poliitika annab tegevusreegli:
„5.2.2 Kui regulatsioon kohaldub mitmele valdkonnale (nt GDPR kohaldub säilitamisele, turvalisusele ja privaatsusele), tuleb see selgelt kaardistada vastavusregistris ja koolitusmaterjalides.”
Jaotisest „Juhtimisnõuded”, poliitika punkt 5.2.2.
Sellest vastavusregistrist saab sild ISO/IEC 27001:2022 kontrollimeetmete, NIS2 Article 21 meetmete, DORA IKT-riski kohustuste, GDPR vastutuse ja kliendilepingute kohustuste vahel.
Ühe projekti tõendusmaterjali paketi kaardistamine NIS2, DORA, GDPR ja NIST CSF 2.0 nõuetega
Kõige tõhusam vastavusstrateegia ei ole töö dubleerimine. See on ühe tugeva tõendusmaterjali kogumi kaardistamine mitme kohustusega.
Zenith Blueprint soovitab riskijuhtimise etapis, 14. sammus, sellist ristviitamist:
„Iga kohaldatava regulatsiooni kohta võite koostada lihtsa kaardistustabeli (näiteks aruande lisana), mis loetleb regulatsiooni peamised turbenõuded ja vastavad kontrollimeetmed/poliitikad teie ISMS-is.”
Lisaks märgib see, et see on kasulik, sest näitab audiitoritele ja hindajatele, „et te ei juhi turvalisust vaakumis, vaid tunnete õiguslikku konteksti.”
Clarysec Zenith Controls: ristvastavuse juhend toetab sama integreeritud lähenemist, kaardistades ISO/IEC 27001:2022 kontrollimeetmed teiste raamistike, auditi ootuste ja vastavusvajadustega. IKT-projektide juhtimises käsitleb see A.5.8, A.8.25 ja A.8.32 ennetavate kontrollimeetmetena, mis kaitsevad konfidentsiaalsust, terviklust ja käideldavust juhtimise, rakendusturbe, ökosüsteemi, kaitse ning süsteemi- ja võrguturbe valdkondades.
| Tõendusmaterjali artefakt | ISO/IEC 27001:2022 eesmärk | NIS2 väärtus | DORA väärtus | GDPR väärtus |
|---|---|---|---|---|
| Projekti turvaklassifikatsioon | Määratleb kohaldamisala, huvitatud osapooled, sõltuvused ja operatiivse ohje | Näitab mõjutatud süsteemide ja teenuste riskipõhist tuvastamist | Tuvastab mõju kriitilisele või olulisele funktsioonile | Tuvastab isikuandmed, rollid ja töötlemiskonteksti |
| Ohumudel | Toetab riskihindamist ja turvalise arenduse kontrollimeetmeid | Toetab turvalist hankimist, arendust ja haavatavuste käsitlemist | Toetab IKT-riski raamistikku ja toimepidevuse strateegiat | Toetab lõimitud andmekaitset ja asjakohaseid kaitsemeetmeid |
| Tarnija hoolsuskontroll ja lepingu ülevaatus | Toetab tarnija ja IKT tarneahela kontrollimeetmeid | Toetab tarneahela turvalisust ja otsest tarnija hindamist | Toetab IKT kolmanda osapoole riski, auditeerimisõigusi ja väljumisplaneerimist | Toetab volitatud töötleja kaitsemeetmeid ja töötlemisjuhiseid |
| Turvalise arenduse ja testimise kirjed | Toetab turvalist SDLC-d, haavatavuste haldust ja muudatuseks valmisolekut | Toetab turvalist arendust ja tõhususe hindamist | Toetab toimepidevuse testimist ja parandusmeetmeid | Toetab töötlemise turvalisust ja rikkumisriski vähendamist |
| Muudatuse heakskiidu kirje | Toetab kavandatud muudatusi, läbivaatamist ja kahjulike mõjude leevendamist | Toetab riskipõhist rakendamist | Toetab juhtimisaruandlust ja talitluspidevust | Toetab vastutust isikuandmeid mõjutavate süsteemimuudatuste eest |
| Intsidendi- ja seireuuendus | Toetab logimist, seiret, intsidentide planeerimist ja tõendite kogumist | Toetab intsidentide käsitlemist ja teavitamisvalmidust | Toetab olulise IKT-intsidendi klassifitseerimist ja eskaleerimist | Toetab isikuandmetega seotud rikkumise tuvastamist ja reageerimist |
| Vastavusregistri kaardistus | Toetab õiguslikke ja regulatiivseid nõudeid ning dokumenteeritud teavet | Tõendab Article 21-ga kooskõla | Tõendab DORA raamistiku lõimimist | Tõendab vastutust põhimõtete lõikes |
See tabel ei asenda õiguslikku analüüsi. See on juhtimise kiirendi. See tagab, et infoturbejuht, DPO, projekti sponsor, hankejuht, süsteemiomanik ja siseaudiitor vaatavad sama tõendusmaterjali.
NIST CSF 2.0 sobitub sellesse mudelisse samuti loomulikult. Selle GOVERN Function aitab organisatsioonidel kehtestada poliitikad, rollid, riskivalmiduse, järelevalve ning õigusliku või lepingulise teadlikkuse. Selle IDENTIFY, PROTECT, DETECT, RESPOND ja RECOVER Functions aitavad meeskondadel arutada varasid, tarnijateenuseid, juurdepääsukontrolli, andmeturvet, platvormiturvet, turvalist tarkvaraarendust, seiret, intsidentidele reageerimist ja taastet ühises tegevuskeeles.
| Regulatiivne või raamistiku nõue | Kuidas ISO 27001 projektijuhtimine tõendusmaterjali annab |
|---|---|
| DORA Article 5, Governance and organisation | Näitab juhtkonna järelevalvet, määratletud vastutusi, eskaleerimisteid ja IKT-riski otsuste heakskiitu |
| DORA Article 6, ICT risk management framework | Loob projekti taseme IKT-riski hindamised, käsitluskirjed, toimepidevuse nõuded ja kontrollimeetmete tõendusmaterjali |
| DORA Article 28, ICT third-party risk | Dokumenteerib tarnija hoolsuskontrolli, lepingulised kaitsemeetmed, auditeerimisõigused, väljumisplaneerimise ja pideva seire |
| NIS2 Article 20, Governance | Näitab küberturbe riskijuhtimise meetmete juhtkonnapoolset heakskiitu ja järelevalvet |
| NIS2 Article 21(2)(d), Supply chain security | Registreerib tarnija hindamise, hankekriteeriumid, teenuseosutaja riskid ja lepingulised turbenõuded |
| NIS2 Article 21(2)(e), Secure acquisition, development and maintenance | Hõlmab turvalisi nõudeid, arhitektuuri ülevaatust, haavatavuste käsitlemist, testimist ja parandusmeetmete tõendusmaterjali |
| GDPR Article 25, Data protection by design and by default | Näitab privaatsusnõudeid, minimaalsust, säilitamist, juurdepääsukontrolli, volitatud töötleja kaitsemeetmeid ja vajaduse korral DPIA tulemusi |
| NIST CSF 2.0 GV.PO-01 ja GV.PO-02 | Tõendab, et küberturbe poliitikad on kehtestatud, edastatud, rakendatud, läbi vaadatud ja ajakohastatud projekti elluviimise käigus |
Üks ISO 27001-ga kooskõlas olev protsess, mille keskmes on lisa A.5.8, võib luua kaitstava tõendusmaterjali kõigi nende ootuste jaoks.
Turvaline arendus on laiem kui koodi kirjutamine
Paljud IKT-projektide tõrked tekivad seetõttu, et organisatsioon käsitleb turvalist arendust millegina, mida teevad ainult arendajad. 2026. aastal hõlmab turvaline arendus ka SaaS-i konfiguratsiooni, töövoo automatiseerimist, taristut koodina, API-integratsioone, identiteedireegleid, pilve maandumistsoone, analüütikatorustikke, robotprotsesside automatiseerimist ja low-code ärirakendusi.
Zenith Blueprint käsitleb etapis Controls in Action, 20. sammus, ISO/IEC 27002:2022 kontrollimeedet 8.25 Secure Development Life Cycle:
„See kontrollimeede kohaldub olenemata sellest, kas kirjutate oma rakendusi, konfigureerite platvorme nagu ERP- või CRM-süsteemid, kohandate SaaS-töövooge või haldate taristu-koodina keskkondi.”
Samuti selgitab see, et turbenõuded peavad paiknema funktsionaalsete nõuete kõrval ning ohumudeldamine aitab tuvastada süsteemi avatud osi, riskantseid kasutajarolle ja kõrgemat kaitset vajavaid andmevooge.
Tänapäevase projekti puhul võib turvalise arenduse tõendusmaterjal sisaldada järgmist:
- Turbenõuded, mis on seotud ärinõuetega
- Ohumudel või turvalise arhitektuuri ülevaatus
- Turvalise programmeerimise või turvalise konfiguratsiooni kontrollnimekiri
- Koodi läbivaatuse või vastastikuse hindamise kirjed
- Komponentide register ja sõltuvusriski staatus
- Saladuste halduse otsused
- Juurdepääsukontroll ja vähima privileegi põhimõtte disain
- Logimise ja seire nõuded
- Haavatavuse skannimise tulemused ja parandusmeetmete kirjed
- Tootmiskeskkonna-eelne turbetestimine
- Vajaduse korral varundus-, taaste- ja toimepidevuse testimine
- Juurutuse heakskiidu ja tagasipööramise tõendusmaterjal
Eesmärk ei ole sundida iga projekti läbi sama raskekaallise protsessi. Eesmärk on proportsionaalsus. Väike sisemise töövoo muudatus ei vaja sama tõendusmaterjali kui põhimakseplatvormi migreerimine. Kuid iga projekt tuleb klassifitseerida, riskihinnata ja juhtida vastavalt mõjule.
Muudatuste juhtimine kaitseb projekti iseenda eest
Paljudes projektides ei ole kõige riskantsem hetk disain ega koodi kirjutamine. See on juurutamine.
Meeskond võib teha ohumudeldamise, koodi läbivaatuse, tarnija hindamise ja privaatsuse ülevaatuse, kuid tekitada siiski kiirustatud tootmiskeskkonna muudatusega katkestuse või rikkumise. Silumislipp jääb sisse. Tulemüüri reegel on heakskiidetust laiem. Migratsiooniskript kopeerib isikuandmed tootmisvälisesse keskkonda. Kolmanda osapoole webhook’i lõpp-punkt juurutatakse ilma autentimiseta. Logimise muudatus salvestab isikut tõendavate dokumentide numbreid. Varundustöö ebaõnnestub pärast üleminekut vaikselt.
Zenith Blueprint kirjeldab etapis Controls in Action, 21. sammus, ISO/IEC 27002:2022 kontrollimeedet 8.32 Change Management otsekoheselt:
„Muutus on vältimatu, kuid küberturbes on ohjeldamata muutus ohtlik.”
See jätkub:
„Tõhusa muudatuste juhtimise tuum on korratav töövoog. See algab selge ettepanekuga, milles kirjeldatakse, mis muutub, miks, millal ja millised on võimalikud riskid.”
Tugev IKT muudatuse kirje peab vastama järgmistele küsimustele:
- Milline süsteem, teenus, andmevoog, tarnija või konfiguratsioon muutub?
- Millised riskid tuvastati ja kes on nende omanik?
- Kas muudatus mõjutab isikuandmeid, kriitilisi teenuseid, autentimist, logimist, varukoopiaid või intsidentidele reageerimist?
- Millised turbe-, privaatsus-, toimepidevuse ja tarnijakontrollid tehti?
- Millised testid viidi lõpule enne juurutamist?
- Milline seire kinnitab ootuspärast käitumist?
- Milline tagasipööramis- või taasteplaan on olemas?
- Kes kiitis jääkriski heaks?
- Milline tõendusmaterjal säilitatakse?
DORA puhul toetab see dokumenteeritud IKT-riski juhtimist, toimepidevust, talitluspidevust, intsidentide klassifitseerimist ja õppetunde. NIS2 puhul toetab see riskijuhtimise meetmeid, turvalist arendust, intsidentide ennetamist ja talitluspidevust. GDPR puhul aitab see tõendada, et isikuandmeid mõjutavad muudatused vaadati läbi eesmärgi, minimaalsuse, säilitamise, juurdepääsu ja turvapõhimõtete suhtes.
Tarnija- ja pilveotsused peavad olema projekti disaini osa
Tänapäevastes IKT-projektides on kõige suurema riskiga disainiotsus sageli „osta”, mitte „ehita”. Pilveteenused, API-pakkujad, identiteedikontrolli platvormid, maksetöötlejad, analüütikatarnijad, hallatud teenusepakkujad ja hallatud turvateenuste pakkujad muutuvad riskipinna osaks.
NIS2 hõlmab sõnaselgelt tarneahela turvalisust, otseste tarnijate ja teenuseosutajate haavatavusi, tarnijate küberturbepraktikaid, turvalise arenduse protseduure ja koordineeritud tarneahela riskihindamise tulemusi. DORA läheb finantsüksuste puhul sügavamale. See nõuab IKT kolmandate osapoolte riskijuhtimist IKT-riski juhtimise raamistiku osana, jätkuvat vastutust ka siis, kui IKT-teenused on allhangitud, teaberegistreid, lepingueelseid hindamisi, kontsentratsiooniriski analüüsi, lepingulisi kontrollimeetmeid, auditi- ja inspekteerimisõigusi, lõpetamise käivitajaid ning testitud väljumisstrateegiaid kriitiliste või oluliste funktsioonide jaoks.
Liitumisportaali puhul ei saa biomeetrilise kontrolli pakkujat heaks kiita ainult seetõttu, et hankele meeldib hind ja API dokumentatsioon on hea. Projekt vajab tõendusmaterjali turbe hoolsuskontrolli, töötlemisrolli, andmete asukoha, alltöötlejate, käideldavuskohustuste, intsidentide toe, auditeerimisõiguste, lõpetamisabi, väljumise teostatavuse ja seirekohustuste kohta.
Küpses tõendusmaterjali mudelis paiknevad tarnija- ja pilveotsused projekti tõendusmaterjali paketis, mitte eraldi tarnijakaustas. Kui audiitor küsib, miks kolmas osapool aktsepteeriti, peab vastus sisaldama ärivajadust, riskihindamist, lepingulisi kaitsemeetmeid, andmekaitse ülevaatust, mõju toimepidevusele ja pidevat seiret.
Kuidas audiitorid turvalisuse kavandamisest alates tõendusmaterjali läbi vaatavad
Erinevad audiitorid lähenevad samale IKT-projektile eri nurkadest. Sertifitseerimisaudiitor, siseaudiitor, DORA läbivaataja, NIS2 pädev asutus, privaatsusaudiitor, NIST-põhine hindaja või COBIT-stiilis audiitor võivad küsida sarnast tõendusmaterjali, kuid tõlgendada seda erinevalt.
| Auditi vaatenurk | Mida audiitor küsib | Tõendusmaterjal, mis tavaliselt küsimuse rahuldab |
|---|---|---|
| ISO/IEC 27001:2022 audiitor | Kas infoturve oli lõimitud projektijuhtimisse ja tegevuse planeerimisse ning kas riskikäsitluse otsused on dokumenteeritud? | Projekti põhikiri, riskihindamine, SoA kaardistus, käsitlusplaan, etapi värava heakskiidud, dokumenteeritud teabe kontrollimeetmed |
| NIST CSF 2.0 hindaja | Kas juhtimise, riski, tarnija, kaitse, tuvastamise, reageerimise ja taastamise tulemused kajastuvad projektiotsustes? | Current and Target Profile, lünkade plaan, tarnijaregister, juurdepääsudisain, seireplaan, intsidendi- ja taastamisprotseduurid |
| COBIT- või ISACA-stiilis audiitor | Kas eesmärgid, omandivastutus, protsessikontrollid, otsustusõigused ja toimivuse seire on selged? | RACI, juhtimise koosolekuprotokollid, kontrollimeetmete omanikud, KPI ja KRI aruanded, muudatuste heakskiidud, siseauditi leiud |
| DORA läbivaataja | Kas projekt mõjutab kriitilisi või olulisi funktsioone, IKT kolmandate osapoolte sõltuvusi, toimepidevuse testimist või intsidentidest teatamist? | Kriitilisuse hindamine, IKT-riski kirje, tarnijaregister, lepinguklauslid, testitulemused, intsidendi klassifikatsiooni uuendused |
| GDPR või privaatsusaudiitor | Kas projekt rakendas lõimitud andmekaitset, õiguslikku alust, minimaalsust, säilitamist, turvalisust ja vastutust? | Andmevoogude kaart, õigusliku aluse kirje, vajaduse korral DPIA, juurdepääsumaatriks, säilitamisreeglid, volitatud töötleja tingimused, rikkumise tööjuhise uuendused |
Audiitorid ei soovi ilusat projekti slaidipakki. Nad soovivad jälgitavust. Nad tahavad näha, et nõuded viisid riskideni, riskid viisid kontrollimeetmeteni, kontrollimeetmed viisid rakendamise tõendusmaterjalini ja rakendamine viis läbivaatamiseni.
Seetõttu on Zenith Controls auditiks ettevalmistamisel kasulik. See aitab meeskondadel selgitada, miks lisa A.5.8, A.8.25 ja A.8.32 on ennetavad kontrollimeetmed, mis kaitsevad konfidentsiaalsust, terviklust ja käideldavust enne, kui prognoositavad rikked jõuavad tootmiskeskkonda.
Clarysec projekti minimaalne tõendusmaterjali pakett
Tugev turvalisuse kavandamisest alates tõendusmaterjali pakett ei pea olema tohutu. See peab olema järjepidev, proportsionaalne ja kaardistatud.
Keskmise riskiga IKT-projekti puhul soovitab Clarysec tavaliselt järgmist minimaalset paketti:
- Projekti turvaklassifikatsiooni kirje
- Regulatiivse kohaldatavuse märkus, mis hõlmab NIS2, vajaduse korral DORA, GDPR ja lepingulisi kohustusi
- Andmevoogude ja varade mõjukaart
- Projekti riskihindamine ja käsitlusplaan
- Ohumudel või turvalise arhitektuuri ülevaatus
- Vajaduse korral tarnija ja pilveteenuse hindamine
- Turvalise arenduse kontrollnimekiri või konfiguratsiooni kontrollnimekiri
- Turbetestide tulemused ja parandusmeetmete tõendusmaterjal
- Muudatuse heakskiit koos tagasipööramis- ja seireplaaniga
- Lõimitud andmekaitse kirje, sealhulgas õiguslik alus ja säilitamine, kui kaasatud on isikuandmed
- Intsidentidele reageerimise ja seire uuendused
- Rakendamisjärgne läbivaatamine ja õppetunnid
- Vastavusregistri kaardistus kontrollimeetmete ja kohustustega
Zenith Blueprint annab teekaardi loogika. 22. samm toob infoturbe kõigisse projektietappidesse. 20. samm lõimib turvalise arenduse planeerimisse, disaini, koodi, testimisse ja juurutusse. 21. samm muudab muudatuste juhtimise struktureerituks, jälgitavaks ja läbivaadatavaks. 14. samm soovitab ristviitamist GDPR, NIS2, DORA ja muude kohustustega, et vastavusnõuded ei jääks tähelepanuta.
Poliitikad annavad tegevusreeglid. Infoturbepoliitika lõimib turvalisuse projektijuhtimise, hanke ja õigusliku järelevalvega. Riskijuhtimise poliitika muudab projektiriskid ISMS-i tegevuse osaks. Turvalise arenduse poliitika nõuab ohumudeldamist. Muudatuste haldamise poliitika nõuab kavandatud, riskihinnatud, testitud ja heaks kiidetud muudatusi. Andmekaitse ja privaatsuspoliitika nõuab lõimitud andmekaitset ja vaikimisi andmekaitset. Õigusnormidele vastavuse poliitika nõuab mitut valdkonda hõlmavate regulatsioonide kaardistamist vastavusregistris.
Koos muudavad need tööriistad turvalisuse kavandamisest alates püüdlusest auditeeritavaks tegevusmudeliks.
Levinud tõrkemustrid IKT-projektides
Tõrked on tavaliselt etteaimatavad.
Esimene on turbe hiline kaasamine. Turbeülevaatused toimuvad pärast seda, kui arhitektuur on fikseeritud, lepingud sõlmitud ja tarnekuupäevad avalikud. Sel hetkel muutub turvalisus takistajaks, mitte disainisisendiks.
Teine on killustunud tõendusmaterjal. Projektil on testitulemused ühes tööriistas, tarnija ülevaatus teises, privaatsuskommentaarid e-kirjas, riski aktsepteerimine koosoleku salvestises ja muudatuse heakskiit piletis. Ükski terviklik lõim ei tõenda juhtimist.
Kolmas on tarnijatega seotud pimeala. Projekt tugineb pilveteenusele või API-pakkujale, kuid keegi ei kontrolli alltöötlejaid, andmete asukohta, auditeerimisõigusi, intsidentide tuge, väljumisplaane ega kontsentratsiooniriski.
Neljas on privaatsuse triiv. Ühe eesmärgi jaoks loodud süsteem hakkab toetama analüütikat, AI katsetamist, turundusekspordiks andmete väljastamist või operatiivset seiret, ilma et uuesti hinnataks õiguslikku alust, läbipaistvust, minimaalsust või säilitamist.
Viies on läbivaatamata muudatus. Tootmiskeskkonda juurutamine kiidetakse heaks funktsionaalsuse tõttu, kuid seda ei hinnata juurdepääsu, logimise, krüptimise, varundamise, toimepidevuse, isikuandmete või aruandlusmõju suhtes.
Kuues on nõrk juhtkonna järelevalve. Suure mõjuga projektiriskid aktsepteeritakse liiga madalal tasemel, ilma tõendusmaterjalita, et vastutav riskiomanik mõistis regulatiivseid tagajärgi.
Neid probleeme ei lahenda järjekordse skanneri ostmine. Need lahendatakse turbejuhtimise lõimimisega sellesse, kuidas projekte välja pakutakse, disainitakse, hangitakse, arendatakse, testitakse, muudetakse ja läbi vaadatakse.
2026. aasta sõnum infoturbejuhile
Turvalisus kavandamisest alates IKT-projektides on nüüd juhatuse, auditi ja regulatiivne teema. NIS2 muudab küberturbe riskijuhtimise juhtorgani küsimuseks. DORA muudab IKT-riski, toimepidevuse testimise, intsidendihalduse ja kolmandate osapoolte järelevalve struktureeritud finantssektori kohustuseks. GDPR nõuab vastutust isikuandmete töötlemise ja asjakohase turvalisuse eest. ISO/IEC 27001:2022 annab juhtimissüsteemi struktuuri, et muuta need kohustused operatiivseks.
Infoturbejuhtide jaoks on võimalus lõpetada projektitiimidega võitlemine tarne lõpus. Viige turvalisus algatamisse, nõuetesse, disaini, tarnija valikusse, arendusse, testimisse, muudatuse heakskiitmisse ja rakendamisjärgsesse läbivaatamisse.
Vastavusjuhtide jaoks on võimalus asendada hajutatud tõendusmaterjal ühe kaardistatud projekti tõendusmaterjali paketiga.
Audiitorite jaoks on võimalus testida projekti elutsüklit, mitte ainult lõppsüsteemi.
Äriomanike jaoks on võimalus kiiremaks ja turvalisemaks tarnimiseks. Turvalisus kavandamisest alates vähendab ümbertööd, ennetab vastavusüllatusi, parandab tarnijaotsuseid ja annab juhtkonnale kaitstava riskiloo.
Kui teie IKT-projektid liiguvad kiiremini kui teie tõendusmaterjali mudel, alustage ühest pilootprojektist. Kasutage Clarysec Zenith Blueprint lahendust projektide turvaväravate määratlemiseks, rakendage Clarysec poliitikaid riskijuhtimise, turvalise arenduse, muudatuste juhtimise ja privaatsuse jaoks ning kasutage Zenith Controls lahendust ISO/IEC 27001:2022 projektijuhtimise kaardistamiseks NIS2, DORA, GDPR ja NIST CSF 2.0-ga.
Clarysec saab aidata teil luua taaskasutatava turvalisuse kavandamisest alates projekti tõendusmaterjali paketi, viia selle kooskõlla teie ISMS-iga ning valmistada selle ette siseauditiks, sertifitseerimisauditiks, DORA valmisolekuks, NIS2 juhtimiseks ja GDPR vastutuseks.
Alustage oma järgmisest olulisest IKT-projektist. Kui see muudab süsteeme, tarnijaid, andmeid, juurdepääsu, toimepidevust või klientide usaldust, väärib see turvalisust kavandamisest alates esimesest päevast alates.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
