Pogodba s ponudnikom IT po NIS2: varnostne klavzule, SLA in prijava incidentov

Pogodba s ponudnikom IT po NIS2 ne sme biti omejena na izjavo o skladnosti, splošno varnostno klavzulo in mesečni kazalnik razpoložljivosti. Tveganja, povezana s storitvijo, mora pretvoriti v jasno razdeljene odgovornosti, merljive ravni storitev, hiter pretok informacij o incidentih, dostop do dokazil in izvedljiv izhodni načrt. Izhodišče sta kritičnost storitve in dejanska razdelitev nadzora med pogodbenima strankama. Šele na tej podlagi je mogoče določiti, kateri varnostni ukrepi, roki, pravice do preverjanja in obveznosti obveščanja morajo biti vključeni v pogodbo.

Pogodba kot mehanizem obvladovanja tveganj

Pregleda pogodb ne začnemo s pripravljenim vzorcem varnostne klavzule, temveč z zemljevidom odvisnosti organizacije od dobaviteljev. Za vsakega dobavitelja je treba opredeliti podprte storitve, procese, sisteme, podatke in lokacije ter nato oceniti posledice nedosegljivosti ali kršitve varnosti. Prednostno se obravnavajo odvisnosti, katerih motnja lahko zaustavi poslovanje, omeji izpolnjevanje obveznosti ali oteži obravnavo incidenta. Zato vse storitve IT ne potrebujejo enake ravni pogodbenih varovalk.

Razvrstitev dobavitelja po kritičnosti mora temeljiti na analizi vplivov na poslovanje in oceni tveganja, ne zgolj na vrednosti pogodbe. Posebno pozornost zahtevajo storitve, pri katerih organizacija odgovarja za neprekinjeno delovanje in obravnavo incidentov, ponudnik pa nadzoruje tehnične informacije, dnevnike dogodkov, varnostne kopije ali okolje, potrebno za obnovitev storitve. Organizacija mora imenovati tudi lastnika tveganja, povezanega z dobaviteljem. Brez te vloge odgovornost ostane razpršena med nabavo, IT, informacijsko varnostjo in lastnikom procesa.

Vsebino pogodbe je smiselno zasnovati na scenarijih motenj: izpadu storitve, napadu, izgubi ali poškodovanju podatkov, nerazpoložljivosti osebja ponudnika, prekinitvi verige podizvajalcev in prenehanju sodelovanja. Za vsak scenarij je treba opredeliti ukrepe pogodbenih strank, obseg odgovornosti, pretok informacij in pogoje obnovitve. Iz teh odločitev izhajajo ravni razpoložljivosti, odzivni in obnovitveni časi, zahtevana dokumentacija ter pravice do preverjanja.

Izjava o zagotavljanju visoke razpoložljivosti ne določa, kako dolgo je lahko nedosegljiv sistem za krmiljenje proizvodnje, od katerega trenutka se meri izpad ali kdo mora zagotoviti podatke za oceno incidenta. Prav tako ne zagotavlja dostopa do kopij dnevniških zapisov, informacij o podizvajalcih ali podatkov, potrebnih za varen prenos storitve. Takšne vrzeli se praviloma pokažejo med izpadom, ko razdelitev odgovornosti ne more več ostati implicitna.

Sklicevanje na NIS2 ali ustrezne zahteve KSC mora zaključiti analizo tveganj in odgovornosti, ne pa nadomestiti operativne vsebine pogodbe. Širši upravljavski vidik predstavlja gradivo NIS2 za proizvodna podjetja: za koga velja, katere obveznosti uvaja in kako pripraviti organizacijo, ne da bi temo omejili izključno na IT. Obseg pogodbenih sprememb je treba vedno prilagoditi vlogi organizacije, kritičnosti storitve in dejanski razdelitvi nadzora med strankama.

Obseg storitve in razdelitev odgovornosti

Razdelitev nalog mora biti opisana v tehnični prilogi in ne sme ostati skrita v splošni opredelitvi predmeta pogodbe. Priloga naj določa podprta sredstva in okolja, vrste podatkov, lokacije obdelave in izvajanja storitev, vmesnike, čas zagotavljanja podpore ter izključitve. Brez teh podatkov ni mogoče nedvoumno določiti, kje se konča odgovornost ponudnika, kateri dogodek sproži merjenje SLA in kdo varuje elemente na stičišču sistemov.

