Kā izvēlēties labāko GRC programmatūru

GRC programmatūrai jāpaplašina jūsu metodoloģijas darbības mērogs, jāsasaista secinājumi ar pierādījumiem un jāsaglabā kontrole atbildīgo cilvēku rokās. Labākā izvēle ir platforma, kas spēj darbināt jūsu atbilstības programmu, nevis tikai attēlot aizpildītu kontrolsarakstu.

Tuvojas audits, bet tam nepieciešamā informācija ir izkaisīta pa visu organizāciju. Kontroļu reģistrs ir izklājlapā. Politikas glabājas SharePoint. Pierādījumi atrodas mapēs. Novēršanas uzdevumi tiek izsekoti Jira. Riska lēmumi ir apglabāti sanāksmju piezīmēs. Pēdējā novērtējuma pamatojums galvenokārt pastāv atbilstības vadītāja vai konsultanta galvā.

Komandas bieži reaģē, pārbūvējot pagājušā gada audita paketi, ieviešot vēl vienu stingru kontrolsarakstu vai lūdzot vispārēja lietojuma MI rīkam ģenerēt dokumentāciju no nepilnīga konteksta. Visi trīs ceļi var radīt rezultātu. Neviens no tiem obligāti nerada uzticamu atbilstības sistēmu.

Tāpēc iegādes lēmums sniedzas tālāk par nākamo auditu. Programmatūra var palīdzēt saglabāt institucionālās zināšanas, koordinēt darbu starp nodaļām un padarīt vadības lēmumus vieglāk pārbaudāmus. Tā var arī ieviest vēl vienu administratīvu slāni, ja kontroļu īpašnieki no tās izvairās, integrācijās iztrūkst svarīgu sistēmu vai pierādījumi importa laikā zaudē savu kontekstu.

No vadības skatpunkta jautājums nav par to, kuram piegādātājam ir pievilcīgākais informācijas panelis. Jautājums ir, kādu darbības modeli organizācija iegādājas, kāds darbs paliek tās cilvēkiem un vai iegūtie ieraksti atbalsta pamatojamus lēmumus.

Izmantojiet septiņus jautājumus, lai novērtētu produktu:

1. Vai tas atbilst tam, kā GRC darbs patiesībā notiek?
2. Vai tas atspoguļo jūsu tvērumu un metodoloģiju?
3. Vai tas sasaista kontroles ar ieviešanu un pierādījumiem?
4. Vai katru novērtējumu un MI ģenerētu secinājumu var pārbaudīt?
5. Vai darbu var droši atkārtoti izmantot dažādos ietvaros?
6. Vai tas var darbināt atkārtojamas darbplūsmas, nenoņemot cilvēka atbildību?
7. Vai tas ir pietiekami drošs un pārnesams sensitīviem atbilstības datiem?

Pēc tam pārbaudiet šīs atbildes, ņemot vērā ieviešanas piepūli, ekspertu atbalstu, pārskatu vajadzības un kopējās īpašumtiesību izmaksas.

Definējiet, ko iegādājaties, pirms salīdzināt produktus

GRC programmatūra atbalsta pārvaldības pienākumus, riskus, kontroles, pierādījumus, novērtējumus, konstatējumus, novēršanu un pārskatu sniegšanu. Šajā ceļvedī galvenā uzmanība pievērsta kiberdrošības GRC un informācijas drošības pārvaldības sistēmas jeb ISMS darbam.

Noderīgs atskaites punkts ir šo ierakstu savstarpējā saistība:

Prasība → kontrole → ieviešana → pierādījums → novērtējums → konstatējums → novēršana → lēmums

Prasībai jāparāda, kuras kontroles to risina. Kontrolei jāapraksta tās ieviešana, atbildīgais īpašnieks, attiecīgie aktīvi vai procesi un pamatojošie pierādījumi. Novērtējumam jāsaglabā, kas tika pārbaudīts, kādi kritēriji piemēroti, secinājums, atlikusī nenoteiktība un izrietošās darbības.

ISO/IEC 27001 attiecas uz noteikta tvēruma ISMS ar organizācijai pielāgotu riska pārvaldību. Tāpēc programmatūras izvēle nav vienkārši garākā ietvaru saraksta meklējumi. Tie ir tādas sistēmas meklējumi, kas spēj atspoguļot faktisko pārvaldības sistēmu.

Dažādas produktu kategorijas uzsver dažādas šī darba daļas:

Šīs kategorijas pārklājas. Plaša platforma nav automātiski labāka izvēle par specializētu. Izlemiet, kura sistēma glabās autoritatīvo ierakstu katram procesam un kur joprojām būs nepieciešams cits rīks.

GRC programmatūrai jāsavienojas ar dokumentu pārvaldību, pieteikumu sistēmām, reģistriem, identitātes nodrošinātājiem, mākoņplatformām un drošības rīkiem. Tai nav jāaizstāj tie visi. Tai jāsaglabā konteksts, kas savieno to informāciju ar atbilstības lēmumiem.

Nosakiet biznesa pamatojumu un darbības modeli

