Kuidas valida parim GRC-tarkvara

GRC-tarkvara peaks teie metoodikat skaleerima, siduma järeldused tõenditega ja jätma kontrolli vastutavate inimeste kätte. Parim valik on platvorm, mis suudab teie vastavusprogrammi käigus hoida, mitte lihtsalt kuvada täidetud kontroll-loendit.

Audit läheneb, kuid selle ettevalmistamiseks vajalik teave on organisatsioonis laiali. Kontrollimeetmete register on arvutustabelis. Poliitikad asuvad SharePointis. Tõendid on kaustades. Parandustöid jälgitakse Jiras. Riskiotsused on maetud koosolekute märkmetesse. Viimase hindamise põhjendused on peamiselt vastavusjuhi või konsultandi peas.

Meeskonnad reageerivad sageli nii, et panevad uuesti kokku eelmise aasta auditipaketi, võtavad kasutusele järjekordse jäiga kontroll-loendi või paluvad üldotstarbelisel tehisintellekti tööriistal koostada dokumentatsiooni puuduliku konteksti põhjal. Kõik kolm annavad mingi tulemuse. Ükski neist ei loo tingimata usaldusväärset vastavussüsteemi.

Ostuotsus ulatub seega järgmisest auditist kaugemale. Tarkvara aitab säilitada organisatsiooni teadmisi, koordineerida tööd osakondade vahel ja muuta juhtkonna otsused paremini kontrollitavaks. See võib aga lisada ka uue halduskihi, kui kontrollimeetmete omanikud seda väldivad, integratsioonid jätavad olulised süsteemid kõrvale või tõendid kaotavad importimisel oma konteksti.

Juhtkonna vaatest ei ole küsimus selles, millisel tarnijal on kõige atraktiivsem töölaud. Küsimus on selles, millist tegevusmudelit organisatsioon ostab, milline töö jääb tema inimestele ja kas tekkivad kirjed toetavad põhjendatud otsuseid.

Hinnake toodet seitsme küsimuse abil:

1. Kas see sobib sellega, kuidas GRC-töö tegelikult toimub?
2. Kas see peegeldab teie ulatust ja metoodikat?
3. Kas see seob kontrollimeetmed rakenduse ja tõenditega?
4. Kas iga hindamist ja tehisintellekti loodud järeldust saab kontrollida?
5. Kas tööd saab raamistike vahel turvaliselt taaskasutada?
6. Kas see suudab käitada korratavaid töövooge ilma inimeste vastutust kõrvaldamata?
7. Kas see on tundlike vastavusandmete jaoks piisavalt turvaline ja ülekantav?

Seejärel kontrollige neid vastuseid juurutamise töömahu, eksperditoe, aruandlusvajaduste ja omamise kogukulu suhtes.

Määratlege enne toodete võrdlemist, mida te ostate

GRC-tarkvara toetab juhtimiskohustusi, riske, kontrollimeetmeid, tõendeid, hindamisi, leide, parandustöid ja aruandlust. See juhend keskendub eelkõige küberturbe GRC-le ja infoturbe juhtimissüsteemi ehk ISMS-i tööle.

Kasulik lähtealus on nende kirjete omavaheline seos:

Nõue → kontrollimeede → rakendus → tõend → hindamine → leid → parandustöö → otsus

Nõudest peaks olema näha, millised kontrollimeetmed seda katavad. Kontrollimeede peaks kirjeldama oma rakendust, vastutavat omanikku, asjakohaseid varasid või protsesse ja toetavaid tõendeid. Hindamine peaks säilitama selle, mida uuriti, milliseid kriteeriume rakendati, milline oli järeldus, milline ebakindlus jäi ja millised tegevused sellest tulenesid.

ISO/IEC 27001 käsitleb kindla ulatusega ISMS-i, mille riskijuhtimine on kohandatud organisatsiooni vajadustele. Tarkvara valimine ei ole seega lihtsalt pikima raamistike loendi otsimine. See on sellise süsteemi otsimine, mis suudab kujutada tegelikku juhtimissüsteemi.

Eri tootekategooriad rõhutavad selle töö eri osi:

Need kategooriad kattuvad. Lai platvorm ei ole automaatselt parem valik kui kitsalt keskendunud platvorm. Otsustage, milline süsteem omab iga protsessi autoriteetset kirjet ja kus jääb vajalikuks mõni muu tööriist.

GRC-tarkvara peaks ühenduma dokumendihalduse, piletisüsteemi, inventaride, identiteedipakkujate, pilveplatvormide ja turbetööriistadega. See ei pea neid kõiki asendama. See peab säilitama konteksti, mis seob nende teabe vastavusotsustega.

Kujundage äriline põhjendus ja tegevusmudel

Valmistage enne demosid ette lühike ostulähteülesanne. Nimetage tegevjuhtkonnast sponsor, programmi omanik, osalevad meeskonnad, esialgne ulatus, nõutavad kohustused, soovitud tulemused ja juurutamiseks saadaolev võimekus.

