ISO 27001:2022 -auditoinnin epäonnistumisen korjaussuunnitelma

Sähköposti, jota kukaan ei halunnut saada

Sähköposti saapuu myöhään perjantaina otsikolla, joka kuulostaa harmittomalta: ”Siirtymäauditoinnin tulos.”

Sisältö ei ole harmiton. Sertifiointielin on kirjannut merkittävän poikkeaman. ISO/IEC 27001 -sertifikaatti on keskeytetty tai siirtymäpäätöstä ei voida sulkea. Auditoijan huomautus on suora: soveltuvuuslausunto ei perustele pois rajattuja kontrolleja, riskien arviointi ei vastaa nykyistä toimintaympäristöä, eikä riittävää näyttöä ole siitä, että uudet sääntelyvelvoitteet on huomioitu.

Tunnin sisällä kyse ei ole enää vain vaatimustenmukaisuusongelmasta. Myynti kysyy, onko julkisen sektorin tarjouskilpailu nyt vaarassa. Lakitoiminto käy läpi asiakassopimusten lausekkeita. Tietoturvajohtaja selittää, miksi SoA ei täsmää riskienkäsittelysuunnitelman kanssa. Toimitusjohtaja kysyy ainoan ratkaisevan kysymyksen: ”Kuinka nopeasti tämä voidaan korjata?”

Monille organisaatioille ISO 27001:2022 -siirtymän määräajan umpeutuminen ei luonut teoreettista aukkoa. Se loi todellisen liiketoiminnan jatkuvuusongelman. Tekemättä jäänyt tai epäonnistunut ISO 27001:2022 -siirtymäauditointi voi vaikuttaa tarjouskelpoisuuteen, toimittajien käyttöönottoon, kybervakuutukseen, asiakkaiden varmentamiseen, NIS2-valmiuteen, DORA-odotuksiin, GDPR:n mukaiseen osoitusvelvollisuuteen ja hallituksen luottamukseen.

Hyvä uutinen on, että tilanne voidaan korjata. Huono uutinen on, että asiakirjojen kosmeettinen siistiminen ei riitä. Korjaaminen on käsiteltävä kurinalaisena ISMS:n korjaavien toimenpiteiden ohjelmana, ei kiireellisenä politiikkojen uudelleenkirjoituksena.

Clarysecissä organisoimme korjaustyön kolmen toisiinsa liittyvän omaisuuserän ympärille:

1. Zenith Blueprint: auditoijan 30-vaiheinen tiekartta, erityisesti Audit, Review & Improvement -vaihe.
2. Clarysecin suuryrityksille ja pk-yrityksille tarkoitettu politiikkakirjasto, joka muuttaa auditointihavainnot hallituiksi velvoitteiksi.
3. Zenith Controls: vaatimustenmukaisuuden ristiinkartoitusopas, joka auttaa yhdistämään ISO/IEC 27002:2022 -kontrolliodotukset NIS2:een, DORAan, GDPR:ään, NIST-tyyppiseen varmentamisajatteluun ja COBIT 2019 -hallintanäkökulmiin.

Tämä on käytännön korjaussuunnitelma tietoturvajohtajille, vaatimustenmukaisuuspäälliköille, auditoijille, perustajille ja liiketoimintavastaaville, jotka eivät ehtineet ISO 27001:2022 -siirtymän määräaikaan tai joiden siirtymäauditointi epäonnistui.

Tunnista ensin epäonnistumisen tyyppi

Ennen kuin yhtäkään politiikkaa muokataan, tilanne tulee luokitella. Kaikilla epäonnistuneilla tai väliin jääneillä siirtymillä ei ole samaa liiketoimintavaikutusta tai korjauspolkua. Ensimmäisten 24 tunnin aikana tulee keskittyä auditointiraportin, sertifiointielimen päätöksen, poikkeaman sanamuodon, näyttöpyyntöjen, määräaikojen ja sertifikaatin nykyisen tilan hankkimiseen.

Korjaussuunnitelma riippuu epäonnistumisen tyypistä. Lykkääntynyt sertifiointipäätös edellyttää kohdennettuja korjaavia toimenpiteitä. Keskeytetty sertifikaatti edellyttää kiireellistä hallinnon ja näytön korjaamista. Peruutettu tai vanhentunut sertifikaatti voi edellyttää laajempaa uudelleensertifiointipolkua.

