Liiketoimintavaikutusten arviointi ISO 27001-, NIS2- ja DORA-vaatimuksia varten

Auditointikysymys, joka paljastaa todellisen jatkuvuuspuutteen

On maanantaiaamu, ja nopeasti kasvavan fintech-yhtiön tietoturvajohtaja Maria valmistautuu hallituksen riskivaliokunnan kokoukseen. Esityslistalla on lyhyt kohta: ”DORA- ja NIS2-valmius: BIA-katselmointi.”

Hänen tiiminsä on koonnut sen, mitä useimmat johtajat odottavat näkevänsä. Organisaatiolla on sertifioitu ISO/IEC 27001:2022 -tietoturvallisuuden hallintajärjestelmä (ISMS), tietoturvapoikkeamiin reagoinnin toimintamallit, kuvakaappauksia varmuuskopioinneista, haavoittuvuusraportteja, toimittajakyselyjä, pilviarkkitehtuurikaavioita ja päivitetty riskirekisteri. Yritysasiakkaat lähettävät NIS2-kyselyjä. Rahoitussektorin asiakkaat lisäävät DORA-lausekkeita sopimuksiin. ISO/IEC 27001:2022 -seuranta-auditointiin on vain kuukausi.

Sitten ulkoinen auditoija esittää kysymyksen, joka muuttaa huoneen tunnelman:

”Jos asiakkaiden käyttöönottoalusta on poissa käytöstä 18 tuntia, mihin säänneltyihin palveluihin se vaikuttaa, mitkä toimittajat ovat mukana, mikä on hyväksytty palautusprioriteetti ja missä on näyttö siitä, että liiketoiminta on hyväksynyt RTO:n ja RPO:n?”

Huone hiljenee.

Varmuuskopiointiaikataulu sanoo yhtä. Katastrofipalautussuunnitelma sanoo toista. Toimittajasopimuksessa on saatavuutta koskeva SLA, mutta ei näyttöä palautustestauksesta. Riskirekisterissä mainitaan saatavuus, mutta se ei selitä, miksi yhden palvelun on palauduttava toista nopeammin. Johto on hyväksynyt tietoturvapolitiikan, mutta ei käyttökatkon liiketoimintavaikutusta.

Tämä on liiketoimintavaikutusten arvioinnin ongelma vuonna 2026.

Liiketoimintavaikutusten arviointi eli BIA ei ole enää jatkuvuussuunnitelman liitteenä oleva taulukko. Se on näyttösilta liiketoimintapalvelujen, ICT-omaisuuserien, toimittajien, palautusprioriteettien, RTO/RPO-tavoitteiden, poikkeamakynnysten, häiriönsietokyvyn testauksen ja hallituksen vastuun välillä. Organisaatioille, jotka yhdenmukaistavat ISO/IEC 27001:2022 -standardia NIS2:n jatkuvuusvaatimusten ja DORA:n ICT-häiriönsietokyvyn kanssa, BIA on kohta, jossa vaatimustenmukaisuus muuttuu operatiiviseksi toiminnaksi.

Vahvimmilla organisaatioilla on jo monet oikeat kontrollit. Niiden heikkous on jäljitettävyys. BIA muuttaa hajallaan olevan näytön auditointivalmiiksi kertomukseksi: mikä on tärkeää, miksi se on tärkeää, kuinka nopeasti sen on palauduttava, mitkä riippuvuudet sitä tukevat, mitä on testattu, mikä epäonnistui, mitä parannettiin ja kuka hyväksyi jäännösriskin.

Miksi vanhat BIA-taulukot ovat nyt riski

NIS2 ja DORA muuttivat jatkuvuuden vaatimustenmukaisuuden sävyä. Ne eivät käsittele liiketoiminnan jatkuvuutta, katastrofipalautusta, tietoturvapoikkeamiin reagointia, toimittajien häiriönsietokykyä ja hallinnointia erillisinä asiakirjoina. Niiden odotetaan toimivan yhtenä järjestelmänä.

NIS2-toimijoille Article 21 edellyttää teknisiä, operatiivisia ja organisatorisia toimenpiteitä verkko- ja tietojärjestelmiin kohdistuvien riskien hallitsemiseksi sekä poikkeamien vaikutusten estämiseksi tai minimoimiseksi palvelujen vastaanottajille ja muille palveluille. Vähimmäistoimenpiteisiin kuuluvat riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus mukaan lukien varmuuskopioinnin hallinta, katastrofipalautus ja kriisinhallinta, toimitusketjun turvallisuus, haavoittuvuuksien käsittely, kontrollien tehokkuuden arviointi, koulutus, kryptografia, henkilöstöturvallisuus, pääsynhallinta, omaisuudenhallinta, MFA ja turvallinen viestintä.