Varnostne ukrepe je smiselno opisati z zahtevanim rezultatom, odgovorno stranko in dokazilom o izvedbi, tehnološke podrobnosti pa ohraniti v nadzorovani tehnični dokumentaciji. Tako se zmanjša tveganje, da bi pogodba hitro zastarala. Standardni nabor varnostnih ukrepov ponudnika je mogoče sprejeti šele po primerjavi s tveganji konkretne storitve in odpravi ugotovljenih vrzeli. Matrika odgovornosti mora razlikovati med lastnikom varnostnega ukrepa, izvajalcem in osebo oziroma funkcijo, ki odobrava odstopanja.

Če okolje upravlja ponudnik, mora pogodba dodatno urediti privilegirani dostop: ločitev nalog, način avtentikacije, evidentiranje administratorskih dejavnosti in takojšen odvzem pravic po spremembi vloge ali prenehanju sodelovanja. Izjava, da se varnostne kopije izdelujejo, ni zadostna, če naročnik ne ve, kdo jih šifrira, kje se hranijo, kdo jih lahko obnovi in kateri dokument potrjuje rezultat preizkusa obnovitve.

Ponudnik mora voditi posodobljen seznam podizvajalcev, ki vplivajo na storitev, skupaj z opisom njihovih vlog in lokacij obdelave, ter jim naložiti zahteve, ki niso manj stroge od zahtev, dogovorjenih z naročnikom. Pogodba mora določiti, katere spremembe zahtevajo predhodno soglasje ter pri katerih zadoščata obvestilo in ponovna ocena tveganja. Certifikat sistema upravljanja lahko podpre takšno oceno, ne nadomešča pa odgovornosti, določenih za konkretno storitev. To razmerje podrobneje obravnava gradivo NIS2 in SIST EN ISO 27001: kaj zagotavlja certifikat in kaj še vedno manjka za skladnost s KSC.

Varnostne klavzule, katerih izvajanje je mogoče preveriti

Varnostna klavzula postane preverljiva šele, ko opredeljuje pričakovani rezultat, področje uporabe, pogostost izvajanja, način dokazovanja izvedbe in postopek obravnave odstopanj. Formulacije, kot sta »v skladu z najboljšimi praksami« ali »z ustrezno skrbnostjo«, lahko zahteve dopolnjujejo, vendar same ne omogočajo ocene, ali je ponudnik obveznost pravilno izpolnil. Za vsak varnostni ukrep je treba določiti lastnika zahteve, obdobje hrambe dokazil in stranko, ki sme odobriti izjemo.

Tako oblikovane zahteve morajo vključevati najmanj upravljanje ranljivosti in posodobitev, vzdrževanje varne konfiguracije, šifriranje, zaščito in hrambo dnevnikov dogodkov, izdelavo varnostnih kopij, preizkuse obnovitve, upravljanje sprememb ter nadzor dostopa. Pogostost pregledov pravic, preizkusov obnovitve in poročanja ter roke za odpravljanje ranljivosti je treba določiti na podlagi ocene tveganja storitve. Enaki roki in intervali niso primerni za vse dobavitelje.

Vsako odstopanje je treba vnesti v register skupaj z utemeljitvijo, rokom odprave, lastnikom tveganja in nadomestnimi ukrepi. Pred odobritvijo je treba oceniti, ali nadomestni ukrepi tveganje dejansko zmanjšujejo na raven, ki jo organizacija lahko sprejme.

Določilo o rednem varnostnem kopiranju je nepopolno, če ne določa podatkov in sistemov, vključenih v kopiranje, obdobja hrambe, zaščite pred spremembo ali izbrisom, pravil dostopa in pogostosti preizkusov obnovitve. Določiti mora tudi način, na katerega ponudnik prijavi neuspešno kopiranje ali preizkus, kdo odobri korektivne ukrepe in katero poročilo potrjuje njihovo zaključitev. Tudi obveznost odpravljanja ranljivosti zahteva dogovor o načinu razvrščanja, odzivnih rokih glede na tveganje, pravilih za odložitev posodobitev in dokumentiranju začasnih zaščitnih ukrepov.

Dokazila je treba razdeliti na tista, ki se posredujejo periodično, in tista, ki so na voljo na zahtevo. V prvo skupino lahko sodijo povzetki ranljivosti, poročila o posodobitvah, rezultati preizkusov obnovitve in potrditve pregledov dostopov. Po incidentu, pomembni spremembi ali ugotovljenem odstopanju so lahko potrebni podrobni rezultati preizkusov, dnevniki dogodkov, zgodovina sprememb, register izjem in načrt korektivnih ukrepov. Obseg, lastnike in obdobje hrambe teh gradiv je smiselno povezati z načeli iz gradiva Dokumentacija NIS2 in KSC pred nadzorom: katere politike, registre in dokazila organizacija dejansko potrebuje.