Jokainen havainto tulee kaikissa tapauksissa kartoittaa asiaankuuluvaan ISMS-lausekkeeseen, liite A -kontrolliin, riskitietueeseen, politiikan omistajaan, lakisääteiseen tai sopimusperusteiseen velvoitteeseen ja näytön lähteeseen.

Tässä kohtaa ISO/IEC 27001:2022 on merkityksellinen hallintajärjestelmänä, ei pelkkänä kontrolliluettelona. Lausekkeet 4–10 edellyttävät, että ISMS ymmärtää toimintaympäristön, sidosryhmät, soveltamisalan, johtajuuden, riskisuunnittelun, tuen, toiminnan, suorituskyvyn arvioinnin ja jatkuvan parantamisen. Jos siirtymä epäonnistui, jokin näistä hallintajärjestelmän yhteyksistä on yleensä katkennut.

Miksi ISO 27001:2022 -siirtymäauditoinnit epäonnistuvat

Epäonnistuneet siirtymäauditoinnit keskittyvät yleensä toistuviin malleihin. Monet niistä eivät ole syvästi teknisiä. Ne ovat hallintoon, jäljitettävyyteen, omistajuuteen ja näyttöön liittyviä epäonnistumisia.

Epäonnistunut auditointi on signaali siitä, ettei ISMS mukautunut riittävän nopeasti organisaation todelliseen toimintaympäristöön.

ISO/IEC 27005:2022 on hyödyllinen korjaamisessa, koska se vahvistaa toimintaympäristön määrittämisen merkitystä lakisääteisten, sääntelyyn perustuvien, toimialakohtaisten, sopimusperusteisten, sisäisten ja olemassa olevien kontrollivaatimusten avulla. Se tukee myös riskikriteerejä, joissa huomioidaan lakisääteiset velvoitteet, toimittajat, tietosuoja, inhimilliset tekijät, liiketoimintatavoitteet ja johdon hyväksymä riskinottohalukkuus.

Käytännössä siirtymän korjaaminen alkaa päivitetystä toimintaympäristöstä ja riskikriteereistä, ei vanhan asiakirjan uudesta versionumerosta.

Vaihe 1: Jäädytä auditointitallenne ja perusta korjaustyön johtokeskus

Ensimmäinen operatiivinen virhe epäonnistuneen auditoinnin jälkeen on näyttökaaos. Tiimit alkavat etsiä sähköposteista, jaetuista asemista, tikettijärjestelmistä, chat-viesteistä, henkilökohtaisista kansioista ja vanhoista auditointipaketeista. Auditoijat tulkitsevat tämän merkiksi siitä, ettei ISMS ole hallinnassa.

Clarysecin pk-yrityksille suunnattu Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka - pk-yritys on täsmällinen näytön hallinnasta:

”Kaikki näyttö on säilytettävä keskitetyssä auditointikansiossa.”

Kohdasta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.2.1.

Tästä keskitetystä auditointikansiosta tulee korjaustyön ohjaamo. Sen tulee sisältää:

• Sertifiointielimen raportti ja kirjeenvaihto.
• Sertifikaatin tilan vahvistus.
• Poikkeamarekisteri.
• CAPA-loki.
• Päivitetty riskien arviointi.
• Päivitetty riskienkäsittelysuunnitelma.
• Päivitetty soveltuvuuslausunto.
• Sisäisen auditoinnin raportti.
• Johdon katselmoinnin pöytäkirjat.
• Politiikkojen hyväksyntätallenteet.
• Näyttö jokaisesta soveltuvasta liite A -kontrollista.
• Asiakasvarmennuspaketti, jos kaupalliset sitoumukset ovat vaikutuspiirissä.

Suuryritysympäristöissä Clarysecin Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka asettaa saman hallinto-odotuksen:

”Kaikista havainnoista on laadittava dokumentoitu CAPA, joka sisältää:”

Kohdasta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.2.1.

Sanamuoto luo odotuksen rakenteisista korjaavista toimenpiteistä. Keskeinen asia on yksinkertainen: jokaisesta auditointihavainnosta on tultava hallittu CAPA-kohde, ei epävirallinen tehtävä jonkun muistivihossa.