NIS2 Article 20 nostaa asian hallitustasolle. Johtoelinten on hyväksyttävä kyberturvallisuusriskien hallintatoimenpiteet, valvottava niiden toteutusta ja ne voidaan asettaa vastuuseen rikkomuksista. Tämä tarkoittaa, että vailla näyttöä oleva neljän tunnin RTO ei ole vain tekninen epäjohdonmukaisuus. Se on hallinnointiin liittyvä heikkous.

DORA:a sovelletaan 17. tammikuuta 2025 alkaen, ja se luo yhtenäisen EU-kehyksen ICT-riskien hallinnalle, poikkeamaraportoinnille, digitaalisen operatiivisen häiriönsietokyvyn testaukselle, ICT-kolmannen osapuolen riskienhallinnalle, sopimusvaatimuksille ja kriittisten ICT-kolmannen osapuolen palveluntarjoajien valvonnalle. Rahoitusalan toimijoille ja niitä sopimusten perusteella tukeville teknologiatoimittajille DORA muuttaa operatiivisen häiriönsietokyvyn rakenteiseksi näyttövaatimukseksi.

DORA Articles 5 ja 6 edellyttävät hallinnointia ja dokumentoitua ICT-riskien hallinnan viitekehystä. Articles 7 to 14 kattavat luotettavat ja häiriönsietokykyiset ICT-järjestelmät, omaisuuserien ja riippuvuuksien tunnistamisen, suojauksen, havaitsemisen, ICT-liiketoiminnan jatkuvuuden, varmuuskopioinnin, palauttamisen, toipumisen, poikkeamien jälkeisen oppimisen, tietoisuuden, koulutuksen ja kriisiviestinnän. Articles 24 to 26 edellyttävät digitaalisen operatiivisen häiriönsietokyvyn testausta muilta kuin mikroyrityksiksi luokitelluilta rahoitusalan toimijoilta. Articles 28 to 30 vakiinnuttavat ICT-kolmannen osapuolen riskin, ICT-palvelusopimusten rekisterit, irtautumisstrategiat, palvelutasot, auditointioikeudet ja varautumisvaatimukset.

ISO/IEC 27001:2022 tarjoaa hallintajärjestelmän selkärangan. Sen lausekkeet edellyttävät, että organisaatio määrittää toimintaympäristön, sidosryhmät, lakisääteiset ja sopimusvelvoitteet, soveltamisalan, johtajuuden, politiikan, roolit, riskien arvioinnin, riskien käsittelyn, soveltuvuuslausunnon, operatiivisen suunnittelun, suorituskyvyn arvioinnin ja jatkuvan parantamisen.

Puuttuva linkki on usein BIA. Ilman sitä jatkuvuussuunnitelmat eivät ole selvästi riskiperusteisia, varmuuskopiointitavoitteet eivät ole liiketoiminnan hyväksymiä, toimittajia ei ole kartoitettu kriittisiin palveluihin eikä johto voi luotettavasti osoittaa, että häiriönsietokykyä koskevat päätökset perustuivat liiketoimintavaikutuksiin.

BIA häiriönsietokyvyn näytön ohjauskerroksena

Todennettava BIA vastaa seitsemään kysymykseen, joita auditoijat, valvojat, asiakkaat ja hallitukset kysyvät yhä useammin:

1. Mitkä liiketoimintapalvelut ovat kriittisiä?
2. Mitkä ICT-omaisuuserät, tietovarastot, henkilöt, toimittajat ja hyödykkeet tukevat kutakin palvelua?
3. Mikä on häiriön operatiivinen, taloudellinen, oikeudellinen, sopimuksellinen, asiakas-, turvallisuus- ja mainevaikutus ajan kuluessa?
4. Mikä on suurin hyväksyttävä keskeytysaika eli MTD?
5. Mitkä ovat hyväksytyt toipumisaikatavoite (RTO) ja palautuspistetavoite (RPO)?
6. Mahdollistavatko varmuuskopiointi-, redundanssi-, pilvi-, toimittaja-, henkilöstö- ja viestintäjärjestelyt näiden tavoitteiden saavuttamisen?
7. Onko organisaatio testannut palautuspolun ja katselmoinut tulokset?

