Saugumas nuo projektavimo etapo IRT projektų valdysenoje 2026 m.

Projektas vyko pagal grafiką, kol auditas uždavė vieną klausimą

Sparčiai augančios mokėjimų technologijų įmonės CISO turėjo gerų naujienų valdybai. Nauja klientų įtraukimo platforma buvo parengta paleidimui. Produkto komanda pristatė mobiliąją patirtį, inžinerijos komanda integravo tapatybės patikrą, teisės funkcija pasirašė sutartis su debesijos ir API teikėjais, o operacijų komanda buvo surepetavusi paleidimo gamybinėje aplinkoje planą.

Tada vidaus auditorius uždavė paprastą klausimą:

„Parodykite, kur kiekviename projekto etape buvo įvertinti saugumas ir privatumas.“

Projekto kambaryje įsivyravo tyla.

Buvo įsiskverbimo testavimo ataskaita, tačiau testas atliktas vėlai. Buvo debesijos architektūros schema, tačiau nebuvo įrodymų, kad duomenų srautai peržiūrėti pagal GDPR principus. Buvo tiekėjų deramo patikrinimo klausimynas, tačiau jis nebuvo susietas su rizikos registru. Buvo pakeitimo užklausa dėl diegimo gamybinėje aplinkoje, tačiau patvirtinime neminėtas poveikis kritinėms paslaugoms, incidentų pranešimui, atsparumo testavimui, klientų informavimui ar asmens duomenų saugumo pažeidimų eskalavimui. Buvo sprintų pastabos, tačiau saugumo reikalavimai buvo išskaidyti naudotojų istorijose ir pokalbių žinutėse.

Nieko akivaizdžiai aplaidžiai padaryta nebuvo. Viskas atrodė kaip intensyvus šiuolaikinis IRT projektas. Tačiau finansų subjektui, kuriam taikoma DORA, SaaS teikėjui, kuris potencialiai patenka į NIS2 taikymo sritį, ir duomenų valdytojui arba duomenų tvarkytojui pagal GDPR klausimas nebebuvo vien tai, ar saugumas egzistavo. Klausimas buvo, ar saugumą nuo projektavimo etapo galima pagrįsti įrodymais.

Tai ir yra 2026 m. problema. IRT projektai nebevertinami tik pagal pristatymo greitį, sąnaudų kontrolę ir techninę kokybę. Jie vertinami pagal valdysenos įrodymus: rizikos vertinimus, projektavimo sprendimus, tiekėjų deramą patikrinimą, saugaus kūrimo įrašus, pakeitimų patvirtinimus, privatumo sprendimus, testavimo rezultatus ir vadovybės priežiūrą.

ISO/IEC 27001:2022 suteikia organizacijoms praktinį valdymo sistemos pagrindą šiai problemai spręsti. Jis padeda CISO, atitikties vadovams, projektų rėmėjams, DAP, architektams, pirkimų komandoms ir auditoriams reikšmingus IRT projektus paversti pagrįstais saugumo nuo projektavimo etapo įrodymais.

Kodėl IRT projektų valdysena tapo reglamentavimo įrodymų klausimu

Debesijos migracija, klientų portalas, mokėjimų platforma, CRM diegimas, tapatybės teikėjo pakeitimas, analitikos duomenų konvejeris, API integracija, SaaS darbo eiga, mažo kodo taikomoji programa ar valdomos paslaugos perėmimas gali pakeisti organizacijos rizikos profilį. 2026 m. tokie pakeitimai vyksta persidengiančių įpareigojimų aplinkoje.

NIS2 plačiai taikoma esminiams ir svarbiems subjektams pagal I ir II priedų sektorius, įskaitant skaitmeninę infrastruktūrą, valdomų paslaugų teikėjus, valdomo saugumo paslaugų teikėjus ir skaitmeninių paslaugų teikėjus. NIS2 Article 20 nustato valdymo organų atsakomybę tvirtinti kibernetinio saugumo rizikos valdymo priemones ir prižiūrėti jų įgyvendinimą. NIS2 Article 21 reikalauja tinkamų ir proporcingų techninių, operacinių ir organizacinių priemonių rizikos valdymui, incidentų valdymui, veiklos tęstinumui, tiekimo grandinės saugumui, saugiam įsigijimui, saugiam kūrimui, pažeidžiamumų valdymui, veiksmingumo vertinimui, kibernetinei higienai, kriptografijai, prieigos kontrolei, turto valdymui ir saugiai komunikacijai.

