Ugovor s IT dobavljačem nakon NIS2: sigurnosne klauzule, SLA i prijava incidenata

Ugovor s IT dobavljačem nakon NIS2 ne bi se trebao svesti na izjavu o usklađenosti, opću sigurnosnu klauzulu i mjesečni pokazatelj dostupnosti. Rizike povezane s uslugom mora pretvoriti u jasnu podjelu odgovornosti, mjerljive razine usluge, pravodoban protok informacija o incidentima, pristup dokazima i provediv izlazni plan. Polazište su kritičnost usluge i stvarna raspodjela kontrole između ugovornih strana. Tek se na toj osnovi mogu odrediti sigurnosne mjere, rokovi, prava provjere i obveze izvješćivanja koje treba uključiti u ugovor.

Ugovor kao mehanizam upravljanja rizikom

Pregled ugovora ne treba započeti gotovim predloškom sigurnosne klauzule, nego mapiranjem ovisnosti organizacije o dobavljačima. Za svakog dobavljača potrebno je utvrditi koje usluge, procese, sustave, podatke i lokacije podržava te procijeniti posljedice nedostupnosti ili narušavanja sigurnosti. Prioritet imaju ovisnosti čiji bi poremećaj mogao zaustaviti poslovanje, ograničiti izvršavanje obveza ili otežati upravljanje incidentom. Zbog toga svaka IT usluga ne zahtijeva jednaku razinu ugovornih zaštitnih mjera.

Klasifikacija kritičnosti dobavljača treba proizlaziti iz analize utjecaja na poslovanje i procjene rizika, a ne samo iz vrijednosti ugovora. Posebnu pozornost zahtijevaju usluge za čiji kontinuitet i upravljanje incidentima odgovara organizacija, dok dobavljač kontrolira tehničke informacije, zapisnike događaja, sigurnosne kopije ili okruženje potrebno za oporavak usluge. Organizacija također treba imenovati vlasnika rizika povezanog s dobavljačem. Bez jasno određene uloge odgovornost ostaje raspršena između nabave, IT-a, informacijske sigurnosti i vlasnika procesa.

Sadržaj ugovora treba oblikovati prema scenarijima poremećaja: prekidu usluge, napadu, gubitku ili oštećenju podataka, nedostupnosti osoblja dobavljača, prekidu lanca podugovaratelja i prestanku suradnje. Za svaki scenarij potrebno je definirati postupke obiju strana, područje odgovornosti, tok informacija i uvjete oporavka. Iz tih odluka proizlaze ciljne razine dostupnosti, vremena odziva i ponovne uspostave, opseg potrebne dokumentacije te prava provjere.

Izjava o visokoj dostupnosti ne određuje koliko dugo sustav za upravljanje proizvodnjom smije biti nedostupan, od kojeg se trenutka mjeri zastoj ni tko će dostaviti podatke potrebne za procjenu incidenta. Također ne jamči pristup preslikama zapisa događaja, informacijama o podugovarateljima ili podacima potrebnima za siguran prijenos usluge. Takvi se nedostaci obično pokažu tijekom prekida, kada podjela odgovornosti više ne može ostati prešutna.

Pozivanje na NIS2 ili mjerodavne nacionalne zahtjeve za kibernetičku sigurnost treba zaključiti analizu rizika i odgovornosti, a ne zamijeniti operativni sadržaj ugovora. Širi upravljački kontekst prikazan je u materijalu NIS2 za proizvodna poduzeća: na koga se odnosi, koje obveze uvodi i kako pripremiti organizaciju bez svođenja teme isključivo na IT. Opseg ugovornih izmjena treba svaki put prilagoditi ulozi organizacije, kritičnosti usluge i stvarnoj raspodjeli kontrole između ugovornih strana.

Opseg usluge i podjela odgovornosti

Podjelu obveza treba opisati u tehničkom prilogu, a ne ostaviti je u općenitoj definiciji predmeta ugovora. Prilog bi trebao navesti obuhvaćenu imovinu i okruženja, vrste podataka, lokacije obrade i pružanja usluge, sučelja, vrijeme dostupnosti podrške te izuzeća. Bez tih podataka nije moguće nedvosmisleno utvrditi gdje završava odgovornost dobavljača, koji događaj pokreće mjerenje SLA-a niti tko štiti elemente na spoju sustava.

Sigurnosne mjere korisno je opisati kroz zahtijevani rezultat, odgovornu stranu i dokaz provedbe, dok tehnološke pojedinosti treba zadržati u kontroliranoj tehničkoj dokumentaciji. Time se smanjuje rizik da ugovor brzo zastari. Standardni katalog kontrola dobavljača može se prihvatiti tek nakon usporedbe s rizikom konkretne usluge i otklanjanja utvrđenih nedostataka. Matrica odgovornosti treba razlikovati vlasnika kontrole, izvršitelja i osobu ovlaštenu za odobravanje odstupanja.