Clarysecin yritystason Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka P32 Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka esittää vaatimuksen selkeästi:

Liiketoimintavaikutusten arviointi (BIA) tulee tehdä vähintään vuosittain kaikille kriittisille liiketoimintayksiköille ja katselmoida, kun järjestelmissä, prosesseissa tai riippuvuuksissa tapahtuu merkittäviä muutoksia. BIA:n tulosten tulee määrittää: 5.2.1. Suurin hyväksyttävä keskeytysaika (MTD) 5.2.2. Toipumisaikatavoitteet (RTO) 5.2.3. Palautuspistetavoitteet (RPO) 5.2.4. Kriittiset riippuvuudet (järjestelmät, toimittajat, henkilöstö)

Tämä lauseke antaa auditoijille käytännöllisen lähtökohdan. Se myös ehkäisee yleisen epäonnistumisen, jossa liiketoiminnan jatkuvuussuunnitelma, katastrofipalautussuunnitelma, varmuuskopiointiaikataulu, toimittajarekisteri ja tietoturvapoikkeamiin reagoinnin prosessi käyttävät kukin erilaista määritelmää käsitteelle ”kriittinen”.

Sama politiikka edellyttää integroitua hallintatapaa:

Organisaation tulee ylläpitää integroitua liiketoiminnan jatkuvuuden hallintajärjestelmää (BCMS), joka on yhdenmukainen ISO 22301- ja ISO/IEC 27001 -standardien kanssa ja varmistaa seuraavien osa-alueiden integroinnin: 5.1.1. Liiketoimintavaikutusten arviointi (BIA) 5.1.2. Jatkuvuusuhkia koskeva tietoturvariskien arviointi 5.1.3. Liiketoiminnan jatkuvuussuunnitelmat (BCP) 5.1.4. ICT-katastrofipalautussuunnitelmat (DRP) 5.1.5. Testaus- ja harjoitusohjelmat 5.1.6. Dokumentaatio ja jatkuva parantaminen

Tämä erottaa tarkistuslistamaisen vaatimustenmukaisuuden auditointivalmiista häiriönsietokyvystä. BIA ei ole kertaluonteinen asiakirja. Siitä tulee osa ISMS- ja BCMS-näyttöketjua.

Miten ISO/IEC 27001:2022 muuttaa BIA:n auditoitavaksi näytöksi

ISO/IEC 27001:2022 ei edellytä, että jokainen organisaatio käyttää ilmaisua ”liiketoimintavaikutusten arviointi” jokaisessa lausekkeessa, mutta sen vaatimukset tekevät BIA-näytöstä erittäin arvokasta.

Lausekkeet 4.1 to 4.4 edellyttävät, että organisaatio ymmärtää sisäiset ja ulkoiset tekijät, sidosryhmät, lakisääteiset ja sääntelyvelvoitteet, sopimusvaatimukset, rajapinnat, riippuvuudet ja ISMS:n soveltamisalan. BIA on usein käytännöllisin näyttö näistä rajapinnoista ja riippuvuuksista. Se osoittaa, mikä pilvipalvelu, maksunkäsittelijä, identiteetin tarjoaja, teleoperaattori, hallittu tietoturvapalvelu, konesali tai ulkoistettu tukitiimi mahdollistaa kriittisen palvelun.

Lausekkeet 5.1 to 5.3 edellyttävät ylimmän johdon johtajuutta, resursointia, viestintää, roolien osoittamista ja raportointia. BIA antaa johdolle liiketoimintaperustan jatkuvuusinvestoinneille. Ilman sitä RTO- ja RPO-tavoitteet ovat teknisiä toiveita, eivät hyväksyttyjä liiketoimintavaatimuksia.

Lausekkeet 6.1.1 to 6.1.3 edellyttävät toistettavaa tietoturvariskien arviointia ja käsittelyä. Organisaation on tunnistettava luottamuksellisuuteen, eheyteen ja saatavuuteen kohdistuvat riskit, analysoitava seuraukset ja todennäköisyys, määritettävä riskitasot, priorisoitava käsittely, valittava kontrollit, verrattava valittuja kontrolleja liite A:han, laadittava soveltuvuuslausunto, luotava riskienkäsittelysuunnitelma ja hankittava riskinomistajan hyväksyntä. BIA vahvistaa riskien arvioinnin ”seuraus”-puolta. Se selittää, miksi yhden järjestelmän kahden tunnin katkos on hyväksyttävissä, kun taas toisen järjestelmän kahden tunnin katkos aiheuttaa asiakashaittaa, sääntelyaltistusta, sopimusrikkomuksen tai vakavan liikevaihtovaikutuksen.