Muutke tulemused konkreetseks. „Vastavuse parandamist“ on raske hinnata. „Korduvate tõendipäringute vähendamine kahe hindamise lõikes nii, et omaniku heakskiit säilib“ annab tarnijatele töövoo, mida demonstreerida.

Eristage kohesed nõuded tõenäolistest tulevastest vajadustest. Ettevõte, mis valmistab ette oma esimest ISMS-i, võib seada esikohale ulatuse, riskikäsitluse, tõendite ülevaatuse ja omanikud. Mitme tütarettevõttega kontsern võib vajada ühiseid kontrollimeetmeid, kohalikke erandeid, piiratud tööruume ja koondaruandlust. Konsultatsioonifirma vajab taaskasutatavaid meetodeid ilma klientide konfidentsiaalset teavet segamata.

Töö ressursside tagamiseks on ka mitu võimalust:

Ükski tee ei kõrvalda juhtkonna vastutust. Nõustamise ostmine ei kanna üle riski aktsepteerimist ja tarkvara ostmine ei tõenda, et kontrollimeetmed toimivad tõhusalt.

Kasutuselevõttu tasub sageli kaaluda enne uue programmi alustamist, siis kui tõendipäringud muutuvad korduvaks, või siis kui laienemine toob kaasa uusi ulatusi ja kohustusi. Peatselt saabuv audit võib aga olla halb hetk täielikuks migratsiooniks. Sellises olukorras stabiliseerige olemasolev tõendipakett ja katsetage uut tegevusmudelit paralleelselt.

1. Kas see sobib sellega, kuidas GRC-töö tegelikult toimub?

GRC-töö toimub intervjuudes, töötubades, poliitikate ülevaatustes, juurutusülesannetes, auditikõnedes ja juhtkonna aruteludes, mitte ainult GRC-rakenduse sees.

Platvorm õigustab oma kohta siis, kui need tegevused moodustavad sidusa töövoo ilma, et meeskond peaks kõike käsitsi teises andmebaasis uuesti looma. Imporditud ekraanipilt on endiselt lihtsalt fail, kui see ei jää seotuks süsteemi, kontrollimeetme, ülevaatusperioodi, omaniku ja hindamisega, mida see toetab.

Hinnake integratsioonide sügavust, kaetust ja tõrgete käsitlemist

Alustage oma tegelikust tehnoloogiakogumist. Tehke iga olulise allika puhul kindlaks vajalik teave ja töövoog, mida see toetab.

Identiteediliides võib tuua kasutajad, kuid mitte privilegeeritud kontosid, autentimisseadeid ega tõendeid, et juurdepääsuõiguste ülevaatus on tehtud. Pilveintegratsioon võib uurida valitud kontosid, jättes kõrvale teise tootmiskeskkonna. Piletisüsteemi ühendus võib luua ülesandeid, ilma et nende lahendamise olek tagasi jõuaks.

Paluge tarnijatel demonstreerida:

• Milliseid kontosid, süsteeme ja varatüüpe liides katab
• Milliseid õigusi on vaja ja kas piisab ainult lugemisõigusest
• Kogumise sagedust ja ajatemplit, mida hindajatele näidatakse
• Kuidas tõrked, tühistatud volitused ja mittetäielik kogumine nähtavaks muutuvad
• Kas lähtekirjed jäävad pärast importi tuvastatavaks
• Mida API-d toetavad lisaks käsitsi failide üleslaadimisele
• Kes hooldab kohandatud liideseid, kui lähtesüsteemide API-d muutuvad

Vaadake pilvekonfiguratsiooni, identiteedi, personali, lõppseadmete, arenduse, intsidentide ja koostöö allikad üle vastavalt oma ulatusele. Ärge eeldage, et tuttav integratsioonilogo tõendab vajalike tõendite kättesaadavust.

Ebaõnnestunud kogumine ei tohiks jätta vana positiivset tulemust ajakohasena paistma. Samamoodi peaks süsteem, mis jääb integratsioonide kaetusest välja, ilmuma kaetuslüngana, mitte nimetajast kaduma.

Katsetage aeg-ajalt kasutajate kogemust

Paluge kontrollimeetme omanikul, kes platvormi ei halda, vastata tõendipäringule, selgitada erandit ja esitada parandustöö olekuuuendus. Paluge hindajal sobimatu tõend tagasi lükata ja täpsustust küsida.

Pange kirja abi, mida nad vajavad. Kui iga toiming nõuab GRC-administraatorit, võib platvorm kirjed küll tsentraliseerida, kuid jätta koordineerimistöö muutumatuks. Kontrollige teavituste suunamist, delegeerimist puudumise ajal, ligipääsetavust ja kasutajalitsentside praktilist mõju osalemisele.

