DORA:n ICT-irtairtautumisstrategiat ISO 27001 -hallintakeinoilla

Maanantaina klo 07.42 fintech-yhtiön operatiivinen omistaja saa viestin, jota kukaan ei halua lukea: yhtiön pilvipohjainen transaktioiden seurantapalveluntarjoaja on kärsinyt vakavasta alueellisesta palvelukatkoksesta. Klo 08.15 riskijohtaja kysyy, tukeeko kyseinen palvelu kriittistä tai tärkeää toimintoa. Klo 08.40 lakitoiminto haluaa tietää, antaako sopimus yhtiölle oikeudet siirtymäapuun, tietojen vientiin, poistamiseen ja auditointiin. Klo 09.05 tietoturvajohtaja etsii näyttöä siitä, että irtautumissuunnitelma on testattu eikä vain kirjoitettu.

Toisessa finanssipalveluyrityksessä nopeasti kasvavan fintech-alustan tietoturvajohtaja Sarah avaa DORA-vaatimustenmukaisuuden arviointia koskevan auditointia edeltävän tietopyynnön. Kysymykset ovat tuttuja siihen saakka, kunnes hän pääsee kriittisiä tai tärkeitä toimintoja tukeviin kolmantena osapuolena oleviin ICT-palveluntarjoajiin. Auditoijat eivät kysy, onko yhtiöllä toimittajapolitiikka. He pyytävät dokumentoituja, testattuja ja toteuttamiskelpoisia irtautumisstrategioita.

Hänen ajatuksensa siirtyvät ensin alustaa ylläpitävään keskeiseen pilvipalveluntarjoajaan ja sitten hallinnoituun tietoturvapalveluntarjoajaan, joka valvoo uhkia ympäri vuorokauden. Entä jos pilvipalveluntarjoaja kärsii geopoliittisesta häiriöstä? Entä jos kilpailija ostaa MSSP-palveluntarjoajan? Entä jos kriittinen SaaS-palveluntarjoaja ajautuu maksukyvyttömäksi, lopettaa palvelun tai menettää asiakkaiden luottamuksen merkittävän poikkeaman jälkeen?

Monessa organisaatiossa epämiellyttävä vastaus on sama. Käytössä on toimittajan riskien arviointi, liiketoiminnan jatkuvuussuunnitelma, sopimuskansio, pilvi-inventaario ja ehkä varmuuskopiointiraportti. Käytössä ei kuitenkaan ole yhtä auditointivalmista DORA:n mukaista kolmannen osapuolen ICT-irtairtautumisstrategiaa, joka yhdistää liiketoiminnan kriittisyyden, sopimusperusteiset oikeudet, teknisen siirrettävyyden, jatkuvuussuunnitelmat, varmuuskopiointinäytön, tietosuojavelvoitteet ja johdon hyväksynnän.

DORA muuttaa toimittajahallinnan sävyä. Asetuksen (EU) 2022/2554 mukaan finanssiyhteisöjen on hallittava kolmansien osapuolten ICT-riskejä osana ICT-riskienhallintakehystään. Ne pysyvät täysimääräisesti vastuussa vaatimustenmukaisuudesta, ylläpitävät ICT-palvelusopimusten rekisteriä, erottavat kriittisiä tai tärkeitä toimintoja tukevat ICT-järjestelyt, arvioivat keskittymä- ja alihankintariskejä sekä ylläpitävät irtautumisstrategioita kriittisille kolmannen osapuolen ICT-riippuvuuksille. DORA:a sovelletaan 17. tammikuuta 2025 alkaen, ja se asettaa yhtenäiset EU-vaatimukset ICT-riskienhallinnalle, poikkeamien raportoinnille, häiriönsietokyvyn testaukselle, tietojen jakamiselle ja kolmansien osapuolten ICT-riskienhallinnalle laajassa finanssialan toimijajoukossa.

DORA:n mukainen irtautumisstrategia ei ole yksittäinen kappale toimittajasopimuksessa. Se on kontrollikokonaisuus. Sen on oltava hallinnoitu, riskienarvioinnin kattama, teknisesti toteuttamiskelpoinen, sopimuksellisesti toimeenpantavissa, testattu, näytöllä osoitettu ja jatkuvasti parannettava.