Liite A tarjoaa kontrollikatalogin. BIA:n ja jatkuvuuden kannalta olennaisimpia ISO/IEC 27001:2022 liite A:n kontrolleja ovat:

Teoksessa Zenith Controls: Cross-Compliance-opas Zenith Controls Clarysec kuvaa ISO/IEC 27002:2022 -kontrollin 5.30, ICT-valmius liiketoiminnan jatkuvuutta varten, korjaavana kontrollina, joka keskittyy saatavuuteen ja joka on kartoitettu Respond-kyberturvallisuuskonseptiin, jatkuvuuden operatiiviseen kyvykkyyteen ja häiriönsietokyvyn tietoturva-alueeseen. Kontrolli 5.29, tietoturvallisuus häiriötilanteessa, kuvataan ennaltaehkäisevänä ja korjaavana kontrollina, joka suojaa luottamuksellisuutta, eheyttä ja saatavuutta. Kontrolli 8.13, tietojen varmuuskopiointi, kuvataan korjaavana kontrollina, joka tukee eheyttä ja saatavuutta palautuksen avulla.

Tällä erolla on merkitystä. BIA:n ei tule kysyä vain: ”Voimmeko palauttaa?” Sen tulee kysyä myös: ”Voimmeko pysyä turvallisina häiriön aikana?” Kiristyshaittaohjelmatapahtuman, pilvikatkoksen, toimittajavian tai konesalipoikkeaman aikana organisaatio tarvitsee edelleen pääsynhallintaa, lokitusta, seurantaa, näytön säilyttämistä, turvallista viestintää ja tietosuojan suojatoimia.

Käytännöllinen BIA-näyttömalli

Vahva BIA yhdistää liiketoimintakielen tekniseen näyttöön. Clarysec jäsentää näyttömallin tyypillisesti viiteen kerrokseen.

Tämä näyttömalli toimii, koska se seuraa auditoijien ajattelutapaa. Ensin he kysyvät, mikä on kriittistä. Sitten he kysyvät, mikä sitä tukee. Sitten he kysyvät, kuka hyväksyi palautustavoitteen. Sitten he kysyvät, voivatko tekniset ja toimittajajärjestelyt täyttää tavoitteen. Lopuksi he kysyvät, onko organisaatio testannut ja parantanut kyvykkyyttä.

NIST CSF 2.0 on hyödyllinen viestintäkerros. Sen CSF Profiles -menetelmä kannustaa organisaatioita määrittämään soveltamisalan, kokoamaan syötteitä, kuten politiikat, yritystason riskiprioriteetit, BIA-rekisterit, kyberturvallisuusvaatimukset, standardit, menettelyt, suojatoimet ja työroolit, luomaan nykytila- ja tavoiteprofiilit, analysoimaan puutteet, tuottamaan priorisoidun toimintasuunnitelman, toteuttamaan sen ja päivittämään profiilin. Tämä vastaa lähes täsmälleen sitä, miten BIA:n tulisi ruokkia eri vaatimuksiin liittyvää tiekarttaa.

Viikon BIA-harjoitus, joka tuottaa todellista näyttöä

Oletetaan, että SaaS-palveluntarjoaja tukee rahoituspalveluasiakkaita. Sen alusta tukee asiakkaiden käyttöönottoa, asiakirjojen todentamista ja asiakasilmoituksia. Se ei itse ole pankki, mutta sen asiakkaat lähettävät DORA-lähtöisiä sopimuspyyntöjä ja NIS2-toimittajakyselyjä.

Kohdennettu viikon harjoitus voi tuottaa hyödyllistä näyttöä nopeasti.

Päivä 1: Tunnista kriittiset palvelut ja vaikutusikkunat

Aloita palveluista, älä palvelimista. Ota mukaan liiketoimintavastaavat, IT, tietoturva, lakiasiat, tuki, tietosuoja ja toimittajahallinta.

Tämä kehystys on tärkeä. Valvojat ja asiakkaat tunnistavat palvelut ja toiminnot. Sovelluksilla on merkitystä, koska ne tukevat näitä palveluja.

Päivä 2: Kartoita riippuvuudet