Pk-yrityksissä johdon osallistuminen on yhtä tärkeää:

”Toimitusjohtajan (GM) on hyväksyttävä korjaavien toimenpiteiden suunnitelma ja seurattava sen toteutusta.”

Lähde: Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka - pk-yritys, kohta ”Hallintovaatimukset”, politiikan lauseke 5.4.2.

Tämä on tärkeää, koska ISO 27001:2022 ei käsittele johtajuutta symbolisena. Ylimmän johdon tulee määrittää politiikka, yhdenmukaistaa tavoitteet liiketoimintastrategian kanssa, tarjota resurssit, viestiä tietoturvallisuuden merkityksestä, osoittaa vastuut ja edistää jatkuvaa parantamista.

Jos epäonnistunut siirtymä käsitellään ”vaatimustenmukaisuudesta vastaavan henkilön ongelmana”, seuraava auditointi paljastaa jälleen heikon johdon vastuun.

Vaihe 2: Rakenna toimintaympäristö, velvoitteet ja riskit uudelleen

Epäonnistunut siirtymäauditointi tarkoittaa usein, ettei ISMS:n toimintaympäristö enää vastaa organisaation todellisuutta. Liiketoiminta on voinut siirtyä pilvialustoihin, lisätä uusia toimittajia, siirtyä säännellyille markkinoille, käsitellä enemmän henkilötietoja tai tulla asiakkaille merkitykselliseksi NIS2:n tai DORA:n perusteella. Jos nämä muutokset puuttuvat ISMS:stä, riskien arviointi ja SoA jäävät puutteellisiksi.

Clarysecin Laki- ja sääntelyvaatimusten noudattamisen politiikka asettaa perustason:

”Kaikki lakisääteiset ja sääntelyyn perustuvat velvoitteet on kartoitettava tiettyihin politiikkoihin, kontrolleihin ja omistajiin tietoturvallisuuden hallintajärjestelmässä (ISMS).”

Kohdasta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.2.1.

Tämä lauseke on kriittinen siirtymäepäonnistumisen jälkeen. ISO 27001:2022 -lausekkeet 4.1–4.3 edellyttävät, että organisaatiot huomioivat sisäiset ja ulkoiset asiat, sidosryhmät, vaatimukset, rajapinnat, riippuvuudet ja soveltamisalan. Lakisääteiset, sääntelyyn perustuvat ja sopimusperusteiset velvoitteet eivät ole sivuhuomautuksia. Ne muovaavat ISMS:ää.

NIS2 Article 21 edellyttää asianmukaisia ja oikeasuhtaisia teknisiä, operatiivisia ja organisatorisia toimenpiteitä, mukaan lukien riskianalyysi, politiikat, poikkeamien käsittely, varmuuskopiointi, katastrofipalautus, kriisinhallinta, toimitusketjun turvallisuus, turvallinen kehittäminen, haavoittuvuuksien käsittely, vaikuttavuuden arvioinnit, kyberhygienia, koulutus, kryptografia, henkilöstöturvallisuus, pääsynhallinta, omaisuudenhallinta ja turvallinen viestintä. Article 20 asettaa vastuun johdon tasolle. Article 23 luo vaiheistetun merkittävien poikkeamien raportoinnin, mukaan lukien ennakkovaroituksen, poikkeamailmoituksen, päivitykset ja loppuraportoinnin.

DORA soveltuu suoraan finanssialan toimijoihin 17. tammikuuta 2025 alkaen ja kattaa ICT-riskien hallinnan, merkittävien poikkeamien raportoinnin, häiriönsietokyvyn testauksen, ICT-kolmannen osapuolen riskin, sopimusvaatimukset ja kriittisten ICT-kolmannen osapuolen palveluntarjoajien valvonnan. Soveltamisalaan kuuluville finanssialan toimijoille DORAsta tulee ICT-hallinnon, toimittajakontrollien, testauksen, poikkeamien luokittelun ja johdon vastuun keskeinen ohjuri.