DORA taikoma finansų subjektams ir orientuota į skaitmeninį operacinį atsparumą. DORA Article 5 nustato, kad valdymo organas atsako už IRT rizikos valdymą. DORA Article 6 reikalauja patikimos, išsamios ir gerai dokumentuotos IRT rizikos valdymo sistemos. DORA taip pat apima su IRT susijusių incidentų pranešimą, operacinio atsparumo testavimą, IRT veiklos tęstinumą, reagavimą ir atkūrimą, dalijimąsi kibernetinių grėsmių informacija, IRT trečiųjų šalių rizikos valdymą, sutartinius susitarimus ir kritinių IRT trečiųjų šalių paslaugų teikėjų priežiūrą.

GDPR prideda atskaitomybės sluoksnį asmens duomenims. GDPR Article 25 reikalauja duomenų apsaugos pagal projektavimą ir pagal numatytuosius nustatymus. Duomenų valdytojai turi gebėti pagrįsti atitiktį tokiems principams kaip teisėtumas, sąžiningumas, skaidrumas, tikslo apribojimas, duomenų minimizavimas, saugojimo trukmės ribojimas, vientisumas, konfidencialumas ir atskaitomybė. Kai tikėtina, kad tvarkymas kels didelę riziką, pagal GDPR Article 35 taip pat gali būti reikalingas poveikio duomenų apsaugai vertinimas.

Bendras vardiklis yra įrodymai. Reguliuotojai ir auditoriai klausia ne tik, ar platforma buvo šifruota, pataisyta, skenuota ar testuota. Jie klausia, ar organizacija gali parodyti, kad saugumas, privatumas, tiekėjų rizika ir atsparumas nuo pat pradžių buvo sprendimų priėmimo dalis.

Todėl ISO/IEC 27001:2022 projektų valdysena yra tokia veiksminga. Ji leidžia organizacijai valdyti NIS2, DORA, GDPR, NIST CSF 2.0, sutartinius įpareigojimus ir klientų patikinimą per vieną pakartojamą ISVS procesą, o ne per kelis atskirus kontrolinius sąrašus.

ISO 27001 projektų valdysenos pagrindas

ISO/IEC 27001:2022 dažnai klaidingai suprantamas kaip sertifikavimo pratyba. IRT projektams jo operacinė vertė yra platesnė. Jis suteikia valdysenos pagrindą verslo pokyčiams.

4.1–4.4 punktai reikalauja, kad organizacijos suprastų vidaus ir išorės klausimus, suinteresuotąsias šalis, teisinius, reglamentavimo ir sutartinius reikalavimus, ISVS taikymo sritį, sąsajas ir priklausomybes. Projekto kontekste tai reiškia, kad projekto chartijoje turi būti identifikuotos paveiktos paslaugos, klientai, tiekėjai, reguliavimas, verslo procesai, asmens duomenys, kritinės operacijos ir išorės paslaugos.

5.1–5.3 punktai reikalauja vadovybės įsipareigojimo, politikos suderinimo, išteklių, integravimo į verslo procesus ir priskirtų atsakomybių. Tai svarbu, nes tiek NIS2, tiek DORA kibernetinį saugumą ir IRT riziką priskiria valdymo organo atsakomybei. Projektas, keičiantis kritinę klientų platformą, negali remtis neformaliu saugumo komentaru pokalbių gijoje. Jam reikia aiškios atskaitomybės.

6.1.1–6.1.3 punktai reikalauja pakartojamo rizikos vertinimo ir tvarkymo proceso, rizikos kriterijų, rizikos savininkų, konfidencialumo, vientisumo ir prieinamumo vertinimo, rizikos tvarkymo planų, Taikymo pareiškimo ir liekamosios rizikos patvirtinimo. Čia projekto rizika tampa audito įrodymais.

7.1–7.5 punktai reikalauja išteklių, kompetencijos, informuotumo, komunikacijos ir dokumentuotos informacijos kontrolės. Taip projekto įrašai tampa patikimais įrodymais, o ne išskaidytais artefaktais.

8.1 punktas reikalauja operacinio planavimo ir kontrolės, dokumentuotos informacijos, rodančios, kad procesai įvykdyti kaip planuota, planuojamų pakeitimų kontrolės, nenumatytų pakeitimų peržiūros, neigiamo poveikio mažinimo ir ISVS aktualių išorės teikiamų procesų, produktų ar paslaugų kontrolės. 8.2 ir 8.3 punktai reikalauja informacijos saugumo rizikos vertinimų ir tvarkymo planuotais intervalais arba įvykus reikšmingiems pakeitimams.

A priedas šį valdymo ciklą susieja su praktinėmis kontrolės priemonėmis. Saugumui nuo projektavimo etapo IRT projektuose svarbiausios yra trys ISO/IEC 27001:2022 A priedo kontrolės priemonės:

Clarysec Zenith Blueprint: auditoriaus 30 žingsnių veiksmų planas informacijos saugumą projektų valdyme traktuoja kaip valdysenos klausimą visų tipų projektuose, ne tik programinės įrangos kūrime:

„Bet kuris projektas — rinkodaros sistemos migracija, pastato perkėlimas, verslo proceso pertvarkymas, žmogiškųjų išteklių įvedimo į darbą platforma ar net susijungimas arba įsigijimas — gali paveikti informacijos konfidencialumą, vientisumą arba prieinamumą. Kai taip nutinka, saugumas turi turėti vietą prie sprendimų priėmimo stalo.“

Toje pačioje dalyje užfiksuota pagrindinė įgyvendinimo pamoka:

„Šios kontrolės priemonės tikslas nėra apkrauti projektų biurokratija. Tikslas yra užtikrinti, kad saugumas būtų laikomas projektavimo įvestimi, o ne testavimo etapu.“

Šis skirtumas atskiria atitikties imitavimą nuo pagrįsto saugumo nuo projektavimo etapo.

Kaip saugumas nuo projektavimo etapo atrodo IRT projekto viduje

Saugumas nuo projektavimo etapo prasideda prieš pirmąjį sprintą, pirkimo prašymą, architektūros schemą ar migracijos atkūrimo instrukcijas. Jis kelia paprastą klausimą: ką šis projektas gali pakeisti rizikos požiūriu?

Praktinis projektų valdysenos modelis naudoja septynis įrodymų vartus.

Tikslas nėra biurokratija. Tikslas yra padaryti saugumą matomą ten, kur realiai priimami projekto sprendimai.

Clarysec Enterprise Informacijos saugumo politika tai išreiškia tiesiogiai:

„Saugumo valdysena turi būti integruota su įmonės valdysena, projektų valdymu, pirkimais ir teisinės priežiūros funkcijomis, kad informacijos saugumas nebūtų izoliuotas, o būtų įtvirtintas visame verslo sprendimų priėmime.“

Iš dalies „Valdysenos reikalavimai“, politikos punktas 5.5.

Ji taip pat projekto gyvavimo ciklus padaro įgyvendinimo klausimu:

„Projektų gyvavimo ciklai (pvz., saugus kūrimas, grėsmių modeliavimas)“

Iš dalies „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.3.1.1.

Ir nustato audito principą, kurį daugelis organizacijų atranda per vėlai:

„Visos įgyvendintos kontrolės priemonės turi būti audituojamos, paremtos dokumentuotomis procedūromis ir saugomais veikimo įrodymais.“

Iš dalies „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.6.1.

Kitaip tariant, saugumo darbas, kuris nėra valdomas, išsaugomas ir susietas, audite dažnai nepasiteisins, net jei techninės komandos priėmė pagrįstus sprendimus.

Nuo grėsmių modeliavimo iki įrodymų: praktinis fintech pavyzdys

Tarkime, vykdomas projektas paleisti naują ES klientų įtraukimo portalą fintech įmonei. Portalas renka tapatybės dokumentus, per trečiąją šalį atlieka biometrinę patikrą, saugo įtraukimo būseną, integruojasi su CRM, inicijuoja klientų pranešimus ir perduoda duomenis rizikos vertinimo balams apskaičiuoti.

Saugumo nuo projektavimo etapo metodas kauptų įrodymus projektui judant pirmyn.

Pirma, atidarykite projekto saugumo klasifikavimo įrašą. Nustatykite, ar projektas paveikia kritines arba svarbias funkcijas, asmens duomenis, specialių kategorijų asmens duomenis, autentifikavimą, klientams skirtų paslaugų prieinamumą, išorines IRT paslaugas, reglamentuojamus ataskaitų teikimo procesus ar klientų komunikaciją. Pagal GDPR biometriniai duomenys, naudojami unikaliam asmens identifikavimui, yra specialios kategorijos asmens duomenys, nebent taikoma konkreti išimtis. Tai iš karto padidina reikalingos teisinės analizės ir apsaugos priemonių lygį.

Antra, parenkite projekto rizikos vertinimą. Clarysec SME Rizikos valdymo politika rizikos valdymą padaro planavimo dalimi, o ne ketvirtiniu skaičiuoklės pratimu:

„1.2 Ji užtikrina, kad rizikos valdymas būtų aktyvi planavimo, projekto vykdymo, tiekėjų atrankos ir reagavimo į incidentus dalis, suderinta su ISO 27001, ISO 31000 ir taikomais reglamentavimo reikalavimais.“

Iš dalies „Tikslas“, politikos punktas 1.2.

Įmonių aplinkoms Clarysec Enterprise Rizikos valdymo politika apibrėžia taikymo sritį strateginiu, projektų ir techniniu lygmenimis:

„Ji apima informacijos saugumo rizikas strateginiu, operaciniu, projektų ir techniniu lygmenimis ir yra privaloma visam personalui, rangovams ir paslaugų teikėjams, dalyvaujantiems informacijos saugumo valdymo sistemos (ISVS) veiklose.“