Pravica do preverjanja mora biti stopnjevana in izvedljiva tudi pri ponudniku storitev v oblaku. Prva raven lahko vključuje pregled dokumentacije in pojasnjevalni sestanek, naslednja neodvisna poročila ali dogovorjene preizkuse, pregled na lokaciji pa se lahko predvidi za povečano tveganje, pomemben incident ali pomanjkanje verodostojnih dokazil. Pogodba mora urejati roke, zaupnost, tehnični obseg in odpravljanje ugotovitev, ne da bi naročniku podelila pravice, ki jih v skupnem okolju ni mogoče uresničiti.

SLA za odpornost, ne le za razpoložljivost

SLA mora izhajati iz analize vplivov na poslovanje in ne iz kataloga standardnih parametrov ponudnika. Lastnik procesa najprej določi dopustno trajanje prekinitve, sprejemljivo izgubo podatkov ter posledice nedosegljivosti za proizvodnjo, podporo strankam, obračune in pravne obveznosti. Šele nato se določijo ciljni časi obnovitve, zahteve glede nadomestne storitve in zasilnega načina delovanja ter prednostne ravni prijav. Mesečni kazalnik razpoložljivosti ne pokaže, ali lahko posamezen izpad v kritičnem trenutku ustavi proces dlje, kot je za organizacijo sprejemljivo.

Poleg razpoložljivosti mora pogodba določati čas potrditve prijave, začetek diagnostike, obnovitev funkcionalnosti in odpravo vzroka, pa tudi pogostost obvestil, ravni eskalacije in način dela zunaj rednega delovnega časa. Odzivni čas ni enak času obnovitve, uvedba nadomestne rešitve pa ne pomeni, da je težava dokončno odpravljena. Jasno razlikovanje teh pojmov operativni ekipi pokaže, kdaj bo lahko nadaljevala delo, lastniku storitve pa, kdaj mora ponudnik zaključiti analizo vzrokov in uvesti trajen korektivni ukrep.

Pri sistemu za krmiljenje proizvodnega procesa lahko kritični incident zahteva takojšnjo eskalacijo in neprekinjeno obveščanje do aktiviranja zasilnega načina. Enaka tehnična napaka v učnem okolju je lahko razvrščena nižje. Razvrščanje mora zato temeljiti na vplivu na poslovanje, ne zgolj na tehničnem opisu napake. Če ima organizacija zanesljive zgodovinske podatke, naj pri določanju pragov upošteva dejanske odzivne in obnovitvene čase, doseženo razpoložljivost ter število ponavljajočih se izpadov.

Mehanizem merjenja mora določati vir podatkov, časovni pas, trenutek začetka in zaustavitve merjenja, dogovorjeni čas izvajanja storitve, vzdrževalna okna ter pravila za spremembo razreda incidenta. Izključitve iz merjenja morajo biti navedene v zaprtem in preverljivem seznamu. Vanj ni dopustno vključiti dogodkov, ki sodijo v področje odgovornosti ponudnika. Usklajenost teh določil z dejansko operativno pripravljenostjo je mogoče oceniti v okviru gradiva Presoja NIS2 v proizvodnem podjetju – kako preveriti pripravljenost organizacije na nove obveznosti.

Dobropisi za storitev ali simbolična nadomestila ne obnovijo procesa in ne zmanjšajo posledic izpada. Pomembnejši so obveznost predložitve načrta izboljšav, vodstvena eskalacija, dodatni preizkusi odpornosti in pravica do odpovedi pogodbe ob trajnem ali ponavljajočem se nedoseganju dogovorjenih ravni. Finančna sankcija lahko okrepi odgovornost, ne more pa nadomestiti mehanizma za obnovitev storitve, odpravo vzrokov in preprečevanje ponovnih izpadov.

Incidenti in obveznosti obveščanja

Pogodba mora ponudnika zavezati, da brez nepotrebnega odlašanja prijavi vsak dogodek, ki bi lahko vplival na storitev, podatke, neprekinjeno poslovanje ali varnost naročnika. Prvo obvestilo ne sme biti odvisno od popolne potrditve vzroka, obsega škode ali pravne opredelitve dogodka. Pogodbeni rok je treba določiti z dovolj rezerve, da lahko naročnik opravi lastno oceno in spoštuje morebitne zunanje roke za prijavo. Izhajati mora iz kritičnosti storitve in razpoložljivosti kontaktne točke 24/7, ne iz organizacijskega udobja pogodbenih strank.