GDPR lisää osoitusvelvollisuuden henkilötietojen osalta. Article 5 edellyttää lainmukaista, kohtuullista, läpinäkyvää, rajattua, täsmällistä, säilytysajat huomioivaa ja turvallista käsittelyä sekä todennettavaa vaatimustenmukaisuutta. Article 4 määrittelee henkilötietojen tietoturvaloukkauksen tavalla, joka vaikuttaa suoraan poikkeamien luokitteluun. Article 6 edellyttää käsittelyn oikeusperusteen kartoittamista, ja Article 9 lisää erityisiin henkilötietoryhmiin kohdistuvia korotettuja vaatimuksia.

Tämä ei tarkoita erillisten vaatimustenmukaisuusmaailmojen rakentamista. Se tarkoittaa ISO 27001:2022:n käyttämistä integroituna hallintajärjestelmänä ja velvoitteiden kartoittamista yhteen riski- ja kontrolliarkkitehtuuriin.

Clarysecin Riskienhallintapolitiikka yhdistää riskien käsittelyn suoraan kontrollien valintaan:

”Riskien käsittelyprosessista seuraavien kontrollipäätösten on heijastuttava SoA:ssa.”

Kohdasta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.5.1.

Epäonnistunut auditointi on myös peruste katselmoida itse riskienhallintaprosessi. Clarysecin pk-yritysten Riskienhallintapolitiikka - pk-yritys tunnistaa tämän herätteen:

”Merkittävä poikkeama tai auditointihavainto paljastaa puutteita riskienhallinnassa”

Kohdasta ”Katselmointi- ja päivitysvaatimukset”, politiikan lauseke 9.2.1.1.

Korjaustilassa tämä tarkoittaa, että riskirekisteri, riskikriteerit, riskienkäsittelysuunnitelma ja SoA on rakennettava uudelleen yhdessä.

Vaihe 3: Korjaa SoA jäljitettävyyden selkärangaksi

Useimmissa epäonnistuneissa siirtymissä soveltuvuuslausunto on ensimmäinen tarkastettava asiakirja. Se on myös yksi ensimmäisistä asiakirjoista, joista auditoijat ottavat otoksia. Heikko SoA kertoo auditoijalle, ettei kontrollien valinta ole riskiperusteista.

Zenith Blueprint antaa käytännön ohjeen Audit, Review & Improvement -vaiheessa, vaiheessa 24, Audit, Review & Improvement:

”SoA:n tulee olla yhdenmukainen riskirekisterin ja riskienkäsittelysuunnitelman kanssa. Tarkista, että jokainen riskien käsittelyksi valittu kontrolli on merkitty SoA:ssa ’soveltuvaksi’. Vastaavasti, jos kontrolli on merkitty SoA:ssa ’soveltuvaksi’, sille tulee olla peruste – yleensä kartoitettu riski, lakisääteinen tai sääntelyyn perustuva vaatimus tai liiketoimintatarve.”

Lähde: Zenith Blueprint: auditoijan 30-vaiheinen tiekartta, Audit, Review & Improvement -vaihe, vaihe 24.

Tämä on korjaamisen periaate. SoA ei ole muodollisuus. Se on jäljitettävyyden selkäranka riskien, velvoitteiden, kontrollien, toteutusnäytön ja auditointipäätelmien välillä.

Käytännön SoA-korjauksen tulee edetä seuraavassa järjestyksessä:

1. Vie nykyinen SoA.
2. Lisää sarakkeet riskitunnisteelle, sääntelyvelvoitteelle, liiketoimintavaatimukselle, politiikkaviittaukselle, näytön sijainnille, omistajalle, toteutuksen tilalle ja viimeisimmälle testauspäivälle.
3. Kartoita jokaiselle soveltuvalle kontrollille vähintään yksi puolustettava peruste.
4. Kirjoita jokaiselle pois rajatulle kontrollille täsmällinen poissulkemisperuste.
5. Täsmäytä SoA riskienkäsittelysuunnitelman kanssa.
6. Täsmäytä SoA sisäisen auditoinnin tulosten kanssa.
7. Esitä vaikea kysymys: jos auditoija ottaa tästä rivistä otoksen, voimmeko todentaa sen viidessä minuutissa?

Puolustettavan SoA-rivin tulee näyttää tältä:

Tämä rivi kertoo korjaustarinan. Se osoittaa liiketoimintaympäristön, riskilogiikan, sääntelyrelevanssin, omistajuuden, toteutuksen, testauksen ja jäljellä olevan toimenpiteen.