Kartoita kullekin palvelulle sovellukset, tietokannat, infrastruktuuri, pilvipalvelut, identiteetin tarjoajat, seuranta, varmuuskopiointityökalut, henkilöt, toimittajat ja tukevat hyödykkeet.

Tässä BIA alkaa tuottaa arvoa. Se paljastaa näkymättömän palautuspolun, mukaan lukien riippuvuudet, jotka usein jäävät teknisessä DR-suunnitelmassa huomaamatta.

Päivä 3: Hyväksy MTD, RTO ja RPO

Liiketoimintavastaava ehdottaa MTD:tä. IT ja tietoturva validoivat, ovatko ehdotetut RTO ja RPO teknisesti saavutettavissa. Johto hyväksyy lopulliset tavoitteet.

Pienemmille organisaatioille Clarysecin Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka - pk-yritys P32S Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka - pk-yritys tarjoaa saman kurinalaisuuden yksinkertaisemmalla kielellä. Se edellyttää BCP/DR-suunnitelmia, joissa määritetään lähestymistapa olennaisten toimintojen palauttamiseen:

Toimitusjohtajan (GM) tulee hyväksyä ja ylläpitää liiketoiminnan jatkuvuus- ja katastrofipalautussuunnitelmia (BCP/DRP), joissa esitetään selkeästi organisaation lähestymistapa olennaisten toimintojen palauttamiseen.

Se edellyttää myös, että suunnitelma sisältää:

priorisoidut palvelut ja järjestelmät (kriittiset liiketoimintatoiminnot)

Sekä:

Toipumisaikatavoitteet (RTO) ja palautuspistetavoitteet (RPO) kullekin järjestelmälle

Avain ei ole liiallinen dokumentointi. Avain on jäljitettävyys, hyväksyntä ja näyttö siitä, että palautustavoitteet perustuvat todellisiin liiketoimintavaikutuksiin.

Päivä 4: Sovita varmuuskopiointi liiketoimintavaikutuksiin

Monet organisaatiot epäonnistuvat tässä. BIA voi asettaa neljän tunnin RPO:n, vaikka varmuuskopiot ajetaan 24 tunnin välein. Tai varmuuskopiointityökalu suojaa tuotantotietokannat, mutta ei konfiguraatiota, salaisuuksia, infrastruktuuri koodina -tietovarastoja, objektitallennusta, DNS-tietueita, identiteettiasetuksia tai API-yhdyskäytävän konfiguraatiota.

Clarysecin Varmuuskopiointi- ja palautuspolitiikka P15 Varmuuskopiointi- ja palautuspolitiikka edellyttää BIA-tuloksiin sidottua päävarmuuskopiointiaikataulua:

Päävarmuuskopiointiaikataulu tulee ylläpitää ja katselmoida vuosittain. Sen on määritettävä: 5.1.1 Varmuuskopiointitiheys (esimerkiksi päivittäiset inkrementaaliset varmuuskopiot ja viikoittaiset täydet varmuuskopiot) 5.1.2 Säilytysajat järjestelmä- tai tietotyypeittäin 5.1.3 Salausvaatimukset ja tallennussijaintien tiedot 5.1.4 RTO/RPO-tavoitteet, jotka on yhdistetty liiketoimintavaikutusten arvioinnin tuloksiin

Tämä lauseke on auditoinnin kannalta erittäin arvokas. Se pakottaa varmuuskopiointisuunnittelun heijastamaan liiketoimintavaikutusta, ei tallennuksen mukavuutta.

Päivä 5: Testaa yksi palautuspolku ja avaa korjaavat toimenpiteet

Älä testaa kaikkea kerralla. Valitse yksi kriittinen palvelu ja suorita kohdennettu palautustesti. Palauta tietokanta. Rakenna sovelluksen konfiguraatio uudelleen. Validoi todennus. Varmista, että lokit ovat saatavilla. Tarkista asiakasilmoituskyky. Kirjaa käytetty aika, tietojen menetys, viat, päätökset ja korjaavat toimenpiteet.

Teoksessa Zenith Blueprint: auditoijan 30 vaiheen tiekartta Zenith Blueprint, Controls in Action -vaiheen vaihe 23 käsittelee organisatorisia kontrolleja, mukaan lukien ICT-valmiutta liiketoiminnan jatkuvuutta varten. Se esittää kysymyksen, joka jokaisen auditointitiimin tulisi kysyä:

Pystyvätkö järjestelmänne tukemaan liiketoiminnan jatkuvuustavoitteitanne, kun valot välkkyvät, verkot kaatuvat ja katastrofi iskee?