Pretok informacij je treba razdeliti na začetno opozorilo, sprotna poročila o stanju, poročilo po dogodku in analizo temeljnih vzrokov. Za vsako fazo je treba določiti obseg podatkov, dovoljeni komunikacijski kanal, prejemnike, pogostost posodobitev in pravila eskalacije ob nedosegljivosti kontakta. Začetno sporočilo mora vsebovati najmanj čas zaznave, prizadeta sredstva in storitve, pričakovani vpliv, že izvedene ukrepe, razpoložljive tehnične kazalnike, oceno tveganja nadaljnjega širjenja in rok naslednje posodobitve. Seznam kontaktov mora vključevati namestnike in se redno preverjati, tudi zunaj običajnega delovnega časa.

Če ponudnik zazna neobičajen promet v okolju, ki podpira ključno aplikacijo, mora naročnika opozoriti, še preden dokončno ugotovi, ali je prišlo do kršitve. Naročnik aktivira svoj proces upravljanja incidentov, imenuje osebo, odgovorno za odločitve, vključi odzivno skupino in po potrebi tudi zavarovalnico ter določi, kdo odobri zunanje prijave in komuniciranje s strankami. Ponudnik zavaruje dogovorjene dnevnike in tehnične sledi ter sodeluje pri analizi, omejevanju posledic in ugotavljanju obsega dogodka, vendar ne prevzema regulatorne odgovornosti naročnika.

Klavzule morajo določati tudi pravila za ohranitev in izročitev dokazov, varovanje njihove celovitosti, dokumentiranje odločitev ter pripravo podatkov, potrebnih za prijave in poznejšo analizo temeljnih vzrokov. Roke, prejemnike in obseg zunanjih prijav je treba vsakokrat preveriti glede na veljavno zakonodajo, status organizacije in vrsto dogodka. Registre obvestil, odločitev, eskalacij in ukrepov je treba povezati z gradivom Dokumentacija NIS2 in KSC pred nadzorom: katere politike, registre in dokazila organizacija dejansko potrebuje, časovni načrt prilagoditve pa z gradivom Uvedba NIS2 po vpisu na seznam KSC – načrt ukrepov do 3. aprila 2027.

Uvedba, nadzor in varen izhod

Podpis aneksa še ne zaključi procesa upravljanja dobavitelja. Lastnik pogodbe mora periodično pregledovati rezultate SLA, incidente, odstopanja, korektivne ukrepe, spremembe podizvajalcev in aktualnost dokazil o izpolnjevanju zahtev. Osnova nadzora je register pogodb, ki vsebuje najmanj datum podaljšanja, lastnika, kritičnost storitve in stanje dogovorjenih varnostnih ukrepov. Izjava o skladnosti ne nadomešča poročil, rezultatov preizkusov in zapisov, ki dokazujejo izpolnjevanje obveznosti.

Pred podaljšanjem pogodbe ali pomembno spremembo storitve je treba ponovno oceniti njeno kritičnost, tehnične in procesne odvisnosti, koncentracijo storitev pri enem ponudniku, izvedljivost varnostnih ukrepov in možnost prehoda na nadomestno rešitev. Tak pregled pokaže, ali zadošča aneks ali je potreben nov nabavni postopek. Če strateški ponudnik zavrne presojo ali spremembo pogojev, mora organizacija vrzel dokumentirati ter izbrati med uvedbo nadomestnega ukrepa, formalnim sprejetjem preostalega tveganja in zamenjavo ponudnika.

Izhodni načrt mora biti izvedljiv že pred odpovedjo pogodbe. Vključevati mora vračilo in prenos podatkov v uporabnem formatu, migracijsko podporo, zagotavljanje neprekinjenega delovanja v prehodnem obdobju, odvzem dostopov, izbris kopij ter potrditev izvedbe teh dejavnosti. Hkrati je treba ohraniti zapise, potrebne za pravne, dokazne in presojevalne namene. Praktičen preizkus je poskusna obnovitev podatkov pri drugem ponudniku, skupaj s preverjanjem popolnosti, časa migracije in možnosti ukinitve obstoječih uporabniških računov.

Posodobitev portfelja pogodb je treba začeti pri storitvah z največjim vplivom na poslovanje, ugotovljene vrzeli pa razvrstiti glede na posledice in nujnost. Učinkovitost sprejetih mehanizmov je smiselno preveriti z vajo odzivanja na incident in presojo vzorca dokazil. Rezultati pregledov SLA, incidentov, odstopanj, korektivnih ukrepov in izhodnih preizkusov pokažejo, ali zahteve delujejo v praksi ali ostajajo zgolj pogodbeno besedilo.

Obseg ocene je mogoče povezati z gradivom Presoja NIS2 v proizvodnem podjetju – kako preveriti pripravljenost organizacije na nove obveznosti. Obveznosti organizacije je treba določiti tudi ob upoštevanju njenega statusa, ki ga obravnava gradivo Direktiva NIS2 – za koga velja in katera podjetja morajo izpolniti nove zahteve?