Kaip pasirinkti geriausią GRC programinę įrangą

GRC programinė įranga turėtų išplėsti jūsų metodikos taikymą, susieti išvadas su įrodymais ir palikti kontrolę atskaitingiems žmonėms. Geriausias pasirinkimas yra platforma, galinti valdyti jūsų atitikties programą, o ne tik parodyti užpildytą kontrolinį sąrašą.

Artėja auditas, tačiau pasirengimui reikalinga informacija išsibarsčiusi po visą organizaciją. Kontrolės priemonių registras yra skaičiuoklėje. Politikos saugomos SharePoint. Įrodymai guli aplankuose. Trūkumų šalinimo užduotys sekamos Jira. Rizikos sprendimai palaidoti susitikimų užrašuose. Naujausio vertinimo pagrindimas daugiausia egzistuoja atitikties vadovo ar konsultanto galvoje.

Komandos dažnai reaguoja iš naujo surinkdamos praėjusių metų audito paketą, įvesdamos dar vieną griežtą kontrolinį sąrašą arba prašydamos bendrosios paskirties DI įrankio sugeneruoti dokumentaciją iš neišsamaus konteksto. Visi trys būdai gali duoti rezultatą. Nė vienas nebūtinai sukuria patikimą atitikties sistemą.

Todėl pirkimo sprendimas apima daugiau nei kitą auditą. Programinė įranga gali padėti išsaugoti organizacijos žinias, koordinuoti darbą tarp padalinių ir palengvinti vadovybės sprendimų patikrinimą. Ji taip pat gali įvesti dar vieną administracinį sluoksnį, jei kontrolės priemonių savininkai jos vengia, integracijos praleidžia svarbias sistemas arba importuojant įrodymai praranda kontekstą.

Vadovybės požiūriu klausimas nėra, kuris tiekėjas turi patraukliausią informacinę suvestinę. Klausimas yra, kokį veiklos modelį organizacija perka, koks darbas lieka jos žmonėms ir ar gauti įrašai pagrindžia pagrįstus sprendimus.

Produktui įvertinti naudokite septynis klausimus:

1. Ar ji atitinka tai, kaip GRC darbas vyksta iš tikrųjų?
2. Ar ji atspindi jūsų apimtį ir metodiką?
3. Ar ji susieja kontrolės priemones su įgyvendinimu ir įrodymais?
4. Ar galima patikrinti kiekvieną vertinimą ir DI sugeneruotą išvadą?
5. Ar darbą galima saugiai pakartotinai naudoti skirtingose sistemose?
6. Ar ji gali vykdyti pakartojamas darbo eigas nepanaikindama žmogaus atskaitomybės?
7. Ar ji pakankamai saugi ir perkeliama jautriems atitikties duomenims?

Tada šiuos atsakymus patikrinkite pagal diegimo pastangas, ekspertinę pagalbą, ataskaitų poreikius ir bendrąsias nuosavybės sąnaudas.

Prieš lygindami produktus, apibrėžkite, ką perkate

GRC programinė įranga palaiko valdymo įpareigojimus, rizikas, kontrolės priemones, įrodymus, vertinimus, radinius, trūkumų šalinimą ir ataskaitas. Šiame vadove daugiausia dėmesio skiriama kibernetinio saugumo GRC ir informacijos saugumo valdymo sistemos (ISMS) darbui.

Naudingas atskaitos taškas yra ryšys tarp šių įrašų:

Reikalavimas → kontrolės priemonė → įgyvendinimas → įrodymas → vertinimas → radinys → trūkumų šalinimas → sprendimas

Reikalavimas turėtų parodyti, kurios kontrolės priemonės jį įgyvendina. Kontrolės priemonė turėtų apibūdinti savo įgyvendinimą, atsakingą savininką, susijusius išteklius ar procesus ir pagrindžiančius įrodymus. Vertinimas turėtų išsaugoti, kas buvo išnagrinėta, kokie kriterijai taikyti, kokia išvada, koks liko neapibrėžtumas ir kokie veiksmai iš to kyla.

ISO/IEC 27001 susijęs su apibrėžtos apimties ISMS ir organizacijai pritaikytu rizikos valdymu. Todėl programinės įrangos pasirinkimas nėra vien ilgiausio sistemų sąrašo paieška. Tai sistemos, galinčios atspindėti faktinę valdymo sistemą, paieška.

Skirtingos produktų kategorijos pabrėžia skirtingas šio darbo dalis:

Šios kategorijos persidengia. Plati platforma automatiškai nėra geresnis pasirinkimas nei specializuota. Nuspręskite, kuri sistema turės autoritetingą kiekvieno proceso įrašą ir kur dar reikės kito įrankio.

GRC programinė įranga turėtų jungtis su dokumentų valdymo, užduočių sekimo, inventorių, tapatybių teikėjų, debesijos platformų ir saugumo įrankiais. Jai nebūtina jų visų pakeisti. Ji turi išsaugoti kontekstą, siejantį jų informaciją su atitikties sprendimais.

Pagrįskite verslo naudą ir nustatykite veiklos modelį

Prieš demonstracijas parenkite trumpą pirkimo aprašą. Įvardykite vadovybės rėmėją, programos savininką, dalyvaujančias komandas, pradinę apimtį, reikalaujamus įpareigojimus, siekiamus rezultatus ir turimus diegimo pajėgumus.