Pirms demonstrācijām sagatavojiet īsu iegādes kopsavilkumu. Norādiet izpildvadības sponsoru, programmas īpašnieku, iesaistītās komandas, sākotnējo tvērumu, nepieciešamos pienākumus, vēlamos rezultātus un pieejamo ieviešanas kapacitāti.

Formulējiet rezultātus konkrēti. „Uzlabot atbilstību” ir grūti novērtēt. „Samazināt atkārtotus pierādījumu pieprasījumus divos novērtējumos, saglabājot īpašnieka apstiprinājumu” dod piegādātājiem darbplūsmu, ko demonstrēt.

Nodaliet tūlītējās prasības no iespējamām nākotnes vajadzībām. Uzņēmums, kas gatavo savu pirmo ISMS, var piešķirt prioritāti tvērumam, riska apstrādei, pierādījumu pārskatīšanai un īpašumtiesībām. Grupai ar vairākiem meitasuzņēmumiem var būt vajadzīgas kopīgas kontroles, vietēji izņēmumi, ierobežotas darbvietas un konsolidēti pārskati. Konsultāciju uzņēmumam vajadzīgas atkārtoti izmantojamas metodes, nesajaucot klientu konfidenciālo informāciju.

Ir arī vairāki veidi, kā nodrošināt darbam resursus:

Neviens ceļš nenoņem vadības atbildību. Konsultāciju iegāde nenodod riska pieņemšanu, un programmatūras iegāde nepierāda, ka kontroles darbojas efektīvi.

Ieviešanu bieži vērts apsvērt pirms jaunas programmas uzsākšanas, kad pierādījumu pieprasījumi kļūst atkārtoti vai kad paplašināšanās ievieš papildu tvērumus un pienākumus. Tomēr nenovēršami tuvs audits var būt slikts brīdis pilnīgai migrācijai. Šādā situācijā stabilizējiet esošo pierādījumu paketi un paralēli izmēģiniet jauno darbības modeli.

1. Vai tas atbilst tam, kā GRC darbs patiesībā notiek?

GRC darbs notiek intervijās, darbnīcās, politiku pārskatīšanā, ieviešanas uzdevumos, audita sarunās un vadības diskusijās, nevis tikai GRC lietotnē.

Platforma attaisno savu vietu, kad šīs darbības kļūst par saskaņotu darbplūsmu, neprasot komandai visu manuāli atjaunot citā datubāzē. Importēts ekrānuzņēmums joprojām ir tikai fails, ja vien tas nepaliek saistīts ar sistēmu, kontroli, pārskatīšanas periodu, īpašnieku un novērtējumu, ko tas atbalsta.

Novērtējiet integrācijas dziļumu, pārklājumu un kļūmju apstrādi

Sāciet ar savu faktisko tehnoloģiju steku. Katram svarīgam avotam nosakiet nepieciešamo informāciju un darbplūsmu, ko tas atbalsta.

Identitātes savienotājs var iegūt lietotājus, bet ne priviliģētos kontus, autentifikācijas iestatījumus vai pierādījumus, ka piekļuves pārskatīšana ir pabeigta. Mākoņa integrācija var pārbaudīt atlasītus kontus, bet palaist garām vēl vienu ražošanas vidi. Pieteikumu sistēmas savienojums var izveidot uzdevumus, neatgriežot to atrisināšanas statusu.

Lūdziet piegādātājiem demonstrēt:

• Kurus kontus, sistēmas un aktīvu tipus savienotājs aptver
• Nepieciešamās atļaujas un vai pietiek ar tikai lasīšanas piekļuvi
• Vākšanas biežumu un pārskatītājiem rādīto laika zīmogu
• Kā kļūst redzamas kļūmes, atsaukti akreditācijas dati un nepilnīga vākšana
• Vai avota ieraksti pēc importa paliek identificējami
• Ko API atbalsta papildus manuālai failu augšupielādei
• Kas uztur pielāgotos savienotājus, kad mainās avotu API

Pārskatiet mākoņa konfigurācijas, identitātes, personāla, galiekārtu, izstrādes, incidentu un sadarbības avotus atbilstoši savam tvērumam. Nepieņemiet, ka pazīstams integrācijas logotips pierāda, ka nepieciešamie pierādījumi ir pieejami.

Neizdevusies vākšana nedrīkst atstāt vecu sekmīgu rezultātu tā, it kā tas būtu aktuāls. Tāpat sistēmai ārpus integrācijas pārklājuma jāparādās kā pārklājuma robam, nevis jāpazūd no saucēja.

Pārbaudiet neregulāru lietotāju pieredzi

Lūdziet kontroles īpašniekam, kurš neadministrē platformu, atbildēt uz pierādījumu pieprasījumu, paskaidrot izņēmumu un iesniegt novēršanas atjauninājumu. Lūdziet pārskatītājam noraidīt nepiemērotu pierādījumu un pieprasīt precizējumu.

Pierakstiet, kāda palīdzība viņiem nepieciešama. Ja katrai darbībai vajadzīgs GRC administrators, platforma var centralizēt ierakstus, atstājot koordinācijas darbu nemainīgu. Pārbaudiet paziņojumu maršrutēšanu, deleģēšanu prombūtnes laikā, piekļūstamību un lietotāju licencēšanas praktisko ietekmi uz līdzdalību.