Clarysecin lähestymistapa yhdistää Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint -mallin, yritystason politiikkamallit ja Zenith Controls: The Cross-Compliance Guide Zenith Controls -oppaan, jotta maanantaiaamun kysymykseen voidaan vastata valmistellusti.

Miksi DORA:n mukaiset irtautumisstrategiat epäonnistuvat todellisissa auditoinneissa

Useimmat DORA:n mukaisten ICT-irtairtautumisstrategioiden puutteet ovat rakenteellisia ennen kuin ne ovat teknisiä. Organisaatiolla on toimittajaomistaja, mutta ei nimettyä riskinomistajaa. Sillä on varmuuskopiointiajoja, mutta ei palautusnäyttöä. Sillä on toimittajan due diligence -kyselylomake, mutta ei dokumentoitua päätöstä siitä, tukeeko palveluntarjoaja kriittistä tai tärkeää toimintoa. Sillä on sopimuksen päättämistä koskevaa tekstiä, mutta ei liiketoiminnan jatkuvuussuunnitelmaan sovitettua siirtymäaikaa.

DORA pakottaa nämä osat yhteen. Article 28 asettaa kolmansien osapuolten ICT-riskienhallinnan yleiset periaatteet, mukaan lukien tarpeen hallita ICT-palveluntarjoajina toimivien kolmansien osapuolten riskejä koko elinkaaren ajan ja ylläpitää asianmukaisia irtautumisstrategioita. Article 30 asettaa yksityiskohtaiset sopimusvaatimukset kriittisiä tai tärkeitä toimintoja tukeville ICT-palveluille, mukaan lukien palvelukuvaukset, tietojen käsittelypaikat, tietoturvasuojaukset, pääsy- ja auditointioikeudet, poikkeamatilanteiden tuki, yhteistyö toimivaltaisten viranomaisten kanssa ja sopimuksen päättämisoikeudet.

Sääntely perustuu myös suhteellisuusperiaatteeseen. Articles 4 and 16 sallivat tietyille pienemmille tai vapautetuille toimijoille yksinkertaistetun ICT-riskienhallintakehyksen soveltamisen. Yksinkertaistettu ei kuitenkaan tarkoita dokumentoimatonta. Myös pienemmät finanssialan toimijat tarvitsevat dokumentoidun ICT-riskienhallinnan, jatkuvan seurannan, häiriönsietokykyiset järjestelmät, ICT-poikkeamien nopean tunnistamisen, keskeisten kolmannen osapuolen ICT-riippuvuuksien tunnistamisen, varmuuskopioinnin ja palautuksen, liiketoiminnan jatkuvuuden, reagoinnin ja toipumisen, testauksen, opit ja koulutuksen.

Pieni fintech-yhtiö ei voi sanoa: ”Olemme liian pieniä irtautumissuunnitteluun.” Se voi sanoa: ”DORA:n mukainen irtautumisstrategiamme on mitoitettu kokomme, riskiprofiilimme ja palvelun monimutkaisuuden mukaan.” Ero on näytössä.

Niille toimijoille, jotka kuuluvat myös NIS2:n kansalliseen soveltamisalaan, DORA toimii finanssisektorin päällekkäisten kyberturvallisuusvelvoitteiden sektorikohtaisena unionin säädöksenä. NIS2 on silti merkityksellinen laajemmassa ekosysteemissä, erityisesti hallinnoiduille palveluntarjoajille, hallinnoiduille tietoturvapalveluntarjoajille, pilvipalveluntarjoajille, konesaleille ja digitaalisen infrastruktuurin toimijoille. NIS2 Article 21 vahvistaa samoja teemoja: riskianalyysi, poikkeamien käsittely, liiketoiminnan jatkuvuus, toimitusketjun tietoturva, turvallinen hankinta, vaikuttavuuden arviointi, koulutus, kryptografia, pääsynhallinta, omaisuudenhallinta ja todennus.

Valvojat, asiakkaat, auditoijat ja hallitukset voivat muotoilla kysymyksen eri tavoin, mutta ydinongelma on sama: voitteko irtautua kriittisestä ICT-palveluntarjoajasta menettämättä hallintaa palvelun jatkuvuudesta, tiedoista, näytöstä tai asiakasvaikutuksista?

Tee irtautumisstrategiasta osa ISMS:ää

ISO/IEC 27001:2022 tarjoaa hallintajärjestelmän rungon DORA:n mukaiselle irtautumissuunnittelulle.