Rezultatus apibrėžkite konkrečiai. „Pagerinti atitiktį“ sunku įvertinti. „Sumažinti pasikartojančius įrodymų prašymus per du vertinimus, išsaugant savininko patvirtinimą“ suteikia tiekėjams darbo eigą, kurią jie gali pademonstruoti.

Atskirkite neatidėliotinus reikalavimus nuo tikėtinų būsimų poreikių. Įmonė, rengianti savo pirmąją ISMS, gali teikti pirmenybę apimčiai, rizikos tvarkymui, įrodymų peržiūrai ir atsakomybei. Grupei su keliomis dukterinėmis įmonėmis gali prireikti bendrų kontrolės priemonių, vietinių išimčių, ribotos prieigos darbo erdvių ir konsoliduotų ataskaitų. Konsultacinei įmonei reikia pakartotinai naudojamų metodų, nemaišant konfidencialios klientų informacijos.

Darbui taip pat galima skirti išteklių keliais būdais:

Nė vienas kelias nepanaikina vadovybės atsakomybės. Perkant konsultacijas rizikos priėmimas neperkeliamas, o perkant programinę įrangą neįrodoma, kad kontrolės priemonės veikia veiksmingai.

Diegimą dažnai verta svarstyti prieš pradedant naują programą, kai įrodymų prašymai tampa pasikartojantys arba kai plėtra įveda papildomų apimčių ir įpareigojimų. Tačiau artėjantis auditas gali būti netinkamas metas visapusiškai migracijai. Tokiu atveju stabilizuokite esamą įrodymų paketą ir lygiagrečiai išbandykite naująjį veiklos modelį.

1. Ar ji atitinka tai, kaip GRC darbas vyksta iš tikrųjų?

GRC darbas vyksta pokalbiuose, dirbtuvėse, politikų peržiūrose, įgyvendinimo užduotyse, audito pokalbiuose ir vadovybės diskusijose, o ne vien GRC programoje.

Platforma pateisina savo vietą, kai šios veiklos tampa nuoseklia darbo eiga, nereikalaujant, kad komanda viską rankiniu būdu atkurtų kitoje duomenų bazėje. Importuota ekrano nuotrauka tebėra tik failas, nebent ji lieka susieta su sistema, kontrolės priemone, peržiūros laikotarpiu, savininku ir vertinimu, kurį ji pagrindžia.

Įvertinkite integracijų gilumą, aprėptį ir gedimų tvarkymą

Pradėkite nuo savo faktinio technologijų rinkinio. Kiekvienam svarbiam šaltiniui nustatykite reikalingą informaciją ir darbo eigą, kurią ji palaiko.

Tapatybių jungtis gali gauti naudotojus, bet ne privilegijuotas paskyras, autentifikavimo nustatymus ar įrodymus, kad prieigos peržiūra buvo atlikta. Debesijos integracija gali tikrinti pasirinktas paskyras, praleisdama kitą gamybinę aplinką. Užduočių sekimo ryšys gali kurti užduotis, bet negrąžinti jų išsprendimo būsenos.

Paprašykite tiekėjų pademonstruoti:

• Kurias paskyras, sistemas ir išteklių tipus apima jungtis
• Kokių leidimų reikia ir ar pakanka tik skaitymo prieigos
• Rinkimo dažnumą ir peržiūrėtojams rodomą laiko žymą
• Kaip tampa matomi gedimai, atšaukti prisijungimo duomenys ir neišsamus rinkimas
• Ar pirminiai įrašai lieka atpažįstami po importo
• Ką API palaiko be rankinio failų įkėlimo
• Kas prižiūri pritaikytas jungtis, kai keičiasi šaltinių API

Debesijos konfigūracijos, tapatybių, personalo, galinių įrenginių, kūrimo, incidentų ir bendradarbiavimo šaltinius peržiūrėkite pagal savo apimtį. Nemanykite, kad pažįstamas integracijos logotipas įrodo, jog reikiami įrodymai prieinami.

Nepavykęs rinkimas neturėtų palikti seno sėkmingo rezultato, atrodančio aktualiu. Lygiai taip pat sistema, nepatenkanti į integracijų aprėptį, turėtų būti rodoma kaip aprėpties spraga, o ne išnykti iš vardiklio.

Išbandykite retkarčiais besinaudojančių naudotojų patirtį

Paprašykite kontrolės priemonės savininko, kuris neadministruoja platformos, atsakyti į įrodymų prašymą, paaiškinti išimtį ir pateikti trūkumų šalinimo atnaujinimą. Paprašykite peržiūrėtojo atmesti netinkamus įrodymus ir paprašyti patikslinimo.

Užfiksuokite, kokios pagalbos jiems reikia. Jei kiekvienam veiksmui reikia GRC administratoriaus, platforma gali centralizuoti įrašus, tačiau koordinavimo darbas lieka nepakitęs. Patikrinkite pranešimų nukreipimą, įgaliojimų perdavimą nebuvimo metu, prieinamumą ir praktinį naudotojų licencijavimo poveikį dalyvavimui.

2. Ar ji atspindi jūsų apimtį ir metodiką?