2. Kas see peegeldab teie ulatust ja metoodikat?

GRC ei ole üks universaalne kontroll-loend. Sama standardit kasutavatel organisatsioonidel võivad olla erinevad süsteemid, riskid, vastutusalad, rakendused ja tõenditele esitatavad ootused.

Tarkvara peaks neid erinevusi kujutama ilma, et iga muudatus muutuks konsultatsiooniprojektiks.

Uurige, kas see suudab modelleerida organisatsiooniüksusi, teenuseid, rakendusi, taristut, teavet, asukohti ja väliseid teenusepakkujaid. Seejärel katsetage nendevahelisi seoseid. Jagatud identiteediteenus võib toetada mitut toodet; teenusepakkuja võib käitada taristut, samal ajal kui konfiguratsiooni ja juurdepääsu eest vastutab teie organisatsioon.

Ulatuse käsitlemine on oluline, sest kontrollimeede võib olla ühes keskkonnas tõhus ja teises puudulik. „MFA rakendatud“ ei tohiks varjata, et väide hõlmab ettevõtte kontosid, kuid jätab välja tootmiskeskkonna haldustee.

Hindamist väärivad muu hulgas järgmised võimalused:

• Kohandatud kontrollimeetmete teegid ja rakenduskirjeldused
• Kohaldatavusotsused koos põhjenduste ja ülevaatusajalooga
• Ühised, päritud ja süsteemipõhised kontrollimeetmed
• Peamised omanikud, hindajad ja jagatud vastutus
• Erinevad hindamis- ja riskimetoodikad
• Kohalikud erandid ilma kontrollimatu dubleerimiseta
• Taaskasutatavad mallid, milles kliendipõhine teave on isoleeritud

Hoidke riskijuhtimine äriotsustega seotuna

Riskiregister peaks tegema enamat kui värve määrama. Ostjad peaksid katsetama, kuidas platvorm salvestab stsenaariumi, mõjutatud teenuse, ärimõju, olemasolevad kontrollimeetmed, hinnangu põhjenduse, käsitluse, jääkriski, heakskiitva volitusega isiku ja järgmise ülevaatuse.

Küsige, kuidas hinnangud muutuvad, kui rakendus või eeldused muutuvad. Automaatne ümberarvutus võib olla kasulik, kuid see ei tohiks vaikselt asendada heakskiidetud riskiotsust. Juhtkond peab suutma eristada uut tehnilist signaali üle vaadatud ärilisest otsustusest.

Katsetage aegumiskuupäevaga riski aktsepteerimist. Kirjest peaks olema näha, kellel oli volitus see aktsepteerida, millised tingimused on sellega seotud ja mis juhtub, kui need tingimused enam ei kehti. Aluseks oleva töövoo kohta vaadake kuidas hoida käigus operatiivset riskiregistrit.

Konsultatsioonifirmad peaksid ulatuse testi kordama kahes kliendi tööruumis. Taaskasutatav meetod ei tohi kanda ühe kliendi tõendeid, kommentaare ega konfidentsiaalseid eeldusi teise kliendi hindamisse.

3. Kas see seob kontrollimeetmed rakenduse ja tõenditega?

Valmis märgitud kontrollimeede ei tõenda rakendamist ega tõhusust. Platvorm vajab tõendikihti, mis teeb enamat kui manuseid salvestab.

Iga tõendi puhul peaksid hindajad suutma kindlaks teha, mida see näitab, kust see pärineb, millist keskkonda see katab ja kas see on hindamisperioodi jaoks endiselt sobiv.

Tõendite kvaliteet sõltub kontekstist. Poliitika võib näidata heakskiidetud ootust; iseenesest ei tõenda see, et inimesed seda järgisid. Konfiguratsiooni eksport võib näidata seadistust; see ei pruugi tõendada, et seadistus kattis kogu hindamisperioodi vältel iga asjakohast vara.

Praktiline tõendite ülevaatus eristab kontrollimeetme ülesehitust, rakendamist ja toimimist. Juurdepääsuõiguste ülevaatuse kontrollimeetme puhul võib see tähendada heakskiidetud protseduuri, üle vaadatud kontode kogumit, hindajate otsuseid ja tõendit, et nõutud eemaldamised tehti.

Demonstreerige vastuolulisi ja aegunud tõendeid

Andke tarnijale üks ajakohane dokument, üks aegunud dokument ja üks kirje, mis on rakenduskirjeldusega osaliselt vastuolus. Kasutage anonüümitud või asjakohaselt heakskiidetud teavet.

Paluge platvormil toetada kontrollimeetme hindamist. See peaks säilitama eraldi allikad ja muutma ebakindluse nähtavaks, mitte neid vaikselt üheks enesekindlaks väiteks liitma.