2. Vai tas atspoguļo jūsu tvērumu un metodoloģiju?

GRC nav viens universāls kontrolsaraksts. Organizācijām, kas izmanto vienu un to pašu standartu, var būt atšķirīgas sistēmas, riski, pienākumi, ieviešanas un pierādījumu gaidas.

Programmatūrai jāatspoguļo šīs atšķirības, nepārvēršot katras izmaiņas konsultāciju projektā.

Pārbaudiet, vai tā var modelēt organizatoriskās vienības, pakalpojumus, lietotnes, infrastruktūru, informāciju, atrašanās vietas un ārējos pakalpojumu sniedzējus. Pēc tam pārbaudiet to savstarpējās attiecības. Kopīgs identitātes pakalpojums var atbalstīt vairākus produktus; pakalpojumu sniedzējs var darbināt infrastruktūru, kamēr jūsu organizācija saglabā atbildību par konfigurāciju un piekļuvi.

Tvēruma apstrāde ir svarīga, jo kontrole var būt efektīva vienā vidē un nepilnīga citā. „MFA ieviesta” nedrīkst slēpt, ka apgalvojums aptver uzņēmuma kontus, bet izslēdz ražošanas administrēšanas ceļu.

Noderīgas novērtējamās iespējas ir:

• Pielāgotas kontroļu bibliotēkas un ieviešanas apraksti
• Piemērojamības lēmumi ar pamatojumiem un pārskatīšanas vēsturi
• Kopīgas, mantotas un sistēmai specifiskas kontroles
• Galvenie īpašnieki, pārskatītāji un dalīta atbildība
• Dažādas novērtēšanas un riska metodoloģijas
• Vietēji izņēmumi bez nekontrolētas dublēšanās
• Atkārtoti izmantojamas veidnes ar izolētu klientam specifisku informāciju

Saglabājiet riska pārvaldību saistītu ar biznesa lēmumiem

Riska reģistram jādara vairāk nekā jāpiešķir krāsas. Pircējiem jāpārbauda, kā platforma reģistrē scenāriju, ietekmēto pakalpojumu, ietekmi uz biznesu, esošās kontroles, vērtējuma pamatojumu, apstrādi, atlikušo risku, apstiprinošo iestādi un nākamo pārskatīšanu.

Pajautājiet, kā mainās vērtējumi, kad mainās ieviešana vai pieņēmumi. Automātiska pārrēķināšana var būt noderīga, taču tai nevajadzētu klusi aizstāt apstiprinātu riska lēmumu. Vadībai jāspēj atšķirt jaunu tehnisku signālu no pārskatīta biznesa sprieduma.

Pārbaudiet riska pieņemšanu ar derīguma termiņu. Ierakstam jāparāda, kam bija pilnvaras to pieņemt, kādi nosacījumi tai piesaistīti un kas notiek, kad šie nosacījumi vairs netiek izpildīti. Pamatā esošo darbplūsmu skatiet rakstā par to, kā uzturēt operacionālo risku reģistru.

Konsultāciju uzņēmumiem atkārtojiet tvēruma testu divās klientu darbvietās. Atkārtoti izmantojama metode nedrīkst pārnest viena klienta pierādījumus, komentārus vai konfidenciālus pieņēmumus cita klienta novērtējumā.

3. Vai tas sasaista kontroles ar ieviešanu un pierādījumiem?

Kontrole, kas atzīmēta kā pabeigta, nav ieviešanas vai efektivitātes pierādījums. Platformai nepieciešams pierādījumu slānis, kas dara vairāk nekā glabā pielikumus.

Katram pierādījumam pārskatītājiem jāspēj noskaidrot, ko tas pierāda, no kurienes tas nāk, kuru vidi tas aptver un vai tas joprojām ir piemērots novērtējuma periodam.

Pierādījumu kvalitāte ir atkarīga no konteksta. Politika var pierādīt apstiprinātas gaidas; tā pati par sevi nepierāda, ka cilvēki tām sekoja. Konfigurācijas eksports var pierādīt iestatījumu; tas var nepierādīt, ka iestatījums aptvēra katru attiecīgo aktīvu visā novērtējuma periodā.

Praktiska pierādījumu pārskatīšana nošķir kontroles izstrādi, ieviešanu un darbību. Piekļuves pārskatīšanas kontrolei tas var nozīmēt apstiprinātu procedūru, pārskatīto kontu kopu, pārskatītāju lēmumus un pierādījumu, ka nepieciešamās dzēšanas ir pabeigtas.

Demonstrējiet pretrunīgus un novecojušus pierādījumus

Iedodiet piegādātājam vienu aktuālu dokumentu, vienu novecojušu dokumentu un vienu ierakstu, kas daļēji ir pretrunā ar ieviešanas aprakstu. Izmantojiet anonimizētu vai atbilstoši apstiprinātu informāciju.

Lūdziet platformai atbalstīt kontroles novērtējumu. Tai jāsaglabā atsevišķie avoti un jāpadara nenoteiktība redzama, nevis klusi jāapvieno tie pārliecinošā apgalvojumā.

