secria.eu

Mida tellija ICT-teenuste osutamisel pärast NIS2 nõuab

Tellija, kes ise kuuluvad NIS2 hoolsuskohustuse alla, tõlgivad selle kohustuse oma ICT-tarnija lepingu nõueteks — süsteemide juurdepääsu, kaughaldustuse ja alamtarnijate kohta.

Mida tellija ICT-teenuste osutamisel pärast NIS2 nõuab

Tellimusesaaja, kes ise NIS2 vastutusega kohustise alla kuulub, peab näitama, et ta kontrollib ka oma tarnijate ahelas olevaid riske. Kui olete kaughaldusteenuste, hostingu, rakenduste haldusteenuste või abistamiskeskuse pakkuja sellisele tellimusesaajale, kajastub see lepingus: nõuded selle kohta, kellel on juurdepääs süsteemidele, kuidas seda juurdepääsu registreeritakse, ja kas kasutate alamhangeid ilma sellest ette teatamata.

Nõuded erinevad tellimusesaaja ja valdkonna järgi, kuid mitmed teemad esinevad peaaegu alati: ligipääsukontroll, haldustegevuste logimine, juhtumist oma poolel teatamise tähtaeg, ja ülevaade sellest, kes on veel kaasatud. See viimane aspekt — alamhanked — on paljudele ICT-teenuste pakkujatele küsitluse kõige pikemalt käsitletav teema.

Miks see nüüd lepingusse kuulub

NIS2-direktiiv kohustab vastutusega subjekte artiklis 21 hindama ka oma tarnijate ja teenuste pakkujate turvalisust. Tellimusesaaja, kes ise auditeerimiskohustise alla kuulub, ei saa seda tõendada suulise lubadusega; tal on vaja kirjalikku lepingut, mida ta oma inspektsioonile näidata saab. Teie jaoks ICT-teenuste pakkujana tähendab see: sama küsimus naaseb, nüüd aga fikseeritud lepingu lisa või lisana, mitte eraldi e-postis.

See on vormi muutus, mitte tingimata sisulise muutuse rõhuasetus. Palju sellest, mida küsitakse, tegite haldurina tõenäoliselt juba. Uus on see, et peate seda tõendama, kuupäeva ja nimega.

Juurdepääs kliendi süsteemidele: mida täpselt küsitakse

Tellimusesaajad küsivad üha sagedamini ülevaadet sellest, kellel on nende juures juurdepääs, milliste õigustega, ja kuidas pääs eemaldatakse, kui keegi meeskonnast lahkub. Multifaktoriline autentimine haldusjuurdepääsuks on vahepeal tavaline nõue, samuti logiraamat, mis jäädvustab, millal ja kes süsteemi külastas. Mõned lepingud nõuavad lisaks kindlat kontaktisikut teie poolel, et tellimusesaaja ei sõltuks sellest, kes sellal teenistuses on.

Tellimusesaaja alusküsimus on alati sama: kas ta suudab, kui midagi läheb valesti, välja selgitada, kellel oli juurdepääs kus ja millal. See on ka põhjus, miks üldised vastused nagu "järgime parimaid tavameetodeid" harva sobivad — nõutakse konkreetset tõendit, mitte kavatsust.

Kaughaldusvõimalused: täiendav tähelepanu autentimisele ja logimisel

Kaughaldusvõimalused saavad paljudes küsitlustes eraldi peatüki, just seetõttu, et rünnak seal võimaldab pääseda ühe sammuga paljudele klientidele. Küsimused käsitlevad ühenduse krüptimist, seda, kas kaughaldusvõimalustele juurdepääs on eraldatud teie ettevõtte tavalisest võrgust, ja seda, kui kiiresti saate sessiooni sulgemist kutsuda, kui kahtlustate kuritarvitamist. Ka siin kehtib: ei ole tegemist teie turvalisuse hindamisega, vaid sellega, kas te seda näidata saate.

Kes sellist küsimust esimest korda saab, nähes seda sageli ühekordse tegevusena ühe kliendi jaoks. Praktikas on tõendid, mille kogundasite ühe tellimusesaaja jaoks, väikeste kohanduste teel kasutatavad ka järgmise jaoks. teemade vaatamine olukorra järgi annab ülevaate sellest, millised küsimused missuguse teenuste tüübi korral esinevad.

Alamhanked: risk, mida te üksinda kontrolli all ei hoia

Paljude IKT-teenusepakkujate jaoks on kõige raskem osa mitte oma julgeolek, vaid nende osapoolte turvalisus, keda nad kasutavad: majutusteenuse pakkuja, jälgimisteenus, vabakutseline spetsialist. Tellija, kes ise vastutab küberturvalisuse eest, soovib teada, kas te kasutate alamhankijaid, kes need on ja kas nad vastavad võrdsetele nõuetele. Mõned lepingud kohustivad teid eelnevalt teatama muutustest selles ketis või kehtestama samad turvalisuse nõuded lepinguliselt oma enda tarnijatele.

Väikesele IKT-ettevõttele pole see alati lihtne korraldada, eriti kui alamhankija ise ei saa aru, miks see küsimus äkitselt esile tuleb. Esimene samm on lihtne ülevaade: kes teeb teie jaoks mida ja millise kokkuleppega olete selle fikseerinud. Ilma selle ülevaateta on iga uus küsimustik jälle uus uurimisvajadus.

Millele saate ja millele ei saa garantiid anda

On mõistlik lisada lepingusse ainult garantiid, mida saate ka tõendada. Tellija, kes küsib juhtumi korral reageerimisaja, 24/7-teenuse või garantii selle kohta, et midagi kunagi valesti ei läheks, küsib tegelikult lubadust, mida vähesed IKT-teenusepakkujad saavad täita ilma eraldi, kallis teenuse loomiseta. Teie ja vajadusel jurist peab hindama, millised klauslid on mõistlikud ja millised lähevad kaugemale sellest, mida tellija vastutus tegelikult nõuab.

Kas teie enda organisatsioon vastutab otseselt küberturvalisuse eest — olles kriitilise tähtsusega või oluline üksus või läbi toimetamisahela — saab kontrollida mõne küsimusega. See eristus määrab, kas te ainult valmistage ette vastuseid oma klientidele või peate ise ka dokumente pidama.

Alustamine

Tellija jaoks on lõpuks oluline mitte teie kavatsus, vaid see, kas vastus tema küsimusele on valmis, kui ta seda küsib. Kes korra kohta maatriks on fikseerinud staatuse, tõenduse ja vastutava isiku, ei pea järgmise küsimustiku puhul uuesti otsima. Vaadake, mida dossee ja küsimustikud maksavad kui soovite seda ettevalmistamist süstemaatiliselt teostada, või lugege esmalt korduma kippuvaid küsimusi platvormi toimimise kohta.

Alustage siduvuseta tasuta küberturvalisuse kontrollimisega, et näha, kas teie organisatsioon ise vastutab, on toimetamisahelas või ei — ja lugege teadmusbaasist edasi neid teemasid, mis teie sektori jaoks olulised on.

See artikkel on üldine teave ja mitte õiguslik nõu.