Küsige ka, mis juhtub, kui tõendid muutuvad. Kas süsteem tuvastab mõjutatud kontrollimeetmed ja hindamised? Kas hindaja saab säilitada varasema järelduse ja algatada samal ajal uue ülevaatuse? Ajalooline põhjendatavus sõltub algse otsuse aluse säilitamisest, mitte selle lihtsast asendamisest tänase failiga.

4. Kas iga hindamist ja tehisintellekti väljundit saab kontrollida?

Allikatele tuginemine ja kontrollimine on seotud, kuid erinevad asjad. Allikatele tuginemine tuvastab materjali, mis väljundit mõjutab. Kontrollimine võimaldab hindajal uurida selle taga olevaid konkreetseid allikaid ja arutluskäiku.

Tehisintellekti vastus, mida kirjeldatakse kui „ettevõtte andmetel põhinevat“, ei ole piisav, kui hindaja ei saa kindlaks teha, millised kirjed toetavad iga olulist väidet. Ladus tekst võib varjata puuduvaid rakendustõendeid või valet ulatuseeldust.

Põhjendatud hindamiskirje peaks näitama:

• Nõuet ja hindamiskriteeriumi
• Uuritud rakendust ja asjakohast ulatust
• Viiteid tõenditele ja toetavaid väljavõtteid
• Puuduvat, vastuolulist või ebakindlat teavet
• Ettepanekut, hindaja muudatusi ja heakskiidetud järeldust
• Hindaja isikut ja otsuse kuupäeva
• Hilisemaid muudatusi, mis võivad nõuda uut hindamist

Paluge tarnijal selgitada, miks kontrollimeede hinnati osaliselt rakendatuks. Seejärel küsige, millised tõendid järeldust tugevdavad, millised seda nõrgendavad, kes selle heaks kiitis ja mis põhjustaks selle muutumise.

Eristage abistamine volitustest

Tehisintellekt võib teavet välja võtta, vastavusseoseid soovitada, rakenduskirjeldusi mustandina koostada või hindamisettepanekut ette valmistada. Nendel tegevustel on teistsugused tagajärjed kui riski aktsepteerimise heakskiitmisel või autoriteetse kirje muutmisel.

Kehtestage võimekusepõhised õiguste piirid. Milliseid allikaid agent lugeda saab? Milliseid kirjeid see saab muuta? Kas sellel on juurdepääs tundlikele tõenditele? Millised toimingud nõuavad inimese heakskiitu? Kuidas saab ekslikku toimingut uurida ja parandada?

Katsetage nii tavalisi kui ka volitamata päringuid. Päring teise kliendi tõendite kokkuvõtmiseks ei tohiks tööruumi piiranguid mööda minna. Üleslaaditud dokumenti põimitud juhiseid tuleks käsitleda dokumendi sisuna, mitte volitusena teabe avaldamiseks või kirjete muutmiseks.

Juhtkonna jaoks on ostuküsimus vastutus: mustandite koostamisel säästetud aeg ei tohiks muutuda ajaks, mis kulub selle rekonstrueerimisele, miks mingi väide heaks kiideti. Täiendavaid hindamisküsimusi käsitleb artikkel tehisintellekti agentide juhtimisest.

5. Kas tööd saab raamistike vahel turvaliselt taaskasutada?

Mitme raamistiku tugi peaks tähendama enamat kui raamistike logode kuvamist. Võimalus seisneb selles, et kontrollimeede rakendatakse üks kord ja sobivaid tõendeid taaskasutatakse. Oht seisneb erinevate nõuete käsitlemises samaväärsetena.

Intsidentidele reageerimise protsess võib toetada ISMS-i, klientide kohustusi ja regulatiivseid kohustusi. Need allikad võivad siiski erineda ulatuse, aruannete saajate, tähtaegade, heakskiidunõuete ja kindlustandvatele tegevustele esitatavate ootuste poolest.

Usaldusväärsed vastavusseosed peaksid säilitama raamistiku versiooni, seose suuna, seose tüübi, autori või allika, kaetuse, allesjäävad lüngad ja ülevaatuse oleku. Seosed võivad olla mitu-mitmele; kattuvus ei tõenda täielikku täitmist kummaski suunas.

NIST-i OSCAL Control Mapping Model pakub struktureeritud viisi kujutada eri dokumendiallikate kontrollimeetmete ja nende elementide vahelisi seoseid ilma nende algset sisu dubleerimata.

Paluge tarnijal siduda üks rakendatud protsess kahe raamistiku ja ühe regulatiivse kohustusega. Kasulik väljund on nii taaskasutatav töö kui ka allesjääv vahe: milliseid täiendavaid rakendusi, tõendeid või otsuseid on vaja?

Rakendage iga kohustuse puhul erinevat testi