Pajautājiet arī, kas notiek, kad pierādījumi mainās. Vai sistēma identificē ietekmētās kontroles un novērtējumus? Vai pārskatītājs var saglabāt agrāku secinājumu, vienlaikus uzsākot jaunu pārskatīšanu? Vēsturiskā pamatojamība ir atkarīga no sākotnējā lēmuma pamata saglabāšanas, nevis tikai no tā aizstāšanas ar šodienas failu.

4. Vai katru novērtējumu un MI rezultātu var pārbaudīt?

Pamatošana un pārbaude ir saistītas, bet atšķirīgas. Pamatošana identificē materiālu, kas informē rezultātu. Pārbaude ļauj pārskatītājam izpētīt konkrētos avotus un tam pamatā esošo argumentāciju.

MI atbilde, kas raksturota kā „balstīta uz uzņēmuma datiem”, nav pietiekama, ja pārskatītājs nevar noskaidrot, kuri ieraksti atbalsta katru būtisko apgalvojumu. Plūstošs teksts var slēpt trūkstošus ieviešanas pierādījumus vai nepareizu pieņēmumu par tvērumu.

Pamatojamam novērtējuma ierakstam jāparāda:

• Prasība un novērtēšanas kritērijs
• Pārbaudītā ieviešana un attiecīgais tvērums
• Atsauces uz pierādījumiem un pamatojoši fragmenti
• Trūkstoša, pretrunīga vai nenoteikta informācija
• Priekšlikums, pārskatītāja izmaiņas un apstiprinātais secinājums
• Pārskatītāja identitāte un lēmuma datums
• Turpmākās izmaiņas, kurām var būt nepieciešams atkārtots novērtējums

Lūdziet piegādātājam paskaidrot, kāpēc kontrole novērtēta kā daļēji ieviesta. Pēc tam pajautājiet, kuri pierādījumi stiprina secinājumu, kuri to vājina, kas to apstiprināja un kas liktu tam mainīties.

Nodaliet palīdzību no pilnvarām

MI var izvilkt informāciju, ieteikt kartējumus, sagatavot ieviešanas apgalvojumu melnrakstus vai sagatavot novērtējuma priekšlikumu. Šīm darbībām ir citas sekas nekā riska pieņemšanas apstiprināšanai vai autoritatīva ieraksta mainīšanai.

Nosakiet atļauju robežas atbilstoši katrai spējai. Kurus avotus aģents var lasīt? Kurus ierakstus tas var mainīt? Vai tas var piekļūt sensitīviem pierādījumiem? Kurām darbībām nepieciešams cilvēka apstiprinājums? Kā kļūdainu darbību var izpētīt un labot?

Pārbaudiet gan neatļautus, gan parastus pieprasījumus. Uzvedne apkopot cita klienta pierādījumus nedrīkst apiet darbvietas ierobežojumus. Augšupielādētā dokumentā iegultas instrukcijas jāuztver kā dokumenta saturs, nevis kā atļauja izpaust informāciju vai mainīt ierakstus.

Vadībai iegādes jautājums ir atbildība: melnrakstu sagatavošanā ietaupītais laiks nedrīkst kļūt par laiku, kas zaudēts, rekonstruējot, kāpēc apgalvojums tika apstiprināts. Papildu novērtēšanas jautājumi aplūkoti rakstā par MI aģentu pārvaldību.

5. Vai darbu var droši atkārtoti izmantot dažādos ietvaros?

Vairāku ietvaru atbalstam jānozīmē vairāk nekā ietvaru logotipu attēlošana. Iespēja ir ieviest kontroli vienreiz un atkārtoti izmantot piemērotus pierādījumus. Briesmas ir atšķirīgas prasības uzskatīt par līdzvērtīgām.

Incidentu reaģēšanas process var atbalstīt ISMS, klientu saistības un regulatīvos pienākumus. Šie avoti tomēr var atšķirties pēc tvēruma, ziņojumu saņēmējiem, termiņiem, apstiprināšanas prasībām un pārliecības gaidām.

Uzticamiem kartējumiem jāsaglabā ietvara versija, kartējuma virziens, attiecības tips, autors vai avots, pārklājums, atlikušie robi un pārskatīšanas statuss. Attiecības var būt „daudzi pret daudziem”; pārklāšanās nepierāda pilnīgu izpildi nevienā virzienā.

NIST OSCAL Control Mapping Model nodrošina strukturētu veidu, kā attēlot attiecības starp kontrolēm un kontroļu elementiem no dažādiem dokumentāriem avotiem, nedublējot to sākotnējo saturu.

Lūdziet piegādātājam kartēt vienu ieviestu procesu pret diviem ietvariem un vienu regulatīvu pienākumu. Noderīgais rezultāts ir gan atkārtoti izmantojams darbs, gan atlikusī starpība: kāda papildu ieviešana, pierādījumi vai lēmums ir nepieciešami?

Katram pienākumam piemērojiet atšķirīgu testu

ISO 27001 programmatūrai pārbaudiet tvērumu, riska novērtēšanu un apstrādi, Piemērojamības paziņojumu, iekšējo auditu, vadības pārskatu un uzlabošanu. Tās ir atšķirīgas darbības. Standarta 4.–10. punktā ietvertas ISMS prasības; A pielikumā ir 93 kontroles, kuru piemērojamība balstās uz risku. Kontroļu kontrolsaraksts nav viss ISMS. Sertifikāciju veic neatkarīga sertifikācijas iestāde, nevis ISO vai programmatūras piegādātājs.