Kohdat 4.1–4.4 edellyttävät, että organisaatio määrittää toimintaympäristönsä, sidosryhmät, lakisääteiset, sääntely- ja sopimusperusteiset vaatimukset, ISMS:n soveltamisalan, rajapinnat, riippuvuudet ja prosessit. Tässä vaiheessa finanssialan toimija tunnistaa DORA:n, asiakassitoumukset, ulkoistukseen liittyvät odotukset, pilviriippuvuudet, tietosuojavelvoitteet, alihankkijat ja ISMS:n rajaukseen kuuluvat ICT-palvelut.

Kohdat 5.1–5.3 edellyttävät johtajuutta, politiikkaa, resursseja, roolien osoittamista ja vastuullisuutta. Tämä vastaa DORA:n hallintomallia, jossa hallintoelin määrittää, hyväksyy ja valvoo ICT-riskienhallintaa sekä pysyy siitä vastuussa. Tähän sisältyvät ICT-liiketoiminnan jatkuvuus, reagointi- ja palautussuunnitelmat, ICT-auditointisuunnitelmat, budjetit, häiriönsietokyvyn strategia ja kolmansien osapuolten ICT-riskipolitiikka.

Kohdat 6.1.1–6.1.3 muuntavat irtautumissuunnittelun riskien käsittelyksi. Organisaatio määrittää riskikriteerit, tekee toistettavat riskien arvioinnit, tunnistaa luottamuksellisuuteen, eheyteen ja saatavuuteen kohdistuvat riskit, nimeää riskinomistajat, arvioi seuraukset ja todennäköisyyden, valitsee käsittelyvaihtoehdot, vertaa hallintakeinoja liite A:han, laatii soveltuvuuslausunnon, valmistelee riskienkäsittelysuunnitelman sekä hankkii riskinomistajan hyväksynnän ja jäännösriskin hyväksynnän.

Kohta 8.1 edellyttää tämän jälkeen operatiivista suunnittelua ja ohjausta. Organisaation on suunniteltava, toteutettava ja ohjattava ISMS-prosesseja, ylläpidettävä dokumentoitua tietoa, joka osoittaa prosessien toteutuneen suunnitellusti, hallittava muutoksia sekä ohjattava ISMS:n kannalta olennaisia ulkoisesti tuotettuja prosesseja, tuotteita tai palveluja.

ISO/IEC 27005:2022 vahvistaa tätä lähestymistapaa. Kohta 6.2 ohjeistaa organisaatioita tunnistamaan sidosryhmien vaatimukset, mukaan lukien ISO/IEC 27001:2022 liite A:n hallintakeinot, sektorikohtaiset standardit, kansalliset ja kansainväliset säädökset, sisäiset säännöt, sopimusvaatimukset sekä aiemmasta riskien käsittelystä syntyneet olemassa olevat hallintakeinot. Kohdat 6.4.1–6.4.3 selittävät, että riskikriteereissä tulee huomioida lakisääteiset ja sääntelyyn liittyvät näkökohdat, toimittajasuhteet, tietosuoja, operatiiviset vaikutukset, sopimusrikkomukset, kolmansien osapuolten toiminta ja mainevaikutukset. Kohdat 8.2–8.6 tukevat kontrollikirjastoa ja käsittelysuunnitelmaa, joka voi yhdistää ISO/IEC 27001:2022 liite A:n DORA:an, NIS2:een, GDPR:ään, asiakassitoumuksiin ja sisäisiin politiikkoihin.

Toimintamalli on suoraviivainen: yksi vaatimusluettelo, yksi toimittajariskirekisteri, yksi soveltuvuuslausunto, yksi riskienkäsittelysuunnitelma ja yksi todentavan aineiston kooste jokaista kriittistä irtautumisskenaariota varten.

ISO/IEC 27001:2022 -hallintakeinot, jotka ankkuroivat DORA:n mukaisen irtautumissuunnittelun

DORA:n mukaiset irtautumisstrategiat ovat auditointivalmiita, kun toimittajahallinta, pilvipalvelujen siirrettävyys, jatkuvuussuunnittelu ja varmuuskopiointinäyttö käsitellään yhtenä toisiinsa kytkeytyvänä kontrolliketjuna.