GRC nėra vienas visuotinis kontrolinis sąrašas. Tą patį standartą taikančios organizacijos gali turėti skirtingas sistemas, rizikas, atsakomybes, įgyvendinimus ir įrodymų lūkesčius.

Programinė įranga turėtų atspindėti šiuos skirtumus, nepaversdama kiekvieno pakeitimo konsultavimo projektu.

Išnagrinėkite, ar ji gali modeliuoti organizacinius padalinius, paslaugas, programas, infrastruktūrą, informaciją, vietas ir išorinius paslaugų teikėjus. Tada išbandykite ryšius tarp jų. Bendra tapatybių paslauga gali palaikyti kelis produktus; paslaugų teikėjas gali valdyti infrastruktūrą, o jūsų organizacija išlaikyti atsakomybę už konfigūraciją ir prieigą.

Apimties tvarkymas svarbus, nes kontrolės priemonė gali būti veiksminga vienoje aplinkoje ir neišsami kitoje. Teiginys „MFA įgyvendinta“ neturėtų nuslėpti, kad jis apima įmonės paskyras, bet neapima gamybinės aplinkos administravimo kelio.

Verta įvertinti šias naudingas galimybes:

• Pritaikomas kontrolės priemonių bibliotekas ir įgyvendinimo aprašymus
• Taikomumo sprendimus su pagrindimais ir peržiūrų istorija
• Bendras, paveldėtas ir konkrečiai sistemai skirtas kontrolės priemones
• Pagrindinius savininkus, peržiūrėtojus ir bendras atsakomybes
• Skirtingas vertinimo ir rizikos metodikas
• Vietines išimtis be nekontroliuojamo dubliavimo
• Pakartotinai naudojamus šablonus su izoliuota konkretaus kliento informacija

Rizikos valdymą laikykite susietą su verslo sprendimais

Rizikos registras turėtų daryti daugiau nei priskirti spalvas. Pirkėjai turėtų išbandyti, kaip platforma fiksuoja scenarijų, paveiktą paslaugą, poveikį verslui, esamas kontrolės priemones, vertinimo pagrindimą, tvarkymą, liekamąją riziką, tvirtinantį asmenį ir kitą peržiūrą.

Paklauskite, kaip keičiasi balai, kai keičiasi įgyvendinimas ar prielaidos. Automatinis perskaičiavimas gali būti naudingas, tačiau jis neturėtų tyliai pakeisti patvirtinto rizikos sprendimo. Vadovybei reikia atskirti naują techninį signalą nuo peržiūrėto verslo vertinimo.

Išbandykite rizikos priėmimą su galiojimo pabaigos data. Įraše turėtų būti matoma, kas turėjo įgaliojimus ją priimti, kokios sąlygos nustatytos ir kas nutinka, kai tos sąlygos nebeįvykdomos. Pagrindinę darbo eigą rasite straipsnyje apie veiklos rizikos registro tvarkymą.

Konsultacinėms įmonėms apimties testą pakartokite dviejose klientų darbo erdvėse. Pakartotinai naudojamas metodas neturi perkelti vieno kliento įrodymų, komentarų ar konfidencialių prielaidų į kito kliento vertinimą.

3. Ar ji susieja kontrolės priemones su įgyvendinimu ir įrodymais?

Kontrolės priemonė, pažymėta kaip užbaigta, nėra įgyvendinimo ar veiksmingumo įrodymas. Platformai reikia įrodymų sluoksnio, kuris daro daugiau nei saugo priedus.

Kiekvienam įrodymui peržiūrėtojai turėtų galėti nustatyti, ką jis parodo, iš kur jis kilęs, kokią aplinką apima ir ar jis tebėra tinkamas vertinamam laikotarpiui.

Įrodymų kokybė priklauso nuo konteksto. Politika gali parodyti patvirtintą lūkestį; ji pati savaime neįrodo, kad žmonės jos laikėsi. Konfigūracijos eksportas gali parodyti nustatymą; jis gali neįrodyti, kad nustatymas apėmė kiekvieną susijusį išteklių per visą vertinamą laikotarpį.

Praktinė įrodymų peržiūra atskiria kontrolės priemonės projektavimą, įgyvendinimą ir veikimą. Prieigos peržiūros kontrolės priemonei tai galėtų reikšti patvirtintą procedūrą, peržiūrėtą paskyrų visumą, peržiūrėtojų sprendimus ir įrodymą, kad reikalingi pašalinimai buvo atlikti.

Pademonstruokite prieštaringus ir pasenusius įrodymus

Pateikite tiekėjui vieną aktualų dokumentą, vieną pasenusį dokumentą ir vieną įrašą, kuris iš dalies prieštarauja įgyvendinimo aprašymui. Naudokite nuasmenintą arba tinkamai patvirtintą informaciją.

Paprašykite platformos padėti atlikti kontrolės priemonės vertinimą. Ji turėtų išsaugoti atskirus šaltinius ir padaryti neapibrėžtumą matomą, o ne tyliai sujungti juos į užtikrintą teiginį.