NIS2 programmatūrai pirms pārklājuma novērtēšanas nosakiet piemērojamību saskaņā ar attiecīgo valsts transpozīcijas likumu. Direktīvas 20.–23. pants attiecas uz vadības pārraudzību, kiberdrošības riska pārvaldības pasākumiem un ziņošanu par būtiskiem incidentiem. Novērtējiet vadības apstiprinājuma un apmācības ierakstus, piegādātāju drošību, efektivitātes pārskatus un ziņošanas pienākumus, nevis tikai pantu kartējumus.

ES direktīvas līmenī ziņošana ietver agrīno brīdinājumu 24 stundu laikā, paziņojumu 72 stundu laikā un parasti galīgo ziņojumu viena mēneša laikā pēc paziņojuma. 24 un 72 stundu termiņi tiek skaitīti no brīža, kad kļūst zināms par būtisku incidentu; abi iesniegumi jāveic bez nepamatotas kavēšanās. Jāpārbauda valsts un nozaru noteikumi. Pārbaudiet darbplūsmu, kurā reģistrēts brīdis, kad par incidentu kļuva zināms, pilnvarotais ziņotājs un aizvietotājs, saņēmēja informācija, ziņošanas lēmumi un iesniegšanas pierādījums. NIS2 neparedz vispārēju uzņēmuma vai programmatūras sertifikāciju.

SOC 2 un auditu programmatūrai nošķiriet apliecinājuma ziņojumu no sertifikācijas. Pārbaudiet pierādījumu periodus, auditoru pieprasījumus, izlases atbalstu, konstatējumus un ierobežotu ārējo piekļuvi. Sekmīgs platformas tests nav auditora secinājums.

Saistītām vajadzībām pārbaudiet faktisko speciālistu darbplūsmu. Privātuma darbam var būt nepieciešami apstrādes darbību reģistri, līgumu pārskatīšana un pieprasījumu apstrāde. MI pārvaldībai var būt nepieciešami lietošanas gadījumu reģistri un lomām specifiski novērtējumi; ISO 42001 un brīvprātīgais NIST AI RMF automātiski nenodrošina atbilstību MI aktam. Finanšu nozares vajadzībām interpretējiet DORA atbilstoši organizācijas lomai, nevis dublējiet katru NIS2 kontroli.

6. Vai tas var darbināt atkārtojamu darbu un parādīt jēgpilnus rezultātus?

Atkārtojamas darbplūsmas pārvērš GRC programmatūru par darbības infrastruktūru. Tām jādefinē ievaddati, atbildība, soļi, pārskatīšanas punkti, rezultāti un apstiprināšanas robežas, saglabājot katras izpildes vēsturi.

Pārbaudiet pilnu kontroles pārskatīšanu: savāciet attiecīgo informāciju, identificējiet robus, sagatavojiet priekšlikumu, nosūtiet to pārskatīšanai, reģistrējiet lēmumu un atjauniniet saistīto novēršanu. Komandai jāredz, ko izdarīja automatizācija, ko mainīja pārskatītājs un kas tika apstiprināts.

Nošķiriet vākšanu, testēšanu un uzraudzību

Atkārtota konfigurācijas datu vākšana nav tas pats, kas kontroles testēšana. Atkārtota kontroles testēšana nav tas pats, kas drošības incidentu atklāšana un reaģēšana uz tiem.

Pajautājiet, ko katrs automatizētais tests patiesībā novērtē, cik bieži tas tiek palaists, kurus aktīvus tas izslēdz un kas notiek, kad tas neizdodas. Tehniskie iestatījumi var ļaut veikt biežas pārbaudes; administratīvām kontrolēm var būt nepieciešama plānota cilvēka pārskatīšana. Saprātīgs ritms seko riskam un kontrolei, nevis universālai priekšrocībai testēt katru stundu.

Novēršanai pārbaudiet īpašumtiesības, smagumu, izpildes termiņus, eskalāciju, izņēmumus un slēgšanas validāciju. Pieteikuma atrisināšana nedrīkst automātiski apliecināt, ka pamatā esošā kontrole ir efektīva. Joprojām var būt nepieciešams atkārtots tests vai pārskatītāja lēmums.

Piegādātāju darbplūsmām pienākas tāda pati rūpīga pārbaude. Meklējiet reģistru ar pakalpojumu atkarībām, kritiskumu, novērtējuma pamatojumu, konstatējumiem, īpašniekiem un pārskatīšanas datumiem. Anketu mape nav nepārtraukts piegādātāju riska process.

Novērtējiet pārskatus trim auditorijām

Inženieriem vajadzīgas kļūmes, uz kurām var rīkoties, un piešķirts darbs. GRC pārskatītājiem vajadzīgs pārklājums, aktuāli pierādījumi, neatrisināti jautājumi un novērtējuma statuss. Vadībai vajadzīgi būtiski riski, nokavēta apstrāde, atkarības un lēmumi, kuriem nepieciešamas pilnvaras.