Sama kurinalaisuus koskee poissulkemisia. Jos organisaatio ei esimerkiksi tee lainkaan sisäistä ohjelmistokehitystä, ISO/IEC 27002:2022 control 8.25 Secure development life cycle ja control 8.28 Secure coding -kontrollien poissulkeminen voi olla puolustettavissa, mutta vain jos se on totta, dokumentoitu ja sitä tukee näyttö siitä, että ohjelmisto on valmis kaupallinen ohjelmisto tai kokonaan ulkoistettu siten, että toimittajakontrollit ovat käytössä.

Vaihe 4: Tee juurisyyanalyysi, älä asiakirjakosmetiikkaa

Epäonnistunut siirtymäauditointi johtuu harvoin yhdestä puuttuvasta tiedostosta. Yleensä syynä on rikkoutunut prosessi.

Zenith Blueprint, Audit, Review & Improvement -vaihe, vaihe 27, Audit Findings - Analysis & Root Cause, toteaa:

”Mieti jokaisen tunnistetun poikkeaman (merkittävän tai vähäisen) osalta, miksi se tapahtui – tämä on ratkaisevan tärkeää tehokkaan korjauksen kannalta.”

Lähde: Zenith Blueprint, Audit, Review & Improvement -vaihe, vaihe 27.

Jos havainto kuuluu ”SoA-perustelut puuttuvat”, korjaus voi olla SoA:n päivittäminen. Juurisyy voi kuitenkin olla, etteivät omaisuuserien omistajat osallistuneet riskien arviointiin, lakisääteisiä velvoitteita ei kartoitettu tai vaatimustenmukaisuustiimi ylläpiti SoA:ta erillään muusta toiminnasta.

Hyödyllinen korjaustaulukko erottaa heikot korjaukset todellisista korjaavista toimenpiteistä:

Tässä uskottavuus palautuu. Auditoijat eivät odota täydellisyyttä. He odottavat hallittua järjestelmää, joka havaitsee, korjaa, oppii ja parantaa.

Vaihe 5: Rakenna CAPA, johon auditoija voi luottaa

Korjaavat ja ennaltaehkäisevät toimenpiteet ovat kohta, jossa monet organisaatiot saavat tilanteen takaisin hallintaan. CAPA-rekisteristä tulee korjaustyön tiekartta ja keskeinen näyttö siitä, että epäonnistunut auditointi käsiteltiin järjestelmällisesti.

Zenith Blueprint, Audit, Review & Improvement -vaihe, vaihe 29, Jatkuva parantaminen, selittää rakenteen:

”Varmista, että jokainen korjaava toimenpide on täsmällinen, kohdistettavissa vastuuhenkilölle ja aikarajattu. Käytännössä luot jokaisesta ongelmasta miniprojektin.”

Lähde: Zenith Blueprint, Audit, Review & Improvement -vaihe, vaihe 29.

CAPA-lokin tulee sisältää:

• Havaintotunniste.
• Lähdeauditointi.
• Lauseke- tai kontrolliviittaus.
• Vakavuus.
• Ongelman kuvaus.
• Välitön korjaus.
• Juurisyy.
• Korjaava toimenpide.
• Ennaltaehkäisevä toimenpide, kun se on tarpeen.
• Omistaja.
• Määräpäivä.
• Vaadittava näyttö.
• Tila.
• Vaikuttavuuden tarkastus.
• Johdon hyväksyntä.

Clarysecin Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka - pk-yritys tunnistaa myös merkittävän poikkeaman katselmointiherätteeksi:

”Sertifiointiauditointi tai valvontaauditointi johtaa merkittävään poikkeamaan”

Kohdasta ”Katselmointi- ja päivitysvaatimukset”, politiikan lauseke 9.2.2.

Jos siirtymäauditointi tuotti merkittävän poikkeaman, katselmoi myös auditointi- ja vaatimustenmukaisuuden seurantaprosessi. Miksi sisäinen auditointi ei havainnut ongelmaa ensin? Miksi johdon katselmointi ei eskaloinut sitä? Miksi SoA ei paljastanut näyttöaukkoa?

Näin epäonnistuneesta auditoinnista tulee vahvempi ISMS.