ISO 27001 tarkvara puhul uurige ulatust, riskihindamist ja -käsitlust, kohaldatavuse avaldust, siseauditit, juhtkonnapoolset läbivaatust ja parendamist. Need on eraldiseisvad tegevused. Standardi punktid 4–10 sisaldavad ISMS-i nõudeid; lisa A sisaldab 93 kontrollimeedet, mille kohaldatavus on riskipõhine. Kontrollimeetmete loend ei ole kogu ISMS. Sertifitseerimise teeb sõltumatu sertifitseerimisasutus, mitte ISO ega tarkvarapakkuja.

NIS2 tarkvara puhul tehke enne kaetuse hindamist kindlaks kohaldatavus asjakohase riikliku ülevõtmisseaduse alusel. Direktiivi artiklid 20–23 käsitlevad juhtkonna järelevalvet, riskijuhtimismeetmeid ja märkimisväärsetest intsidentidest teatamist. Hinnake juhtkonna heakskiidu ja koolituse, tarnijate turvalisuse, tõhususe ülevaatuste ja teavitamiskohustuste kirjeid, mitte ainult artiklite vastavusseoseid.

ELi direktiivi tasandil hõlmab teavitamine 24 tunni jooksul esitatavat varajast hoiatust, 72 tunni jooksul esitatavat teadet ja üldjuhul lõpparuannet ühe kuu jooksul pärast teate esitamist. 24- ja 72-tunnised tähtajad algavad märkimisväärsest intsidendist teadasaamisest; mõlemad tuleb esitada põhjendamatu viivituseta. Riiklikud ja sektoripõhised reeglid tuleb üle kontrollida. Katsetage töövoogu, milles on kirjas intsidendist teadasaamine, volitatud teataja ja asendaja, saaja andmed, teavitamisotsused ja esitamise tõend. NIS2 ei loo ettevõtete ega tarkvara üldist sertifitseerimist.

SOC 2 ja auditi tarkvara puhul eristage kinnitusaruannet sertifikaadist. Katsetage tõendusperioode, audiitori päringuid, valimi toetamist, leide ja piiratud välist juurdepääsu. Platvormi läbitud test ei ole audiitori järeldus.

Kõrvalvajaduste puhul katsetage tegelikku erialast töövoogu. Privaatsustöö võib nõuda töötlemistoimingute registreid, lepingute ülevaatusi ja taotluste käsitlemist. Tehisintellekti juhtimine võib nõuda kasutusjuhtude inventare ja rollipõhiseid hindamisi; ISO 42001 ja vabatahtlik NIST AI RMF ei taga automaatselt vastavust tehisintellekti määrusele. Finantssektori vajaduste puhul tõlgendage DORA-t organisatsiooni rolli järgi, mitte iga NIS2 kontrollimeedet dubleerides.

6. Kas see suudab käitada korratavat tööd ja näidata sisukaid tulemusi?

Korratavad töövood muudavad GRC-tarkvara operatiivseks taristuks. Need peaksid määratlema sisendid, vastutuse, sammud, ülevaatuspunktid, väljundid ja heakskiidu piirid ning säilitama iga täitmise ajaloo.

Katsetage kontrollimeetme täielikku ülevaatust: koguge asjakohane teave, tuvastage lüngad, valmistage ette ettepanek, suunake see ülevaatusele, salvestage otsus ja uuendage seotud parandustöid. Meeskond peaks nägema, mida automatiseerimine tegi, mida hindaja muutis ja mis heaks kiideti.

Eristage kogumist, testimist ja seiret

Konfiguratsiooniandmete korduv kogumine ei ole sama mis kontrollimeetme testimine. Kontrollimeetme korduv testimine ei ole sama mis turbeintsidentide avastamine ja neile reageerimine.

Küsige, mida iga automaatne test tegelikult hindab, kui sageli see käivitub, milliseid varasid see välistab ja mis juhtub, kui see ebaõnnestub. Tehnilised seadistused võivad võimaldada sagedasi kontrolle; halduslikud kontrollimeetmed võivad nõuda inimese plaanilist ülevaatust. Mõistlik sagedus lähtub riskist ja kontrollimeetmest, mitte üldisest eelistusest testida iga tund.

Parandustööde puhul katsetage omanikke, raskusastet, tähtaegu, eskaleerimist, erandeid ja sulgemise kontrolli. Pileti lahendamine ei tohiks automaatselt tõendada, et aluseks olev kontrollimeede on tõhus. Endiselt võib olla vaja kordustesti või hindaja otsust.

Tarnijate töövood väärivad sama põhjalikku kontrolli. Otsige registrit, milles on teenuste sõltuvused, kriitilisus, hindamise põhjendus, leiud, omanikud ja ülevaatuse kuupäevad. Küsimustike kaust ei ole pidev tarnijariskide protsess.

Hinnake aruandlust kolme sihtrühma jaoks

Insenerid vajavad tegutsemist võimaldavaid tõrkeid ja määratud tööd. GRC-hindajad vajavad kaetust, ajakohaseid tõendeid, lahendamata küsimusi ja hindamise olekut. Juhtkond vajab olulisi riske, tähtaja ületanud käsitlusi, sõltuvusi ja volitust nõudvaid otsuseid.