Sama vaihe antaa käytännön ohjeen:

Varmista, että kriittisten järjestelmien toipumisaikatavoitteet (RTO) ja palautuspistetavoitteet (RPO) ovat yhdenmukaisia liiketoiminnan jatkuvuusodotusten kanssa (5.30). Suorita vähintään yksi tekninen palautustesti tai failover-simulaatio ja dokumentoi tulokset.

Tämä on ero BIA:n omistamisen ja todennettavan BIA-näytön välillä. Tavoitetta ei ole vain dokumentoitu. Se on testattu.

BIA-näytön kartoitus NIS2-, DORA-, GDPR-, NIST- ja COBIT 2019 -vaatimuksiin

Hyvin rakennettu BIA muuttuu eri vaatimuksia palvelevaksi omaisuuseräksi. Yksi näyttökokonaisuus voi vastata moneen kysymykseen.

GDPR unohtuu usein BIA-keskusteluissa. GDPR Article 5 kuitenkin edellyttää, että henkilötietoja käsitellään eheästi ja luottamuksellisesti, mukaan lukien suojaaminen tahattomalta menetykseltä, tuhoutumiselta tai vahingoittumiselta asianmukaisilla teknisillä tai organisatorisilla toimenpiteillä. Osoitusvelvollisuus edellyttää, että rekisterinpitäjä pystyy osoittamaan vaatimustenmukaisuuden. Jos henkilötietoja käsittelevää alustaa ei voida palauttaa hyväksytyssä ja testatussa aikarajassa, tietosuojariski vaikuttaa saatavuuteen, eheyteen, loukkausarviointiin ja asiakkaiden luottamukseen.

NIS2:n poikkeamaraportointi tuo mukaan toisen ulottuvuuden. Article 23 edellyttää, että merkittävistä poikkeamista ilmoitetaan ilman aiheetonta viivytystä, mukaan lukien varhaisvaroitus 24 tunnin kuluessa, poikkeamailmoitus 72 tunnin kuluessa ja loppuraportti kuukauden kuluessa. BIA auttaa vakavuuden luokittelussa, koska se määrittää vaikutuksen kohteena olevat palvelut, palvelun vastaanottajat, operatiivisen häiriön ja mahdollisen rajat ylittävän vaikutuksen.

DORA:n poikkeamaluokittelu huomioi myös vaikutuksen kohteena olevat asiakkaat tai tapahtumat, keston, maantieteellisen laajuuden, tietojen menetykset, vaikutuksen kohteena olevien palvelujen kriittisyyden ja taloudellisen vaikutuksen. Nämä ovat BIA-kenttiä. Jos BIA on heikko, poikkeamaluokittelusta tulee subjektiivista juuri pahimmalla mahdollisella hetkellä.

Toimittajien jatkuvuus on kohta, jossa BIA kohtaa sopimustodellisuuden

NIS2:n ja DORA:n näkökulmasta toimittajien jatkuvuus ei ole enää valinnainen asia. NIS2 Article 21 sisältää toimitusketjun turvallisuuden ja edellyttää huomiota toimittajien haavoittuvuuksiin, tuotteiden laatuun ja häiriönsietokykyyn, toimittajien kyberturvallisuuskäytäntöihin sekä turvallisen kehityksen menettelyihin. DORA edellyttää, että ICT-kolmannen osapuolen riskiä hallitaan osana ICT-riskien viitekehystä, mukaan lukien ICT-palvelusopimusten rekisterit, huolellisuus, keskittymäriski, irtautumisstrategiat, auditointi- ja käyttöoikeudet, poikkeamatuki, palvelutasot ja varautumisvaatimukset.

Yritystason Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka edellyttää:

Kolmansien osapuolten ja toimitusketjun riippuvuudet 6.5.1. Kriittisten toimittajien kanssa tehtävien sopimusten tulee sisältää jatkuvuusvelvoitteet ja palautusaikasitoumukset. 6.5.2. Keskeisten palveluntarjoajien tulee pyynnöstä osoittaa säännöllinen jatkuvuustestaus ja osallistuminen poikkeamaharjoituksiin.

Pk-yritysversio edellyttää myös:

toimittajien jatkuvuusyhteyspisteet

Tämä pieni kenttä voi olla ratkaiseva todellisessa poikkeamassa. Jos palautussuunnitelmassa lukee ”ota yhteyttä pilvipalveluntarjoajan tukeen”, mutta kukaan ei tiedä eskalointireittiä, sopimusviitettä, vakavuusprosessia tai päivystysyhteystietoa, RTO on fiktiota.