Taip pat paklauskite, kas nutinka, kai įrodymai keičiasi. Ar sistema nustato paveiktas kontrolės priemones ir vertinimus? Ar peržiūrėtojas gali išsaugoti ankstesnę išvadą ir kartu pradėti naują peržiūrą? Istorinis pagrįstumas priklauso nuo to, ar išsaugomas pradinio sprendimo pagrindas, o ne vien ar jis pakeičiamas šiandieniniu failu.

4. Ar galima patikrinti kiekvieną vertinimą ir DI rezultatą?

Pagrindimas šaltiniais ir patikra yra susiję, bet skirtingi dalykai. Pagrindimas nurodo medžiagą, kuria remiasi rezultatas. Patikra leidžia peržiūrėtojui išnagrinėti konkrečius šaltinius ir samprotavimus, kuriais jis grindžiamas.

DI atsakymo, apibūdinto kaip „pagrįstas įmonės duomenimis“, nepakanka, jei peržiūrėtojas negali nustatyti, kurie įrašai pagrindžia kiekvieną esminį teiginį. Sklandus tekstas gali nuslėpti trūkstamus įgyvendinimo įrodymus ar klaidingą apimties prielaidą.

Pagrįstame vertinimo įraše turėtų būti matoma:

• Reikalavimas ir vertinimo kriterijus
• Išnagrinėtas įgyvendinimas ir susijusi apimtis
• Nuorodos į įrodymus ir pagrindžiančios ištraukos
• Trūkstama, prieštaringa ar neaiški informacija
• Pasiūlymas, peržiūrėtojo pakeitimai ir patvirtinta išvada
• Peržiūrėtojo tapatybė ir sprendimo data
• Vėlesni pakeitimai, dėl kurių gali prireikti pakartotinio vertinimo

Paprašykite tiekėjo paaiškinti, kodėl kontrolės priemonė įvertinta kaip iš dalies įgyvendinta. Tada paklauskite, kurie įrodymai sustiprina išvadą, kurie ją susilpnina, kas ją patvirtino ir kas galėtų ją pakeisti.

Atskirkite pagalbą nuo įgaliojimų

DI gali išgauti informaciją, siūlyti susiejimus, rengti įgyvendinimo aprašymų juodraščius ar parengti vertinimo pasiūlymą. Šios veiklos turi kitokias pasekmes nei rizikos priėmimo patvirtinimas ar autoritetingo įrašo keitimas.

Nustatykite konkrečioms galimybėms skirtas leidimų ribas. Kuriuos šaltinius agentas gali skaityti? Kuriuos įrašus jis gali keisti? Ar jis gali pasiekti jautrius įrodymus? Kuriems veiksmams reikia žmogaus patvirtinimo? Kaip galima išnagrinėti ir ištaisyti klaidingą veiksmą?

Išbandykite ne tik įprastas, bet ir neleistinas užklausas. Prašymas apibendrinti kito kliento įrodymus neturėtų apeiti darbo erdvės apribojimų. Į įkeltą dokumentą įterptos instrukcijos turėtų būti laikomos dokumento turiniu, o ne leidimu atskleisti informaciją ar keisti įrašus.

Vadovybei pirkimo klausimas yra atskaitomybė: laikas, sutaupytas rengiant juodraščius, neturėtų virsti laiku, prarastu atkuriant, kodėl teiginys buvo patvirtintas. Daugiau vertinimo klausimų rasite straipsnyje apie DI agentų valdymą.

5. Ar darbą galima saugiai pakartotinai naudoti skirtingose sistemose?

Kelių sistemų palaikymas turėtų reikšti daugiau nei sistemų logotipų rodymą. Galimybė yra kontrolės priemonę įgyvendinti vieną kartą ir pakartotinai naudoti tinkamus įrodymus. Pavojus yra skirtingus reikalavimus laikyti lygiaverčiais.

Reagavimo į incidentus procesas gali palaikyti ISMS, klientų įpareigojimus ir reguliavimo pareigas. Šie šaltiniai vis tiek gali skirtis apimtimi, pranešimų gavėjais, terminais, patvirtinimo reikalavimais ir užtikrinimo lūkesčiais.

Patikimuose susiejimuose turėtų būti išsaugota sistemos versija, susiejimo kryptis, ryšio tipas, autorius ar šaltinis, aprėptis, likusios spragos ir peržiūros būsena. Ryšiai gali būti „daug su daug“; persidengimas neįrodo visiško įvykdymo nė viena kryptimi.

NIST OSCAL Control Mapping Model suteikia struktūrizuotą būdą atvaizduoti ryšius tarp kontrolės priemonių ir jų elementų iš skirtingų dokumentinių šaltinių, nedubliuojant jų pradinio turinio.

Paprašykite tiekėjo susieti vieną įgyvendintą procesą su dviem sistemomis ir vienu reguliavimo įpareigojimu. Naudingas rezultatas yra ir pakartotinai naudojamas darbas, ir likęs skirtumas: koks papildomas įgyvendinimas, įrodymai ar sprendimas reikalingi?

Kiekvienam įpareigojimui taikykite skirtingą testą