Paluge jälitada juhtkonna kokkuvõte tagasi aluseks olevate kirjeteni. Protsendid peaksid avalikustama oma nimetaja ja välistused. „Kõik ühendatud testid on läbitud“ ei tohi esitada kui „kõik kohustused on täidetud“.

Kasulikud juhtimismõõdikud on muu hulgas ülevaatust ootavad tõendid, tähtaja ületanud suure mõjuga tegevused, aegunud riskide aktsepteerimised, korduvad leiud ja muutused kaetuses. Aruanded peaksid eristama ajakohast teavet aegunud või hindamata kirjetest. Kontroll-loendi täitmisest kaugemale ulatuvate mõõtmisvalikute kohta vaadake ISMS-i mõõdikuid.

7. Kas see on tundlike andmete jaoks piisavalt turvaline ja ülekantav?

GRC-platvorm võib paljastada arhitektuuri, teadaolevad nõrkused, tarnijasõltuvused, intsidendiprotseduurid ja juhtkonna otsused. Hinnake selle turvalisust enne päris tõendite üleslaadimist.

Küsige tõendeid rentnike ja klientide isoleerimise, edastamisel ja salvestamisel krüpteerimise, juurdepääsukontrolli, haldusjuurdepääsu, logimise, intsidentidele reageerimise, varundamise ja taastamise, säilitamise ning kustutamise kohta. Kui juttu on krüpteerimisest, küsige võtmete omandi, elutsükli, taastamise ja eraldatuse kohta, mitte ainult selle kohta, kas krüpteerimine on sisse lülitatud.

Eristage tavapärast lugemist, tundlikku lugemist, kirjutamist, heakskiitmist ja haldamist. Katsetage välise hindaja juurdepääsu ja selle aegumist. Konsultatsioonifirmade puhul kontrollige, et jagatud metoodika ei paljastaks kliendipõhiseid kirjeid otsingu, tehisintellekti konteksti, ekspordi ega teavituste kaudu.

Tehisintellekti töötlemise puhul tehke kindlaks, millised teenusepakkujad ja alamtöötlejad teavet saavad, miks nad seda saavad, milline säilitamine kehtib ja kas klientide teavet kasutatakse treenimiseks. Nõudke lepingulist selgust, selle asemel et tugineda üldisele privaatsusteatele.

Majutamise asukoht on oluline, kuid üksi ei tõenda see suveräänsust ega vastavust GDPR-ile. Arvestage juurdepääsukorraldust, töötlemisrolle, lepinguid, alamtöötlejaid ja asjakohaseid edastamise hindamisi.

Vaadake üle tarnija kindlustandvate tõendite ulatus ja periood. Sertifikaat või aruanne võib välistada teenuse, funktsiooni või töötlemiskorralduse, mida kavatsete kasutada. Artikkel kuidas hinnata turvalisuse kindlustandvaid tõendeid selgitab seda ülevaatust.

Katsetage lahkumist enne allkirjastamist

Küsige näidiseksporti, mis sisaldab kontrollimeetmeid, rakendusi, vastavusseoseid, riske, viiteid tõenditele, hindamisi, otsuseid ja seoseid. Kontrollige, kas manused ja ajalugu jäävad väljaspool platvormi kasutatavaks.

NIST-i OSCAL-i mudelid toetavad masinloetavat teavet kontrollimeetmete, rakenduse, hindamise, tulemuste ja parandustööde kohta. Struktureeritud XML, JSON või YAML võib parandada ülekantavust, kuid vormingu nimi üksi ei tõenda täielikku eksporti. Kontrollige, millised mudelid, seosed ja laiendused on kaasatud.

Leppige kokku ekspordi kättesaadavus, migratsiooniabi, juurdepääs pärast lepingu lõppu ja kustutamisprotseduurid. Lõplikud PDF-id ja lamedaks muudetud arvutustabelid võivad säilitada esitlusviisi, kaotades samal ajal tegevusmudeli.

Võrrelge tuge ja omamise kogukulu

Eristage tehniline tugi, juurutusabi, professionaalsed nõustamisteenused ja sõltumatu kindlustandev töö. Need lahendavad eri probleeme.

Küsige, kes vastab tõlgendusküsimusele, milline kogemus neil on, kas sama nõustaja jääb kaasatuks ja kui kaua see teenus hinna sees on. Täpsustage reageerimiskohustused, ajavööndite kaetus, eskaleerimine auditi ajal ja see, kes teeb töö ära, kui juurutus jääb ajakavast maha.

Kui testimis- või auditeerimisteenused on paketis, uurige neid eraldi. Haavatavuste skaneerimine ja läbistustest annavad erinevaid tõendeid. Ei ISO 27001 ega SOC 2 kehtesta igale organisatsioonile ühte universaalset läbistustesti nõuet; olulised on ulatus, risk, valitud kontrollimeetmed ja klientide ootused. Kinnitage testimise ulatus, metoodika, parandustööde tugi ja kordustestimise tingimused.