Clarysecin Zenith Controls kohdistaa ISO/IEC 27001:2022 liite A:n hallintakeinot kontrolliattribuutteihin, auditointinäyttöön ja poikkivaatimusten odotuksiin. Se ei ole erillinen kontrolliviitekehys. Se on Clarysecin poikkivaatimusten opas sen ymmärtämiseksi, miten ISO/IEC 27001:2022 -hallintakeinot tukevat auditointi-, sääntely- ja operatiivisia tuloksia.

DORA:n mukaisen kolmannen osapuolen ICT-irtairtautumisstrategian auditointijäljen tulee osoittaa, että:

• Toimittaja on luokiteltu ja linkitetty liiketoimintaprosesseihin.
• Palvelun tuki kriittiselle tai tärkeälle toiminnolle on arvioitu.
• Irtautumisriski on kirjattu nimetylle riskinomistajalle.
• Sopimuslausekkeet tukevat siirtymää, pääsyä, auditointia, tietojen palautusta, tietojen poistamista, yhteistyötä ja jatkuvuutta.
• Pilvipalvelun siirrettävyys ja yhteentoimivuus on validoitu.
• Varmuuskopiointi- ja palautustestit osoittavat palautuskelpoisuuden.
• Tilapäinen korvaaminen tai vaihtoehtoinen käsittely on dokumentoitu.
• Irtautumistestauksen tulokset on katselmoitu, korjattu ja raportoitu johdolle.

Sopimuskieli on ensimmäinen jatkuvuuskontrolli

Sopimuksen tulee olla ensimmäinen jatkuvuuskontrolli, ei jatkuvuuden este. Jos palveluntarjoaja voi päättää sopimuksen nopeasti, viivyttää vientiä, rajoittaa lokien käyttöä, veloittaa määrittelemättömiä siirtymämaksuja tai kieltäytyä migraatiotuesta, irtautumisstrategia on hauras.

Zenith Blueprint -mallin Controls in Action -vaiheen Step 23, Control 5.20 selittää, että toimittajasopimusten tulee sisältää käytännön tietoturvavaatimukset, jotka tekevät irtautumisen mahdolliseksi:

Toimittajasopimuksissa käsitellään tyypillisesti seuraavia keskeisiä alueita:

✓ Luottamuksellisuusvelvoitteet, mukaan lukien soveltamisala, kesto ja kolmansille osapuolille luovuttamista koskevat rajoitukset;

✓ Pääsynhallinnan vastuut, kuten kuka voi käyttää tietojanne, miten tunnistetietoja hallitaan ja millainen seuranta on käytössä;

✓ Tekniset ja organisatoriset toimenpiteet tietosuojan, salauksen, turvallisen siirron, varmuuskopioinnin ja saatavuussitoumusten osalta;

✓ Poikkeamien ilmoitusmääräajat ja menettelyt, usein määritellyillä määräajoilla;

✓ Tarkastusoikeudet, mukaan lukien tiheys, soveltamisala ja pääsy olennaiseen näyttöön;

✓ Alihankkijakontrollit, jotka edellyttävät toimittajaa siirtämään vastaavat tietoturvavelvoitteet jatkokumppaneilleen;

✓ Sopimuksen päättymistä koskevat ehdot, kuten tietojen palautus tai tuhoaminen, omaisuuden palautus ja käyttäjätilien sulkeminen.

Tämä luettelo yhdistää DORA Article 30:n sopimusodotukset ja ISO/IEC 27001:2022 liite A:n hallintakeinon A.5.20.

Clarysecin yritystason politiikkakieli tekee samasta asiasta operatiivisen. Toimittajariippuvuuksien riskienhallintapolitiikan Toimittajariippuvuuksien riskienhallintapolitiikka kohdassa ”Toteutusvaatimukset”, kohta 6.4.3 todetaan:

Tekniset varajärjestelyt: Varmista tietojen siirrettävyys ja yhteentoimivuus palvelusiirtymän tukemiseksi tarvittaessa (esim. säännölliset varmuuskopiot vakiomuodoissa SaaS-palveluntarjoajalta migraation mahdollistamiseksi).

Saman politiikan kohta 6.8.2 edellyttää:

Oikeus siirtymäapuun, kun palveluntarjoajan vaihtaminen on tarpeen, mukaan lukien palvelun jatkuminen määritellyn siirtymäkauden ajan.