Ako okruženjem upravlja dobavljač, ugovor treba dodatno urediti privilegirani pristup: razdvajanje dužnosti, način autentifikacije, evidenciju administratorskih aktivnosti i neodgodivo ukidanje ovlasti nakon promjene uloge ili prestanka suradnje. Sama izjava da se izrađuju sigurnosne kopije nije dovoljna ako naručitelj ne zna tko ih šifrira, gdje se čuvaju, tko ih može obnoviti i koji dokument potvrđuje rezultat testa oporavka.

Dobavljač treba održavati ažuran popis podugovaratelja koji utječu na uslugu, s opisom njihovih uloga i lokacija obrade, te na njih prenijeti zahtjeve koji nisu blaži od onih dogovorenih s naručiteljem. Ugovor mora jasno odrediti koje promjene zahtijevaju prethodnu suglasnost, a za koje su dovoljni obavijest i ponovna procjena rizika. Certifikat sustava upravljanja može biti koristan ulaz u procjenu, ali ne zamjenjuje odgovornosti utvrđene za konkretnu uslugu. Taj je odnos detaljnije obrađen u materijalu NIS2 i HRN EN ISO 27001: što potvrđuje certifikat, a što još treba urediti radi ispunjavanja primjenjivih zahtjeva kibernetičke sigurnosti.

Sigurnosne klauzule koje se mogu provjeriti

Sigurnosna klauzula postaje mjerljiva i provjerljiva tek kada definira očekivani rezultat, područje primjene, učestalost aktivnosti, način dokazivanja provedbe i postupanje s odstupanjima. Izrazi poput „u skladu s najboljom praksom” ili „uz dužnu pažnju” mogu dopuniti zahtjeve, ali sami ne omogućuju procjenu je li dobavljač pravilno izvršio obvezu. Za svaku kontrolu treba odrediti vlasnika zahtjeva, razdoblje čuvanja dokaza i stranu ovlaštenu za prihvaćanje iznimke.

Tako postavljeni zahtjevi trebali bi obuhvatiti najmanje upravljanje ranjivostima i ažuriranjima, održavanje sigurne konfiguracije, šifriranje, zaštitu i čuvanje zapisa događaja, izradu sigurnosnih kopija, testove oporavka, upravljanje promjenama i kontrolu pristupa. Učestalost pregleda ovlasti, testova oporavka i izvješćivanja, kao i rokove za otklanjanje ranjivosti, treba izvesti iz procjene rizika usluge. Ne trebaju biti jednaki za sve dobavljače.

Svako odstupanje treba evidentirati zajedno s obrazloženjem, rokom otklanjanja, vlasnikom rizika i kompenzacijskim kontrolama. Prihvaćanje odstupanja zahtijeva procjenu smanjuju li zamjenske kontrole rizik na razinu koju je organizacija odobrila.

Odredba o redovitoj izradi sigurnosnih kopija ostaje nepotpuna ako ne navodi obuhvaćene podatke i sustave, razdoblje čuvanja, zaštitu od izmjene ili brisanja, pravila pristupa ni učestalost testova oporavka. Također treba odrediti kako dobavljač prijavljuje neuspješnu izradu kopije ili test, tko odobrava korektivne mjere i koje izvješće potvrđuje njihovo zatvaranje. Jednako tako, obveza otklanjanja ranjivosti zahtijeva definiranu klasifikaciju, rokove odziva ovisne o riziku, pravila odgode ažuriranja i dokumentiranje privremenih zaštitnih mjera.

Dokaze treba podijeliti na one koji se dostavljaju periodično i one koji se daju na zahtjev. Prva skupina može obuhvaćati sažetke ranjivosti, izvješća o ažuriranjima, rezultate testova oporavka i potvrde pregleda pristupa. Nakon incidenta, značajne promjene ili utvrđenog odstupanja mogu biti potrebni detaljni rezultati testiranja, zapisi događaja, povijest promjena, registar iznimaka i plan korektivnih radnji. Opseg, vlasnike i rok čuvanja tih materijala korisno je povezati s načelima opisanima u tekstu Dokumentacija za NIS2 i nacionalne zahtjeve prije nadzora: koje politike, evidencije i dokaze organizacija zaista treba imati.