ISO 27001 programinės įrangos atveju išnagrinėkite apimtį, rizikos vertinimą ir tvarkymą, taikomumo pareiškimą, vidaus auditą, vadovybės peržiūrą ir tobulinimą. Tai skirtingos veiklos. Standarto 4–10 skyriuose pateikiami ISMS reikalavimai; A priede yra 93 kontrolės priemonės, kurių taikomumas grindžiamas rizika. Kontrolės priemonių kontrolinis sąrašas nėra visa ISMS. Sertifikavimą atlieka nepriklausoma sertifikavimo įstaiga, o ne ISO ar programinės įrangos tiekėjas.

NIS2 programinės įrangos atveju prieš vertindami aprėptį nustatykite taikymą pagal atitinkamą nacionalinį įgyvendinamąjį teisės aktą. Direktyvos 20–23 straipsniai reglamentuoja vadovybės priežiūrą, rizikos valdymo priemones ir pranešimą apie reikšmingus incidentus. Vertinkite vadovybės patvirtinimo ir mokymų įrašus, tiekėjų saugumą, veiksmingumo peržiūras ir pranešimo atsakomybes, o ne vien susiejimus su straipsniais.

ES direktyvos lygmeniu pranešimas apima išankstinį įspėjimą per 24 valandas, pranešimą per 72 valandas ir, paprastai, galutinę ataskaitą per vieną mėnesį nuo pranešimo. 24 ir 72 valandų terminai skaičiuojami nuo sužinojimo apie reikšmingą incidentą; abu pranešimai turi būti pateikti nepagrįstai nedelsiant. Nacionalines ir sektorių taisykles reikia patikrinti. Išbandykite darbo eigą, kurioje užfiksuotas sužinojimas apie incidentą, įgaliotas pranešėjas ir jo pavaduotojas, gavėjų duomenys, sprendimai dėl pranešimo ir pateikimo įrodymas. NIS2 nesukuria bendro įmonės ar programinės įrangos sertifikavimo.

SOC 2 ir audito programinės įrangos atveju atskirkite patvirtinimo ataskaitą nuo sertifikavimo. Išbandykite įrodymų laikotarpius, auditoriaus prašymus, imčių palaikymą, radinius ir ribotą išorinę prieigą. Sėkmingas platformos testas nėra auditoriaus išvada.

Gretimiems poreikiams išbandykite faktinę specializuotą darbo eigą. Privatumo darbui gali prireikti duomenų tvarkymo įrašų, sutarčių peržiūrų ir prašymų tvarkymo. DI valdymui gali prireikti naudojimo atvejų inventorių ir vaidmenims būdingų vertinimų; ISO 42001 ir savanoriška NIST AI RMF automatiškai neužtikrina atitikties Dirbtinio intelekto aktui. Finansų sektoriaus poreikiams DORA aiškinkite pagal organizacijos vaidmenį, o ne dubliuokite kiekvieną NIS2 kontrolės priemonę.

6. Ar ji gali vykdyti pakartojamą darbą ir parodyti prasmingus rezultatus?

Pakartojamos darbo eigos paverčia GRC programinę įrangą veiklos infrastruktūra. Jos turėtų apibrėžti įvestis, atsakomybes, žingsnius, peržiūros taškus, rezultatus ir patvirtinimo ribas, kartu išsaugodamos kiekvieno vykdymo istoriją.

Išbandykite visą kontrolės priemonės peržiūrą: surinkite reikšmingą informaciją, nustatykite spragas, parenkite pasiūlymą, nukreipkite jį peržiūrai, užfiksuokite sprendimą ir atnaujinkite susijusį trūkumų šalinimą. Komanda turėtų matyti, ką padarė automatizavimas, ką pakeitė peržiūrėtojas ir kas tapo patvirtinta.

Atskirkite rinkimą, testavimą ir stebėseną

Pakartotinis konfigūracijos duomenų rinkimas nėra tas pats, kas kontrolės priemonės testavimas. Pakartotinis kontrolės priemonės testavimas nėra tas pats, kas saugumo incidentų aptikimas ir reagavimas į juos.

Paklauskite, ką iš tikrųjų vertina kiekvienas automatinis testas, kaip dažnai jis vykdomas, kokių išteklių jis neapima ir kas nutinka, kai jis nepavyksta. Techniniai nustatymai gali leisti dažnas patikras; administracinėms kontrolės priemonėms gali prireikti suplanuotos žmogaus peržiūros. Protingas periodiškumas atitinka riziką ir kontrolės priemonę, o ne visuotinį polinkį į valandinį testavimą.

Trūkumų šalinimui išbandykite atsakomybę, sunkumą, terminus, eskalavimą, išimtis ir užbaigimo patvirtinimą. Užduoties išsprendimas neturėtų automatiškai įrodyti, kad pagrindinė kontrolės priemonė veiksminga. Pakartotinis testas ar peržiūrėtojo sprendimas vis tiek gali būti reikalingi.

Tiekėjų darbo eigoms reikia tokio pat kruopštumo. Ieškokite registro su paslaugų priklausomybėmis, kritiškumu, vertinimo pagrindimu, radiniais, savininkais ir peržiūros datomis. Klausimynų aplankas nėra nuolatinis tiekėjų rizikos procesas.

Įvertinkite ataskaitas trims auditorijoms

Inžinieriams reikia įgyvendinamų gedimų aprašymų ir paskirto darbo. GRC peržiūrėtojams reikia aprėpties, aktualių įrodymų, neišspręstų klausimų ir vertinimo būsenos. Vadovybei reikia reikšmingų rizikų, vėluojančių tvarkymo priemonių, priklausomybių ir sprendimų, kuriems reikia įgaliojimų.