Tämä lauseke ratkaisee usein, kestääkö irtautumisstrategia auditoinnin. Se muuttaa irtautumisen jyrkkäreunaisesta tapahtumasta hallituksi siirtymäksi.

Pienemmille toimijoille Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - pk-yritys Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - pk-yritys, kohta ”Hallinnointivaatimukset”, kohta 5.3.6 edellyttää:

Sopimuksen päättämisehdot, mukaan lukien turvallinen tietojen palautus tai tuhoaminen

Yritysympäristöissä Kolmansien osapuolten ja toimittajien tietoturvapolitiikka Kolmansien osapuolten ja toimittajien tietoturvapolitiikka, kohta ”Politiikan toteutusvaatimukset”, kohta 6.5.1.2 edellyttää:

Kaikkien organisaation omistamien tietojen palautus tai sertifioitu tuhoaminen

Näiden politiikkavaatimusten tulee jäljittyä suoraan sopimuslausekkeisiin, toimittajan menettelyihin, irtautumisen toimintaohjeisiin ja auditointinäyttöön.

Pilvipalvelusta irtautuminen: testaa siirrettävyys ennen kuin tarvitset sitä

Pilvipalveluissa DORA:n mukaiset irtautumisstrategiat muuttuvat usein epämääräisiksi. Organisaatio olettaa voivansa viedä tiedot, mutta kukaan ei ole testannut formaattia. Se olettaa, että poistaminen tapahtuu, mutta palveluntarjoajan säilytysmalli sisältää varmuuskopioita ja replikoitua tallennusta. Se olettaa, että vaihtoehtoinen palveluntarjoaja voi vastaanottaa tiedot, mutta skeemat, identiteetti-integraatiot, salausavaimet, salaisuudet, lokit, ohjelmointirajapinnat ja nopeusrajoitukset hidastavat migraatiota enemmän kuin vaikutustoleranssi sallii.

ISO/IEC 27001:2022 liite A:n hallintakeino A.5.23 käsittelee tätä elinkaariongelmaa edellyttämällä tietoturvakontrolleja pilvipalvelujen hankintaan, käyttöön, hallintaan ja niistä irtautumiseen.

Clarysecin Pilvipalvelujen käyttöpolitiikka - pk-yritys Pilvipalvelujen käyttöpolitiikka - pk-yritys, kohta ”Politiikan toteutusvaatimukset”, kohta 6.3.4 edellyttää:

Tietojen vientikyvykkyys vahvistettu ennen käyttöönottoa (esim. toimittajalukkiutumisen välttämiseksi)

Kohta 6.3.5 edellyttää:

Turvallisten poistomenettelyjen vahvistaminen ennen käyttäjätilin sulkemista

Nämä vaatimukset kuuluvat toimittajaelinkaaren alkuun. Älä odota sopimuksen päättämiseen asti kysyäksesi, voidaanko tiedot viedä. Älä odota käyttäjätilin sulkemiseen asti kysyäksesi, onko poistamisesta näyttöä.

Käytännön DORA-pilvi-irtautumistestin tulee sisältää:

1. Edustavan tietoaineiston vienti sovitussa muodossa.
2. Täydellisyyden, eheyden, aikaleimojen, metatietojen ja käyttöoikeuksien validointi.
3. Tietoaineiston tuonti staging-ympäristöön tai vaihtoehtoiseen työkaluun.
4. Salausavainten käsittelyn ja salaisuuksien kierron vahvistaminen.
5. Lokien viennin ja auditointijäljen säilytyksen vahvistaminen.
6. Palveluntarjoajan poistomenettelyjen dokumentointi, mukaan lukien varmuuskopioiden säilytys ja poistotodistus.
7. Havaintojen, korjaavien toimenpiteiden, omistajien ja määräaikojen kirjaaminen.
8. Toimittajariskien arvioinnin, soveltuvuuslausunnon ja irtautumissuunnitelman päivittäminen.

Siirrettävyys ei ole hankinnassa annettu lupaus. Se on testattu kyvykkyys.

Viikon sprintti DORA:n mukaisen irtautumissuunnitelman saamiseksi auditointivalmiiksi