Pravo na provjeru treba biti razmjerno, stupnjevano i provedivo i kada je riječ o pružatelju usluga u oblaku. Prva razina može uključivati pregled dokumentacije i sastanak radi pojašnjenja, sljedeća neovisna izvješća ili dogovorena testiranja, dok se audit na lokaciji može rezervirati za povišeni rizik, značajan incident ili nedostatak vjerodostojnih dokaza. Ugovor treba urediti rokove, povjerljivost, tehnički opseg i način otklanjanja nalaza, bez dodjeljivanja naručitelju prava koja nije moguće ostvariti u dijeljenom okruženju.

SLA za otpornost, a ne samo za dostupnost

SLA treba proizlaziti iz analize utjecaja na poslovanje, a ne iz standardnog kataloga parametara dobavljača. Vlasnik procesa najprije određuje prihvatljivo trajanje prekida, dopušteni gubitak podataka i posljedice nedostupnosti za proizvodnju, korisničku podršku, obračune i pravne obveze. Tek se zatim utvrđuju ciljno vrijeme oporavka, zahtjevi za zamjensku uslugu i krizni način rada te prioriteti prijava. Mjesečni pokazatelj dostupnosti ne daje odgovor na pitanje može li jedan prekid u kritičnom trenutku zaustaviti proces dulje nego što organizacija može prihvatiti.

Osim dostupnosti, ugovor treba definirati vrijeme potvrde prijave, početka dijagnostike, ponovne uspostave funkcije i uklanjanja uzroka, kao i učestalost obavijesti, razine eskalacije te način rada izvan uobičajenog radnog vremena. Vrijeme odziva nije isto što i vrijeme oporavka, a aktiviranje zamjenskog rješenja ne znači da je problem trajno uklonjen. Razdvajanje tih pojmova omogućuje operativnom timu da utvrdi kada će ponovno moći raditi, a vlasniku usluge kada dobavljač mora dovršiti analizu uzroka i provesti trajnu korektivnu radnju.

Kod sustava koji upravlja proizvodnim procesom kritični incident može zahtijevati trenutačnu eskalaciju i kontinuiranu komunikaciju do aktiviranja kriznog načina rada. Ista pogreška u okruženju za edukaciju može imati niži prioritet. Klasifikacija se zato mora temeljiti na poslovnom utjecaju, a ne samo na tehničkom opisu pogreške. Ako organizacija raspolaže vjerodostojnim povijesnim podacima, pri određivanju pragova treba uzeti u obzir stvarna vremena odziva i oporavka, ostvarenu dostupnost i broj ponavljajućih prekida.

Mehanizam mjerenja treba definirati izvor podataka, vremensku zonu, trenutak pokretanja i zaustavljanja mjerenja, ugovoreno vrijeme pružanja usluge, termine održavanja i pravila promjene klasifikacije incidenta. Izuzeća iz mjerenja moraju biti navedena u zatvorenom i provjerljivom popisu. Ne smiju obuhvaćati događaje koji su u području odgovornosti dobavljača. Usklađenost tih pravila sa stvarnom operativnom spremnošću može se procijeniti kroz NIS2 audit u proizvodnom poduzeću – kako provjeriti je li organizacija spremna za nove obveze.

Ugovorni krediti ni simbolične naknade ne vraćaju proces u rad niti ograničavaju posljedice zastoja. Veću vrijednost imaju obveza izrade plana poboljšanja, upravljačka eskalacija, dodatni testovi otpornosti i pravo na raskid ugovora u slučaju trajnog ili ponavljajućeg neispunjavanja dogovorenih razina. Financijska sankcija može pojačati odgovornost, ali ne može zamijeniti mehanizam oporavka usluge, uklanjanja uzroka i sprječavanja ponovnih prekida.

Incidenti i obveze izvješćivanja

Ugovor treba obvezati dobavljača da bez odgode prijavi svaki događaj koji može utjecati na uslugu, podatke, kontinuitet poslovanja ili sigurnost naručitelja. Početna obavijest ne smije ovisiti o potpunoj potvrdi uzroka, opsega štete ili pravne kvalifikacije događaja. Ugovorni rok treba sadržavati dovoljno vremena da naručitelj provede vlastitu procjenu i, ako je potrebno, ispuni vanjske rokove izvješćivanja. Taj rok treba proizlaziti iz kritičnosti usluge i dostupnosti kontaktne točke 24/7, a ne iz administrativne praktičnosti ugovornih strana.

Tok informacija treba podijeliti na početno upozorenje, situacijska ažuriranja, izvješće nakon događaja i analizu temeljnog uzroka. Za svaku fazu treba definirati sadržaj, dopušteni komunikacijski kanal, primatelje, učestalost ažuriranja i pravila eskalacije u slučaju nedostupnosti kontakta. Početna obavijest treba sadržavati najmanje vrijeme otkrivanja, pogođenu imovinu i usluge, procijenjeni utjecaj, poduzete mjere, raspoložive tehničke pokazatelje, procjenu rizika daljnjeg širenja i termin sljedećeg ažuriranja. Popis kontakata mora uključivati zamjene i treba ga periodično provjeravati, uključujući izvan uobičajenog radnog vremena.