Kui kaasatakse audiitor või sertifitseerimisasutus, tehke kindlaks tegelik sõltumatus, valikuvabadus ja ärilised kokkulepped. Tarkvaraline valmisolek ei ole kindlustandev arvamus ja kindlustandev töö ei rahulda automaatselt iga kliendi turvaülevaatust.

Koostage kulumudel, mis hõlmab:

• Tellimust, mooduleid, kasutajatüüpe, üksusi ja raamistikke
• Juurutamist, migratsiooni ja integratsioonide hooldust
• Majasisest haldust ja kontrollimeetmete omanike töömahtu
• Nõustamisteenuseid, testimist, kordustestimist ja sõltumatuid auditeid
• Tehisintellekti kasutust, salvestusruumi, API piiranguid ja muid tarbimistasusid
• Uuendamist, oodatavat kasvu ja lõplikku lahkumist

Küsige hinda nii tänase ulatuse kui ka realistliku tulevase ulatuse jaoks. Dokumenteerige, mis põhjustab hinnatõuse ja millised funktsioonid on välistatud. Madalam tellimustasu võib kokkuvõttes kallim olla, kui see nõuab märkimisväärset ühitamist ja käsitsi ülevaatust.

Viige läbi esinduslik pilootprojekt, mitte üldine demo

Kasutage iga lühinimekirja jõudnud tarnija puhul sama anonüümitud tõendipaketti ja vastuvõtukriteeriume. Kaasake kontrollimeetme omanik, hindaja, tehniline administraator ja hankega seotud huvipool.

Praktiline hindamistabel võib anda töövoo ja metoodikaga sobivusele kaalu 25%, tõenditele ja kontrollitavusele 20%, turvalisusele ja ülekantavusele 20%, integratsioonide kaetusele 15%, kasutatavusele ja aruandlusele 10% ning toele ja kogukulule 10%. Need kaalud on soovitus, mitte universaalne valem; leppige need kokku enne demosid.

Hinnake demonstreeritud võimekust eraldi konfiguratsioonilubadustest ja tegevuskava punktidest. Turvalisuse või isoleerimise tõrge peaks olema ostuotsuse välistav tingimus, mitte midagi, mida atraktiivne töölaud suudaks tasakaalustada.

Näide: juurdepääsuõiguste ülevaatus kahes ulatuses

Illustreerivad eeldused: 180 töötajaga tarkvaraettevõte käitab kahte teenust, peab ISMS-i ja saab korduvaid klientide päringuid kindlustandvate tõendite kohta. Selle pilootprojekt hõlmab privilegeeritud juurdepääsu ülevaatust ühes tootmisteenuses. Kõik tõendid on anonüümitud.

Pakett sisaldab heakskiidetud protseduuri, identiteedieksporti, täidetud ülevaatuskirjet, aegunud kontode loendit ja piletit, millest nähtub, et üks nõutud eemaldamine on endiselt avatud.

Paluge igal tarnijal tuvastada asjakohane ulatus ja omanik, siduda tõendid rakendusega, eristada ajakohased kirjed aegunutest ja valmistada ette ülevaadatav hindamine. Lahendamata eemaldamine peaks jääma nähtavaks. Nende tõendite taaskasutamine teise raamistiku jaoks peab säilitama nende ulatuse ja ülevaatusperioodi.

Seejärel lisage teine teenus, mis kasutab teistsugust identiteedisüsteemi. Algsed positiivsed tõendid ei tohiks seal automaatselt kaetust tõendada. Lõpuks asendage eksport uuemaga, milles on seletamatu privilegeeritud konto. Küsige, millised heakskiidetud järeldused vajavad ülevaatust ja kas varasem otsus jääb rekonstrueeritavaks.

Pilootprojekti nõutavad väljundid on ulatusega kontrollimeetme kirje, tõendite register, üle vaadatud hindamine, määratud parandustöö, nähtavate lünkadega vastavusseos, juhtkonna kokkuvõte, õiguste testi tulemused ja kasutatav eksport.

Illustreeriva kuluvõrdluse jaoks eeldage, et praegune protsess võtab kuus 30 töötunni ja planeerimise täiskulu määr on 60 € tunnis: 21 600 € aastas. Oletame, et pilootprojekt viitab kasutuselevõtu järel 12 tunnile kuus: 8640 € aastas. Modelleeritud võimekuse vahe on 12 960 € enne tellimuse, juurutamise ja integratsioonide kulusid. See ei ole lubatud sääst ega tingimata vabanev raha; see näitab, milliseid eeldusi ostuotsus peab kinnitama.

Muutke juurutamine ostuotsuse osaks