Tarkastellaan maksulaitosta, joka käyttää SaaS-pohjaista petosanalytiikkapalveluntarjoajaa. Palveluntarjoaja vastaanottaa transaktiotietoja, asiakastunnisteita, laitteen telemetriatietoja, käyttäytymissignaaleja, petossääntöjä, pisteytystuloksia ja tapausmuistiinpanoja. Palvelu tukee kriittistä petosten havaitsemisprosessia. Organisaatio käyttää lisäksi pilvessä toimivaa tietovarastoa vietyjen analytiikkatulosten tallentamiseen.

Tietoturvajohtaja haluaa DORA:n mukaisen kolmannen osapuolen ICT-irtairtautumisstrategian, joka kestää sisäisen tarkastuksen ja valvontaviranomaisen arvioinnin. Yhden viikon sprintti voi paljastaa puutteet ja rakentaa näyttöketjun.

Päivä 1: luokittele toimittaja ja määritä irtautumisskenaario

Zenith Blueprint -mallin Controls in Action -vaiheen Step 23:n, Controls 5.19 to 5.37:n Action Items -kohdan avulla tiimi aloittaa katselmoimalla ja luokittelemalla toimittajaportfolion:

Kokoa täydellinen luettelo nykyisistä toimittajista ja palveluntarjoajista (5.19) ja luokittele ne järjestelmiin, tietoihin tai operatiiviseen ohjaukseen liittyvän pääsyn perusteella. Varmista kunkin luokitellun toimittajan osalta, että tietoturvaodotukset on sisällytetty selkeästi sopimuksiin (5.20), mukaan lukien luottamuksellisuus, pääsy, poikkeamien raportointi ja vaatimustenmukaisuusvelvoitteet.

Toimittaja luokitellaan kriittiseksi, koska se tukee kriittistä tai tärkeää toimintoa, käsittelee arkaluonteista operatiivista dataa ja vaikuttaa transaktioiden seurantatuloksiin.

Tiimi määrittää kolme irtautumisen laukaisevaa tekijää:

• Palveluntarjoajan maksukyvyttömyys tai palvelun lopettaminen.
• Olennainen tietoturvaloukkaus tai luottamuksen menetys.
• Strateginen migraatio keskittymäriskin vähentämiseksi.

Päivä 2: rakenna vaatimusluettelo ja riskitallenne

Tiimi laatii yhden vaatimusluettelon, joka kattaa DORA:n mukaiset kolmansien osapuolten ICT-riskit, ISO/IEC 27001:2022:n toimittaja- ja pilvikontrollit, henkilötietoja koskevat GDPR-velvoitteet, asiakassopimusten sitoumukset ja sisäisen riskinottohalukkuuden.

GDPR:n perusteella organisaatio vahvistaa, liittyvätkö transaktiotunnisteet, laitetunnisteet, sijaintisignaalit ja käyttäytymisanalytiikka tunnistettuihin tai tunnistettavissa oleviin henkilöihin. GDPR Article 5:n periaatteet, mukaan lukien eheys, luottamuksellisuus, säilytyksen rajoittaminen ja osoitusvelvollisuus, tulevat osaksi irtautumisen näyttövaatimusta. Jos irtautuminen sisältää siirron uudelle palveluntarjoajalle, oikeusperuste, tarkoitus, minimointi, säilytys, käsittelijäehdot ja suojatoimet on dokumentoitava.

Riskitallenne sisältää seuraavat tiedot:

Päivä 3: korjaa sopimuspuutteet

Lakitoiminto ja hankinta vertaavat sopimusta Clarysecin toimittajalausekkeisiin. Ne lisäävät siirtymäavun, palvelun jatkumisen määritellyn siirtymäkauden ajan, pääsyn auditointi- ja näyttöaineistoon, alihankkijailmoitukset, tietojen vientimuodon, turvallisen poistamisen sertifioinnin, yhteistyön poikkeamatilanteissa ja palautumisaikasitoumukset.

Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikan Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka kohdassa ”Politiikan toteutusvaatimukset”, kohta 6.5.1 todetaan:

Kriittisten toimittajien sopimuksiin on sisällytettävä jatkuvuusvelvoitteet ja palautumisaikasitoumukset.

Pk-yrityksille Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka - pk-yritys Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka - pk-yritys, kohta ”Riskienkäsittely ja poikkeukset”, kohta 7.2.1.4 edellyttää tiimeiltä, että ne:

dokumentoivat tilapäiset toimittajan tai kumppanin korvaussuunnitelmat