Vaihe 6: Käytä Zenith Controlsia ISO-näytön ristiinkartoittamiseen eri vaatimuksiin

Uusinta-auditointi ei tapahdu tyhjiössä. Asiakkaat, viranomaiset, vakuuttajat ja sisäiset hallintotiimit voivat kaikki tarkastella samaa näyttöä eri näkökulmista. Tässä Zenith Controls on arvokas vaatimustenmukaisuuden ristiinkartoitusopas. Se auttaa tiimejä lopettamaan ISO 27001:n, NIS2:n, DORA:n, GDPR:n, NIST-tyyppisen varmentamisen ja COBIT 2019 -hallinnon käsittelyn erillisinä tarkistuslistoina.

Kolme ISO/IEC 27002:2022 -kontrollia on erityisen olennaisia siirtymän korjaamisessa.

Zenith Controlsissa ISO/IEC 27002:2022 control 5.31 yhdistetään suoraan yksityisyyteen ja PII-tietoihin:

”5.34 kattaa tietosuojalainsäädännön (esim. GDPR) noudattamisen, joka on yksi 5.31:n mukaisista lakisääteisten vaatimusten luokista.”

Lähde: Zenith Controls, control 5.31, yhteydet muihin kontrolleihin.

Korjaustilanteessa tämä tarkoittaa, ettei lakirekisteri saa sijaita ISMS:n ulkopuolella. Sen on ohjattava SoA:ta, riskienkäsittelysuunnitelmaa, politiikkakokonaisuutta, kontrollien omistajuutta ja auditointinäyttöä.

ISO/IEC 27002:2022 control 5.35:n osalta Zenith Controls korostaa, että riippumaton katselmointi ulottuu usein operatiiviseen näyttöön:

”5.35:n mukaiset riippumattomat katselmoinnit arvioivat usein lokituksen ja seurannan riittävyyttä.”

Lähde: Zenith Controls, control 5.35, yhteydet muihin kontrolleihin.

Tämä on käytännöllistä. Auditoija voi aloittaa hallinnosta ja ottaa sen jälkeen otoksia lokeista, hälytyksistä, seurantatallenteista, käyttöoikeuskatselmoinneista, poikkeamatiketeistä, varmuuskopiointitesteistä, toimittajakatselmoinneista ja johdon päätöksistä.

ISO/IEC 27002:2022 control 5.36:n osalta Zenith Controls selittää suhteen sisäiseen politiikkahallintaan:

”Control 5.36 toimii 5.1:n mukaisesti määriteltyjen sääntöjen soveltamismekanismina.”

Lähde: Zenith Controls, control 5.36, yhteydet muihin kontrolleihin.

Tässä monet siirtymäohjelmat epäonnistuvat. Politiikat ovat olemassa, mutta niiden noudattamista ei seurata. Menettelyt ovat olemassa, mutta poikkeuksia ei kirjata. Kontrollit ilmoitetaan, mutta niitä ei testata.

Vaihe 7: Valmistaudu erilaisiin auditointinäkökulmiin

Vahvan korjauspaketin tulee kestää useamman kuin yhden auditoijan näkökulma. ISO-sertifiointiauditoijat, DORA-valvojat, NIS2-arvioijat, GDPR-sidosryhmät, asiakkaiden varmentamistiimit, NIST-suuntautuneet arvioijat ja COBIT 2019 -hallintokatselmoijat voivat kysyä erilaisia kysymyksiä samasta näytöstä.

Tavoitteena ei ole näytön monistaminen. Yksi SoA-rivi lokituksesta ja seurannasta voi tukea ISO-näyttöä, NIST-tyyppisiä havaitsemisodotuksia, DORA:n poikkeamien käsittelyä, NIS2:n vaikuttavuusarviointia ja GDPR:n loukkausten havaitsemista. Yksi toimittajariskitiedosto voi tukea ISO:n toimittajakontrolleja, DORA:n ICT-kolmannen osapuolen riskiä, NIS2:n toimitusketjun turvallisuutta ja GDPR:n käsittelijän osoitusvelvollisuutta.

Tämä on ristiin sovellettavan vaatimustenmukaisuuden käytännön arvo.