Paprašykite atsekti vadovybei skirtą santrauką iki pagrindinių įrašų. Procentai turėtų atskleisti savo vardiklį ir išimtis. „Visi prijungti testai sėkmingi“ neturi būti pateikiama kaip „visi įpareigojimai įvykdyti“.

Naudingi vadovybės rodikliai: peržiūros laukiantys įrodymai, vėluojantys didelio poveikio veiksmai, pasibaigę rizikos priėmimai, pasikartojantys radiniai ir aprėpties pokyčiai. Ataskaitos turėtų atskirti aktualią informaciją nuo pasenusių ar neįvertintų įrašų. Apie matavimo pasirinkimus už kontrolinių sąrašų užbaigimo ribų skaitykite straipsnyje apie ISMS rodiklius.

7. Ar ji pakankamai saugi ir perkeliama jautriems duomenims?

GRC platforma gali atskleisti architektūrą, žinomus trūkumus, tiekėjų priklausomybes, incidentų procedūras ir vadovybės sprendimus. Prieš įkeldami realius įrodymus, įvertinkite jos saugumą.

Paprašykite įrodymų apie nuomininkų ir klientų izoliaciją, šifravimą perdavimo ir saugojimo metu, prieigos kontrolę, administracinę prieigą, žurnalų registravimą, reagavimą į incidentus, atsargines kopijas ir atkūrimą, saugojimą ir ištrynimą. Kai kalbama apie šifravimą, klauskite apie raktų nuosavybę, gyvavimo ciklą, atkūrimą ir atskyrimą, o ne vien ar šifravimas įjungtas.

Atskirkite įprastą skaitymą, jautrių duomenų skaitymą, rašymą, patvirtinimą ir administravimą. Išbandykite išorinio peržiūrėtojo prieigą ir jos galiojimo pabaigą. Konsultacinėms įmonėms patikrinkite, ar bendra metodika neatskleidžia konkrečių klientų įrašų per paiešką, DI kontekstą, eksportus ar pranešimus.

DI duomenų tvarkymo atveju nustatykite, kurie paslaugų teikėjai ir subtvarkytojai gauna informaciją, kodėl jie ją gauna, koks taikomas saugojimas ir ar klientų informacija naudojama mokymui. Prašykite sutartinio aiškumo, o ne remkitės bendru privatumo pranešimu.

Prieglobos vieta svarbi, tačiau vien ji neįrodo suverenumo ar atitikties BDAR. Atsižvelkite į prieigos tvarką, duomenų tvarkymo vaidmenis, sutartis, subtvarkytojus ir atitinkamus perdavimo vertinimus.

Peržiūrėkite tiekėjo užtikrinimo įrodymų apimtį ir laikotarpį. Sertifikatas ar ataskaita gali neapimti paslaugos, funkcijos ar duomenų tvarkymo tvarkos, kurią ketinate naudoti. Šią peržiūrą paaiškina straipsnis apie saugumo užtikrinimo vertinimą.

Prieš pasirašydami išbandykite pasitraukimą

Paprašykite eksporto pavyzdžio, kuriame būtų kontrolės priemonės, įgyvendinimai, susiejimai, rizikos, nuorodos į įrodymus, vertinimai, sprendimai ir ryšiai. Patikrinkite, ar priedai ir istorija lieka tinkami naudoti už platformos ribų.

NIST OSCAL modeliai palaiko mašininiu būdu skaitomą informaciją apie kontrolės priemones, įgyvendinimą, vertinimą, rezultatus ir trūkumų šalinimą. Struktūrizuotas XML, JSON ar YAML gali pagerinti perkeliamumą, tačiau vien formato pavadinimas neįrodo išsamaus eksporto. Patikrinkite, kurie modeliai, ryšiai ir plėtiniai įtraukti.

Susitarkite dėl eksporto prieinamumo, pagalbos migruojant, prieigos pasibaigus sutarčiai ir ištrynimo procedūrų. Galutiniai PDF failai ir suplokštintos skaičiuoklės gali išsaugoti pateikimą, bet prarasti veiklos modelį.

Palyginkite pagalbą ir bendrąsias nuosavybės sąnaudas

Atskirkite techninę pagalbą, pagalbą diegiant, profesines konsultavimo paslaugas ir nepriklausomą užtikrinimą. Jos sprendžia skirtingas problemas.

Paklauskite, kas atsakys į interpretavimo klausimą, kokią patirtį jie turi, ar tas pats konsultantas liks įtrauktas ir kiek laiko ši paslauga įskaičiuota. Išsiaiškinkite atsakymo įsipareigojimus, laiko juostų aprėptį, eskalavimą audito metu ir tai, kas atlieka darbą, kai diegimas vėluoja.

Jei testavimo ar audito paslaugos įtrauktos į paketą, išnagrinėkite jas atskirai. Pažeidžiamumų skenavimas ir skverbties testas pateikia skirtingus įrodymus. Nei ISO 27001, nei SOC 2 nenustato vieno visuotinio skverbties testo reikalavimo kiekvienai organizacijai; svarbi apimtis, rizika, pasirinktos kontrolės priemonės ir klientų lūkesčiai. Patvirtinkite testavimo apimtį, metodiką, pagalbą šalinant trūkumus ir pakartotinio testavimo sąlygas.