Tämä lauseke muuttaa ilmauksen ”siirrymme muualle” toteuttamiskelpoiseksi varajärjestelyksi: mikä palveluntarjoaja, mikä sisäinen kiertomenettely, mikä manuaalinen prosessi, mikä tietopoiminta, mikä omistaja ja mikä hyväksymispolku.

Päivä 4: testaa tietojen siirrettävyys ja varmuuskopioiden palautuskelpoisuus

Teknologiatiimi vie petossäännöt, tapaustiedot, transaktioiden pisteytystulokset, lokit, konfiguraation, API-dokumentaation ja käyttäjien käyttöoikeusluettelot. Tiimi testaa, voidaanko tiedot palauttaa tai käyttää uudelleen hallitussa ympäristössä.

Varmuuskopiointi- ja palautuspolitiikka - pk-yritys Varmuuskopiointi- ja palautuspolitiikka - pk-yritys, kohta ”Hallinnointivaatimukset”, kohta 5.3.3 edellyttää:

Palautustestit tehdään vähintään neljännesvuosittain, ja tulokset dokumentoidaan palautuskelpoisuuden todentamiseksi

Yritystason Varmuuskopiointi- ja palautuspolitiikka Varmuuskopiointi- ja palautuspolitiikka, kohta ”Soveltaminen ja vaatimustenmukaisuus”, kohta 8.3.1 lisää:

Auditoi säännöllisesti varmuuskopiointilokit, kokoonpanoasetukset ja testitulokset

Zenith Blueprint -mallin Controls in Action -vaiheen Step 19, Control 8.13 -kohdassa Clarysec varoittaa, miksi tämä on tärkeää:

Palautustestaus on kohta, jossa useimmat organisaatiot epäonnistuvat. Varmuuskopio, jota ei voida palauttaa ajoissa tai lainkaan, on vastuu, ei omaisuuserä. Aikatauluta säännölliset palautusharjoitukset, vaikka ne olisivat vain osittaisia, ja dokumentoi lopputulos.

Tiimi havaitsee, että viedyt tapausmuistiinpanot eivät sisällä liitteitä ja että API-nopeusrajoitukset tekevät täysimääräisestä viennistä liian hitaan määriteltyyn palautumistavoitteeseen nähden. Havainto kirjataan, osoitetaan omistajalle ja korjataan sopimusliitteellä sekä teknisellä vientirakenteen uudistuksella.

Päivä 5: toteuta irtautumisen pöytäharjoitus ja näytön katselmointi

Tiimi toteuttaa pöytäharjoituksen: toimittaja ilmoittaa sopimuksen päättämisestä 90 päivän kuluttua merkittävän poikkeaman jälkeen. Operatiivisen toiminnan on jatkettava petosseurantaa samalla, kun tiedot migroidaan.

Zenith Blueprint -mallin Controls in Action -vaiheen Step 23, Control 5.30 -kohdassa Clarysec selittää testausstandardin:

ICT-valmius alkaa kauan ennen häiriön syntymistä. Se edellyttää kriittisten järjestelmien tunnistamista, niiden keskinäisten riippuvuuksien ymmärtämistä ja niiden kytkemistä liiketoimintaprosesseihin.

Sama kohta lisää:

Liiketoiminnan jatkuvuussuunnitelmassa määritettyjen toipumisaikatavoitteiden (RTO) ja palautuspistetavoitteiden (RPO) on heijastuttava teknisiin konfiguraatioihin, sopimuksiin ja infrastruktuurisuunnitteluun.

Todentavan aineiston kooste sisältää toimittajaluokittelun, riskien arvioinnin, sopimuslausekkeet, irtautumisen toimintaohjeen, tietojen vientitulokset, varmuuskopioiden palautusnäytön, poistomenettelyn, vaihtoehtoisen palveluntarjoajan arvioinnin, pöytäharjoituksen pöytäkirjat, korjaavien toimenpiteiden lokin, johdon hyväksynnän ja jäännösriskipäätöksen.

Tietoturvajohtaja voi nyt vastata hallituksen kysymykseen näytöllä, ei optimismilla.

Poikkivaatimukset: yksi irtautumissuunnitelma, useita auditointinäkökulmia

Vahva DORA:n mukainen irtautumisstrategia vähentää päällekkäistä vaatimustenmukaisuustyötä ISO/IEC 27001:2022:n, NIS2:n, GDPR:n, NIST:n ja COBIT 2019:n hallinnointiodotuksissa.