Vaihe 8: Suorita lopullinen dokumentaatiokatselmointi ja koeauditointi

Ennen paluuta sertifiointielimen luo suorita tiukka sisäinen haastaminen. Zenith Blueprint, Audit, Review & Improvement -vaihe, vaihe 30, Certification Preparation - Final Review & Mock Audit, suosittelee tarkistamaan ISO 27001:2022 -lausekkeet 4–10 yksi kerrallaan ja validoimaan näytön jokaisesta soveltuvasta liite A -kontrollista.

Se neuvoo:

”Tarkista liite A -kontrollit: varmista, että sinulla on jotakin esitettävää jokaisesta kontrollista, jonka merkitsit SoA:ssa ’soveltuvaksi’.”

Lähde: Zenith Blueprint, Audit, Review & Improvement -vaihe, vaihe 30.

Lopullisen katselmoinnin tulee olla suora:

• Voidaanko jokainen soveltuva kontrolli selittää?
• Voidaanko jokainen pois rajattu kontrolli perustella?
• Voidaanko jäännösriskin hyväksyntä osoittaa?
• Katselmoiko johto siirtymän epäonnistumisen, resurssit, tavoitteet, auditointitulokset ja korjaavat toimenpiteet?
• Testasiko sisäinen auditointi päivitetyn SoA:n ja riskienkäsittelysuunnitelman?
• Onko toimittaja-, pilvi-, jatkuvuus-, poikkeama-, tietosuoja-, pääsy-, haavoittuvuus-, lokitus- ja seurantakontrolleista näyttö?
• Ovatko politiikat hyväksyttyjä, ajantasaisia, viestittyjä ja versiohallittuja?
• Onko CAPA-toimet yhdistetty juurisyihin ja vaikuttavuuden tarkastuksiin?
• Löytyykö näyttö nopeasti keskitetystä auditointikansiosta?

Clarysecin Tietoturvapolitiikka antaa hallinnon perustason:

”Organisaation on toteutettava ja ylläpidettävä tietoturvallisuuden hallintajärjestelmää (ISMS) ISO/IEC 27001:2022 -lausekkeiden 4–10 mukaisesti.”

Kohdasta ”Politiikan toteutusvaatimukset”, politiikan lauseke 6.1.1.

Pk-yrityksissä katselmoinnin on myös seurattava sertifiointivaatimuksia ja sääntelymuutoksia. Clarysecin Tietoturvapolitiikka - pk-yritys toteaa:

”Toimitusjohtajan (GM) on katselmoitava tämä politiikka vähintään vuosittain sen varmistamiseksi, että ISO/IEC 27001 -sertifiointivaatimusten, sääntelymuutosten (kuten GDPR, NIS2 ja DORA) sekä muuttuvien liiketoimintatarpeiden noudattaminen jatkuu.”

Kohdasta ”Katselmointi- ja päivitysvaatimukset”, politiikan lauseke 9.1.1.

Juuri tämän monet siirtymäohjelmat ohittivat: ISO, sääntely ja liiketoiminnan muutos liikkuvat yhdessä.

Mitä asiakkaille kerrotaan korjaustyön aikana

Jos epäonnistunut tai tekemättä jäänyt siirtymä vaikuttaa asiakassopimuksiin, hiljaisuus on vaarallista. Kaikkia sisäisen auditoinnin yksityiskohtia ei tarvitse paljastaa, mutta hallittua varmistavaa tietoa tulee antaa.

Asiakasviestintäpaketin tulee sisältää:

• Sertifiointielimen vahvistama nykyinen sertifiointitila.
• Siirtymäauditoinnin tila ja ylätason korjaussuunnitelma.
• Vahvistus siitä, että CAPA-prosessi on aktiivinen ja johdon hyväksymä.
• Korjaavien toimenpiteiden ja auditoinnin sulkemisen tavoitepäivät.
• Lausuma siitä, että ISMS toimii edelleen.
• Tietoturvavarmennuksen yhteyspiste.
• Päivitetty tietoturvapolitiikan lausuma, jos se on tarkoituksenmukaista.
• Näyttö korvaavista kontrolleista korkean riskin alueilla.