Iš dalies „Taikymo sritis“, politikos punktas 2.3.

Trečia, prieš pradedant kūrimą atlikite grėsmių modeliavimą. Enterprise Saugaus kūrimo politika tai nurodo aiškiai:

„Visoms naujoms taikomosioms programoms ir reikšmingiems pakeitimams prieš pradedant kūrimą turi būti atlikta saugios architektūros peržiūra ir grėsmių modeliavimas.“

Iš dalies „Politikos įgyvendinimo reikalavimai“, politikos punktas 6.1.1.

Klientų įtraukimo portalui grėsmių modelis turėtų apimti atviras sąsajas, tapatybės srautus, privilegijų ribas, API piktnaudžiavimo scenarijus, webhook klastojimą, pakartojimo atakas, kompromituotus prisijungimo duomenis, duomenų nutekėjimo kelius, priklausomybių riziką, žurnalavimo reikalavimus, atsarginių kopijų prielaidas, atkūrimo reikalavimus ir teikėjo nesuveikimo režimus.

Ketvirta, atnaujinkite privatumo įrodymus. SME Duomenų apsaugos ir privatumo politika nustato bazinį reikalavimą:

„5.3.1. Privatumas pagal projektavimą ir pagal numatytuosius nustatymus turi būti taikomas visose naujose sistemose ir paslaugose“

Iš dalies „Valdysenos reikalavimai“, politikos punktas 5.3.1.

Projekto įraše turėtų būti nurodytas tikslas, teisinis pagrindas, duomenų valdytojo arba duomenų tvarkytojo vaidmuo, duomenų minimizavimo sprendimai, saugojimo taisyklės, prieigos vaidmenys, šifravimo pasirinkimai, poveikio duomenų subjektams aspektai, skaidrumo reikalavimai, duomenų tvarkytojo sąlygos ir asmens duomenų saugumo pažeidimų pranešimo keliai.

Penkta, užfiksuokite saugaus kūrimo įrodymus. SME Saugaus kūrimo politika pateikia glaustą įrodymų sąrašą, tinkantį mažoms ir vidutinėms komandoms:

„5.3 Generalinis vadovas (GM) turi saugoti įrašus apie: 5.3.1 visus aktyvius programinės įrangos kūrimo projektus ir atsakingus kūrėjus arba tiekėjus; 5.3.2 kiekvienam projektui naudotus saugumo kontrolinius sąrašus; 5.3.3 atliktas kodo peržiūras ir jas atlikusius asmenis; 5.3.4 testavimo rezultatus prieš diegimą; 5.3.5 trečiųjų šalių komponentus ir su jais susijusią licencijavimo arba rizikos būseną.“

Iš dalies „Valdysenos reikalavimai“, politikos punktas 5.3.

Šešta, valdykite diegimą kaip pakeitimą. SME Pakeitimų valdymo politika nustato:

„1.1 Ši politika užtikrina, kad visi IT sistemų, konfigūracijų, verslo taikomųjų programų ar debesijos paslaugų pakeitimai prieš įgyvendinimą būtų suplanuoti, įvertinti pagal riziką, testuoti ir patvirtinti.“

Iš dalies „Tikslas“, politikos punktas 1.1.

Klientų įtraukimo portalui pakeitimo užklausoje turėtų būti paveiktos paslaugos, rizikos vertinimas, testavimo rezultatai, grąžinimo į ankstesnę būseną planas, stebėsenos planas, saugumo patvirtinimai, privatumo patvirtinimas, tiekėjų pasirengimas, incidentų eskalavimo atnaujinimai ir klientų komunikacijos paleidikliai.

Galiausiai susiekite įpareigojimus. SME Teisinės ir reglamentavimo atitikties politika pateikia veiklos taisyklę:

„5.2.2 Kai reglamentas taikomas kelioms sritims (pvz., GDPR taikomas saugojimui, saugumui ir privatumui), tai turi būti aiškiai susieta Atitikties registre ir mokymų medžiagoje.“

Iš dalies „Valdysenos reikalavimai“, politikos punktas 5.2.2.

Šis Atitikties registras tampa tiltu tarp ISO/IEC 27001:2022 kontrolės priemonių, NIS2 Article 21 priemonių, DORA IRT rizikos įpareigojimų, GDPR atskaitomybės ir klientų sutarčių įsipareigojimų.

Vieno projekto įrodymų paketo susiejimas su NIS2, DORA, GDPR ir NIST CSF 2.0

Efektyviausia atitikties strategija nėra darbo dubliavimas. Ji reiškia vieno stipraus įrodymų rinkinio susiejimą su keliais įpareigojimais.

Zenith Blueprint rizikos valdymo etape, 14 žingsnyje, rekomenduoja tokio pobūdžio kryžminį susiejimą:

„Kiekvienam reglamentui, jei taikoma, galite sukurti paprastą susiejimo lentelę (ji gali būti ataskaitos priedas), kurioje išvardijami pagrindiniai reglamento saugumo reikalavimai ir atitinkamos kontrolės priemonės / politikos jūsų ISVS.“

Taip pat pažymima, kad tai naudinga, nes auditoriams ir vertintojams parodo, „kad saugumo nevaldote vakuume, o suprantate teisinį kontekstą.“

Clarysec Zenith Controls: kelių atitikčių vadovas palaiko tą patį integruotą metodą, susiedamas ISO/IEC 27001:2022 kontrolės priemones su kitomis sistemomis, audito lūkesčiais ir atitikties poreikiais. IRT projektų valdysenoje A.5.8, A.8.25 ir A.8.32 pateikiamos kaip prevencinės kontrolės priemonės, saugančios konfidencialumą, vientisumą ir prieinamumą valdysenos, taikomųjų programų saugumo, ekosistemos, apsaugos bei sistemų ir tinklo saugumo srityse.

Ši lentelė nepakeičia teisinės analizės. Ji yra valdysenos spartintuvas. Ji užtikrina, kad CISO, DAP, projekto rėmėjas, pirkimų vadovas, sistemos savininkas ir vidaus auditorius žiūrėtų į tuos pačius įrodymus.

NIST CSF 2.0 taip pat natūraliai dera su šiuo modeliu. Jo GOVERN funkcija padeda organizacijoms nustatyti politikas, vaidmenis, rizikos apetitą, priežiūrą ir teisinį arba sutartinį kontekstą. IDENTIFY, PROTECT, DETECT, RESPOND ir RECOVER funkcijos padeda komandoms bendra operacine kalba aptarti turtą, tiekėjų paslaugas, prieigos kontrolę, duomenų saugumą, platformos saugumą, saugų programinės įrangos kūrimą, stebėseną, reagavimą į incidentus ir atkūrimą.

Vienas su ISO 27001 suderintas procesas, sutelktas į A priedo A.5.8, gali sukurti pagrįstus įrodymus visiems šiems lūkesčiams.

Saugus kūrimas yra daugiau nei kodo rašymas

Daugelis IRT projektų nesėkmių įvyksta todėl, kad organizacija saugų kūrimą laiko vien kūrėjų darbu. 2026 m. saugus kūrimas taip pat apima SaaS konfigūravimą, darbo eigos automatizavimą, infrastruktūrą kaip kodą, API integracijas, tapatybės taisykles, debesijos „landing zone“, analitikos duomenų konvejerius, robotizuotą procesų automatizavimą ir mažo kodo verslo taikomąsias programas.

Zenith Blueprint kontrolės priemonių taikymo etape, 20 žingsnyje, aptaria ISO/IEC 27002:2022 kontrolės priemonę 8.25 „Saugaus kūrimo gyvavimo ciklas“:

„Ši kontrolės priemonė taikoma nepriklausomai nuo to, ar kuriate savo taikomąsias programas, konfigūruojate tokias platformas kaip ERP ar CRM sistemos, pritaikote SaaS darbo eigas ar valdote infrastruktūros kaip kodo aplinkas.“

Taip pat paaiškinama, kad saugumo reikalavimai turi būti greta funkcinių reikalavimų, o grėsmių modeliavimas padeda identifikuoti atviras sistemos dalis, rizikingus naudotojų vaidmenis ir duomenų srautus, kuriems reikia didesnės apsaugos.

Šiuolaikiniame projekte saugaus kūrimo įrodymai gali apimti:

• Saugumo reikalavimus, susietus su verslo reikalavimais
• Grėsmių modelį arba saugios architektūros peržiūrą
• Saugaus programavimo arba saugios konfigūracijos kontrolinį sąrašą
• Kodo peržiūros arba tarpusavio peržiūros įrašus
• Komponentų apskaitą ir priklausomybių rizikos būseną
• Paslapčių valdymo sprendimus
• Prieigos kontrolės ir mažiausių privilegijų principo projektavimą
• Žurnalavimo ir stebėsenos reikalavimus
• Pažeidžiamumų skenavimo rezultatus ir taisomųjų veiksmų įrašus
• Saugumo testavimą priešgamybinėje aplinkoje
• Atsarginių kopijų, atkūrimo ir atsparumo testavimą, kai aktualu
• Diegimo patvirtinimo ir grąžinimo į ankstesnę būseną įrodymus

Tikslas nėra priversti kiekvieną projektą eiti per tą patį sunkiasvorį procesą. Tikslas yra proporcingumas. Nedideliam vidinės darbo eigos pakeitimui nereikia tokių pačių įrodymų kaip pagrindinės mokėjimų platformos migracijai. Tačiau kiekvienas projektas turi būti klasifikuotas, įvertintas pagal riziką ir valdomas pagal poveikį.