Ako dobavljač otkrije neuobičajen promet u okruženju koje podržava ključnu aplikaciju, treba upozoriti naručitelja prije konačne potvrde je li došlo do povrede. Naručitelj aktivira vlastiti proces upravljanja incidentima, imenuje osobu odgovornu za odluke, uključuje tim za odgovor na incidente, a prema potrebi i osiguratelja, te utvrđuje tko odobrava vanjsku prijavu i komunikaciju s korisnicima. Dobavljač čuva dogovorene zapisnike i tehničke tragove, podupire analizu, ograničavanje posljedica i određivanje opsega događaja, ali ne preuzima regulatornu odgovornost naručitelja.

Klauzule trebaju urediti i pravila očuvanja i stavljanja dokaza na raspolaganje, zaštitu njihova integriteta, dokumentiranje odluka te pripremu podataka potrebnih za prijave i naknadnu analizu temeljnog uzroka. Rokove, primatelje i sadržaj vanjskih prijava potrebno je svaki put provjeriti prema važećim propisima, statusu organizacije i vrsti događaja. Evidencije obavijesti, odluka, eskalacija i aktivnosti treba povezati s materijalom Dokumentacija za NIS2 i nacionalne zahtjeve prije nadzora: koje politike, evidencije i dokaze organizacija zaista treba imati, a plan prilagodbe s tekstom Uvođenje NIS2 nakon upisa u nacionalni registar – plan aktivnosti do 3. travnja 2027..

Provedba, nadzor i siguran izlazak iz ugovornog odnosa

Potpisivanje dodatka ugovoru ne završava proces upravljanja dobavljačem. Vlasnik ugovora treba periodično pregledavati rezultate SLA-a, incidente, odstupanja, korektivne radnje, promjene podugovaratelja i aktualnost dokaza o ispunjavanju zahtjeva. Temelj nadzora čini registar ugovora koji sadržava najmanje datum obnove, vlasnika, kritičnost usluge i status dogovorenih sigurnosnih mjera. Izjava o usklađenosti ne zamjenjuje izvješća, rezultate testiranja ni zapise koji dokazuju izvršavanje obveza.

Prije obnove ugovora ili značajne promjene usluge treba ponovno procijeniti njezinu kritičnost, tehničke i procesne ovisnosti, koncentraciju usluga kod jednog dobavljača, provedivost zaštitnih mjera i mogućnost prelaska na zamjensko rješenje. Takav pregled pokazuje je li dovoljan dodatak ugovoru ili je potreban novi postupak nabave. Ako strateški dobavljač odbija audit ili promjenu uvjeta, organizacija treba dokumentirati nedostatak i odlučiti između uvođenja kompenzacijske kontrole, formalnog prihvaćanja preostalog rizika i promjene dobavljača.

Izlazni plan mora biti provediv prije nego što se ugovor otkaže. Treba obuhvatiti povrat i prijenos podataka u upotrebljivom formatu, pomoć pri migraciji, održavanje kontinuiteta tijekom prijelaznog razdoblja, ukidanje pristupa, brisanje kopija i potvrdu izvršenja tih aktivnosti. Istodobno se moraju sačuvati zapisi potrebni u pravne, dokazne i auditne svrhe. Praktična provjera može uključivati probni oporavak podataka kod drugog dobavljača, uz provjeru cjelovitosti, trajanja migracije i mogućnosti deaktiviranja postojećih računa.

Modernizaciju portfelja ugovora treba započeti uslugama s najvećim utjecajem na poslovanje, a nedostatke rasporediti prema posljedicama i hitnosti. Učinkovitost dogovorenih mehanizama korisno je provjeriti kroz vježbu odgovora na incident i audit uzorka dokaza. Rezultati pregleda SLA-a, incidenata, odstupanja, korektivnih radnji i testova izlaska pokazat će funkcioniraju li zahtjevi u praksi ili postoje samo kao ugovorne odredbe.

Opseg procjene može se povezati s materijalom NIS2 audit u proizvodnom poduzeću – kako provjeriti je li organizacija spremna za nove obveze. Obveze organizacije pritom treba utvrditi uzimajući u obzir njezin status, koji je obrađen u tekstu Direktiva NIS2 – na koga se odnosi i koja poduzeća moraju ispuniti nove zahtjeve?