Vältä epämääräisiä väitteitä, kuten ”olemme täysin vaatimustenmukaisia”, kun auditointi on ratkaisematta. Kerro se, mikä on totta: ISMS toimii, korjaavat toimenpiteet on hyväksytty, näyttöä kootaan ja sulkukatselmointi tai uusinta-auditointi on aikataulutettu.

Tämä on erityisen tärkeää, jos asiakkaat tukeutuvat teihin toimittajana NIS2:n kannalta merkityksellisillä sektoreilla, kuten digitaalisessa infrastruktuurissa, pilvessä, datakeskuksissa, sisällönjakeluverkoissa, DNS-palveluissa, luottamuspalveluissa, julkisissa sähköisissä viestintäpalveluissa, hallinnoiduissa palveluissa tai hallinnoiduissa tietoturvapalveluissa. Jos auditointitilanne vaikuttaa heidän toimitusketjuriskiinsä, he tarvitsevat uskottavaa varmistusta.

Käytännön 10 päivän korjaussprintti

Aikataulut vaihtelevat sertifiointielimen, vakavuuden, soveltamisalan ja näytön kypsyyden mukaan. Korjausjärjestys on kuitenkin luotettava.

Älä toimita vastausta ennen kuin se kertoo johdonmukaisen tarinan. Auditoijan tulee pystyä seuraamaan ketjua havainnosta juurisyyhyn, juurisyystä korjaavaan toimenpiteeseen, korjaavasta toimenpiteestä näyttöön ja näytöstä johdon katselmointiin.

Clarysecin korjaustyönkulku

Kun Clarysec tukee tekemättä jäänyttä tai epäonnistunutta ISO 27001:2022 -siirtymää, organisoimme työn kohdennetuksi korjaustyönkuluksi.

Kyse ei ole paperityön tuottamisesta. Kyse on luottamuksen palauttamisesta siihen, että ISMS on hallittu, riskiperusteinen, näytöllä tuettu ja paraneva.

Lopullinen neuvo: käsittele epäonnistunut siirtymä stressitestinä

Tekemättä jäänyt ISO 27001:2022 -siirtymän määräaika tai epäonnistunut siirtymäauditointi tuntuu kriisiltä, mutta se on myös diagnostinen mahdollisuus. Se osoittaa, pystyykö ISMS ottamaan vastaan muutoksia, integroimaan lakisääteiset velvoitteet, hallitsemaan toimittajia, todentamaan kontrollien toiminnan ja oppimaan epäonnistumisesta.

Nopeimmin tilanteen korjaavat organisaatiot tekevät kolme asiaa hyvin:

1. Ne keskittävät näytön ja pysäyttävät kaaoksen.
2. Ne rakentavat uudelleen jäljitettävyyden riskien, SoA:n, kontrollien, politiikkojen ja velvoitteiden välille.
3. Ne käsittelevät auditointihavainnot kurinalaisen CAPA:n ja johdon katselmoinnin kautta.

Vaikeuksiin joutuvat organisaatiot yrittävät ratkaista ongelman muokkaamalla asiakirjoja korjaamatta omistajuutta, seurantaa, näyttöä tai juurisyytä.

Jos määräaika jäi väliin tai siirtymäauditointi epäonnistui, seuraava askel ei ole paniikki. Se on rakenteinen korjaaminen.

Clarysec voi auttaa siirtymäauditoinnin ensiarvioinnissa, SoA:n uudelleenrakentamisessa, NIS2-, DORA-, GDPR-, NIST-tyyppisten ja COBIT 2019 -odotusten kartoittamisessa Zenith Controlsin avulla, korjaavien toimenpiteiden toteuttamisessa Zenith Blueprintin avulla sekä politiikkanäytön yhdenmukaistamisessa Tietoturvapolitiikan, Auditointi- ja vaatimustenmukaisuuden seurantapolitiikan, Riskienhallintapolitiikan ja Laki- ja sääntelyvaatimusten noudattamisen politiikan avulla.

Sertifikaattiongelma voidaan korjata. ISMS voi vahvistua auditointia edeltänyttä tilaa paremmaksi. Jos siirtymäauditointisi on ratkaisematta, käynnistä korjausarviointi nyt, kokoa näyttö yhteen ja valmistele uusinta-auditointipaketti, joka osoittaa, ettei ISMS ole vain dokumentoitu vaan toimii käytännössä.