Pakeitimų valdymas apsaugo projektą nuo jo paties

Rizikingiausias momentas daugelyje projektų nėra projektavimas ar programavimas. Tai diegimas.

Komanda gali atlikti grėsmių modeliavimą, kodo peržiūrą, tiekėjo vertinimą ir privatumo peržiūrą, bet vis tiek sukelti paslaugos nepasiekiamumą arba pažeidimą per skubotą gamybinės aplinkos pakeitimą. Derinimo vėliavėlė lieka įjungta. Ugniasienės taisyklė yra platesnė nei patvirtinta. Migracijos scenarijus nukopijuoja asmens duomenis į negamybinę aplinką. Trečiosios šalies webhook galinis taškas įdiegiamas be autentifikavimo. Žurnalavimo pakeitimas įrašo tapatybės dokumentų numerius. Atsarginių kopijų užduotis po perjungimo nepastebimai nesuveikia.

Zenith Blueprint kontrolės priemonių taikymo etape, 21 žingsnyje, ISO/IEC 27002:2022 kontrolės priemonę 8.32 „Pakeitimų valdymas“ apibūdina tiesiogiai:

„Pakeitimai neišvengiami, tačiau kibernetiniame saugume nekontroliuojami pakeitimai yra pavojingi.“

Toliau nurodoma:

„Iš esmės veiksmingas pakeitimų valdymas yra pakartojama darbo eiga. Ji prasideda nuo aiškaus pasiūlymo, kuriame aprašoma, kas keičiasi, kodėl, kada ir kokios galimos rizikos.“

Stiprus IRT pakeitimo įrašas turėtų atsakyti:

• Kokia sistema, paslauga, duomenų srautas, tiekėjas ar konfigūracija keičiasi?
• Kokios rizikos identifikuotos ir kas yra jų savininkai?
• Ar pakeitimas paveikia asmens duomenis, kritines paslaugas, autentifikavimą, žurnalavimą, atsargines kopijas ar reagavimą į incidentus?
• Kokie saugumo, privatumo, atsparumo ir tiekėjų patikrinimai atlikti?
• Kokie testai užbaigti prieš diegimą?
• Kokia stebėsena patvirtins tikėtiną elgseną?
• Koks grąžinimo į ankstesnę būseną arba atkūrimo planas parengtas?
• Kas patvirtino liekamąją riziką?
• Kokie įrodymai bus saugomi?

DORA kontekste tai palaiko dokumentuotą IRT rizikos valdymą, atsparumą, veiklos tęstinumą, incidentų klasifikavimą ir įgytą patirtį. NIS2 kontekste tai palaiko rizikos valdymo priemones, saugų kūrimą, incidentų prevenciją ir veiklos tęstinumą. GDPR kontekste tai padeda parodyti, kad pakeitimai, darantys poveikį asmens duomenims, buvo peržiūrėti pagal tikslą, minimizavimą, saugojimą, prieigą ir saugumo principus.

Tiekėjų ir debesijos sprendimai turi būti projekto projektavimo dalis

Šiuolaikiniuose IRT projektuose didžiausios rizikos projektavimo sprendimas dažnai yra „pirkti“, o ne „kurti“. Debesijos paslaugos, API teikėjai, tapatybės patikros platformos, mokėjimų tvarkytojai, analitikos tiekėjai, valdomų paslaugų teikėjai ir valdomo saugumo paslaugų teikėjai tampa rizikos paviršiaus dalimi.

NIS2 aiškiai apima tiekimo grandinės saugumą, tiesioginių tiekėjų ir paslaugų teikėjų pažeidžiamumus, tiekėjų kibernetinio saugumo praktikas, saugaus kūrimo procedūras ir koordinuoto tiekimo grandinės rizikos vertinimo rezultatus. DORA finansų subjektams numato dar išsamesnius reikalavimus. Ji reikalauja IRT trečiųjų šalių rizikos valdymo kaip IRT rizikos valdymo sistemos dalies, tęstinės atsakomybės net tada, kai IRT paslaugos perduodamos išorės teikėjams, informacijos registrų, ikisutartinių vertinimų, koncentracijos rizikos analizės, sutartinių kontrolės priemonių, audito ir patikrinimo teisių, nutraukimo paleidiklių ir ištestuotų pasitraukimo strategijų kritinėms arba svarbioms funkcijoms.

Klientų įtraukimo portalo atveju biometrinės patikros teikėjas negali būti patvirtintas vien todėl, kad pirkimų komandai patinka kaina, o API dokumentacija yra gera. Projektui reikia saugumo deramo patikrinimo, tvarkymo vaidmens, duomenų vietos, subtiekėjų, prieinamumo įsipareigojimų, pagalbos incidentų atvejais, audito teisių, nutraukimo pagalbos, pasitraukimo įgyvendinamumo ir stebėsenos įpareigojimų įrodymų.

