ISO 27001 -sisäinen auditointi, joka parantaa järjestelmää

Sisäinen auditointi antaa organisaatiolle mahdollisuuden havaita, missä sen tietoturvallisuuden hallintajärjestelmä (ISMS) poikkeaa sen tavoitteista. Hyödyllinen tulos on perusteltu arvio ja selkeä parannuspolku jokaiselle olennaiselle havainnolle, ei pelkkä sertifiointia varten koottu kansio kuvakaappauksia.

Teknologiajohtajalle keskeinen kysymys on, toimiiko järjestelmä todellisissa palveluissa, ihmisten keskuudessa ja vastuunvaihdoissa. Politiikka voidaan hyväksyä, vaikka sen toteutus epäonnistuu. Auditoinnin tulisi paljastaa tämä ero muuttamatta jokaista operatiivista epätäydellisyyttä perusteettomaksi vaatimustenmukaisuushavainnoksi.

Määritä, mitä auditoinnin on osoitettava

ISO/IEC 27001 -standardin kohta 9.2 edellyttää sisäisiä auditointeja suunnitelluin väliajoin sen arvioimiseksi, onko ISMS organisaation omien vaatimusten ja standardin mukainen ja onko se toteutettu ja ylläpidetty vaikuttavasti. Auditointiohjelmassa on otettava huomioon prosessien merkitys ja aiempien auditointien tulokset, ja auditoijat on valittava objektiivisuuden ja puolueettomuuden varmistamiseksi.

Sisäisen auditoinnin voivat tehdä työntekijät tai tätä tarkoitusta varten hankittu ulkoinen asiantuntija. Se ei myönnä sertifikaattia: sertifiointi on riippumattoman sertifiointielimen tekemä erillinen arviointi. Sisäiset auditoinnit ovat osa ISMS:n toimintaa myös sertifioinnin jälkeen, eivät pelkkää valmistautumista ensimmäiseen arviointiin.

ISO 27001 ei määrää yleistä vuotuista sisäisen auditoinnin tiheyttä. Käytännön suosituksena käytä dokumentoitua aikataulua, joka heijastaa riskejä, muutoksia ja aiempia havaintoja, ja kiinnitä useammin huomiota epävakaisiin tai kriittisiin prosesseihin.

Sopikaa kriteereistä, rajoista ja vastuista

Yksittäisen auditoinnin ei tarvitse tarkastella kaikkea samanaikaisesti. Ohjelman tulisi kattaa rajattu ISMS suunnitellun jakson aikana sen sijaan, että tarkastettaisiin toistuvasti vain tuttuja kontrolleja.

Dokumentoi nämä päätökset ennen näytön pyytämistä:

Liite A ei ole vaatimus toteuttaa jokainen kontrolli samalla tavalla. Tarkista, ovatko sovellettavuuspäätökset ja poissulkemiset perusteltuja, ja testaa sitten ne sitoumukset, jotka organisaatio on todella tehnyt.

Valitse päteviä auditoijia, jotka ymmärtävät sekä hallintajärjestelmän vaatimukset että tarkasteltavat kontrollit. Vältä tilanteita, joissa ihmiset auditoivat omaa työtään. Pienessä kehitystiimissä ulkoinen auditoija tai toisen toiminnon tarkastaja voi ratkaista eturistiriidat, kunhan hänellä on riittävä pätevyys ja pääsy näyttöön.

Rakenna näyttö operatiivisten kysymysten ympärille

Aloita soveltamisalasta, riskiarviosta, käsittelysuunnitelmasta, soveltamisalaselvityksestä, politiikoista, aiemmista havainnoista ja asiaankuuluvista operatiivisista tallenteista. Ne kertovat, mitä pitäisi tapahtua ja missä epäonnistumisilla olisi suurin merkitys.

Muotoile sitten testattavia kysymyksiä. Pääkäyttäjäoikeuksien osalta kysy, edeltävätkö hyväksynnät pääsyä, kattavatko katselmoinnit asiaankuuluvan tilijoukon ja katoavatko mitätöidyt oikeudet todella. Allekirjoitettu käyttöoikeuspolitiikka osoittaa aikomuksen; tilivienti, hyväksymistallenteet ja poistolokit osoittavat toiminnan.

Laadi otantasuunnitelma, joka sisältää äskettäiset muutokset, kriittiset palvelut, aiemmat heikkoudet ja poikkeukset. Kirjaa perusjoukko, valintamenetelmä, ajanjakso ja perustelut. Käytännön otannassa ei tarvitse käyttää yhtä kiinteää otoskokoa, mutta sen on oltava selitettävissä. Kourallinen helposti saatavia kuvakaappauksia edustaa harvoin koko toimintajaksoa.

Vahvista tallenteet haastatteluilla ja havainnoinnilla. Jos omistajat kuvaavat manuaalisen vastuunvaihdon, tarkasta toteutuneita vastuunvaihtoja. Jos näyttö on ristiriidassa haastattelun kanssa, tutki asiaa sen sijaan, että valitsisit rauhoittavamman version. Kirjaa rajoitukset, kun järjestelmä ei pysty tuottamaan historiallista näyttöä; älä hiljaisesti päättele aiempaa toimintaa nykyisestä konfiguraatiosta.