Jei pasiūlomas auditorius ar sertifikavimo įstaiga, įsitikinkite tikru nepriklausomumu, pasirinkimo laisve ir komercine tvarka. Pasirengimas programinėje įrangoje nėra užtikrinimo nuomonė, o užtikrinimas automatiškai netenkina kiekvieno kliento saugumo peržiūros.

Sudarykite sąnaudų modelį, apimantį:

• Prenumeratą, modulius, naudotojų tipus, subjektus ir sistemas
• Diegimą, migraciją ir integracijų priežiūrą
• Vidinį administravimą ir kontrolės priemonių savininkų pastangas
• Konsultavimo paslaugas, testavimą, pakartotinį testavimą ir nepriklausomus auditus
• DI naudojimą, saugyklą, API ribas ir kitus mokesčius už naudojimą
• Atnaujinimą, numatomą augimą ir galimą pasitraukimą

Paprašykite kainų pagal dabartinę apimtį ir realistišką būsimą apimtį. Dokumentuokite, kas sukelia kainų didėjimą ir kurios funkcijos neįtrauktos. Mažesnė prenumerata iš viso gali kainuoti daugiau, jei jai reikia didelio suderinimo ir rankinės peržiūros.

Atlikite reprezentatyvų bandomąjį projektą, o ne bendrą demonstraciją

Kiekvienam atrinktam tiekėjui naudokite tą patį nuasmenintą įrodymų paketą ir priėmimo kriterijus. Įtraukite kontrolės priemonės savininką, peržiūrėtoją, techninį administratorių ir pirkimo suinteresuotąjį asmenį.

Praktinėje vertinimo lentelėje darbo eigos ir metodikos atitikčiai galima skirti 25 %, įrodymams ir patikrai 20 %, saugumui ir perkeliamumui 20 %, integracijų aprėpčiai 15 %, naudojimo patogumui ir ataskaitoms 10 %, o pagalbai ir bendrosioms sąnaudoms 10 %. Šie svoriai yra rekomendacija, o ne visuotinė formulė; susitarkite dėl jų prieš demonstracijas.

Pademonstruotas galimybes vertinkite atskirai nuo konfigūravimo pažadų ir plėtros plano elementų. Saugumo ar izoliacijos gedimas turėtų būti pirkimo barjeras, o ne kažkas, ką gali kompensuoti patraukli informacinė suvestinė.

Pavyzdys: prieigos peržiūra dviejose apimtyse

Iliustracinės prielaidos: 180 darbuotojų programinės įrangos įmonė teikia dvi paslaugas, palaiko ISMS ir gauna pasikartojančius klientų užtikrinimo prašymus. Jos bandomasis projektas apima privilegijuotos prieigos peržiūrą vienoje gamybinėje paslaugoje. Visi įrodymai nuasmeninti.

Pakete yra patvirtinta procedūra, tapatybių eksportas, užbaigtos peržiūros įrašas, pasenęs paskyrų sąrašas ir užduotis, rodanti, kad vienas reikalingas pašalinimas tebėra neatliktas.

Paprašykite kiekvieno tiekėjo nustatyti atitinkamą apimtį ir savininką, susieti įrodymus su įgyvendinimu, atskirti aktualius įrašus nuo pasenusių ir parengti peržiūrimą vertinimą. Neišspręstas pašalinimas turėtų likti matomas. Pakartotinai naudojant šiuos įrodymus kitai sistemai, turi būti išsaugota jų apimtis ir peržiūros laikotarpis.

Toliau įveskite antrą paslaugą, kuri naudoja kitą tapatybių sistemą. Pradiniai sėkmingi įrodymai neturėtų automatiškai įrodyti aprėpties ten. Galiausiai pakeiskite eksportą naujesniu, kuriame yra nepaaiškinta privilegijuota paskyra. Paklauskite, kurias patvirtintas išvadas reikia peržiūrėti ir ar ankstesnį sprendimą vis dar galima atkurti.

Reikalingi bandomojo projekto rezultatai: apibrėžtos apimties kontrolės priemonės įrašas, įrodymų rodyklė, peržiūrėtas vertinimas, paskirtas trūkumų šalinimas, susiejimas su matomomis spragomis, vadovybei skirta santrauka, leidimų testų rezultatai ir tinkamas naudoti eksportas.

Iliustraciniam sąnaudų palyginimui tarkime, kad dabartinis procesas per mėnesį sunaudoja 30 darbuotojų valandų, taikant 60 € už valandą planavimo įkainį su visomis sąnaudomis: 21 600 € per metus. Tarkime, bandomasis projektas rodo, kad po diegimo reikėtų 12 valandų per mėnesį: 8 640 € per metus. Sumodeliuotas pajėgumų skirtumas yra 12 960 €, neįskaičiavus prenumeratos, diegimo ir integracijų sąnaudų. Tai nėra pažadėtas sutaupymas ir nebūtinai atlaisvinti pinigai; tai parodo, kurias prielaidas pirkimo sprendimui reikia patvirtinti.