Brandžiame įrodymų modelyje tiekėjų ir debesijos sprendimai yra projekto įrodymų paketo viduje, o ne atskirame tiekėjų aplanke. Kai auditorius klausia, kodėl trečioji šalis buvo priimta, atsakymas turi apimti verslo poreikį, rizikos vertinimą, sutartines apsaugos priemones, duomenų apsaugos peržiūrą, poveikį atsparumui ir nuolatinę stebėseną.

Kaip auditoriai peržiūrės saugumo nuo projektavimo etapo įrodymus

Skirtingi auditoriai į tą patį IRT projektą žiūri skirtingais kampais. Sertifikavimo auditorius, vidaus auditorius, DORA peržiūrą atliekantis asmuo, NIS2 kompetentinga institucija, privatumo auditorius, pagal NIST vertinantis asmuo arba COBIT tipo auditorius gali prašyti panašių įrodymų, tačiau juos interpretuoti skirtingai.

Auditoriai nenori gražios projekto skaidrių prezentacijos. Jie nori atsekamumo. Jie nori matyti, kad reikalavimai vedė į rizikas, rizikos — į kontrolės priemones, kontrolės priemonės — į įgyvendinimo įrodymus, o įgyvendinimas — į peržiūrą.

Todėl Zenith Controls yra naudingas rengiantis auditui. Jis padeda komandoms paaiškinti, kodėl A priedo A.5.8, A.8.25 ir A.8.32 yra prevencinės kontrolės priemonės, saugančios konfidencialumą, vientisumą ir prieinamumą prieš numatomoms nesėkmėms pasiekiant gamybinę aplinką.

Minimalus Clarysec projekto įrodymų paketas

Stiprus saugumo nuo projektavimo etapo įrodymų paketas neturi būti milžiniškas. Jis turi būti nuoseklus, proporcingas ir susietas.

Vidutinės rizikos IRT projektui Clarysec paprastai rekomenduoja šį minimalų paketą:

1. Projekto saugumo klasifikavimo įrašas
2. Reglamentavimo taikytinumo pastaba, apimanti NIS2, DORA, kai aktualu, GDPR ir sutartinius įpareigojimus
3. Duomenų srautų ir turto poveikio žemėlapis
4. Projekto rizikos vertinimas ir tvarkymo planas
5. Grėsmių modelis arba saugios architektūros peržiūra
6. Tiekėjo ir debesijos paslaugos vertinimas, kai taikoma
7. Saugaus kūrimo kontrolinis sąrašas arba konfigūracijos kontrolinis sąrašas
8. Saugumo testavimo rezultatai ir taisomųjų veiksmų įrodymai
9. Pakeitimo patvirtinimas su grąžinimo į ankstesnę būseną ir stebėsenos planu
10. Privatumo pagal projektavimą įrašas, įskaitant teisinį pagrindą ir saugojimo terminus, kai tvarkomi asmens duomenys
11. Reagavimo į incidentus ir stebėsenos atnaujinimai
12. Peržiūra po įgyvendinimo ir įgyta patirtis
13. Atitikties registro susiejimas su kontrolės priemonėmis ir įpareigojimais

Zenith Blueprint pateikia veiksmų plano logiką. 22 žingsnis įtraukia informacijos saugumą į visus projekto etapus. 20 žingsnis įtvirtina saugų kūrimą planavime, projektavime, kode, testavime ir diegime. 21 žingsnis padaro pakeitimų valdymą struktūruotą, atsekamą ir tinkamą peržiūrai. 14 žingsnis rekomenduoja kryžmiškai susieti GDPR, NIS2, DORA ir kitus įpareigojimus, kad atitikties reikalavimai nepraslystų pro spragas.

Politikos nustato veiklos taisykles. Informacijos saugumo politika integruoja saugumą su projektų valdymu, pirkimais ir teisine priežiūra. Rizikos valdymo politika projekto rizikas padaro ISVS veiklos dalimi. Saugaus kūrimo politika reikalauja grėsmių modeliavimo. Pakeitimų valdymo politika reikalauja suplanuotų, pagal riziką įvertintų, testuotų ir patvirtintų pakeitimų. Duomenų apsaugos ir privatumo politika reikalauja privatumo pagal projektavimą ir pagal numatytuosius nustatymus. Teisinės ir reglamentavimo atitikties politika reikalauja kelioms sritims taikomus reglamentus susieti Atitikties registre.

Kartu šios priemonės saugumą nuo projektavimo etapo paverčia ne siekiamybe, o audituojamu veiklos modeliu.