Seuraa yhtä kontrollia esimerkin avulla

Havainnollistavat oletukset: SaaS-yritys auditoi työntekijöiden lähtöjä kolmen kuukauden ajalta. Sen menettelyn mukaan käyttöoikeudet on poistettava työntekijän lähtöhetkeen mennessä. Henkilöstöhallinnon tietojen mukaan lähtöjä on ollut 12; auditoija tarkastaa kaikki kolme pääkäyttäjää ja neljä muuta lähtöä eri tiimeistä.

Auditoija vertaa henkilöstöhallinnon lähtöaikaleimoja identiteetintarjoajan tapahtumiin, sovellustilien tilaan ja työsuhteen päättymiseen liittyviin tiketteihin. Yhden entisen kehittäjän identiteetintarjoajan tili poistettiin käytöstä ajallaan, mutta erikseen hallittu koodivaraston tili pysyi aktiivisena kaksi päivää.

Ennen havainnon luokittelua selvitä, pystyikö tilillä tunnistautumaan, mitkä oikeudet säilyivät ja oliko olemassa hyväksytty poikkeus. Haastattele henkilöstöhallintoa ja sovelluksen omistajaa vastuunvaihdon ymmärtämiseksi. Laajenna testaus muihin lähtöihin, joihin liittyy erikseen hallittuja sovelluksia, jos puute vaikuttaa järjestelmälliseltä.

Puolustettava havainto yksilöi rikotun menettelyn, havaitun tilanteen, tukevat tallenteet, vaikutusalueen ja mahdollisen seurauksen. Siinä ei pidä väittää luvatonta pääsyä tapahtuneen, ellei näyttö tue tätä johtopäätöstä.

Erota havainnot oletuksista

Poikkeama edellyttää näyttöä siitä, että vaatimus ei ole täyttynyt. Parannusmahdollisuus tunnistaa hyödyllisen kehityskohteen osoittamatta rikkomusta. Ratkaisematon kysymys pysyy avoinna, kunnes riittävä näyttö tukee johtopäätöstä.

Käytä johdonmukaisia luokituksia ja priorisoi havainnot altistumisen, toistuvuuden ja laajuuden mukaan. Älä anna vakavuusluokituksen korvata perusteluja. Anna prosessien omistajille mahdollisuus korjata tosiasiavirheet, mutta säilytä auditoijan vastuu johtopäätöksestä.

Raportissa tulisi todeta soveltamisala, kriteerit, menetelmät, rajoitukset, havainnot ja tehdyn työn tukema kokonaisarvio.

Tee korjaavista toimenpiteistä muutakin kuin sulkemista

Toimintasuunnitelmassa tulisi yksilöidä omistaja, määräpäivä, välitön korjaus, juurisyy ja muutos, jolla toistuminen on tarkoitus estää. Koodivaraston tilin poistaminen korjaa kyseisen tapauksen. Puutteellisen sovellusluettelon sekä henkilöstöhallinnon ja IT:n välisen vastuunvaihdon korjaaminen puuttuu prosessiin.

Vältä hyväksymästä ”inhimillistä virhettä” täydelliseksi juurisyyksi, kun työnkulku perustuu muistiin tai siltä puuttuu omistaja. Määritä vaikuttavuuskriteerit ennen toimenpiteen sulkemista: esimerkiksi seuraavissa lähdöissä on oltava täsmäytetyt tarkistukset asiaankuuluvaa sovellusluetteloa vasten.

Valmis tiketti todistaa toteutuksen, ei välttämättä vaikuttavuutta. Tarkasta toteutuksen jälkeen uusi otos ja säilytä varmennuksen tulos. Avaa toimenpide uudelleen, jos sama epäonnistuminen toistuu.

Vie tulokset johdolle ja arkityöhön

Raportoi toistuvat heikkoudet, myöhässä olevat toimenpiteet, resurssitarpeet ja merkittävät riskipäätökset asianomaiselle johdolle. Sisäisen auditoinnin tulokset ovat ISO 27001:n mukaisen johdon katselmuksen lähtötietoja; katselmus on erillinen toiminto, jolla on muitakin vaadittuja lähtötietoja, ei pelkkä kokous auditointiraportin hyväksymiseksi.

Secani kytkee vaatimukset, näytön, vastuuhenkilöt, tehtävät ja katselmointipäätökset toisiinsa, jotta arviointi ja jatkotoimet pysyvät samassa kontekstissa. Pidä tukevat tallenteet liitettyinä asiaankuuluviin kontrolleihin ja säilytä ihmisen hyväksyntä näyttöä koskeville johtopäätöksille. Käytä auditointivalmiutta käsittelevää opastamme näiden tallenteiden järjestämiseen ennen kenttätyötä.

Käytännön seuraava askel on valita yksi kriittinen prosessi, nimetä puolueeton auditoija ja kirjoittaa sen kriteerit ja otantasuunnitelma. Ajoita vaikuttavuuden tarkistus samalla kun korjaavat toimenpiteet osoitetaan, ei vasta sen jälkeen, kun kaikki pitävät niitä valmiina.