Tämä taulukko ei korvaa toimittajariskien hallintaa. Se tekee toimittajariskistä operatiivista.

Miten auditoijat testaavat BIA:si

ISO/IEC 27001:2022 -auditoija aloittaa yleensä soveltamisalasta, toimintaympäristöstä, riskien arvioinnista, riskien käsittelystä, soveltuvuuslausunnosta, liite A:n kontrolleista, dokumentoidusta tiedosta, operatiivisesta suunnittelusta, suorituskyvyn arvioinnista ja parantamisesta. Hän vertaa BIA:ta riskien arviointiin ja SoA:han. Jos A.5.30, A.5.29 tai A.8.13 sisältyvät soveltamisalaan, auditoija pyytää näyttöä toteutuksesta ja testauksesta.

DORA-katselmoija keskittyy kriittisiin tai tärkeisiin toimintoihin, ICT-omaisuuseriin, ICT-kolmannen osapuolen riippuvuuksiin, häiriönsietokyvyn testaukseen, poikkeamaluokitteluun, sopimusvaatimuksiin, irtautumisstrategioihin ja johtoelimen valvontaan. Hän odottaa BIA:n olevan yhdenmukainen ICT-riskien hallinnan viitekehyksen, digitaalisen operatiivisen häiriönsietokyvyn strategian, ICT-liiketoiminnan jatkuvuussuunnitelmien, reagointi- ja palautussuunnitelmien sekä testausohjelman kanssa.

NIS2-valvoja kysyy liiketoiminnan jatkuvuustoimenpiteistä, varmuuskopioinnin hallinnasta, katastrofipalautuksesta, kriisinhallinnasta, toimitusketjun turvallisuudesta, hallinnoinnin hyväksynnästä ja merkittävien poikkeamien raportointikyvystä. BIA:n tulee osoittaa, että nämä toimenpiteet perustuvat palveluvaikutukseen ja hyväksyttyihin prioriteetteihin.

NIST CSF 2.0 -arvioija kysyy, miten BIA ohjaa nykytila- ja tavoiteprofiilia, puuteanalyysiä ja toimintasuunnitelmaa. Hän tarkastelee Govern-tuloksia lakisääteisten, sääntelyyn liittyvien, sopimusperusteisten, riski-, rooli-, politiikka-, valvonta- ja toimittajariskipäätösten osalta. Hän tarkastelee myös Identify-, Protect-, Detect-, Respond- ja Recover-tuloksia.

COBIT 2019- tai ISACA-tyyppinen auditoija keskittyy yleensä hallinnointiin. Kuka omistaa palvelun? Kuka hyväksyi riskin? Ovatko tavoitteet yhdenmukaisia yrityksen tavoitteiden kanssa? Seurataanko toimittajia? Ovatko hyödyt, riskit ja resurssit tasapainossa? Seurataanko korjaavia toimenpiteitä sulkemiseen asti?

Clarysecin Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka Auditointi- ja vaatimustenmukaisuuden seurantapolitiikka tekee BIA:sta osan auditoinnin suunnittelusykliä:

Riskiperusteinen auditointisuunnitelma tulee laatia ja hyväksyä vuosittain ottaen huomioon: 5.2.1 Viimeisimpien riskien arviointien ja liiketoimintavaikutusten arvioinnin (BIA) tulokset 5.2.2 Aiemmat auditointihavainnot ja korjaavien toimenpiteiden tila 5.2.3 Muutokset prosesseissa, IT-infrastruktuurissa, järjestelmissä tai toimittajissa 5.2.4 Ulkoiset velvoitteet, kuten DORA Article 25 tai asiakassopimukset

Tämä on kypsyysaskel, joka monilta organisaatioilta jää väliin. BIA:n ei tule sijaita varmennuksen ulkopuolella. Sen tulee ohjata auditointisuunnitelmaa.

Yleiset BIA-puutteet todellisissa arvioinneissa

Samat heikkoudet toistuvat jatkuvasti.

Ensinnäkin BIA listaa sovelluksia, ei palveluja. Asiakkaita ja valvojia kiinnostaa palveluhäiriö. Sovelluksilla on merkitystä, koska ne tukevat näitä palveluja.