Padarykite diegimą pirkimo sprendimo dalimi

Prieš pasirašydami paskirkite vidinį savininką ir susitarkite dėl pirmosios diegimo ribos. Venkite importuoti kiekvieną istorinį failą nenusprendę, kas lieka aktualu, autoritetinga ar verta saugoti.

Pradėkite nuo vienos paslaugos ar proceso, įvardytų savininkų ir peržiūrėtojų, reprezentatyvių kontrolės priemonių ir trumpo įrodymų peržiūros ciklo. Priklausomybes ir išorinius paslaugų teikėjus aprašykite anksti. Perkelkite įrašus, reikalingus šiai apimčiai valdyti, išsaugokite reikalaujamą istoriją ir suderinkite importuotą modelį su šaltinio registru.

Naudotojus mokykite pagal vaidmenis: savininkai pateikia ir paaiškina įrodymus, peržiūrėtojai juos vertina, administratoriai prižiūri prieigą ir struktūrą, o vadovai tvirtina sprendimus pagal savo įgaliojimus. Apibrėžkite, kaip bus tvarkomi apimties pokyčiai, pasenę įrodymai, vėluojantys veiksmai ir šaltinių gedimai.

Po pirmojo peržiūros ciklo palyginkite rezultatus su pirkimo aprašu. Matuokite peržiūrėtojų pastangas, įrodymų aktualumą, pasikartojančius prašymus, neišspręstą atsakomybę ir naudojimą už GRC komandos ribų. Plėskite tik tada, kai darbo eiga suprantama ir pakartojama. Produkto atnaujinimams ir sistemų pokyčiams turėtų būti atliekama poveikio peržiūra, o ne leidžiama jiems tyliai keisti patvirtintus įrašus.

Secani sukurta susietam kibernetinio saugumo atitikties darbui. Jos dokumentuota pradinė darbo eiga naudoja tikslingai pasirinktą organizacinį padalinį, procesą, produktą ar valdomą paslaugą. Komandos modeliuoja tikslinius objektus ir priklausomybes, susieja politikas, eksportus ir ekrano nuotraukas su reikalavimais ar kontrolės priemonėmis, kuriuos jie pagrindžia, o trūkstamus įrodymus ar neaiškią atsakomybę paverčia užduotimis. DI pasiūlymai lieka juodraštiniu darbu: peržiūrėtojai patikrina šaltinius, pakoreguoja formuluotes ir patvirtina atsekamus sprendimus. Dokumentacija ir leidimų gairės suteikia pradinį kontekstą. Naudokite viešą plėtros planą kartu su praktine demonstracija, kad suplanuotumėte, kaip jūsų komanda diegs papildomas darbo eigas produktui tobulėjant. Pademonstruotas galimybes vertinkite pagal bandomojo projekto priėmimo kriterijus, o planuojamą darbą fiksuokite atskirai.

Dažniausiai užduodami klausimai

Ar GRC programinė įranga gali padaryti organizaciją atitinkančią reikalavimus?

Ne. Ji gali struktūrizuoti reikalavimus, koordinuoti įgyvendinimą, išsaugoti įrodymus ir padėti atlikti vertinimą. Kontrolės priemones vis tiek valdo žmonės, jie aiškina įpareigojimus, priima rizikas ir peržiūri išvadas. Sprendimai dėl sertifikavimo ar patvirtinimo priklauso atitinkamam nepriklausomam užtikrinimo paslaugų teikėjui.

Ar turėtume pirkti platesnę platformą galimiems būsimiems įpareigojimams?

Įvertinkite patikimus būsimus poreikius, tačiau venkite mokėti už spekuliatyvų platumą. Paklauskite, kaip kita apimtis ar sistema būtų pridėta naudojant jūsų esamą modelį. Pademonstruotas plėtros kelias naudingesnis nei didelis nenaudojamų modulių katalogas.

Ar DI pagrįsta GRC pakeičia konsultantą ar atitikties specialistą?

Ne. Specialiai sukurta sistema gali palaikyti nuolatinį, leidimus paisantį kontekstą ir padaryti ekspertų metodus pakartotinai naudojamus. Ji turėtų sumažinti mechaninį darbą, kartu išsaugodama atsakomybę už dviprasmiškus aiškinimus, apimties sprendimus, tinkamumo vertinimus ir patvirtinimus.

Ką daryti, jei joks produktas neapima viso mūsų technologijų rinkinio?

Aiškiai nustatykite neapimtas sistemas ir susitarkite dėl kontroliuojamo rankinio ar pritaikytos integracijos proceso. Paskirkite atsakomybę, peržiūros dažnumą ir priežiūros sąnaudas. Dalinis automatizavimas yra įgyvendinamas, kai aprėpties riba lieka matoma.

Ką turėtume daryti toliau?

Parenkite vieno puslapio pirkimo aprašą ir vieną reprezentatyvų įrodymų paketą. Paprašykite atrinktų tiekėjų tą paketą nuvesti nuo reikalavimo iki peržiūrėtos išvados, tada pakeiskite svarbų šaltinio įrašą. Vertinkite paveiktą darbą, peržiūrėtojų pastangas, atskaitomybę ir eksportą, o ne vien pradinį rezultatą.