Tärkeää ei ole, että yksi viitekehys korvaa toisen. Arvo syntyy siitä, että hyvin rakennettu ISMS antaa organisaatiolle mahdollisuuden tuottaa näyttö kerran ja käyttää sitä uudelleen hallitusti.

Clarysecin Zenith Controls auttaa tiimejä valmistautumaan näihin auditointinäkökulmiin yhdistämällä ISO/IEC 27001:2022 -hallintakeinot auditointinäyttöön ja viitekehysten välisiin odotuksiin.

Yleinen auditointipuute on näytön pirstoutuminen. Toimittajaomistajalla on sopimus. IT:llä on varmuuskopiointilokit. Lakitoiminnolla on tietojenkäsittelysopimus. Riskitoiminnolla on arviointi. Vaatimustenmukaisuustoiminnolla on sääntelykartoitus. Kenelläkään ei ole kokonaiskuvaa.

Clarysec ratkaisee tämän suunnittelemalla todentavan aineiston koosteet irtautumisskenaarion ympärille. Jokainen asiakirja vastaa yhteen auditointikysymykseen: mistä palvelusta irtaudutaan, miksi se on kriittinen, mihin tietoihin ja järjestelmiin se vaikuttaa, kuka omistaa riskin, mitkä sopimusoikeudet tekevät irtautumisen mahdolliseksi, mitkä tekniset mekanismit tekevät migraation mahdolliseksi, mitkä jatkuvuusjärjestelyt pitävät liiketoiminnan käynnissä, mikä testi osoittaa suunnitelman toimivuuden, mitkä havainnot on korjattu ja kuka hyväksyi jäännösriskin.

Clarysecin DORA-irtairtautumisstrategian tarkistuslista

Käytä tätä tarkistuslistaa muuttaaksesi DORA:n mukaisen kolmannen osapuolen ICT-irtairtautumisstrategian asiakirjasta auditoitavaksi kontrollikokonaisuudeksi.

Tee irtautumissuunnittelusta hallitukselle kelpaava häiriönsietokyvyn kontrolli

Jos DORA:n mukainen irtautumisstrategianne on vain sopimuslauseke, se ei ole valmis. Jos varmuuskopiota ei ole koskaan palautettu, se ei ole valmis. Jos pilvipalveluntarjoaja voi viedä tiedot mutta kukaan ei ole validoinut täydellisyyttä, se ei ole valmis. Jos hallitus ei näe jäännösriskipäätöstä, se ei ole valmis.

Clarysec auttaa tietoturvajohtajia, vaatimustenmukaisuuspäälliköitä, auditoijia ja liiketoimintavastaavia rakentamaan DORA:n mukaisia kolmansien osapuolten ICT-irtairtautumisstrategioita, jotka ovat käytännöllisiä, suhteellisia ja auditointivalmiita. Yhdistämme toteutusjärjestystä varten Zenith Blueprint Zenith Blueprint -mallin, poikkivaatimusten kartoitusta varten Zenith Controls Zenith Controls -oppaan sekä politiikkamallit, kuten Toimittajariippuvuuksien riskienhallintapolitiikka Toimittajariippuvuuksien riskienhallintapolitiikka, Pilvipalvelujen käyttöpolitiikka - pk-yritys Pilvipalvelujen käyttöpolitiikka - pk-yritys, Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - pk-yritys Kolmansien osapuolten ja toimittajien tietoturvapolitiikka - pk-yritys ja Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka Liiketoiminnan jatkuvuus- ja katastrofipalautuspolitiikka, jotta syntyy täydellinen kontrollista näyttöön ulottuva ketju.

Seuraava askel on yksinkertainen ja arvokas: valitkaa tällä viikolla yksi kriittinen ICT-toimittaja. Luokitelkaa se, katselmoikaa sen sopimus, testatkaa yksi tietojen vienti, varmentakaa yksi palautus, dokumentoikaa yksi korvaussuunnitelma ja luokaa yksi todentavan aineiston kooste.

Tämä yksittäinen harjoitus osoittaa, onko DORA:n mukainen irtautumisstrategianne todellinen häiriönsietokyvyn kyvykkyys vai vain asiakirja, joka odottaa epäonnistumistaan auditoinnissa.