Toiseksi RTO- ja RPO-tavoitteet kopioidaan malleista. Neljän tunnin RTO voi kuulostaa kohtuulliselta, kunnes palautustesti osoittaa, että identiteetti-integraation uudelleenrakentaminen, konfiguraation palauttaminen, tietojen palauttaminen, eheyden validointi ja seurannan uudelleenkäyttöönotto vievät yhdeksän tuntia.

Kolmanneksi varmuuskopioita ei ole yhdistetty liiketoimintavaikutukseen. Tiheyden, säilytyksen, salauksen, tallennussijainnin, palautusprioriteetin ja testauksen on heijastettava hyväksyttyjä palautustavoitteita.

Neljänneksi toimittajia käsitellään kyselylomakkeen kohteina, ei palautusriippuvuuksina. Toimittajien jatkuvuussitoumukset, eskalointiyhteystiedot, palautusnäyttö ja osallistuminen poikkeamaharjoituksiin tulee yhdistää kriittisiin palveluihin.

Viidenneksi johdon hyväksyntä puuttuu. NIS2:ssa ja DORA:ssa johdon vastuu on nimenomainen. ISO/IEC 27001:2022 -standardissa johtajuus, roolit, riskinomistajan hyväksyntä ja suorituskykyraportointi ovat keskeisiä vaatimuksia.

Kuudenneksi testaus on liian kapea. Yhden tiedoston palauttaminen on hyödyllistä, mutta se ei todista palvelun palautumista. Kriittisen palvelun palautuspolku voi sisältää DNS:n, identiteetin, salaisuudet, infrastruktuuri koodina -ratkaisut, API-yhdyskäytävät, seurannan, lokituksen, toimittajaeskaloinnin, asiakasviestinnän ja tietosuojakatselmoinnin.

Zenith Blueprint tiivistää Controls in Action -vaiheen vaiheessa 19 varmuuskopiointeja koskevan auditointiodotuksen:

Testaatteko varmuuskopionne?

Vastauksen on oltava ”kyllä, näytön kanssa”, ja tämän näytön on yhdistyttävä takaisin BIA:an.

Auditointivalmis BIA-näyttöpaketti

Käytännöllisen BIA-ohjelman tulee tuottaa tiivis näyttöpaketti, jota voidaan käyttää auditoinneissa, asiakkaiden huolellisuusarvioinneissa, hallitusraportoinnissa ja häiriönsietokyvyn parantamisessa.

Tämä paketti kertoo johdonmukaisen tarinan. Se tekee myös häiriönsietokyvystä mitattavaa.

Seuraava askel: muuta BIA vaatimustenmukaisuusnäytöksi

Maria ei tarvitse suurempaa taulukkoa. Hän tarvitsee elävän näyttöketjun.

Aloita yhdestä kriittisestä palvelusta. Kartoita sen ICT-omaisuuserät, tiedot, henkilöt, toimittajat ja hyödykkeet. Hyväksy MTD, RTO ja RPO. Sovita varmuuskopiointiaikataulu niihin. Tarkista toimittajien palautumissitoumukset. Suorita yksi palautustesti. Kirjaa puutteet. Päivitä riskienkäsittelysuunnitelma. Esittele tulos johdolle.

Toista sitten.

Clarysec voi nopeuttaa tätä prosessia hyödyntämällä Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikkaa, Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikkaa - pk-yritys, Varmuuskopiointi- ja palautuspolitiikkaa, Auditointi- ja vaatimustenmukaisuuden seurantapolitiikkaa, Zenith Blueprintia ja Zenith Controlsia.

BIA:n ei tule olla hyllydokumentti, joka on luotu auditointia varten. Sen tulee olla operatiivinen todiste siitä, että tärkeimmät palvelunne kestävät häiriön, täyttävät asiakkaiden ja sääntelyn odotukset ja palautuvat rajoissa, jotka johto on tosiasiallisesti hyväksynyt.

Jos organisaatiosi valmistautuu ISO/IEC 27001:2022 -seuranta-auditointiin, NIS2-asiakasvarmennukseen, DORA:n ICT-kolmannen osapuolen katselmointeihin tai hallitustason häiriönsietokykyraportointiin, aloita tekemällä BIA:sta todennettava. Lataa Clarysecin jatkuvuus- ja auditointipolitiikat, katselmoi Zenith-toteutustiekartta tai pyydä häiriönsietokyvyn näyttöarviointi, jotta hajallaan olevat kontrollit voidaan muuttaa yhdeksi auditointivalmiiksi kertomukseksi.