Määrake enne allkirjastamist majasisene omanik ja leppige kokku juurutamise esimene piir. Vältige kõigi ajalooliste failide importimist ilma otsustamata, mis on ajakohane, autoriteetne või väärib säilitamist.

Alustage ühest teenusest või protsessist, nimeliselt määratud omanikest ja hindajatest, esinduslikest kontrollimeetmetest ja lühikese tõendite ülevaatuse sagedusega. Kaardistage sõltuvused ja välised teenusepakkujad varakult. Migreerige kirjed, mida on selle ulatuse käitamiseks vaja, säilitage nõutav ajalugu ja ühitage imporditud mudel lähteregistriga.

Koolitage kasutajaid rollipõhiselt: omanikud esitavad ja selgitavad tõendeid, hindajad hindavad neid, administraatorid hooldavad juurdepääsu ja struktuuri ning juhid kiidavad otsused heaks oma volituste piires. Määratlege, kuidas käsitletakse ulatuse muutusi, aegunud tõendeid, tähtaja ületanud tegevusi ja allikate tõrkeid.

Võrrelge pärast esimest ülevaatustsüklit tulemusi ostulähteülesandega. Mõõtke hindajate töömahtu, tõendite ajakohasust, korduvaid päringuid, lahendamata omanikuküsimusi ja kasutuselevõttu väljaspool GRC-meeskonda. Laiendage alles siis, kui töövoog on arusaadav ja korratav. Tooteuuendused ja raamistike muudatused peaksid läbima mõjuülevaatuse, mitte vaikselt heakskiidetud kirjeid muutma.

Secani on üles ehitatud omavahel seotud küberturbe vastavustöö ümber. Selle dokumenteeritud lähtetöövoog kasutab kitsalt piiritletud organisatsiooniüksust, protsessi, toodet või hallatud teenust. Meeskonnad modelleerivad sihtobjektid ja sõltuvused, seovad poliitikad, ekspordid ja ekraanipildid nõuete või kontrollimeetmetega, mida need toetavad, ning muudavad puuduvad tõendid või ebaselge omandi ülesanneteks. Tehisintellekti soovitused jäävad mustandiks: hindajad uurivad allikaid, kohandavad sõnastust ja kiidavad heaks jälgitavad otsused. Dokumentatsioon ja õiguste juhend annavad lähtekonteksti. Kasutage avalikku tegevuskava koos praktilise demoga, et planeerida, kuidas teie meeskond toote arenedes täiendavaid töövooge kasutusele võtab. Hinnake demonstreeritud võimekusi pilootprojekti vastuvõtukriteeriumide alusel ja märkige plaanitud töö eraldi üles.

Korduma kippuvad küsimused

Kas GRC-tarkvara suudab muuta organisatsiooni nõuetele vastavaks?

Ei. See suudab struktureerida nõudeid, koordineerida rakendamist, säilitada tõendeid ja toetada hindamist. Inimesed käitavad endiselt kontrollimeetmeid, tõlgendavad kohustusi, aktsepteerivad riske ja vaatavad järeldused üle. Sertifitseerimise või kinnitamise otsused kuuluvad asjakohasele sõltumatule kindlustandjale.

Kas peaksime võimalike tulevaste kohustuste jaoks ostma laiema platvormi?

Hinnake usutavaid tulevasi vajadusi, kuid vältige spekulatiivse laiuse eest maksmist. Küsige, kuidas lisataks teie olemasolevat mudelit kasutades veel üks ulatus või raamistik. Demonstreeritud laiendustee on kasulikum kui suur kataloog kasutamata mooduleid.

Kas tehisintellektil põhinev GRC asendab konsultandi või vastavusspetsialisti?

Ei. Selleks loodud süsteem suudab hoida püsivat, õigusi arvestavat konteksti ja muuta eksperdimeetodid taaskasutatavaks. See peaks vähendama mehaanilist tööd, säilitades samal ajal vastutuse mitmetähenduslike tõlgenduste, ulatuseotsuste, piisavushinnangute ja heakskiitude eest.

Mis siis, kui ükski toode ei kata kogu meie tehnoloogiakogumit?

Tuvastage kaetuseta süsteemid selgesõnaliselt ja leppige kokku kontrollitud käsitsi või kohandatud integratsiooni protsess. Määrake omand, ülevaatuse sagedus ja hoolduskulud. Osaline automatiseerimine on toimiv, kui kaetuse piir jääb nähtavaks.

Mida peaksime järgmiseks tegema?

Valmistage ette üheleheküljeline ostulähteülesanne ja üks esinduslik tõendipakett. Paluge lühinimekirja jõudnud tarnijatel viia see pakett nõudest kuni üle vaadatud järelduseni ja seejärel muuta üht olulist lähtekirjet. Hinnake mõjutatud tööd, hindajate töömahtu, vastutust ja eksporti, mitte ainult esialgset tulemust.