Lūdziet izsekot vadības kopsavilkumu atpakaļ līdz pamatā esošajiem ierakstiem. Procentiem jāatklāj to saucējs un izņēmumi. „Visi pievienotie testi sekmīgi” nedrīkst pasniegt kā „visi pienākumi izpildīti”.

Noderīgi vadības rādītāji ir pierādījumi, kas gaida pārskatīšanu, nokavētas augstas ietekmes darbības, beigušās riska pieņemšanas, atkārtoti konstatējumi un pārklājuma izmaiņas. Pārskatiem jānošķir aktuāla informācija no novecojušiem vai nenovērtētiem ierakstiem. Mērījumu izvēles ārpus kontrolsaraksta izpildes skatiet rakstā par ISMS rādītājiem.

7. Vai tas ir pietiekami drošs un pārnesams sensitīviem datiem?

GRC platforma var atklāt arhitektūru, zināmas nepilnības, piegādātāju atkarības, incidentu procedūras un vadības lēmumus. Novērtējiet tās drošību, pirms augšupielādējat reālus pierādījumus.

Pieprasiet pierādījumus par nomnieku un klientu izolāciju, šifrēšanu pārsūtīšanas laikā un glabāšanā, piekļuves kontrolēm, administratīvo piekļuvi, žurnālēšanu, incidentu reaģēšanu, rezerves kopēšanu un atjaunošanu, glabāšanu un dzēšanu. Kur tiek apspriesta šifrēšana, jautājiet par atslēgu īpašumtiesībām, dzīves ciklu, atgūšanu un nodalīšanu, nevis tikai par to, vai šifrēšana ir ieslēgta.

Nodaliet parastu lasīšanu, sensitīvu lasīšanu, rakstīšanu, apstiprināšanu un administrēšanu. Pārbaudiet ārējo pārskatītāju piekļuvi un tās beigu termiņu. Konsultāciju uzņēmumiem pārbaudiet, vai kopīgā metodoloģija neatklāj klientam specifiskus ierakstus caur meklēšanu, MI kontekstu, eksportiem vai paziņojumiem.

MI apstrādei noskaidrojiet, kuri pakalpojumu sniedzēji un apakšapstrādātāji saņem informāciju, kāpēc viņi to saņem, kāda ir piemērojamā glabāšana un vai klientu informācija tiek izmantota apmācībai. Pieprasiet līgumisku skaidrību, nevis paļaujieties uz vispārīgu privātuma paziņojumu.

Mitināšanas vieta ir svarīga, taču tā viena pati nepierāda suverenitāti vai atbilstību VDAR. Apsveriet piekļuves kārtību, apstrādes lomas, līgumus, apakšapstrādātājus un attiecīgos pārsūtīšanas novērtējumus.

Pārskatiet piegādātāja pārliecības pierādījumu tvērumu un periodu. Sertifikāts vai ziņojums var izslēgt pakalpojumu, funkciju vai apstrādes kārtību, ko plānojat izmantot. Rakstā par to, kā novērtēt drošības pārliecību, šī pārskatīšana ir izskaidrota.

Pārbaudiet izstāšanos pirms parakstīšanas

Pieprasiet eksporta paraugu, kas satur kontroles, ieviešanas, kartējumus, riskus, atsauces uz pierādījumiem, novērtējumus, lēmumus un attiecības. Pārbaudiet, vai pielikumi un vēsture paliek izmantojami ārpus platformas.

NIST OSCAL modeļi atbalsta mašīnlasāmu informāciju par kontrolēm, ieviešanu, novērtēšanu, rezultātiem un novēršanu. Strukturēts XML, JSON vai YAML var uzlabot pārnesamību, taču formāta nosaukums vien nepierāda pilnīgu eksportu. Pārbaudiet, kuri modeļi, attiecības un paplašinājumi ir iekļauti.

Vienojieties par eksporta pieejamību, migrācijas palīdzību, piekļuvi pēc līguma izbeigšanas un dzēšanas procedūrām. Galīgie PDF faili un saplacinātas izklājlapas var saglabāt noformējumu, zaudējot darbības modeli.

Salīdziniet atbalstu un kopējās īpašumtiesību izmaksas

Nodaliet tehnisko atbalstu, ieviešanas palīdzību, profesionālus konsultatīvos pakalpojumus un neatkarīgu pārliecību. Tie risina dažādas problēmas.

Pajautājiet, kas atbildēs uz interpretācijas jautājumu, kāda viņiem ir pieredze, vai tas pats konsultants paliek iesaistīts un cik ilgi šis pakalpojums ir iekļauts. Precizējiet reaģēšanas saistības, laika joslu pārklājumu, eskalāciju audita laikā un to, kas veic darbu, kad ieviešana atpaliek.

Ja testēšanas vai audita pakalpojumi ir iekļauti komplektā, izvērtējiet tos atsevišķi. Ievainojamību skenēšana un ielaušanās tests sniedz atšķirīgus pierādījumus. Ne ISO 27001, ne SOC 2 neuzliek katrai organizācijai vienu universālu ielaušanās testa prasību; nozīme ir tvērumam, riskam, izvēlētajām kontrolēm un klientu gaidām. Apstipriniet testēšanas tvērumu, metodoloģiju, novēršanas atbalstu un atkārtotas testēšanas noteikumus.