Dažniausi IRT projektų nesėkmių modeliai

Nesėkmės paprastai yra nuspėjamos.

Pirmoji — pavėluotas saugumo įtraukimas. Saugumo peržiūros vyksta po to, kai architektūra jau fiksuota, sutartys pasirašytos, o pristatymo datos paskelbtos. Tuo metu saugumas tampa kliūtimi, o ne projektavimo įvestimi.

Antroji — fragmentuoti įrodymai. Projektas turi testavimo rezultatus viename įrankyje, tiekėjo peržiūrą kitame, privatumo komentarus el. pašte, rizikos priėmimą susitikimo įraše ir pakeitimo patvirtinimą užklausoje. Nėra vienos gijos, pagrindžiančios valdyseną.

Trečioji — tiekėjų aklosios zonos. Projektas remiasi debesijos paslauga arba API teikėju, tačiau niekas nepatikrina subtiekėjų, duomenų vietos, audito teisių, pagalbos incidentų atvejais, pasitraukimo planų ar koncentracijos rizikos.

Ketvirtoji — privatumo nukrypimas. Sistema, sukurta vienam tikslui, pradeda palaikyti analitiką, AI eksperimentavimą, rinkodaros eksportus ar operacinę stebėseną neperžiūrint teisinio pagrindo, skaidrumo, minimizavimo ar saugojimo terminų.

Penktoji — neperžiūrėtas pakeitimas. Gamybinės aplinkos diegimas patvirtinamas pagal funkcionalumą, tačiau neįvertinamas poveikis prieigai, žurnalavimui, šifravimui, atsarginėms kopijoms, atsparumui, asmens duomenims ar ataskaitų teikimui.

Šeštoji — silpna vadovybės priežiūra. Didelio poveikio projekto rizikos priimamos per žemu lygiu, be įrodymų, kad atsakingas rizikos savininkas suprato reglamentavimo pasekmes.

Šios problemos neišsprendžiamos įsigyjant dar vieną skenerį. Jos sprendžiamos integruojant saugumo valdyseną į tai, kaip projektai siūlomi, projektuojami, perkami, kuriami, testuojami, keičiami ir peržiūrimi.

2026 m. CISO išvada

Saugumas nuo projektavimo etapo IRT projektuose dabar yra valdybos, audito ir reglamentavimo klausimas. NIS2 kibernetinio saugumo rizikos valdymą padaro valdymo organo atsakomybe. DORA IRT riziką, atsparumo testavimą, incidentų valdymą ir trečiųjų šalių priežiūrą paverčia struktūruotu finansų sektoriaus įpareigojimu. GDPR reikalauja atskaitomybės už asmens duomenų tvarkymą ir tinkamo saugumo. ISO/IEC 27001:2022 suteikia valdymo sistemos struktūrą šiems įpareigojimams paversti operacine praktika.

CISO galimybė — nebekovoti su projektų komandomis pristatymo pabaigoje. Įtraukite saugumą į inicijavimą, reikalavimus, projektavimą, tiekėjų atranką, kūrimą, testavimą, pakeitimo patvirtinimą ir peržiūrą po įgyvendinimo.

Atitikties vadovų galimybė — pakeisti išskaidytus įrodymus vienu susietu projekto įrodymų paketu.

Auditorių galimybė — testuoti projekto gyvavimo ciklą, o ne tik galutinę sistemą.

Verslo savininkų galimybė — greitesnis ir saugesnis pristatymas. Saugumas nuo projektavimo etapo mažina perdarymą, apsaugo nuo netikėtų atitikties problemų, gerina tiekėjų sprendimus ir suteikia vadovybei pagrįstą rizikos istoriją.

Jei jūsų IRT projektai juda greičiau nei jūsų įrodymų modelis, pradėkite nuo vieno bandomojo projekto. Naudokite Clarysec Zenith Blueprint, kad apibrėžtumėte projekto saugumo vartus, taikykite Clarysec politikas rizikos valdymui, saugiam kūrimui, pakeitimų valdymui ir privatumui, ir naudokite Zenith Controls, kad susietumėte ISO/IEC 27001:2022 projektų valdyseną su NIS2, DORA, GDPR ir NIST CSF 2.0.

Clarysec gali padėti sukurti pakartotinai naudojamą saugumo nuo projektavimo etapo projekto įrodymų paketą, suderinti jį su jūsų ISVS ir parengti vidaus auditui, sertifikavimo auditui, DORA pasirengimui, NIS2 valdysenai ir GDPR atskaitomybei.

Pradėkite nuo kito reikšmingo IRT projekto. Jei jis keičia sistemas, tiekėjus, duomenis, prieigą, atsparumą ar klientų pasitikėjimą, jis nusipelno saugumo nuo projektavimo etapo nuo pirmos dienos.