Drošība pēc projektējuma IKT projektu pārvaldībā 2026. gadā
Projekts tika pabeigts laikā, līdz audits uzdeva vienu jautājumu
Strauji augoša maksājumu tehnoloģiju uzņēmuma informācijas drošības vadītājam (CISO) bija labas ziņas valdei. Jaunā klientu sākotnējās piesaistes platforma bija gatava palaišanai. Produktu komanda bija nodrošinājusi mobilo lietotāja pieredzi, inženierijas komanda bija integrējusi identitātes verifikāciju, juridiskā funkcija bija parakstījusi līgumus ar mākoņpakalpojumu un API pakalpojumu sniedzējiem, un ekspluatācijas komanda bija izmēģinājusi ieviešanas produkcijas vidē plānu.
Tad iekšējais auditors uzdeva vienkāršu jautājumu:
“Parādiet, kur katrā projekta posmā tika izvērtēta drošība un privātums.”
Projekta telpā iestājās klusums.
Bija ielaušanās testēšanas pārskats, bet testēšana tika veikta vēlu. Bija mākoņarhitektūras shēma, bet nebija pierādījumu, ka datu plūsmas būtu pārskatītas pret GDPR principiem. Bija piegādātāju pienācīgas pārbaudes anketa, bet tā nebija sasaistīta ar risku reģistru. Bija izmaiņu pieteikums ieviešanai produkcijas vidē, bet apstiprinājumā nebija minēta ietekme uz kritiskiem pakalpojumiem, incidentu ziņošanu, noturības testēšanu, klientu informēšanu vai personas datu aizsardzības pārkāpuma eskalāciju juridiskajai funkcijai. Bija sprintu piezīmes, bet drošības prasības bija izkaisītas lietotājstāstos un tērzēšanas ziņās.
Nekas acīmredzami neliecināja par nolaidību. Viss izskatījās kā noslogots mūsdienīgs IKT projekts. Taču finanšu vienībai, uz kuru attiecas DORA, SaaS pakalpojumu sniedzējam, kas, iespējams, ir NIS2 piemērošanas jomā, un pārzinim vai apstrādātājam GDPR izpratnē jautājums vairs nebija tikai par to, vai drošība pastāv. Jautājums bija par to, vai drošību pēc projektējuma var pierādīt.
Tā ir 2026. gada problēma. IKT projektus vairs nevērtē tikai pēc piegādes ātruma, izmaksu kontroles un tehniskās kvalitātes. Tos vērtē pēc pārvaldības pierādījumiem: risku izvērtējumiem, projektējuma lēmumiem, piegādātāju pienācīgas pārbaudes, drošas izstrādes ierakstiem, izmaiņu apstiprinājumiem, privātuma lēmumiem, testēšanas rezultātiem un vadības pārraudzības.
ISO/IEC 27001:2022 organizācijām sniedz praktisku pārvaldības sistēmas mugurkaulu šīs problēmas risināšanai. Tas palīdz CISO, atbilstības vadītājiem, projektu sponsoriem, datu aizsardzības speciālistiem, arhitektiem, iepirkuma komandām un auditoriem pārvērst būtiskus IKT projektus pamatotos drošības pēc projektējuma pierādījumos.
Kāpēc IKT projektu pārvaldība tagad ir regulatīvo pierādījumu jautājums
Migrācija uz mākoņvidi, klientu portāls, maksājumu platforma, CRM ieviešana, identitātes nodrošinātāja maiņa, analītikas datu plūsma, API integrācija, SaaS darbplūsma, zemkoda lietotne vai pārvaldīta pakalpojuma pāreja — visi šie gadījumi var mainīt organizācijas riska profilu. 2026. gadā šādas izmaiņas notiek pārklājošos pienākumu apstākļos.
NIS2 plaši attiecas uz būtiskām un svarīgām vienībām Annex I un Annex II nozarēs, tostarp digitālo infrastruktūru, pārvaldīto pakalpojumu sniedzējiem, pārvaldīto drošības pakalpojumu sniedzējiem un digitālo pakalpojumu sniedzējiem. NIS2 Article 20 nosaka, ka vadības struktūras ir atbildīgas par kiberdrošības risku pārvaldības pasākumu apstiprināšanu un to ieviešanas pārraudzību. NIS2 Article 21 prasa atbilstošus un samērīgus tehniskos, operatīvos un organizatoriskos pasākumus risku pārvaldībai, incidentu apstrādei, darbības nepārtrauktībai, piegādes ķēdes drošībai, drošam iepirkumam, drošai izstrādei, ievainojamību apstrādei, efektivitātes izvērtēšanai, kiberdrošības higiēnai, kriptogrāfijai, piekļuves kontrolei, aktīvu pārvaldībai un drošai saziņai.
DORA attiecas uz finanšu vienībām un koncentrējas uz digitālo operacionālo noturību. DORA Article 5 nosaka vadības struktūras atbildību par IKT risku pārvaldību. DORA Article 6 prasa stabilu, visaptverošu un labi dokumentētu IKT risku pārvaldības ietvaru. DORA aptver arī ar IKT saistītu incidentu ziņošanu, operacionālās noturības testēšanu, IKT darbības nepārtrauktību, reaģēšanu un atjaunošanu, kiberdraudu informācijas apmaiņu, IKT trešo pušu risku pārvaldību, līgumiskās vienošanās un kritisko IKT trešo pušu pakalpojumu sniedzēju pārraudzību.
GDPR pievieno pārskatatbildības slāni personas datiem. GDPR Article 25 prasa integrētu datu aizsardzību un datu aizsardzību pēc noklusējuma. Pārziņiem jāspēj pierādīt atbilstība tādiem principiem kā likumība, godprātība, pārredzamība, nolūka ierobežošana, datu minimizēšana, glabāšanas ierobežošana, integritāte, konfidencialitāte un pārskatatbildība. Ja apstrāde, visticamāk, rada augstu risku, var būt nepieciešams arī datu aizsardzības ietekmes novērtējums saskaņā ar GDPR Article 35.
Kopīgais elements ir pierādījumi. Regulatori un auditori neprasa tikai, vai platforma tika šifrēta, ielāpota, skenēta vai testēta. Viņi jautā, vai organizācija var parādīt, ka drošība, privātums, piegādātāju risks un noturība bija daļa no lēmumu pieņemšanas jau no sākuma.
Tāpēc ISO/IEC 27001:2022 projektu pārvaldība ir tik spēcīga. Tā ļauj organizācijai pārvaldīt NIS2, DORA, GDPR, NIST CSF 2.0, līgumiskos pienākumus un klientu apliecinājumus, izmantojot vienu atkārtojamu IDPS procesu, nevis vairākus savstarpēji nesaistītus kontrolsarakstus.
ISO 27001 projektu pārvaldības mugurkauls
ISO/IEC 27001:2022 bieži tiek pārprasts kā sertifikācijas vingrinājums. IKT projektiem tā operatīvā vērtība ir plašāka. Tas nodrošina pārvaldības mugurkaulu biznesa izmaiņām.
Punkti 4.1 līdz 4.4 prasa organizācijām izprast iekšējos un ārējos jautājumus, ieinteresētās puses, tiesiskās, regulatīvās un līgumiskās prasības, IDPS darbības jomu, saskarnes un atkarības. Projektu kontekstā tas nozīmē, ka projekta hartā jāidentificē ietekmētie pakalpojumi, klienti, piegādātāji, regulējums, biznesa procesi, personas dati, kritiskās operācijas un ārpakalpojumi.
Punkti 5.1 līdz 5.3 prasa vadības apņemšanos, politiku saskaņošanu, resursus, integrāciju biznesa procesos un piešķirtas atbildības. Tas ir būtiski, jo gan NIS2, gan DORA kiberdrošību un IKT risku nosaka kā vadības struktūras atbildības jautājumu. Projekts, kas maina kritisku klientu platformu, nevar paļauties uz neformālu drošības komentāru tērzēšanas pavedienā. Tam ir vajadzīga skaidra pārskatatbildība.
Punkti 6.1.1 līdz 6.1.3 prasa atkārtojamu riska izvērtēšanas un apstrādes procesu, riska kritērijus, riska īpašniekus, konfidencialitātes, integritātes un pieejamības izvērtēšanu, riska apstrādes plānus, Piemērojamības paziņojumu un atlikušā riska apstiprināšanu. Tieši šeit projekta risks kļūst par audita pierādījumiem.
Punkti 7.1 līdz 7.5 prasa resursus, kompetenci, informētību, komunikāciju un dokumentētas informācijas kontroli. Tā projekta ieraksti kļūst par uzticamiem pierādījumiem, nevis izkaisītiem artefaktiem.
Punkts 8.1 prasa darbības plānošanu un kontroli, dokumentētu informāciju, kas apliecina, ka procesi veikti kā plānots, plānoto izmaiņu kontroli, neparedzētu izmaiņu pārskatīšanu, nelabvēlīgu seku mazināšanu un ārēji nodrošinātu procesu, produktu vai pakalpojumu kontroli, ja tie ir būtiski IDPS. Punkti 8.2 un 8.3 prasa informācijas drošības risku izvērtēšanu un apstrādi plānotos intervālos vai būtisku izmaiņu gadījumā.
A pielikums sasaista šo pārvaldības ciklu ar praktiskiem kontroles pasākumiem. Drošībai pēc projektējuma IKT projektos centrāli ir trīs ISO/IEC 27001:2022 A pielikuma kontroles pasākumi:
| ISO/IEC 27001:2022 kontroles pasākums | Kontroles nosaukums | Kāpēc tas ir būtisks IKT projektiem |
|---|---|---|
| A.5.8 | Informācijas drošība projektu pārvaldībā | Integrē drošību visos projekta posmos un izveido pārvaldības pierādījumus pirms rodas pakļautība riskam |
| A.8.25 | Drošas izstrādes dzīves cikls | Iestrādā drošības prasības, drošu projektējumu, drošu kodēšanu, testēšanu un izvietošanas disciplīnu |
| A.8.32 | Izmaiņu pārvaldība | Nodrošina, ka produkcijas vides izmaiņas tiek plānotas, izvērtētas pēc riska, testētas, apstiprinātas, uzraudzītas un pārskatītas |
Clarysec Zenith Blueprint: auditora 30 soļu ceļvedis informācijas drošību projektu pārvaldībā aplūko kā pārvaldības jautājumu visos projektu veidos, ne tikai programmatūras izstrādē:
“Jebkurš projekts — mārketinga sistēmas migrācija, ēkas pārcelšana, biznesa procesa pārveide, HR sākotnējās piesaistes platforma vai pat apvienošanās vai iegāde — var ietekmēt informācijas konfidencialitāti, integritāti vai pieejamību. Un, ja tā notiek, drošībai ir jābūt vietai pie lēmumu galda.”
Tā pati sadaļa precīzi formulē galveno ieviešanas mācību:
“Šī kontroles pasākuma mērķis nav noslogot projektus ar birokrātiju. Tā mērķis ir nodrošināt, ka drošība tiek uztverta kā projektēšanas ievade, nevis testēšanas posms.”
Šī atšķirība nošķir atbilstības teātri no pamatotas drošības pēc projektējuma.
Kā drošība pēc projektējuma izskatās IKT projektā
Drošība pēc projektējuma sākas pirms pirmā sprinta, iepirkuma pieprasījuma, arhitektūras shēmas vai migrācijas rokasgrāmatas. Tā uzdod vienkāršu jautājumu: ko šis projekts varētu mainīt riska ziņā?
Praktisks projektu pārvaldības modelis izmanto septiņus pierādījumu vārtus.
| Projekta vārti | Drošības pēc projektējuma pierādījumi | Tipiskais īpašnieks | Vērtība vairākām atbilstības prasībām |
|---|---|---|---|
| Uzsākšana | Projekta drošības klasifikācija, ietekmētie pakalpojumi, regulējuma piemērojamība, datu kategorijas, kritiskums | Projekta sponsors un CISO | Atbalsta ISO darbības jomu, NIS2 riska pasākumus, DORA kritisko funkciju analīzi, GDPR pārskatatbildību |
| Prasības | Drošības prasības, privātuma prasības, noturības prasības, piegādātāju prasības | Produkta īpašnieks, drošības vadītājs, datu aizsardzības speciālists, iepirkums | Atbalsta drošu iepirkumu, integrētu datu aizsardzību, trešo pušu klauzulas |
| Projektējums | Arhitektūras pārskatīšana, draudu modelis, datu plūsmas karte, uzticamības robežas, kriptogrāfijas lēmumi | Arhitektūras un drošības komandas | Atbalsta drošu izstrādi, GDPR datu aizsardzību, DORA IKT riska kontroles pasākumus |
| Izstrāde vai konfigurēšana | Drošas kodēšanas ieraksti, komponentu uzskaite, atkarību risks, bāzes konfigurācijas | Inženierijas vai platformas komanda | Atbalsta ievainojamību apstrādi un programmatūras piegādes ķēdes drošību |
| Testēšana | Drošības testēšanas rezultāti, ļaunprātīgas izmantošanas gadījumi, ievainojamību skenēšana, rezerves kopiju un atjaunošanas testi, ja attiecināms | QA, drošība, ekspluatācija | Atbalsta DORA testēšanu, NIS2 efektivitātes izvērtēšanu, ISO pierādījumus |
| Izmaiņu apstiprināšana | Riska pieņemšana, atcelšanas plāns, uzraudzības plāns, incidentu eskalācijas atjauninājumi | Izmaiņu konsultatīvā padome (CAB) vai deleģētie apstiprinātāji | Atbalsta ISO izmaiņu kontroli, DORA pārvaldības ziņošanu, operacionālo noturību |
| Pēc ieviešanas | Gūtās mācības, atlikušā riska pārskatīšana, piegādātāju uzraudzība, kontroles efektivitātes pārskatīšana | Pakalpojuma īpašnieks un IDPS vadītājs | Atbalsta nepārtrauktu pilnveidi un gatavību auditam |
Mērķis nav birokrātija. Mērķis ir padarīt drošību redzamu tur, kur projekta lēmumi faktiski tiek pieņemti.
Clarysec Enterprise Informācijas drošības politika to formulē tieši:
“Drošības pārvaldība jāintegrē ar uzņēmuma pārvaldību, projektu vadību, iepirkumu un juridiskās pārraudzības funkcijām, lai nodrošinātu, ka informācijas drošība nav izolēta, bet ir iestrādāta visā biznesa lēmumu pieņemšanā.”
No sadaļas “Pārvaldības prasības”, politikas punkts 5.5.
Tā arī nosaka projekta dzīves ciklus kā ieviešanas jautājumu:
“Projektu dzīves cikli (piem., droša izstrāde, draudu modelēšana)”
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.3.1.1.
Un tā nosaka audita principu, ko daudzas organizācijas atklāj pārāk vēlu:
“Visiem ieviestajiem kontroles pasākumiem jābūt auditējamiem, atbalstītiem ar dokumentētām procedūrām un saglabātiem darbības pierādījumiem.”
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.6.1.
Citiem vārdiem, drošības darbs, kas nav pārvaldīts, saglabāts un kartēts, auditā bieži neiztur pārbaudi pat tad, ja tehniskās komandas pieņēma pamatotus lēmumus.
No draudu modelēšanas līdz pierādījumiem: praktisks fintech piemērs
Apsveriet projektu jauna ES klientu sākotnējās piesaistes portāla palaišanai fintech uzņēmumā. Portāls vāc identitātes dokumentus, veic biometrisko verifikāciju ar trešās puses starpniecību, glabā sākotnējās piesaistes statusu, integrējas ar CRM, aktivizē klientu paziņojumus un nodod datus riska skoringam.
Drošības pēc projektējuma pieeja veidotu pierādījumus projekta gaitā.
Pirmkārt, jāatver projekta drošības klasifikācijas ieraksts. Jāidentificē, vai projekts ietekmē kritiskas vai svarīgas funkcijas, personas datus, īpašu kategoriju personas datus, autentifikāciju, klientiem pieejamu pieejamību, ārpakalpojumā sniegtus IKT pakalpojumus, reglamentētus ziņošanas procesus vai klientu komunikāciju. Saskaņā ar GDPR biometriskie dati, kas izmantoti unikālai identifikācijai, ir īpašu kategoriju personas dati, ja vien nav piemērojams konkrēts izņēmums. Tas uzreiz paaugstina nepieciešamo juridiskās analīzes un drošības pasākumu līmeni.
Otrkārt, jāizveido projekta risku izvērtējums. Clarysec SME Risku pārvaldības politika padara risku pārvaldību par plānošanas daļu, nevis ceturkšņa izklājlapas vingrinājumu:
“1.2 Tā nodrošina, ka risku pārvaldība ir aktīva plānošanas, projekta izpildes, piegādātāju atlases un reaģēšanas uz incidentiem sastāvdaļa, saskaņā ar ISO 27001, ISO 31000 un piemērojamām regulatīvajām prasībām.”
No sadaļas “Mērķis”, politikas punkts 1.2.
Uzņēmuma vidēm Clarysec Enterprise Risku pārvaldības politika definē darbības jomu stratēģiskā, projektu un tehniskā līmenī:
“Tā aptver informācijas drošības riskus stratēģiskajā, operatīvajā, projektu un tehniskajā līmenī un ir obligāta visam personālam, līgumslēdzējiem un pakalpojumu sniedzējiem, kas iesaistīti informācijas drošības pārvaldības sistēmas (IDPS) darbībās.”
No sadaļas “Piemērošanas joma”, politikas punkts 2.3.
Treškārt, pirms izstrādes sākuma jāveic draudu modelēšana. Enterprise Drošas izstrādes politika ir skaidra:
“Visām jaunām lietojumprogrammām un būtiskām izmaiņām pirms izstrādes sākuma jāveic drošības arhitektūras izvērtēšana un draudu modelēšana.”
No sadaļas “Politikas ieviešanas prasības”, politikas punkts 6.1.1.
Sākotnējās piesaistes portālam draudu modelim jāaptver eksponētās saskarnes, identitātes plūsmas, privilēģiju robežas, API ļaunprātīgas izmantošanas gadījumi, webhook viltošana, atkārtojuma uzbrukumi, kompromitēti autentifikācijas dati, datu noplūdes ceļi, atkarību risks, žurnālfiksēšanas prasības, rezerves kopiju pieņēmumi, atjaunošanas prasības un pakalpojumu sniedzēja atteices scenāriji.
Ceturtkārt, jāatjaunina privātuma pierādījumi. SME Datu aizsardzības un privātuma politika nosaka pamatlīmeni:
“5.3.1. Integrēta datu aizsardzība un datu aizsardzība pēc noklusējuma jāpiemēro visās jaunajās sistēmās un pakalpojumos”
No sadaļas “Pārvaldības prasības”, politikas punkts 5.3.1.
Projekta ierakstā jāiekļauj nolūks, tiesiskais pamats, pārziņa vai apstrādātāja loma, datu minimizēšanas lēmumi, glabāšanas noteikumi, piekļuves lomas, šifrēšanas izvēles, datu subjekta ietekmes apsvērumi, pārredzamības prasības, apstrādātāja noteikumi un personas datu aizsardzības pārkāpuma paziņošanas ceļi.
Piektkārt, jāreģistrē drošas izstrādes pierādījumi. SME Drošas izstrādes politika sniedz kodolīgu pierādījumu sarakstu, kas darbojas mazām un vidējām komandām:
“5.3 Ģenerāldirektoram (GM) jāuztur ieraksti par: 5.3.1 visiem aktīvajiem programmatūras izstrādes projektiem un atbildīgajiem izstrādātājiem vai piegādātājiem; 5.3.2 drošības kontrolsarakstiem, kas izmantoti katram projektam; 5.3.3 veiktajām koda pārskatīšanām un personām, kas tās veica; 5.3.4 testēšanas rezultātiem pirms izvietošanas; 5.3.5 trešo pušu komponentiem un ar tiem saistīto licencēšanas vai riska statusu.”
No sadaļas “Pārvaldības prasības”, politikas punkts 5.3.
Sestkārt, izvietošana jākontrolē kā izmaiņa. SME Izmaiņu pārvaldības politika nosaka:
“1.1 Šī politika nodrošina, ka visas izmaiņas IT sistēmās, konfigurācijās, biznesa lietojumprogrammās vai mākoņpakalpojumos pirms ieviešanas tiek plānotas, izvērtētas pēc riska, testētas un apstiprinātas.”
No sadaļas “Mērķis”, politikas punkts 1.1.
Sākotnējās piesaistes portālam izmaiņu pieteikumā jāiekļauj ietekmētie pakalpojumi, risku izvērtējums, testēšanas rezultāti, atcelšanas plāns, uzraudzības plāns, drošības apstiprinājumi, privātuma apstiprinājums, piegādātāju gatavība, incidentu eskalācijas atjauninājumi un klientu komunikācijas trigeri.
Visbeidzot, pienākumi jākartē. SME Tiesiskās un regulatīvās atbilstības politika sniedz darbības noteikumu:
“5.2.2 Ja regulējums attiecas uz vairākām jomām (piem., GDPR attiecas uz glabāšanu, drošību un privātumu), tas skaidri jākartē Atbilstības reģistrā un apmācību materiālos.”
No sadaļas “Pārvaldības prasības”, politikas punkts 5.2.2.
Šis Atbilstības reģistrs kļūst par tiltu starp ISO/IEC 27001:2022 kontroles pasākumiem, NIS2 Article 21 pasākumiem, DORA IKT riska pienākumiem, GDPR pārskatatbildību un klientu līgumiskajām saistībām.
Vienas projekta pierādījumu paketes kartēšana pret NIS2, DORA, GDPR un NIST CSF 2.0
Visefektīvākā atbilstības stratēģija nav darba dublēšana. Tā ir viena spēcīga pierādījumu kopuma kartēšana pret vairākām prasībām.
Zenith Blueprint risku pārvaldības posmā, 14. solī, iesaka šāda veida savstarpējo atsauču darbu:
“Katrai regulai, ja tā ir piemērojama, var izveidot vienkāršu kartēšanas tabulu (piemēram, kā pārskata pielikumu), kurā uzskaitītas regulas galvenās drošības prasības un atbilstošie kontroles pasākumi/politikas jūsu IDPS.”
Tas piebilst, ka tas ir noderīgi, jo auditoriem un izvērtētājiem parāda, “ka jūs nepārvaldāt drošību vakuumā, bet apzināties tiesisko kontekstu.”
Clarysec Zenith Controls: savstarpējās atbilstības ceļvedis atbalsta to pašu integrēto pieeju, kartējot ISO/IEC 27001:2022 kontroles pasākumus pret citiem ietvariem, audita gaidām un atbilstības vajadzībām. IKT projektu pārvaldībā tas A.5.8, A.8.25 un A.8.32 pozicionē kā preventīvus kontroles pasākumus, kas aizsargā konfidencialitāti, integritāti un pieejamību pārvaldības, lietojumprogrammu drošības, ekosistēmas, aizsardzības, kā arī sistēmu un tīklu drošības jomās.
| Pierādījumu artefakts | ISO/IEC 27001:2022 nolūks | NIS2 vērtība | DORA vērtība | GDPR vērtība |
|---|---|---|---|---|
| Projekta drošības klasifikācija | Definē darbības jomu, ieinteresētās puses, atkarības un darbības kontroli | Parāda uz risku balstītu ietekmēto sistēmu un pakalpojumu identificēšanu | Identificē ietekmi uz kritiskām vai svarīgām funkcijām | Identificē personas datus, lomas un apstrādes kontekstu |
| Draudu modelis | Atbalsta risku izvērtēšanu un drošas izstrādes kontroles pasākumus | Atbalsta drošu iepirkumu, izstrādi un ievainojamību apstrādi | Atbalsta IKT riska ietvaru un noturības stratēģiju | Atbalsta integrētu datu aizsardzību un atbilstošus drošības pasākumus |
| Piegādātāju pienācīga pārbaude un līguma pārskatīšana | Atbalsta piegādātāju un IKT piegādes ķēdes kontroles pasākumus | Atbalsta piegādes ķēdes drošību un tiešo piegādātāju izvērtēšanu | Atbalsta IKT trešo pušu risku, audita tiesības un izstāšanās plānošanu | Atbalsta apstrādātāja drošības pasākumus un apstrādes norādījumus |
| Drošas izstrādes un testēšanas ieraksti | Atbalsta drošu SDLC, ievainojamību pārvaldību un gatavību izmaiņām | Atbalsta drošu izstrādi un efektivitātes izvērtēšanu | Atbalsta noturības testēšanu un trūkumu novēršanu | Atbalsta apstrādes drošību un pārkāpuma riska samazināšanu |
| Izmaiņu apstiprinājuma ieraksts | Atbalsta plānotas izmaiņas, pārskatīšanu un nelabvēlīgu seku mazināšanu | Atbalsta ar risku pārvaldītu ieviešanu | Atbalsta pārvaldības ziņošanu un operacionālo noturību | Atbalsta pārskatatbildību par sistēmas izmaiņām, kas ietekmē personas datus |
| Incidentu un uzraudzības atjauninājums | Atbalsta žurnālfiksēšanu, uzraudzību, incidentu plānošanu un pierādījumu vākšanu | Atbalsta incidentu apstrādi un gatavību ziņošanai | Atbalsta būtisku IKT incidentu klasifikāciju un eskalāciju | Atbalsta personas datu aizsardzības pārkāpuma atklāšanu un reaģēšanu |
| Atbilstības reģistra kartējums | Atbalsta tiesiskās un regulatīvās prasības un dokumentētu informāciju | Demonstrē saskaņojumu ar Article 21 | Demonstrē DORA ietvara integrāciju | Demonstrē pārskatatbildību attiecībā uz principiem |
Šī tabula neaizstāj juridisko analīzi. Tā ir pārvaldības paātrinātājs. Tā nodrošina, ka CISO, datu aizsardzības speciālists, projekta sponsors, iepirkuma vadītājs, sistēmas īpašnieks un iekšējais auditors skatās uz vieniem un tiem pašiem pierādījumiem.
NIST CSF 2.0 arī dabiski iekļaujas šajā modelī. Tā GOVERN funkcija palīdz organizācijām noteikt politikas, lomas, riska apetīti, pārraudzību un tiesisko vai līgumisko apzinātību. Tā IDENTIFY, PROTECT, DETECT, RESPOND un RECOVER funkcijas palīdz komandām kopīgā darbības valodā apspriest aktīvus, piegādātāju pakalpojumus, piekļuves kontroli, datu drošību, platformas drošību, drošu programmatūras izstrādi, uzraudzību, reaģēšanu uz incidentiem un atjaunošanu.
| Regulatīvā vai ietvara prasība | Kā ISO 27001 projektu pārvaldība nodrošina pierādījumus |
|---|---|
| DORA Article 5, pārvaldība un organizācija | Parāda vadības pārraudzību, definētas atbildības, eskalācijas ceļus un IKT riska lēmumu apstiprināšanu |
| DORA Article 6, IKT risku pārvaldības ietvars | Izveido projekta līmeņa IKT risku izvērtējumus, apstrādes ierakstus, noturības prasības un kontroles pierādījumus |
| DORA Article 28, IKT trešo pušu risks | Dokumentē piegādātāju pienācīgu pārbaudi, līgumiskos drošības pasākumus, audita tiesības, izstāšanās plānošanu un nepārtrauktu uzraudzību |
| NIS2 Article 20, pārvaldība | Parāda vadības apstiprinājumu un kiberdrošības risku pārvaldības pasākumu pārraudzību |
| NIS2 Article 21(2)(d), piegādes ķēdes drošība | Reģistrē piegādātāju izvērtēšanu, iepirkuma kritērijus, pakalpojumu sniedzēju riskus un līgumiskās drošības prasības |
| NIS2 Article 21(2)(e), drošs iepirkums, izstrāde un uzturēšana | Fiksē drošības prasības, arhitektūras pārskatīšanu, ievainojamību apstrādi, testēšanu un trūkumu novēršanas pierādījumus |
| GDPR Article 25, integrēta datu aizsardzība un datu aizsardzība pēc noklusējuma | Parāda privātuma prasības, minimizēšanu, glabāšanu, piekļuves kontroli, apstrādātāja drošības pasākumus un DPIA rezultātus, ja nepieciešams |
| NIST CSF 2.0 GV.PO-01 un GV.PO-02 | Demonstrē, ka kiberdrošības politikas tiek noteiktas, komunicētas, piemērotas, pārskatītas un atjauninātas projekta izpildes gaitā |
Viens ar ISO 27001 saskaņots process, kura centrā ir A pielikuma 5.8, var radīt pamatotus pierādījumus visām šīm gaidām.
Droša izstrāde ir plašāka par koda rakstīšanu
Daudzas IKT projektu neveiksmes rodas tāpēc, ka organizācija drošu izstrādi uzskata par kaut ko tādu, ko dara tikai izstrādātāji. 2026. gadā droša izstrāde ietver arī SaaS konfigurēšanu, darbplūsmu automatizāciju, infrastruktūru kā kodu, API integrācijas, identitātes noteikumus, mākoņvides bāzes zonas, analītikas datu plūsmas, robotizētu procesu automatizāciju un zemkoda biznesa lietojumprogrammas.
Zenith Blueprint sadaļā “Kontroles pasākumi praksē”, 20. solī, aplūko ISO/IEC 27002:2022 kontroles pasākumu 8.25 Drošas izstrādes dzīves cikls:
“Šis kontroles pasākums ir piemērojams neatkarīgi no tā, vai jūs rakstāt savas lietojumprogrammas, konfigurējat platformas, piemēram, ERP vai CRM sistēmas, pielāgojat SaaS darbplūsmas vai pārvaldāt infrastruktūras kā koda vides.”
Tas arī skaidro, ka drošības prasībām jāatrodas līdzās funkcionālajām prasībām un ka draudu modelēšana palīdz identificēt sistēmas eksponētās daļas, riskantas lietotāju lomas un datu plūsmas, kurām nepieciešama augstāka aizsardzība.
Mūsdienīgam projektam drošas izstrādes pierādījumi var ietvert:
- Drošības prasības, kas sasaistītas ar biznesa prasībām
- Draudu modeli vai drošības arhitektūras izvērtēšanu
- Drošas kodēšanas vai drošas konfigurācijas kontrolsarakstu
- Koda pārskatīšanas vai kolēģu pārskatīšanas ierakstus
- Komponentu uzskaiti un atkarību riska statusu
- Lēmumus par noslēpumu pārvaldību
- Piekļuves kontroles un minimālo privilēģiju projektējumu
- Žurnālfiksēšanas un uzraudzības prasības
- Ievainojamību skenēšanas rezultātus un trūkumu novēršanas ierakstus
- Pirmsprodukcijas drošības testēšanu
- Rezerves kopiju, atjaunošanas un noturības testēšanu, ja attiecināms
- Izvietošanas apstiprinājumu un izmaiņu atcelšanas pierādījumus
Mērķis nav piespiest katru projektu iziet cauri vienam un tam pašam smagnējam procesam. Mērķis ir samērīgums. Nelielām iekšējās darbplūsmas izmaiņām nav nepieciešami tādi paši pierādījumi kā galvenās maksājumu platformas migrācijai. Taču katram projektam jābūt klasificētam, izvērtētam pēc riska un pārvaldītam atbilstoši ietekmei.
Izmaiņu pārvaldība aizsargā projektu no paša projekta
Daudzos projektos riskantākais brīdis nav projektējums vai kodēšana. Tā ir izvietošana.
Komanda var veikt draudu modelēšanu, koda pārskatīšanu, piegādātāju izvērtēšanu un privātuma pārskatīšanu, bet tomēr izraisīt pakalpojumu nepieejamību vai pārkāpumu ar sasteigtām izmaiņām produkcijas vidē. Atkļūdošanas karogs paliek iespējots. Ugunsmūra noteikums ir plašāks, nekā apstiprināts. Migrācijas skripts kopē personas datus uz neprodukcijas vidi. Trešās puses webhook galapunkts tiek izvietots bez autentifikācijas. Žurnālfiksēšanas izmaiņa ieraksta identitātes dokumentu numurus. Rezerves kopiju uzdevums pēc pārslēgšanas klusi neizdodas.
Zenith Blueprint sadaļā “Kontroles pasākumi praksē”, 21. solī, ISO/IEC 27002:2022 kontroles pasākumu 8.32 Izmaiņu pārvaldība apraksta tieši:
“Izmaiņas ir neizbēgamas, bet kiberdrošībā nekontrolētas izmaiņas ir bīstamas.”
Tas turpina:
“Pamatā efektīva izmaiņu pārvaldība ir atkārtojama darbplūsma. Tā sākas ar skaidru priekšlikumu, kurā izklāstīts, kas mainās, kāpēc, kad un kādi ir potenciālie riski.”
Spēcīgam IKT izmaiņu ierakstam jāatbild uz šādiem jautājumiem:
- Kāda sistēma, pakalpojums, datu plūsma, piegādātājs vai konfigurācija mainās?
- Kādi riski tika identificēti un kas ir to īpašnieki?
- Vai izmaiņa ietekmē personas datus, kritiskus pakalpojumus, autentifikāciju, žurnālfiksēšanu, rezerves kopijas vai reaģēšanu uz incidentiem?
- Kādas drošības, privātuma, noturības un piegādātāju pārbaudes tika veiktas?
- Kādi testi tika pabeigti pirms izvietošanas?
- Kāda uzraudzība apstiprinās sagaidāmo uzvedību?
- Kāds izmaiņu atcelšanas vai atjaunošanas plāns pastāv?
- Kas apstiprināja atlikušo risku?
- Kādi pierādījumi tiks saglabāti?
DORA vajadzībām tas atbalsta dokumentētu IKT risku pārvaldību, noturību, nepārtrauktību, incidentu klasifikāciju un gūtās mācības. NIS2 vajadzībām tas atbalsta risku pārvaldības pasākumus, drošu izstrādi, incidentu novēršanu un nepārtrauktību. GDPR vajadzībām tas palīdz demonstrēt, ka izmaiņas, kas ietekmē personas datus, tika pārskatītas pret nolūka, minimizēšanas, glabāšanas, piekļuves un drošības principiem.
Piegādātāju un mākoņpakalpojumu lēmumiem jābūt daļai no projekta projektējuma
Mūsdienu IKT projektos augstākā riska projektējuma lēmums bieži ir “pirkt”, nevis “būvēt”. Mākoņpakalpojumi, API sniedzēji, identitātes verifikācijas platformas, maksājumu apstrādātāji, analītikas piegādātāji, pārvaldīto pakalpojumu sniedzēji un pārvaldītās drošības pakalpojumu sniedzēji kļūst par daļu no riska virsmas.
NIS2 skaidri ietver piegādes ķēdes drošību, tiešo piegādātāju un pakalpojumu sniedzēju ievainojamības, piegādātāju kiberdrošības prakses, drošas izstrādes procedūras un koordinētu piegādes ķēdes risku izvērtēšanas rezultātus. DORA finanšu vienībām iet vēl dziļāk. Tā prasa IKT trešo pušu risku pārvaldību kā daļu no IKT risku pārvaldības ietvara, nepārtrauktu atbildību arī tad, ja IKT pakalpojumi ir uzticēti ārpakalpojumā, informācijas reģistrus, pirmslīguma izvērtējumus, koncentrācijas riska analīzi, līguma kontroles pasākumus, audita un pārbaudes tiesības, izbeigšanas trigerus un testētas izstāšanās stratēģijas kritiskām vai svarīgām funkcijām.
Sākotnējās piesaistes portālam biometriskās verifikācijas pakalpojumu sniedzēju nevar apstiprināt tikai tāpēc, ka iepirkumam patīk cena un API dokumentācija ir laba. Projektam nepieciešami pierādījumi par drošības pienācīgu pārbaudi, apstrādes lomu, datu atrašanās vietu, apakšuzņēmējiem, pieejamības saistībām, atbalstu incidentu gadījumā, audita tiesībām, izbeigšanas palīdzību, izstāšanās īstenojamību un uzraudzības pienākumiem.
Nobriedušā pierādījumu modelī piegādātāju un mākoņpakalpojumu lēmumi atrodas projekta pierādījumu paketē, nevis atsevišķā piegādātāju mapē. Kad auditors jautā, kāpēc trešā puse tika pieņemta, atbildei jāietver biznesa vajadzība, risku izvērtējums, līgumiskie drošības pasākumi, datu aizsardzības pārskatīšana, noturības ietekme un nepārtraukta uzraudzība.
Kā auditori pārskatīs drošības pēc projektējuma pierādījumus
Dažādi auditori uz vienu un to pašu IKT projektu skatās no dažādiem skatpunktiem. Sertifikācijas auditors, iekšējais auditors, DORA pārskatītājs, NIS2 kompetentā iestāde, privātuma auditors, uz NIST orientēts izvērtētājs vai COBIT stila auditors var prasīt līdzīgus pierādījumus, bet interpretēt tos atšķirīgi.
| Audita skatpunkts | Ko auditors jautās | Pierādījumi, kas parasti apmierina jautājumu |
|---|---|---|
| ISO/IEC 27001:2022 auditors | Vai informācijas drošība tika integrēta projektu pārvaldībā un darbības plānošanā, un vai riska apstrādes lēmumi ir dokumentēti? | Projekta harta, risku izvērtējums, SoA kartējums, apstrādes plāns, posmu vārtu apstiprinājumi, dokumentētas informācijas kontroles pasākumi |
| NIST CSF 2.0 izvērtētājs | Vai pārvaldības, riska, piegādātāju, aizsardzības, atklāšanas, reaģēšanas un atjaunošanas rezultāti atspoguļojas projekta lēmumos? | Pašreizējais un mērķa profils, trūkumu novēršanas plāns, piegādātāju uzskaite, piekļuves projektējums, uzraudzības plāns, incidentu un atjaunošanas procedūras |
| COBIT vai ISACA stila auditors | Vai mērķi, īpašumtiesības, procesu kontroles pasākumi, lēmumu tiesības un veiktspējas uzraudzība ir skaidri? | RACI, pārvaldības sanāksmju protokoli, kontroles pasākumu īpašumtiesības, KPI un KRI pārskati, izmaiņu apstiprinājumi, iekšējā audita konstatējumi |
| DORA pārskatītājs | Vai projekts ietekmē kritiskas vai svarīgas funkcijas, IKT trešo pušu atkarības, noturības testēšanu vai incidentu ziņošanu? | Kritiskuma izvērtējums, IKT riska ieraksts, piegādātāju reģistrs, līguma klauzulas, testēšanas rezultāti, incidentu klasifikācijas atjauninājumi |
| GDPR vai privātuma auditors | Vai projektā tika piemērota integrēta datu aizsardzība, tiesiskais pamats, minimizēšana, glabāšana, drošība un pārskatatbildība? | Datu plūsmas karte, tiesiskā pamata ieraksts, DPIA, ja piemērojams, piekļuves matrica, glabāšanas noteikumi, apstrādātāja noteikumi, pārkāpumu rokasgrāmatas atjauninājumi |
Auditori nevēlas skaistu projekta slaidu komplektu. Viņi vēlas izsekojamību. Viņi vēlas redzēt, ka prasības noveda pie riskiem, riski noveda pie kontroles pasākumiem, kontroles pasākumi noveda pie ieviešanas pierādījumiem un ieviešana noveda pie pārskatīšanas.
Tāpēc Zenith Controls ir noderīgs gatavībā auditam. Tas palīdz komandām izskaidrot, kāpēc A pielikuma 5.8, A.8.25 un A.8.32 ir preventīvi kontroles pasākumi, kas aizsargā konfidencialitāti, integritāti un pieejamību, pirms paredzamas kļūmes nonāk produkcijas vidē.
Minimālā Clarysec projekta pierādījumu pakete
Spēcīgai drošības pēc projektējuma pierādījumu paketei nav jābūt milzīgai. Tai jābūt konsekventai, samērīgai un kartētai.
Vidēja riska IKT projektam Clarysec parasti iesaka šādu minimālo paketi:
- Projekta drošības klasifikācijas ieraksts
- Regulējuma piemērojamības piezīme, kas aptver NIS2, DORA, ja attiecināms, GDPR un līgumiskos pienākumus
- Datu plūsmas un aktīvu ietekmes karte
- Projekta risku izvērtējums un riska apstrādes plāns
- Draudu modelis vai drošības arhitektūras izvērtēšana
- Piegādātāju un mākoņpakalpojumu izvērtēšana, ja piemērojams
- Drošas izstrādes kontrolsaraksts vai konfigurācijas kontrolsaraksts
- Drošības testēšanas rezultāti un trūkumu novēršanas pierādījumi
- Izmaiņu apstiprinājums ar atcelšanas un uzraudzības plānu
- Integrētās datu aizsardzības ieraksts, tostarp tiesiskais pamats un glabāšana, ja iesaistīti personas dati
- Reaģēšanas uz incidentiem un uzraudzības atjauninājumi
- Pārskatīšana pēc ieviešanas un gūtās mācības
- Atbilstības reģistra kartējums pret kontroles pasākumiem un pienākumiem
Zenith Blueprint sniedz ceļveža loģiku. 22. solis ievieš informācijas drošību visos projekta posmos. 20. solis iestrādā drošu izstrādi plānošanā, projektējumā, kodā, testēšanā un izvietošanā. 21. solis padara izmaiņu pārvaldību strukturētu, izsekojamu un pārskatāmu. 14. solis iesaka savstarpēji sasaistīt GDPR, NIS2, DORA un citus pienākumus, lai atbilstības prasības nepazustu starp procesiem.
Politikas sniedz darbības noteikumus. Informācijas drošības politika integrē drošību ar projektu vadību, iepirkumu un juridisko pārraudzību. Risku pārvaldības politika padara projekta riskus par daļu no IDPS darbības. Drošas izstrādes politika prasa draudu modelēšanu. Izmaiņu pārvaldības politika prasa plānotas, pēc riska izvērtētas, testētas un apstiprinātas izmaiņas. Datu aizsardzības un privātuma politika prasa integrētu datu aizsardzību un datu aizsardzību pēc noklusējuma. Tiesiskās un regulatīvās atbilstības politika prasa vairāku jomu regulējumus kartēt Atbilstības reģistrā.
Kopā šie rīki pārvērš drošību pēc projektējuma no ieceres par auditējamu darbības modeli.
Biežākie neveiksmju modeļi IKT projektos
Neveiksmes parasti ir paredzamas.
Pirmā ir novēlota drošības iesaiste. Drošības pārskatīšana notiek pēc tam, kad arhitektūra ir nostiprināta, līgumi ir parakstīti un piegādes datumi ir publiski. Tajā brīdī drošība kļūst par bloķētāju, nevis projektēšanas ievadi.
Otrā ir fragmentēti pierādījumi. Projektam ir testēšanas rezultāti vienā rīkā, piegādātāju pārskatīšana citā, privātuma komentāri e-pastā, riska pieņemšana sanāksmes ierakstā un izmaiņu apstiprinājums pieteikumā. Neviens vienots pavediens nepierāda pārvaldību.
Trešā ir piegādātāju aklās zonas. Projekts paļaujas uz mākoņpakalpojumu vai API sniedzēju, bet neviens nepārbauda apakšuzņēmējus, datu atrašanās vietu, audita tiesības, atbalstu incidentu gadījumā, izstāšanās plānus vai koncentrācijas risku.
Ceturtā ir privātuma novirze. Sistēma, kas izveidota vienam nolūkam, sāk atbalstīt analītiku, AI eksperimentēšanu, mārketinga eksportus vai operatīvo uzraudzību, nepārskatot tiesisko pamatu, pārredzamību, minimizēšanu vai glabāšanu.
Piektā ir nepārskatīta izmaiņa. Ieviešana produkcijas vidē tiek apstiprināta funkcionalitātes dēļ, bet netiek izvērtēta ietekme uz piekļuvi, žurnālfiksēšanu, šifrēšanu, rezerves kopijām, noturību, personas datiem vai ziņošanu.
Sestā ir vāja vadības pārraudzība. Augstas ietekmes projekta riski tiek pieņemti pārāk zemā līmenī, bez pierādījumiem, ka atbildīgais riska īpašnieks saprata regulatīvās sekas.
Šīs problēmas neatrisina vēl viena skenera iegāde. Tās atrisina drošības pārvaldības integrēšana veidā, kā projekti tiek ierosināti, projektēti, iepirkti, būvēti, testēti, mainīti un pārskatīti.
2026. gada secinājums CISO
Drošība pēc projektējuma IKT projektos tagad ir valdes, audita un regulējuma jautājums. NIS2 padara kiberdrošības risku pārvaldību par vadības struktūras jautājumu. DORA padara IKT risku, noturības testēšanu, incidentu pārvaldību un trešo pušu pārraudzību par strukturētu finanšu sektora pienākumu. GDPR prasa pārskatatbildību par personas datu apstrādi un atbilstošu drošību. ISO/IEC 27001:2022 nodrošina pārvaldības sistēmas struktūru, lai šos pienākumus ieviestu praksē.
CISO iespēja ir pārtraukt cīņu ar projekta komandām piegādes beigās. Ievietojiet drošību uzsākšanā, prasībās, projektējumā, piegādātāju atlasē, izstrādē, testēšanā, izmaiņu apstiprināšanā un pārskatīšanā pēc ieviešanas.
Atbilstības vadītājiem iespēja ir aizstāt izkaisītus pierādījumus ar vienu kartētu projekta pierādījumu paketi.
Auditoriem iespēja ir testēt projekta dzīves ciklu, nevis tikai gala sistēmu.
Biznesa īpašniekiem iespēja ir ātrāka un drošāka piegāde. Drošība pēc projektējuma samazina pārstrādi, novērš atbilstības pārsteigumus, uzlabo piegādātāju lēmumus un sniedz vadībai pamatotu riska stāstu.
Ja jūsu IKT projekti virzās ātrāk nekā jūsu pierādījumu modelis, sāciet ar vienu pilotprojektu. Izmantojiet Clarysec Zenith Blueprint, lai definētu projekta drošības vārtus, piemērojiet Clarysec politikas risku pārvaldībai, drošai izstrādei, izmaiņu pārvaldībai un privātumam, un izmantojiet Zenith Controls, lai kartētu ISO/IEC 27001:2022 projektu pārvaldību pret NIS2, DORA, GDPR un NIST CSF 2.0.
Clarysec var palīdzēt jums izveidot atkārtoti izmantojamu drošības pēc projektējuma projekta pierādījumu paketi, saskaņot to ar jūsu IDPS un sagatavot to iekšējam auditam, sertifikācijas auditam, gatavībai DORA, NIS2 pārvaldībai un GDPR pārskatatbildībai.
Sāciet ar savu nākamo būtisko IKT projektu. Ja tas maina sistēmas, piegādātājus, datus, piekļuvi, noturību vai klientu uzticēšanos, tam nepieciešama drošība pēc projektējuma jau no pirmās dienas.
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