Ja tiek piedāvāts auditors vai sertifikācijas iestāde, pārliecinieties par patiesu neatkarību, izvēles brīvību un komerciālajiem nosacījumiem. Programmatūras gatavība nav pārliecības atzinums, un pārliecība automātiski neapmierina katra klienta drošības pārskatīšanu.

Izveidojiet izmaksu modeli, kas aptver:

• Abonementu, moduļus, lietotāju tipus, juridiskās personas un ietvarus
• Ieviešanu, migrāciju un integrāciju uzturēšanu
• Iekšējo administrēšanu un kontroļu īpašnieku piepūli
• Konsultatīvos pakalpojumus, testēšanu, atkārtotu testēšanu un neatkarīgus auditus
• MI lietojumu, krātuvi, API ierobežojumus un citas patēriņa maksas
• Atjaunošanu, paredzamo izaugsmi un iespējamo izstāšanos

Pieprasiet cenas šodienas tvērumam un reālistiskam nākotnes tvērumam. Dokumentējiet, kas izraisa cenu pieaugumu un kuras funkcijas nav iekļautas. Lētāks abonements kopumā var izrādīties dārgāks, ja tas prasa ievērojamu saskaņošanu un manuālu pārskatīšanu.

Veiciet reprezentatīvu izmēģinājumu, nevis vispārīgu demonstrāciju

Katram atlasītajam piegādātājam izmantojiet vienu un to pašu anonimizēto pierādījumu paketi un pieņemšanas kritērijus. Iesaistiet kontroles īpašnieku, pārskatītāju, tehnisko administratoru un iepirkuma ieinteresēto pusi.

Praktiskā vērtēšanas kartē darbplūsmas un metodoloģijas atbilstībai var piešķirt 25 %, pierādījumiem un pārbaudei 20 %, drošībai un pārnesamībai 20 %, integrāciju pārklājumam 15 %, lietojamībai un pārskatiem 10 % un atbalstam un kopējām izmaksām 10 %. Šie svari ir ieteikums, nevis universāla formula; vienojieties par tiem pirms demonstrācijām.

Demonstrētās spējas vērtējiet atsevišķi no konfigurācijas solījumiem un ceļveža punktiem. Drošības vai izolācijas kļūmei jābūt iegādes barjerai, nevis kaut kam, ko var kompensēt pievilcīgs informācijas panelis.

Praktisks piemērs: piekļuves pārskatīšana divos tvērumos

Ilustratīvi pieņēmumi: programmatūras uzņēmums ar 180 darbiniekiem darbina divus pakalpojumus, uztur ISMS un saņem regulārus klientu pārliecības pieprasījumus. Tā izmēģinājums aptver priviliģētās piekļuves pārskatīšanu vienā ražošanas pakalpojumā. Visi pierādījumi ir anonimizēti.

Pakete satur apstiprinātu procedūru, identitātes eksportu, pabeigtas pārskatīšanas ierakstu, novecojušu kontu sarakstu un pieteikumu, kas rāda, ka viena nepieciešamā dzēšana joprojām ir atvērta.

Lūdziet katram piegādātājam identificēt attiecīgo tvērumu un īpašnieku, sasaistīt pierādījumus ar ieviešanu, nošķirt aktuālus ierakstus no novecojušiem un sagatavot pārskatāmu novērtējumu. Neatrisinātajai dzēšanai jāpaliek redzamai. Šo pierādījumu atkārtotai izmantošanai citā ietvarā jāsaglabā to tvērums un pārskatīšanas periods.

Pēc tam ieviesiet otru pakalpojumu, kas izmanto citu identitātes sistēmu. Sākotnējie sekmīgie pierādījumi nedrīkst automātiski apliecināt pārklājumu tur. Visbeidzot aizstājiet eksportu ar jaunāku, kurā ir neizskaidrots priviliģēts konts. Pajautājiet, kuri apstiprinātie secinājumi jāpārskata un vai agrāko lēmumu joprojām var rekonstruēt.

Nepieciešamie izmēģinājuma nodevumi ir tvērumam piesaistīts kontroles ieraksts, pierādījumu indekss, pārskatīts novērtējums, piešķirta novēršana, kartējums ar redzamiem robiem, vadības kopsavilkums, atļauju testu rezultāti un izmantojams eksports.

Ilustratīvam izmaksu salīdzinājumam pieņemsim, ka pašreizējais process patērē 30 darbinieku stundas mēnesī pēc plānošanas likmes, kas ietver visas izmaksas, 60 € stundā: 21 600 € gadā. Pieņemsim, ka izmēģinājums liecina par 12 stundām mēnesī pēc ieviešanas: 8640 € gadā. Modelētā kapacitātes starpība ir 12 960 € pirms abonementa, ieviešanas un integrācijas izmaksām. Tas nav solīts ietaupījums un ne obligāti atbrīvota nauda; tas parāda, kuri pieņēmumi iegādes lēmumam jāvalidē.

Padariet ieviešanu par iegādes lēmuma daļu

Pirms parakstīšanas ieceliet iekšējo īpašnieku un vienojieties par pirmo ieviešanas robežu. Izvairieties no visu vēsturisko failu importēšanas, neizlemjot, kas paliek aktuāls, autoritatīvs vai saglabāšanas vērts.

Sāciet ar vienu pakalpojumu vai procesu, nosauktiem īpašniekiem un pārskatītājiem, reprezentatīvām kontrolēm un īsu pierādījumu pārskatīšanas ritmu. Agri kartējiet atkarības un ārējos pakalpojumu sniedzējus. Migrējiet ierakstus, kas nepieciešami šī tvēruma darbībai, saglabājiet nepieciešamo vēsturi un saskaņojiet importēto modeli ar avota reģistru.

Apmāciet lietotājus atbilstoši lomām: īpašnieki iesniedz un paskaidro pierādījumus, pārskatītāji tos novērtē, administratori uztur piekļuvi un struktūru, un vadītāji apstiprina lēmumus savu pilnvaru ietvaros. Definējiet, kā tiks apstrādātas tvēruma izmaiņas, novecojuši pierādījumi, nokavētas darbības un avotu kļūmes.

Pēc pirmā pārskatīšanas cikla salīdziniet rezultātus ar iegādes kopsavilkumu. Izmēriet pārskatītāju piepūli, pierādījumu aktualitāti, atkārtotus pieprasījumus, neatrisinātas īpašumtiesības un ieviešanu ārpus GRC komandas. Paplašiniet tikai tad, kad darbplūsma ir saprasta un atkārtojama. Produkta atjauninājumiem un ietvaru izmaiņām jāveic ietekmes pārskatīšana, nevis jāļauj tiem klusi mainīt apstiprinātus ierakstus.

Secani ir veidots ap savienotu kiberdrošības atbilstības darbu. Tā dokumentētā sākuma darbplūsma izmanto fokusētu organizatorisko vienību, procesu, produktu vai pārvaldītu pakalpojumu. Komandas modelē mērķa objektus un atkarības, sasaista politikas, eksportus un ekrānuzņēmumus ar prasībām vai kontrolēm, kuras tie atbalsta, un pārvērš trūkstošus pierādījumus vai neskaidras īpašumtiesības uzdevumos. MI ieteikumi paliek melnraksta darbs: pārskatītāji pārbauda avotus, pielāgo formulējumu un apstiprina izsekojamus lēmumus. Dokumentācija un norādījumi par atļaujām sniedz sākuma kontekstu. Izmantojiet publisko ceļvedi kopā ar praktisku demonstrāciju, lai plānotu, kā jūsu komanda ieviesīs papildu darbplūsmas, produktam attīstoties. Novērtējiet demonstrētās spējas pret izmēģinājuma pieņemšanas kritērijiem un plānoto darbu reģistrējiet atsevišķi.

Bieži uzdotie jautājumi

Vai GRC programmatūra var padarīt organizāciju atbilstošu?

Nē. Tā var strukturēt prasības, koordinēt ieviešanu, saglabāt pierādījumus un atbalstīt novērtēšanu. Cilvēki joprojām darbina kontroles, interpretē pienākumus, pieņem riskus un pārskata secinājumus. Sertifikācijas vai apliecinājuma lēmumi pieder attiecīgajam neatkarīgajam pārliecības sniedzējam.

Vai mums vajadzētu iegādāties plašāku platformu iespējamiem nākotnes pienākumiem?

Novērtējiet ticamas nākotnes vajadzības, bet izvairieties maksāt par spekulatīvu plašumu. Pajautājiet, kā, izmantojot jūsu esošo modeli, tiktu pievienots vēl viens tvērums vai ietvars. Demonstrēts paplašināšanas ceļš ir noderīgāks par lielu neizmantotu moduļu katalogu.

Vai uz MI balstīta GRC aizstāj konsultantu vai atbilstības profesionāli?

Nē. Mērķtiecīgi veidota sistēma var uzturēt pastāvīgu, atļaujas ievērojošu kontekstu un padarīt ekspertu metodes atkārtoti izmantojamas. Tai jāsamazina mehāniskais darbs, saglabājot atbildību par neviennozīmīgām interpretācijām, tvēruma lēmumiem, atbilstības spriedumiem un apstiprinājumiem.

Ko darīt, ja neviens produkts neaptver visu mūsu steku?

Skaidri identificējiet neaptvertās sistēmas un vienojieties par kontrolētu manuālu vai pielāgotas integrācijas procesu. Piešķiriet īpašumtiesības, pārskatīšanas biežumu un uzturēšanas izmaksas. Daļēja automatizācija ir izmantojama, ja pārklājuma robeža paliek redzama.

Ko mums darīt tālāk?

Sagatavojiet vienas lappuses iegādes kopsavilkumu un vienu reprezentatīvu pierādījumu paketi. Lūdziet atlasītajiem piegādātājiem šo paketi aizvest no prasības līdz pārskatītam secinājumam, pēc tam mainiet kādu svarīgu avota ierakstu. Novērtējiet ietekmēto darbu, pārskatītāju piepūli, atbildību un eksportu, nevis tikai sākotnējo rezultātu.