Kuinka ISO 27001 vahvistaa liiketoiminnan jatkuvuutta pelialan jättipottitapahtumissa

Miltä "jackpot-tapahtumat" oikeasti näyttävät organisaatiossasi?

Jättipottitapahtumat ovat harvinaisia, suuria häiriöitä, jotka ylikuormittavat normaalit häiriö- ja jatkuvuussuunnitelmat. Ne yleensä yhdistävät useita häiriöitä kerralla, kestävät paljon pidempään kuin päivittäiset käyttökatkokset ja kuluttavat nopeasti loppuun yksinkertaiset kiertotavat. Ne ovat epätodennäköisiä, mutta erittäin suuria skenaarioita – kuten alueellinen sähkökatkos useissa toimipisteissä, tuhoisa kyberhyökkäys suuren julkaisun aikana tai pilvipalveluntarjoajan käyttökatkos yhdistettynä avainhenkilöiden poissaoloon – ja niistä tulee hallittavia vain, kun niitä käsitellään eksplisiittisinä riskeinä tietoturvanhallintajärjestelmässä ja liiketoiminnan jatkuvuuskehyksessä abstraktien työpajatarinoiden sijaan.

Rutiinihäiriöt vaikuttavat rajattuun osaan ympäristöstäsi, kun taas jättiläistapahtumat ylikuormittavat useita palveluita kerralla ja tekevät niin pitkään. Yhden palvelimen kaatuminen tai paikallisen toimiston käyttökatkos on hankalaa, mutta se voidaan yleensä korjata tavanomaisilla vikasietoisuus- tai manuaalisilla ratkaisuilla. Jättiläistapahtuma sitä vastoin iskee useisiin kriittisiin elementteihin kerralla ja vie toimintamallisi, henkilöstösi ja toimittajat äärirajoilleen.

Jatkuvuussuunnittelu keskittyy edelleen useimmiten ennustettaviin, yhden pisteen häiriöihin, kuten yhden palvelimen vikaantumiseen, paikallisen toimiston yhteyden katkeamiseen tai yhden avainhenkilön muutaman päivän tauolle jäämiseen. Näillä skenaarioilla on merkitystä, mutta ne eivät yleensä ole niitä, jotka uhkaavat yrityksesi selviytymistä, toimilupaa tai kykyäsi täyttää sopimus- ja sääntelyvelvollisuuksiasi.

Jackpot-tapahtumilla on tyypillisesti kolme yhteistä piirrettä:

Korkoa korottavat tekijät: – useita asioita menee pieleen samanaikaisesti; esimerkiksi datakeskuksen käyttökatkos ja tärkeä SaaS-vika.
Pidennetty kesto: – häiriö kestää niin kauan, että manuaaliset kiertotavat ja hyvän tahdon keinot alkavat epäonnistua.
Systeeminen vaikutus: – useat kriittiset palvelut, alueet tai liiketoimintayksiköt ovat samanaikaisesti kärsineet.

Jos riskirekisterisi ja testiohjelmasi keskittyvät lähes kokonaan siisteihin yksittäisiin vikatilanteisiin, olet lähes varmasti alialtistunut jättipottiriskille ja ylivarma kyvystäsi selviytyä todella vakavista tapahtumista.

Eron selventämiseksi voi olla hyödyllistä vertailla rutiinitapahtumia ja jättipottitapahtumia rinnakkain.

Yksinkertainen vertailu osoittaa, miten rutiinitapahtumat ja jättipottitapahtumat eroavat toisistaan laajuuden ja odotusten suhteen.

Ulottuvuus	Rutiinitapaus	Jackpot-tapahtuma
Laajuus	Yksittäinen järjestelmä, toimipaikka tai tiimi	Useita järjestelmiä, toimipisteitä ja tiimejä
Kesto	Lyhyt, usein tunteja tai vähemmän	Pitkäaikainen, usein useita tunteja tai päiviä
Vaikutus	Paikallinen häiriö, rajoitettu vaikutus asiakkaisiin	Koko yrityksen kattava häiriö, merkittävä vaikutus asiakkaisiin
kiertotavat	Tavalliset pelikirjat yleensä riittävät	Kiertoratkaisut heikkenevät ajan myötä
Hallintokeskeisyys	Operatiiviset tiimit ja paikallinen johto	Johto, sääntelyviranomaiset ja suuret asiakkaat
Testiodotukset	Yksinkertaiset vikasieto- ja palautustarkistukset	Monimutkaiset skenaarioharjoitukset ja tiimien väliset harjoitukset

Tämä rajaus auttaa sinua päättämään, mitkä skenaariot kuuluvat jokapäiväisiin jatkuvuustesteihin ja mitä tulisi käsitellä jättipottitapahtumina, jotka vaativat vakavampaa, toimintojen rajat ylittävää huomiota – tätä erottelua käytät uudelleen, kun suunnittelet skenaarioita ja testejä myöhemmin tässä käsikirjassa.

Rutiinitapaukset vs. jättipottitapahtumat

Rutiinitapaukset vaikuttavat suljettuihin järjestelmiin tai sijainteihin, kun taas jättipottitapahtumat ulottuvat koko organisaatiosi ulottuville teknologian, ihmisten ja kolmansien osapuolten osalta. Molempien tyyppien tarkka ajatteleminen auttaa sinua välttämään liiallista keskittymistä ongelmiin, joita jo hallitset hyvin.

Suurin osa jatkuvuussuunnittelusta perustuu edelleen ennustettaviin, jokapäiväisiin epäonnistumisiin, joita operatiiviset tiimit kohtaavat useimmiten. Sinulla voi olla vahvat käsikirjat yksittäisten järjestelmien käyttökatkoksiin, paikallisten toimistojen häiriöihin tai lyhytaikaisiin henkilöstön poissaoloihin, mutta hyvin vähän hankaliin yhdistelmiin, jotka tuovat useita näistä ongelmista yhteen.

Tietoturvajohtajien, jatkuvuuspäälliköiden ja IT-päälliköiden kaltaisille johtajille todellinen arvo piilee tämän erottelun käyttämisessä ajan ja investointien priorisoinnissa. Rutiinitapahtumien tulisi pysyä vakiotapahtumien ja palveluiden hallintaprosesseissa. Päävoittotapahtumiin sitä vastoin on kiinnitettävä erityistä huomiota riskinarvioinnissa, liiketoimintavaikutusten analysoinnissa ja harjoitusohjelmassa, koska ne todennäköisimmin testaavat toimilupaasi ja lupauksiasi asiakkaille ja sääntelyviranomaisille.

Miksi jättipottitapahtumista on yhtäkkiä tullut kaikkien ongelma

Päävoittotapahtumista on tullut merkityksellisiä lähes kaikille organisaatioille, koska systeemiset shokit ja digitaalinen riippuvuus ovat tehneet vakavista häiriöistä todennäköisempiä. Olet nyt riippuvainen jaetusta pilvi-infrastruktuurista, kriittisistä SaaS-toimittajista ja tiiviisti kytketyistä prosesseista tavoilla, jotka olivat harvinaisia vielä kymmenen vuotta sitten, joten häiriöt voivat levitä paljon pidemmälle ja nopeammin kuin ennen.

Viimeisen vuosikymmenen aikana useat trendit ovat siirtäneet jättipottitapahtumat mielenkiintoisista aiheista johtokunnan tason aiheiksi:

Pandemiat ja geopoliittiset shokit: osoittivat, että yhden suunnittelusyklin aikana voi esiintyä oletettavasti harvinaisia, maailmanlaajuisia häiriöitä.
Kiristysohjelmat ja tuhoisat haittaohjelmat: poistavat nyt rutiininomaisesti käytöstä satoja järjestelmiä ja organisaatioita yhden kampanjan aikana.
Pilvipalveluiden keskittyminen ja jaetut toimittajat: yhden palveluntarjoajan kaatuminen voi vaikuttaa samanaikaisesti laajoihin osiin ekosysteemiä.
Toiminnan sietokyvyn sääntely: rahoituspalveluissa ja kriittisessä infrastruktuurissa odotetaan nyt suunnittelua ja testausta vakavien mutta mahdollisten häiriöiden varalta, ei vain päivittäisten käyttökatkosten.

Olitpa sitten hakemassa ISO 27001 -sertifiointia, ylläpitämässä sitä tai käyttämässä standardia vain vertailukohtana, nämä odotukset muokkaavat sitä, miten tilintarkastajat, sääntelyviranomaiset ja asiakkaat tulkitsevat jatkuvuustarinaasi. Jackpot-tapahtumat ovat käytännössä siirtyneet riskinottohalukkuutesi reunalta sietokykysi arvioinnin keskiöön, joten ne ovat nyt yhtä lailla huolenaihe tietosuojavastaaville, tietoturvajohtajille ja IT-ammattilaisille kuin liiketoiminnan jatkuvuustiimeille.

Varaa demo

Miten jättipottitapahtumat sopivat tietoturvanhallintajärjestelmääsi (ISMS) ja liiketoimintanhallintajärjestelmääsi (BCMS)?

Päävoittotapahtumat sopivat parhaiten, kun niitä käsitellään vaikuttavina tietoturva- ja jatkuvuusriskeinä, jotka sisältyvät olemassa oleviin hallintajärjestelmiisi. Niiden tulisi näkyä riskinarvioinnissa, liiketoimintavaikutusten analysoinnissa ja harjoitusohjelmassa samalla jäsennellyllä tavalla kuin tutummat skenaariot, vain erilaisilla oletuksilla mittakaavasta ja kestosta. Todellinen kysymys on, kuvaavatko, omistavatko ja testaavatko tietoturvan hallintajärjestelmäsi ja liiketoiminnan hallintajärjestelmäsi näitä skenaarioita johdonmukaisesti, vai ovatko ne edelleen olemassa vain "mitä jos" -skenaarioita, joista ei koskaan tule konkreettisia suunnitelmia.

Jos sinulla on jo ISO 27001 -standardin mukainen tietoturvan hallintajärjestelmä (ISMS) erillisellä alustalla, kuten ISMS.online, voit käsitellä jättipottiskenaarioita erillisenä kategoriana olemassa olevassa riski- ja jatkuvuusmallissasi erillisen projektin sijaan. Voit sitten yhdistää nämä skenaariot omistajiin, kontrolleihin, suorituskirjoihin ja testitodisteisiin keksimättä rinnakkaista rakennetta, joka pitää kaiken näkyvänä yhden hallintojärjestelmän sisällä.

Resilienssi kasvaa nopeimmin, kun testaat tietoisesti asioita, joiden et toivo koskaan tapahtuvan.

ISMS vs. BCMS: kaksi linssiä samoilla ääripäillä

Tietoturvan hallintajärjestelmäsi (ISMS) ja liiketoiminnan hallintajärjestelmäsi (BCMS) tarkastelevat samoja äärimmäisiä tapahtumia eri, mutta toisiaan täydentävistä näkökulmista. Toinen keskittyy tiedon suojaamiseen, toinen tärkeiden palveluiden toiminnan ylläpitämiseen. Kun ne yhdistetään, jättipottiskenaarioista tulee yhteinen objekti sen sijaan, että ne olisivat hämmentäviä päällekkäisyyksiä eri tiimien ja dokumenttien välillä.

ISO 27001 -standardin mukainen tietoturvallisuuden hallintajärjestelmä (ISMS) keskittyy ensisijaisesti tiedon luottamuksellisuuteen, eheyteen ja saatavuuteen. Liiketoiminnan jatkuvuuden hallintajärjestelmä (BCMS), joka on tyypillisesti ISO 22301 -standardin mukainen, keskittyy kriittisten toimintojen jatkuvuuteen häiriön aikana ja sen jälkeen.

Jackpot-tapahtumille:

Focus-patjan ISMS-linssi testaa, pysyvätkö tiedot turvassa ja saatavilla stressin alla kysymällä, mitä tiedoillesi, järjestelmillesi ja tietoturvakontrolleillesi tapahtuu äärimmäisen skenaarion iskiessä.
Focus-patjan BCMS-linssi testaa, pystytkö pitämään tärkeimmät palvelusi siedettävissä rajoissa kyseisessä skenaariossa, vaikka osat ympäristöstä heikentyisivät.

Jos nämä kaksi järjestelmää käyttävät eri kieltä ja tapausluetteloita, huomaat aukkoja ja sekaannusta. Vankempi malli on käyttää:

Yhteinen riskiluokitus: – mukaan lukien selkeät ”alhaisen todennäköisyyden / suuren vaikutuksen” tunnisteet, jotta jättipottiriskit ovat näkyvissä.
Jaettu luettelo kriittisistä palveluista ja niitä tukevista resursseista: – joten sekä tietoturvan hallintajärjestelmät (ISMS) että liiketoiminnan hallintajärjestelmät (BCMS) perustuvat samoihin liiketoimintaprioriteettiin.
Yksittäinen skenaariokirjasto: syöttämällä sekä lohkoketjusuunnitelmiin että tietoturvapoikkeamien käsittelykirjoihin.

Tämän yhdenmukaistamisen ansiosta tilintarkastajille, sääntelyviranomaisille ja johdolle on paljon helpompi osoittaa, että turvallisuus- ja jatkuvuussuunnittelu toimivat saman äärimmäisen riskin kuvan pohjalta sen sijaan, että ne käyttäisivät kilpailevia versioita todellisuudesta.

Missä jackpot-skenaarioiden tulisi näkyä dokumentaatiossasi

Jackpot-skenaarioiden tulisi esiintyä johdonmukaisesti tietoturvan hallintajärjestelmien (ISMS) ja liiketoiminnan hallintajärjestelmien (BCMS) dokumentaatiossa, jotta niitä hallitaan, testataan ja parannetaan yhtenäisellä tavalla. Johdonmukaisuus on tärkeämpää kuin määrä: tilintarkastajat ja sisäiset sidosryhmät haluavat nähdä, että samat vakavat skenaariot esiintyvät kaikkialla, missä hallintoa ja testausta koskevia päätöksiä tehdään.

Integroidussa tietoturvan hallintajärjestelmässä (ISMS/BCMS) jättipottitapahtumien tulisi tyypillisesti näkyä useissa tietyissä paikoissa:

Konteksti ja laajuus: – lyhyt lausunto siitä, että organisaatio on alttiina harvinaisille, koko järjestelmän laajuisille häiriöille, kuten alueellisille infrastruktuurivioille, merkittäville toimittajien kaatumisille tai tuhoisille kyberongelmille.
Riskin arviointi: – eksplisiittiset riskit, joilla on erittäin korkea vaikutusluokitus, vaikka todennäköisyys olisi pieni, selkeät vastuuhenkilöt ja sovitut hoitosuunnitelmat.
Liiketoimintavaikutusten analyysi (BIA): – skenaariot, joita käytetään palautumisaikatavoitteiden (RTO), palautumispistetavoitteiden (RPO) ja siedettävien käyttökatkosten enimmäisaikojen validointiin, selkokielellä ilmaistuna.
Jatkuvuus- ja häiriösuunnitelmat: – Useita kontrolleja tai sijainteja olettavat pelisuunnitelmat saattavat epäonnistua kerralla yksittäisten, siistien tapausten sijaan.
Liikuntakalenterit: – ainakin joitakin harjoituksia vuosittain, jotka on omistettu monimutkaisille, monitekijäisille skenaarioille yksinkertaisten yksittäisten vikaantumisten sijaan.

Jos et pysty nopeasti osoittamaan, missä "alueellinen pilvipalvelukatkos plus toimittajan vika" sijaitsee riskirekisterissäsi, liiketoiminta-analyysissäsi ja harjoituslokissasi, olet löytänyt ensimmäisen parannusmahdollisuutesi. Näiden viitekehysten yhdistäminen helpottaa myös yhdenmukaisuuden ylläpitämistä arkkitehtuurisi ja toimittajajoukkosi kehittyessä ja roolien, kuten tietoturvajohtajan, tietosuojavastaavan ja jatkuvuusjohtajan, vaihtuessa.

ISMS.online antaa sinulle 81 %:n etumatkan heti sisäänkirjautumisestasi lähtien.

ISO 27001 helposti

Olemme tehneet kovan työn puolestasi ja antavat sinulle 81 % etumatkan kirjautuessasi sisään. Sinun tarvitsee vain täyttää tyhjät kohdat.

Aloita

Miten ISO 27001 ja ISO 22301 voivat antaa sinulle hallintotavan selkärangan?

ISO 27001 ja ISO 22301 tarjoavat jaetun hallintorakenteen, joten jättipottitapahtumien testaus suunnitellaan, siitä omistetaan, sitä parannetaan ja sitä hallinnoidaan selkeästi sen sijaan, että se olisi improvisoitua tai ad hoc -menetelmää. Molemmat standardit noudattavat Annex SL -johtamisjärjestelmärakennetta, jonka avulla voit sijoittaa vakavien skenaarioiden suunnittelun suoraan tuttuihin lausekkeisiin ja prosesseihin kontekstia, riskinarviointia, toimintaa, mittaamista ja parantamista varten. Uuden viitekehyksen keksimisen sijaan laajennat jo olemassa olevaa, sisällytät jättipottitestauksen normaaliin hallintosykliin ja annat tilintarkastajille, sääntelyviranomaisille ja suurille asiakkaille yksinkertaisen tavan nähdä riskinsietokyky muiden riskien rinnalla erillisen "erityisprojektin" sijaan.

ISO 27001 -standardin ydinlausekkeet, joilla on merkitystä jackpot-tapahtumissa

Muutamat ISO 27001 -standardin lausekkeet ankkuroivat sen, miten kuvailet, käytät ja parannat jättipottitapahtumien testausta tietoturvanhallintajärjestelmässäsi. Sinun ei tarvitse käsitellä jättipottiskenaarioita erillisenä standardina; sinun tarvitsee vain kutoa ne olemassa olevaan lausekerakenteeseen näkyvällä tavalla, jotta varmuuden sidosryhmät voivat seurata niiden juovaa.

Useat ISO 27001:2022 -standardin lausekkeet ja liitteen A mukaiset kontrollit ovat erityisen merkityksellisiä:

4 § – Organisaation konteksti:

Tunnistat ulkoiset ja sisäiset ongelmat sekä intressitahot. Tähän kuuluu riskialttius: jaettuihin pilvialueisiin, kriittisiin kolmansiin osapuoliin ja alueelliseen infrastruktuuriin perustuva riippuvuus on tunnistettava nimenomaisesti, joten äärimmäiset häiriöt ovat osa lähtökohtaisia oletuksiasi.

6 § – Suunnittelu (riskinarviointi ja -käsittely):

Päävoittotapahtumat mallinnetaan erittäin vaikuttavina riskeinä. Voit käsitellä niitä eri tavoin metodologiassasi, esimerkiksi käyttämällä skenaarioanalyysiä yksinkertaisten todennäköisyyspisteiden sijaan, mutta ne pysyvät osana tietoturvan hallintajärjestelmän (ISMS) riskinhallintaprosessia, jossa omistajat ja hoitosuunnitelmat on määritelty.

8 § – Käyttö:

Täällä käytät ja testaat vakavien häiriöiden aikana käyttöön otettavia kontrolleja ja prosesseja, mukaan lukien häiriötilanteisiin reagointi, jatkuvuusmenettelyt ja katastrofien jälkeinen palautuminen. Tässä osoitat, että vakavien skenaarioiden kontrollit voidaan todella suorittaa stressin aikana.

9 § – Suorituskyvyn arviointi:

Sinä päätät, mitä jatkuvuus- ja resilienssimittareita seuraat ja miten arvioit harjoitusten ja testien tehokkuutta. Tässä kohtaa jättipottitapahtumien mittarit luonnollisesti sijoittuvat muiden valvonnan suorituskykyä ja johdon tarkastelusisältöä mittaavien mittareiden rinnalle.

10 § – Parannus:

Jackpot-tapahtumatestien tulokset ja korjaavat toimenpiteet otetaan huomioon jatkuvan parantamisen prosessissasi, joten heikkouksia seurataan ja ratkaistaan sen sijaan, että ne jäisivät hautautuneiksi harjoitusraportteihin. Voit myös osoittaa oppimisen ajan myötä.

Liitteessä A on lisätty erityisiä jatkuvuuteen liittyviä kontrolleja, kuten tietoturva häiriöiden aikana ja ICT-valmius liiketoiminnan jatkuvuuden varmistamiseksi. Esimerkiksi kontrollit, jotka edellyttävät turvallista toimintaa häiriöiden aikana ja tietojenkäsittelytilojen valmiutta, tarjoavat suoran yhteyden skenaariosuunnittelusta tiettyihin suojatoimiin, mikä auttaa osoittamaan, että jatkuvuus on osa normaalia tietoturvakontrollien suunnittelua eikä erillinen osa-alue.

Miten ISO 22301 täydentää ISO 27001 -standardia

ISO 22301 -standardi syventää vaikutusten analysointia, jatkuvuusstrategioiden valintaa ja järjestelmällisen harjoitusohjelman toteuttamista. Se keskittyy liiketoimintapuolen kysymyksiin, kuten mitkä palvelut ovat tärkeimpiä, kuinka kauan ne voivat keskeytyä ja miten voit todistaa, että valitsemasi strategiat todella toimivat kyseisten palvelujen kohdalla.

Käytännössä ISO 22301 keskittyy seuraaviin:

liiketoimintavaikutusten analyysi
jatkuvuusstrategiat ja -ratkaisut
dokumentoidut menettelytavat vaaratilanteisiin reagoimiseksi
harjoitus- ja testausohjelmia.

Jos sinulla on jo BCMS, tavoitteena ei ole kopioida kaikkea tietoturvanhallintajärjestelmääsi, vaan:

viitata tietoturvallisuuden hallintajärjestelmäsi BCMS-artefakteihin, jos ne kattavat tietoturvan jatkuvuuden
varmista, että BC-harjoituksissa käytetyt jättipottiskenaariot näkyvät myös ISMS-riskirekisterissä ja sovellettavuuslausunnossa
sopikaa yhteisestä harjoituskalenterista, jotta samassa skenaariossa voidaan testata sekä palvelun jatkuvuutta että tietoturvaa.

Jos sinulla ei vielä ole kypsää liiketoiminnan jatkuvuuden hallintajärjestelmää (BCMS), ISO 27001 edellyttää silti, että käsittelet tietoturvan jatkuvuuden. Siinä tapauksessa voit aloittaa pienestä: tunnistaa yhden tai kaksi kriittisimmistä tietoon perustuvista palveluistasi ja rakentaa niille kevyen jatkuvuustestausmenetelmän, esimerkiksi tarkistamalla, pystytkö saavuttamaan peruspalautustavoitteet määritellyssä vakavassa skenaariossa. Standardien käyttäminen tällä tavalla antaa sinulle yksinkertaisen tarkistuslistan, joka osoittaa, että jättipottitestaus suunnitellaan, toteutetaan ja parannetaan hallintajärjestelmän sisällä, eikä se ole kiinnitetty sen reunalle.

Tästä hallintotavan selkärangasta tulee sitten kehys kaikelle seuraavalle: skenaarioiden suunnittelu, harjoitusten suunnittelu, todisteiden kerääminen ja jatkuva parantaminen liittyvät kaikki näihin tuttuihin lausekkeisiin sen sijaan, että ne eläisivät eristyksissä, mitä juuri tilintarkastajat ja sääntelyviranomaiset odottavat näkevänsä.

Miten muutat jättipotti-ideat konkreettisiksi skenaarioiksi ja testisuunnitelmiksi?

Voit muuttaa jättipotti-ideat konkreettisiksi testeiksi kääntämällä epämääräiset "entä jos?" -kysymykset tarkkoiksi, realistisiksi skenaarioiksi, joilla on selkeät tavoitteet ja todisteet, ei vain dramaattisiksi tarinoiksi "pilven kaatumisesta". Hyvä skenaario kuvaa, mitkä palvelut ovat vaarassa, mikä epäonnistuu, kuinka kauan se kestää, mitä yrität todistaa sekä laajuuden, oletukset, laukaisevat tekijät ja onnistumiskriteerit kielellä, jota liiketoiminta- ja tekniset tiimit voivat jakaa. Kun sinulla on tämä selkeyden taso, voit suunnitella harjoituksia, jotka ihmiset ymmärtävät, suorittaa ne turvallisesti, näyttää tarkalleen, mitä olet oppinut, ja pitää skenaariot ajan tasalla ympäristösi ja toimittajiesi muuttuessa.

Aloita kriittisistä palveluistasi ja pahimmista uskottavista vaikutuksista

Käytännöllisin lähtökohta on luettelo kriittisistä palveluista ja pahimmasta uskottavasta haitasta, jos ne epäonnistuvat. Työskentely taaksepäin sietämättömistä tuloksista pitää sinut rehellisenä siitä, mitkä skenaariot todella merkitsevät, ja estää sinua suunnittelemasta testejä mielenkiintoisten mutta vähäseurauksisten tapahtumien ympärille. Aloita luettelolla tärkeistä palveluista tai prosesseista ja kysy:

Mitkä palvelut aiheuttaisivat pitkäaikaisesti keskeytettynä sietämätöntä vahinkoa, kuten merkittäviä taloudellisia menetyksiä, sääntelyrikkomuksia tai pysyviä mainehaitoja?
Mitkä "uskottavimmat" vikayhdistelmät voisivat vaikuttaa näihin palveluihin arkkitehtuurisi ja toimittajakarttasi perusteella?

Esimerkiksi verkkomaksupalveluntarjoajalle jättipottiskenaario voisi olla ensisijaisen maksupalveluntarjoajan pilvialueen pitkittynyt käyttökatkos ruuhka-kaupankäyntipäivänä yhdistettynä varapalvelun API-vikaan ja tavanomaisen tapahtumapäällikön tavoittamattomuuteen. Yhdistetty vaikutus on ketjureaktio, joka rasittaa sekä teknistä kapasiteettia että päätöksentekokykyä samanaikaisesti.

Kirjaa jokainen skenaario yksinkertaiseen mallipohjaan, joka voi sisältää seuraavat:

Selkokielinen yhteenveto: – yhden lauseen mittainen kuvaus, jonka kuka tahansa sidosryhmä ymmärtää.
Soveltamisala: – skenaarioon liittyvät järjestelmät, sijainnit, tiimit ja toimittajat.
Oletukset: – mikä edelleen toimii ja mikä ei, mukaan lukien mahdolliset tunnetut rajoitukset.
Sisään- ja ulosmenokriteerit: – miten testi alkaa ja millä ehdoilla se päättyy.
tavoitteet: – erityistavoitteita, kuten ”jatkaa perusmaksuvirtoja määritellyn ajan kuluessa käyttäen sovittua varamenetelmää”.

Visuaalinen: yksinkertainen matriisi, joka kartoittaa kriittiset palvelusi yhdellä akselilla ja uskottavimmat jättipottiskenaariot toisella akselilla. Näin osoitetaan, mihin huomio tulisi kiinnittää ja mitkä yhdistelmät ansaitsevat testausta varhaisessa vaiheessa.

Rakenna uudelleenkäytettävä "testipakkaus" jokaista skenaariota varten

Uudelleenkäytettävä testipaketti muuttaa yhden hyvin suunnitellun skenaarion toistettavaksi harjoitukseksi, jota voit hioa ajan myötä. Se myös helpottaa uusien osallistujien perehdyttämistä ja todisteiden säilyttämistä yhdenmukaisina eri testiajoista riippumatta siitä, johdatko työtä tietoturvajohtajana, jatkuvuuspäällikkönä vai IT-ammattilaisena.

Jotta skenaariot olisivat toistettavia ja auditoitavia, määritä testipaketti, joka sisältää:

Esityöt: – tiedon syöttäminen, ympäristön valmistelu ja tiiviit sidosryhmätiedotukset.
roolit: – kuka hoitaa mitäkin roolia, mukaan lukien harjoituksen johtaja, tarkkailijat, päätöksentekijät, muistiinpanojen tekijät, teknologiajohtajat ja asiakaspalveluhenkilöstö.
Aikajana: – testin selkeät vaiheet, kuten alkusokki, eskaloituminen, vakautuminen ja toipuminen.
Injektiot: – käsikirjoitettuja tapahtumia tai tiedonmenetyksiä, jotka pakottavat päätöksiin, esimerkiksi ”toimittaja ilmoittaa, että RTO:ta ei täytetä” tai ”media raportoi käyttökatkoksesta”.
Onnistumiskriteerit: – pieni joukko mittareita, joita mittaat, kuten saavutettu RTO/RPO, päätöksentekonopeus ja viestinnän laatu.
Todistevaatimukset: – mitä tallennat, mukaan lukien lokit, kuvakaappaukset, tallenteet, keskeiset päätökset ja ongelmat.

Voit sitten skaalata testausta käyttämällä näitä paketteja uudelleen ja päivittämällä niitä ympäristösi ja riskiprofiilisi muuttuessa sen sijaan, että keksiisit jokaisen harjoituksen alusta alkaen. Ajan myötä jokaisesta skenaariosta tulee elävä resurssi tietoturvanhallintajärjestelmässäsi tai liiketoiminnan hallintajärjestelmässäsi kertaluonteisen, diaesitykseen haudatun tapahtuman sijaan, ja johtajat voivat verrata suorituskykyä toistuvien testien välillä nähdäkseen, paraneeko kyky.

Ota käyttöön, laajenna ja skaalaa vaatimustenmukaisuus ilman sotkua. Io antaa sinulle joustavuutta ja luottamusta kasvaa turvallisesti.

Varaa esittelysi

Miten käytännössä suoritat realistisia ja matalan riskin jättipottitestejä?

Voit suorittaa realistisia jättipottitestejä asettamatta reaaliaikaisia palveluita kohtuuttomaan riskiin, jos valitset sopivat harjoitustyypit ja käsittelet testejä kontrolloituina muutoksina. Asteittainen siirtyminen matalan riskin keskusteluista teknisempiin harjoituksiin antaa sinulle mahdollisuuden oppia paljon ennen kuin siirryt tuotantoon. Tavoitteena on saada oivalluksia, ei tehdä vaikutusta ihmisiin sillä, kuinka paljon häiriötä voit aiheuttaa.

Monet tiimit epäröivät testata äärimmäisiä skenaarioita, koska he pelkäävät suunnittelemattomia seisokkeja tai negatiivisia otsikoita. Suunnittelemalla harjoituksia, joissa on selkeät tavoitteet, suojakaiteet ja palautusvaihtoehdot, voit osoittaa vakavaa aikomusta pysyen samalla organisaatiosi riskinottohalukkuuden ja sääntelyvelvoitteiden rajoissa. Tietoturvajohtajille, jatkuvuusjohtajille ja IT-päälliköille tämä on usein ero johdon tukeman testausohjelman ja sellaisen välillä, joka ei koskaan pääse käyntiin.

Valitse oikea yhdistelmä liikuntatyyppejä

Erilaiset harjoitustyypit auttavat sinua rakentamaan itseluottamusta askel askeleelta ennen kuin yrität mitään häiritsevää. Sinun ei tarvitse aloittaa täydellä vikasietoisuudella tuotannossa löytääksesi tärkeitä heikkouksia päätöksenteossa, koordinoinnissa tai teknisessä suunnittelussa.

Järkevä kehitysaskel voisi näyttää tältä:

Pöytäharjoitukset: – keskusteluun perustuvia istuntoja, joissa käytetään skenaariokertomusta. Ne ovat vähäriskisiä ja erinomaiset päätöksenteon, roolien ja viestinnän tutkimiseen.
Läpikäynnit tai simulaatiot: – strukturoidut läpikäynnit testiympäristöjen tai teknisten vaiheiden ”paperiharjoitusten” avulla, keskittyen tiimien ja järjestelmien vuorovaikutukseen.
Tekniset harjoitukset: – kohdennetut testit alemmissa ympäristöissä, kuten tahallinen vikasietoisuustestaus ei-tuotantotietokannan kautta tai identiteetintarjoajan vikaantumisen simulointi hiekkalaatikossa.
Osittaiset tai rinnakkaiset vikasietoisuudet: – ohjaamalla osan liikenteestä varasivustolle tai -ratkaisuun samalla, kun valvot toimintaa, ja laatimalla selkeän peruutussuunnitelman, jos jokin näyttää vaaralliselta.
Täydelliset vikasietoisuudet: – tuotannon täydellinen vaihtaminen, tyypillisesti varattu organisaatioille, joilla on korkea kypsyysaste, vahvat palautussuunnitelmat ja selkeä johdon hyväksyntä.

Sinun ei tarvitse hypätä suoraan täyteen tuotantotilan vikasietoisuuteen oppiaksesi hyödyllisiä asioita. Aloittaminen pöytäharjoituksista ja syvyyden ja teknisen realismin lisääminen ajan myötä antaa yleensä paremman tasapainon oivalluksen ja riskin välillä ja antaa sinulle mahdollisuuden edetä uralla itseluottamuksesi ja kypsyytesi kasvaessa.

Visuaalinen: yksinkertainen tikapuukaavio, joka näyttää etenemisen pohjalla olevista pöytäkeskusteluista simulaatioiden ja teknisten harjoitusten kautta yläosassa oleviin osittaisiin ja täydellisiin vikasietoisuuksiin kapasiteetin kasvaessa.

Voit myös ilmaista harjoitustyyppien, tavoitteiden ja suhteellisen riskin välisen suhteen tiiviisti vertaillen.

Tämä yleiskatsaus auttaa sinua valitsemaan sopivat harjoitustyypit nykyisen kypsyystasosi ja riskinottohalukkuutesi mukaan ja näkemään, miten voit siirtyä kohti kunnianhimoisempia testejä ajan myötä.

Harjoituksen tyyppi	Päätavoite	Suhteellinen riskitaso
Pöytälevy	Selvennä päätöksiä, rooleja ja viestintää	Matala
Läpikäynti / simulaatio	Prosessin ja luovutusten validointi	Matala–keskitaso
Tekninen harjoitus	Testaa tiettyjä ohjausobjekteja tai suorituskirjoja	Keskikova
Osittainen/rinnakkainen vikasieto	Vikasietopolkujen validointi turvaverkon avulla	Keski-korkea
Täysi vikasietoisuus	Todista kokonaisvaltainen joustavuus	Korkea

Tämä taulukko ei ole resepti, vaan opas. Voit muokata omaa kokoonpanoasi ajan myötä tiimien itseluottamuksen kasvaessa ja sääntelyviranomaisten, asiakkaiden tai riskikomitean odottaessa suorempia osoituksia resilienssistä.

Riskien hallinta ennen testejä, niiden aikana ja niiden jälkeen

Merkittävän muutoksena käsitteleminen auttaa hallitsemaan riskejä ja rauhoittamaan ylemmän tason sidosryhmiä. Kun testit suunnitellaan, hyväksytään ja niitä seurataan kuten mitä tahansa muuta merkittävää muutosta, johtajat todennäköisemmin tukevat niitä ja yllättyvät vähemmän sivuvaikutuksista.

Intrusiivisempien testien osalta käsittele itse harjoitusta kontrolloituna muutoksena:

Ennen: – hankittava johdon hyväksyntä, suoritettava riskinarviointeja, sovittava selkeät ”ei-mene”- ja ”pysäytys”-kriteerit ja ajoitettava testit ruuhka-aikojen ulkopuolelle.
Aikana: – seurata keskeisiä indikaattoreita, kuten järjestelmän suorituskykyä, virhemääriä ja asiakasvaikutuksia, ja antaa nimetyille henkilöille valtuudet keskeyttää tai keskeyttää harjoitus, jos kynnysarvot ylittyvät.
Jälkeen: – pidä jälkipuintikeskusteluja niin kauan kuin muistot ovat tuoreet, kirjaa ylös, mikä toimi ja mikä ei, ja sovi välittömistä toimenpiteistä havaittujen heikkouksien korjaamiseksi.

Voit lainata ideoita myös kaaostekniikan ja punaisen tiimin menetelmistä. Kaaostekniikan menetelmä tarkoittaa pienten, hallittujen vikojen tarkoituksellista injektoimista ei-tuotantoympäristöihin piilevien riippuvuuksien paljastamiseksi. Punainen tiimin menetelmä tarkoittaa realistisen hyökkääjän käyttäytymisen simulointia sen selvittämiseksi, miten tietoturva- ja jatkuvuustiimit koordinoivat toisiaan. Valitsetpa minkä tahansa yhdistelmän, avainasemassa on varmistaa, että jokainen testi on turvallinen, tarkoituksellinen ja hyvin hallittu eikä ad hoc -kokeilu, joka huolestuttaa liiketoimintaa.

Miten todistat tilintarkastajille, että jättipottitestaus todella toimii?

Todistat jättipottitestauksen toimivuuden yhdistämällä pienen, merkityksellisen mittariston jäsenneltyihin, auditointivalmiisiin todistepaketteihin. Tilintarkastajat, sääntelyviranomaiset ja suuret asiakkaat haluavat nähdä, että olet valinnut sopivat skenaariot, saavuttanut järkevät tavoitteet ja käyttänyt tuloksia kontrollien ja prosessien vahvistamiseen. He eivät odota täydellisyyttä, mutta he odottavat selkeää ja toistettavaa tapaa osoittaa kyvykkyys ja parannus.

Testien suunnittelu ja suorittaminen on tärkeää, mutta se on vasta puolet työstä. Toinen puoli on testien muuttaminen narratiiviseksi kokonaisuudeksi, joka on järkevä varmennussidosryhmille: mitkä vakavat skenaariot valittiin, mitä pyrittiin todistamaan, miten onnistumista mitattiin ja mitä muutettiin sen seurauksena.

Määrittele pieni, merkityksellinen mittarijoukko

Pieni ja vakaa mittaristo kertoo sinulle ja tilintarkastajille, paraneeko vakavien skenaarioiden hallintakykysi ajan myötä. Et tarvitse kymmenien mittareiden kojelautaa; kourallinen hyvin valittuja indikaattoreita riittää yleensä osoittamaan, oletko oikealla tiellä.

Jackpot-tapahtumien jatkuvuustestauksessa hyödyllisiä mittareita ovat usein:

RTO ja RPO-saavutus: – palautitko tiedot liiketoiminta-analyysissäsi sovitussa ajassa ja sovittujen tietojen menetystä koskevien tavoitteiden puitteissa.
Aktivointiaika: – kuinka kauan kesti tunnistaa tilanne ja käynnistää virallinen jatkuvuus- tai kriisisuunnitelma, esimerkiksi pyrkiä aktivoimaan se tietyn ajan kuluessa tapahtuman vahvistamisesta.
Päätöksenteon nopeus ja laatu: – olivatko oikeat ihmiset mukana ja tehtiinkö keskeiset päätökset ajoissa asianmukaisia tietoja käyttäen.
Viestinnän tehokkuus: – tiedotettiinko sisäisille sidosryhmille, asiakkaille, toimittajille ja sääntelyviranomaisille oikea-aikaisesti ja asianmukaisesti.
Ohjauksen suorituskyky: – toimivatko tietyt kontrollit, kuten varmuuskopiointi, vikasietoisuus tai pääsynhallinta, suunnitellusti stressitilanteissa.

Pieni joukko mittareita, jotka on valittu huolellisesti ja sovellettu johdonmukaisesti, antaa sinulle terävämmän kuvan kyvyistäsi ja selkeämmän pohjan tarkastuksille. Se auttaa myös välttämään vaikuttavilta vaikuttavien lukujen jahtaamista, jotka eivät muuta sijoitus- tai valmistautumistapaasi.

Kerää todisteita auditointivalmiisiin harjoituspaketteihin

Auditointivalmiit harjoituspaketit muuttavat raakatestien aktiviteetit jäsennellyksi todistusaineistoksi, jota voit jakaa luottavaisin mielin. Ne myös tehostavat omia sisäisiä tarkastuksiasi kokoamalla kaiken, mitä päätöksentekijät tarvitsevat, yhteen paikkaan.

Pyri jokaista jättipottitestiä varten laatimaan harjoituspaketti, joka sisältää:

hyväksytty testaussuunnitelma ja -tavoitteet
skenaarion kuvaus ja laajuus
läsnäololistat ja roolien jako
tapahtumien ja käytettyjen "injektioiden" aikajana
lokit, kuvakaappaukset ja vastaavat esineet, jotka näyttävät tärkeimmät toteutetut vaiheet
testitulokset kutakin onnistumiskriteeriä ja mittaria vasten
ongelmia ja havaintoja
sovitut toimenpiteet, omistajat ja määräajat.

Kun tämä materiaali sijaitsee jäsennellyssä arkistossa hajallaan olevien sähköpostien ja diaesitysten sijaan, voit vastata nopeasti auditointipyyntöihin, jotka koskevat ISO 27001 -valvontaa ja -uudelleensertifiointia, ISO 22301 -standardin mukaisia tai toiminnan sietokykyarviointeja, asiakkaan tuntemisvelvollisuutta ja sisäisiä varmennustoimia. Alustat, kuten ISMS.online, voivat auttaa sinua pitämään nämä paketit suoraan yhteydessä riskeihin, kontrolleihin ja käytäntöihin, jotta todisteesi pysyvät jäljitettävinä ja helposti esitettävinä.

Visuaalinen: yksinkertainen yhden sivun harjoituksen yhteenvetomalli, jossa on osiot skenaariolle, tavoitteille, aikajanalle, mittareille, keskeisille havainnoille ja sovituille toimenpiteille, joita voit käyttää uudelleen eri testeissä ja auditoinneissa.

Rakennat myös organisaatiosi muistia. Uudet jäsenet ja tulevat johtajat näkevät, miten organisaatio suoriutui stressin alla, eivätkä vain sitä, mitä dokumenteissa sanotaan tapahtuvan. Tämä historia vahvistaa uskottavuuttasi sekä sisäisten että ulkoisten sidosryhmien silmissä ja tukee luottavaisempia keskusteluja tilintarkastajien kanssa, jotka haluavat nähdä näyttöä oppimisesta, eivätkä vain toiminnasta.

ISMS.online tukee yli 100 standardia ja sääntöä, mikä tarjoaa sinulle yhden alustan kaikkiin vaatimustenmukaisuustarpeisiisi.

Varaa esittelysi

Miten muutat jättipottitapahtumien testit jatkuvaksi parantamiseksi?

Muutat jättipottitapahtumien testit jatkuvaksi parantamiseksi antamalla jokaiselle löydökselle selkeän hoitopolun ja testaamalla sitten uudelleen tarkistaaksesi, että muutokset toimivat. ISO 27001 ja ISO 22301 tarjoavat jo poikkeamien, korjaavien toimenpiteiden ja johdon tarkastusten silmukat. Tehtäväsi on varmistaa, että harjoitusten löydökset kulkevat näiden silmukoiden läpi sen sijaan, että ne jäisivät kokousmuistiinpanoihin.

Testi, joka paljastaa heikkouksia, mutta ei koskaan johda toimiin, on arvoltaan rajallinen. Testi, joka johtaa selkeisiin korjaaviin toimenpiteisiin, päivitettyihin toimintasuunnitelmiin ja seurantaharjoituksiin, osoittaa tilintarkastajille, sääntelyviranomaisille ja asiakkaille, että suhtaudut vakavasti resilienssiin etkä vain rastita ruutuja. Se auttaa myös osoittamaan ISO 27001 -standardin kohdan 10 parantamisen tarkoituksen, jossa odotetaan oppivan poikkeamista ja harjoituksista.

Havainnoista korjaaviin ja parannustoimenpiteisiin

Voit siirtyä raaoista havainnoista todellisiin parannuksiin luokittelemalla näkemäsi ja liittämällä sen olemassa oleviin riski- ja parannusprosesseihisi. Tällä tavoin mikään ei katoa keskustelutilaisuuden ja seuraavan johdon katselmuksen välillä.

Jokaisen harjoituksen jälkeen:

Vaihe 1 – Luokittele löydökset

Erottele yksinkertaiset havainnot, jotka kuvaavat, mikä meni hyvin, aidoista heikkouksista, kuten puuttuvasta tiedosta, epäselvistä rooleista tai epäonnistuneista kontrolleista. Positiivisilla havainnoilla on edelleen merkitystä, mutta ne eivät yleensä vaadi samanlaista seurantaa.

Vaihe 2 – Hoitopolku

Päätä, onko kukin heikkous poikkeama omista käytännöistäsi tai ISO-lausekkeista, parannusmahdollisuus vai tietoisesti hyväksytty riski. Säännellyillä aloilla sinun on ehkä osoitettava, että tiettyjä ongelmia käsitellään muodollisina poikkeamina, joihin liittyy selkeät korjaavat toimenpiteet.

Vaihe 3 – Rakenteelliset toimenpiteet

Kirjaa jokainen kohde omistajan, määräpäivän ja linkin kera asiaankuuluvaan riskiin, kontrolliin tai asiakirjaan, jotta se ei katoa kokousten välillä. Käytä ISMS- tai BCMS-työkalujasi erillisten seurantajärjestelmien sijaan aina kun mahdollista, jotta kaikki pysyy yhdessä hallintajärjestelmässä.

Vaihe 4 – Seuranta sulkemiseen

Sisällytä toimenpiteitä säännöllisiin riski- ja parannusarviointeihin ja päivitä niiden tilaa, kunnes ne ovat valmiita, sen sijaan, että käsittelisit harjoitusraportteja staattisina asiakirjoina. Yhdistä merkittävät havainnot virallisiin riskimerkintöihin ja tarvittaessa sovellettavuuslausuntoosi, jotta skenaariosta havaintoihin ja muutokseen siirtymisen ketju on helppo osoittaa.

Tämä kurinalainen lähestymistapa tarkoittaa, että kun tilintarkastajat kysyvät, miten olet tunnistanut ja käsitellyt tiettyjä riskejä, voit osoittaa konkreettisia esimerkkejä anekdoottien sijaan. Se auttaa myös ylempää johtoa ja hallituksia näkemään, että jättipottitapahtumien testaus on osa jatkuvaa parantamisprosessia, ei satunnainen "sotapeli".

Uudelleentestaus ja ohjelmatason oppiminen

Uudelleentestaus ja säännöllinen tarkastelu auttavat sinua näkemään, paraneeko organisaatiosi todella jackpot-tapahtumien käsittelyssä. Parannus ei niinkään tarkoita useampien harjoitusten suorittamista vaan pikemminkin sen osoittamista, että kykykäyräsi taipuu oikeaan suuntaan.

Vakavien puutteiden varalta suunnittele uudelleentestaukset:

toista sama skenaario, kun muutokset on toteutettu
tai ajaa variantti, joka korostaa samaa ominaisuutta hieman eri tavalla.

Ohjelmatasolla, ota askel taaksepäin joka vuosi tai kaksi ja kysy itseltäsi seuraavanlaisia kysymyksiä:

Näetkö samoja ongelmaluokkia toistuvasti, kuten heikkoa viestintää tai epäselviä päätösoikeuksia?
Vastaavatko skenaariosi edelleen nykyistä arkkitehtuuriasi, toimittajiasi ja sääntelyyn liittyviä velvoitteitasi?
Kehitytkö riskinottohalukkuutesi ja sääntelyviranomaisten edellyttämällä nopeudella?

Käytä vastauksia testauskalenterisi, investointiprioriteettiesi ja koulutuksen painopisteesi mukauttamiseen. Ajan myötä toistuvien ongelmien pitäisi vähentyä, ratkaisut nopeutuvat ja sidosryhmien luottamus kasvaa siihen, että vakavia skenaarioita hallitaan kurinalaisesti sen sijaan, että ne olisivat satunnaisia harjoituksia ilman jatkotoimia.

Miten saat kaiken tämän yhteen paikkaan?

Yhdistät kaiken käyttämällä yhtä, jäsenneltyä ympäristöä riskien, skenaarioiden, suunnitelmien, testien ja toimenpiteiden yhdistämiseen. Jättipottitapahtumatestaus koskettaa monia liikkuvia osia: riskinarviointia, liiketoiminta-analyysia, jatkuvuussuunnitelmia, tapausten hallintaa, teknisiä suorituskirjoja, testisuunnitelmia, lokeja ja toimenpiteiden seurantaa. Kun nämä sijaitsevat eri työkaluissa ja jaetuissa kansioissa, ihmiset tuhlaavat aikaa tiedon jahtaamiseen ja tilintarkastajat näkevät epäjohdonmukaisen kuvan. Yhdistäminen saa vakavien skenaarioiden työt tuntumaan osalta normaalia hallintoa eikä erityisprojektilta.

Yhtenäinen ympäristö parantaa myös selviytymiskykyä henkilöiden muuttojen välillä. Kun avainhenkilöt lähtevät tai roolit vaihtuvat, hyvin jäsennelty sisältö ja todisteet pysyvät saatavilla ja ymmärrettävissä sen sijaan, että ne katoaisivat henkilökohtaisiin ajatuksiin tai lukemattomiin esityksiin.

Mitä hyvän alustan tulisi tarjota sinulle

Erillisen tietoturvallisuuden hallintajärjestelmän tai integroidun tietoturvallisuuden hallintajärjestelmän/yrityksen liiketoiminnan hallintajärjestelmän (TBMS) tulisi tehdä jättipottitestauksesta osa jokapäiväistä käytäntöä, ei erillistä yhden tiimin harjoitusta. Tavoitteena on yhdistää hallintorakenne, skenaariot, harjoitukset ja todisteet tavalla, joka on helppo toteuttaa ja selittää tilintarkastajille, sääntelyviranomaisille ja ylemmälle johdolle.

Käytitpä sitten ISMS-kohtaista alustaa, kuten ISMS.onlinea tai muuta työkalupakkia, etsi mahdollisuuksia:

linkitä riskit, kontrollit, varat, palvelut ja skenaariot yhteen malliin, jotta näet, miten jättipottitapahtuma etenee organisaatiossa
tallentaa BC- ja tapauskohtaiset suorituskirjat ISO 27001- ja ISO 22301 -dokumentaation rinnalla selkeällä versionhallinnalla ja hyväksynnöillä
suunnittele ja aikatauluta harjoituksia selkeällä omistajuudella, hyväksymisreiteillä ja näkyvällä testauskalenterilla
liitä todisteita suoraan testitietoihin, kuten lokitietoja, kuvakaappauksia, pöytäkirjoja ja päätöksiä, jotta sinun ei tarvitse selailla postilaatikoita auditoinnin aikana
Seuraa havaintoja ja korjaavia toimenpiteitä aina päätökseen asti, tilan näkyessä johdolle ja raportoitaessa helposti
luoda tarkastusvalmiita raportteja, jotka osoittavat tarkalleen, miten jättipottiskenaarioita tunnistetaan, testataan ja parannetaan.

Esimerkiksi ISMS.online on suunniteltu tarjoamaan sinulle yhden totuuden lähteen ISO 27001 -standardille ja siihen liittyville viitekehyksille. Jättipottiskenaarioista tulee sitten vain yksi hyvin hallittu riskikategoria yksittäisen laskentataulukon erityisprojektin sijaan, ja tiimisi voivat käyttää enemmän energiaa hyvään skenaarioiden suunnitteluun ja seurantaan. Käytitpä sitten ISMS.onlinea tai jotain muuta alustaa, kaava on sama: yhdistä hallinto, skenaariot, testit ja toimenpiteet siten, että vakavien tapahtumien sietokyky on osa normaalia hallintajärjestelmääsi.

Käytännönläheinen seuraava askel

Käytännöllinen seuraava askel on todistaa malli kerran alusta loppuun yhdessä skenaariossa ja sitten skaalata sitä vähitellen. Et tarvitse kokonaista ohjelmaa parantamisen aloittamiseen; tarvitset vain yhden hyvin valitun testin, joka kattaa koko matkan riskien tunnistamisesta uudelleentestaukseen.

Jos haluat siirtyä teoriasta käytäntöön ylikuormittamatta organisaatiotasi:

Valitse yksi tai kaksi jättipottiskenaariota, jotka todella huolestuttavat sinua.
Yhdistä ne tietoturvan hallintajärjestelmäsi (ISMS) ja liiketoiminnan hallintajärjestelmän (BCMS) osioihin – riskirekisteriin, liiketoiminta-analyysiin (BIA) ja suunnitelmiin.
Suunnittele vaatimaton testi, kuten monialainen pöytämalli, jolla on selkeät tavoitteet ja näyttöön liittyvät vaatimukset.
Suorita harjoitus, kirjaa ylös tapahtuneet asiat ja sovi muutamista konkreettisista toimenpiteistä.
Säilytä kaikki yhdessä jäsennellyssä työtilassa, mieluiten erillisessä ISMS/BCMS-ympäristössä, kuten ISMS.online, jotta voit näyttää tarkalleen, mitä teit.

Kun olet todistanut kyseisen kaavan alusta loppuun, voit laajentaa skenaariojoukkoa, tarkentaa mittareitasi ja rakentaa monivuotisen testaussuunnitelman. Ajan myötä jättipottitapahtumat lakkaavat olemasta abstrakti pelko ja niistä tulee hyvin hallittu osa ISO-standardien mukaista kriisinsietokykyohjelmaasi. Tämä antaa sinulle paremmat valmiudet vastata sääntelyviranomaisten ja asiakkaiden vaikeisiin kysymyksiin ja luottaa siihen, että organisaatiosi pystyy selviytymään, kun useita huonoja asioita tapahtuu samanaikaisesti.

Varaa demo

Usein Kysytyt Kysymykset

Miten "jackpot-tapahtumia" tulisi käsitellä ISO 27001 -standardin mukaisessa tietoturvan hallintajärjestelmässä (ISMS) ja liiketoiminnan hallintajärjestelmässä (BCMS)?

Sinun tulisi käsitellä jättipottitapahtumia nimettyinä, vaikutteisina riskeinä, jotka kulkevat läpi normaalin ISO 27001- ja (jos käytössä) ISO 22301 -elinkaaresi, eikä epämääräisinä reunatapauksina, jotka on sijoitettu tietoturvanhallintajärjestelmäsi ulkopuolelle. Ne sijaitsevat nykyisen riskispektrin ääripäässä ja ansaitsevat selkeät omistajat, käsittelyt ja testit.

Mikä tekee jackpot-tapahtumasta erilaisen kuin tavallisen "huonon päivän"?

Useimmat tapaukset kohdistuvat yhteen järjestelmään, tiimiin tai toimittajaan, ja ne voidaan hallita tutuilla toimintaohjeilla. Jättipottitapahtumassa yhdistyy yleensä kolme asiaa kerralla:

Useita rinnakkaisia vikoja: – esimerkiksi ensisijaisen pilvialueen käyttökatkos, merkittävä SaaS-häiriö ja avainhenkilöstö tai palvelukumppani ei ole tavoitettavissa samana päivänä.
Pidempi kesto kuin suunniteltu: – normaalit kiertotavat alkavat purkautua, palvelutasosopimuksia rikotaan ja ilmaantuu toissijaisia riskejä.
Tiivis kytkentä palveluiden ja toimittajien välillä: – joten yksi vika leviää nopeasti sovelluksiin, tiimeihin ja sijainteihin.

Yksinkertainen lakmustesti, jota monet tietoturvajohtajat ja jatkuvuusjohtajat käyttävät, on:

Jos tämä skenaario menee huonosti, voimmeko menettää toimilupamme, rikkoa säännöksiä tai menettää ankkuriasiakkaamme?

Jos rehellinen vastaus on kyllä, kyseessä on jättipottitilanne, etkä vain rankka aamu.

ISO 27001 -standardin mukaan tähän ei tarvita uutta luokkaa. Sinun tulisi:

luoda eksplisiittiset riskimerkinnät ISO 27001 -standardin mukaisessa riskirekisterissäsi näitä skenaarioita varten (kohta 6), selkeät omistajat ja käsittelytavat mukaan lukien
heijasta niitä omassa liiketoimintavaikutusten analyysi ja jatkuvuusstrategia, jos käytät ISO 22301 -standardia
muuta ne testattavat tavoitteet, joten johtamispäätökset ja tiimien välinen koordinointi harjoitellaan, ei improvisoidaan.

Tuo kuri muuttaa "painajaismaiset skenaariot" hallituiksi riskeiksi, joita voit selittää tilintarkastajille, sääntelyviranomaisille, hallituksellesi ja suurimmille asiakkaille.

Missä tarkalleen ottaen jackpot-tapahtumien tulisi sijaita ISO 27001- ja ISO 22301 -standardeissa?

Voit ankkuroida vakavat skenaariot selkeästi lausekkeisiin, joiden kanssa jo työskentelet:

ISO 27001, kohta 4 – Konteksti ja asianosaiset:

Kirjaa ylös rakenteelliset riskit, jotka tekevät jättipoteista uskottavia: keskittyminen pilvi- tai datakeskuksiin, riippuvuus yhdestä identiteetintarjoajasta, kriittisen infrastruktuurin tila, tiukat käyttöaikatakuut tai toiminnan sietokykyä koskevat säännöt. Tämä selittää miksi erityiset skenaariot ovat soveltamisalaan kuuluvia.

6 § – Tietoturvariskien arviointi ja käsittely:

Rekisteröi pahimmat uskottavat skenaariosi suuria riskejäKäytä skenaariopohjaisia, laadullisia asteikkoja ("harvinainen mutta katastrofaalinen") näennäistarkkojen frekvenssien sijaan ja linkitä käsittelytavat arkkitehtuurin, toimittajastrategian, harjoitusten ja hallinnon välillä.

8 § – Käyttö:

Varmista toimintatavat, katastrofien jälkeiset palautumismenettelyt ja liiketoiminnan jatkuvuuden turvaaminen nimeä parhaat jättipottiskenaariosi, ei vain yksittäisten järjestelmien vikoja. Suorituskirjojen, testisuunnitelmien ja muutostietojen tulisi osoittaa, miten odotat toimivasi, kun useita asioita menee pieleen samanaikaisesti.

9 ja 10 kohta – Suorituskyvyn arviointi ja parantaminen:

Käsittele vakavien skenaarioiden harjoituksia sisäisen tarkastuksen, johdon tarkastelun, poikkeamien ja korjaavien toimenpiteiden syötteenä. Suunnittele uusintatestejä sen osoittamiseksi, että aiempien harjoitusten muutokset on otettu käyttöön.

Jos käytät myös ISO 22301:

tuo jättipottiskenaarioita omaan liiketoimintavaikutusten analyysi, jatkuvuusstrategia ja harjoitusohjelma
näytä johdonmukainen ketju konteksti → riski → vaikutus → strategia → suunnitelmat → testit → parannus pienelle määrälle suuria vaikutuksia omaavia tapahtumia.

Käyttämällä yhtä ympäristöä, kuten ISMS.online tekee tästä paljon helpompaa. Voit pitää jättipottiriskejä muiden ISO 27001 -riskien rinnalla, linkittää ne liiketoiminta-analyysiin, jatkuvuussuunnitelmiin ja -harjoituksiin sekä tallentaa todisteet yhteen paikkaan. Tällä tavoin pahimman päivän suunnittelusta tulee osa normaalia tietoturvan hallintajärjestelmääsi/toiminnan jatkuvuuden hallintajärjestelmääsi, eikä se ole erillinen ajatuskoe, joka elää vain dioissa.

Kuinka voit suunnitella realistisia jättipottitapahtumien testejä asettamatta tuotantoa kohtuuttomalle riskille?

Suunnittelet turvallisia ja realistisia jättipottitapahtumien testejä aloittamalla kriittisimmistä palveluistasi, sopimalla "uskottavimmista" skenaarioista ja valitsemalla harjoitustyyppejä, jotka painottavat päätöksentekoa ja valvontaa ylittämättä kuitenkaan riskinottohalukkuuttasi.

Miten määrittelet "huonoimmat uskottavat" jättipottiskenaariot keskeisille palveluillesi?

Aloita niistä palveluista, joita käytät ei todellakaan ole varaa hävitä pitkään aikaan, esimerkiksi:

tulojen kannalta kriittiset alustat, kuten kaupankäynti-, maksu-, varaus- tai toimitusjärjestelmät
hengenpelastus-, turvallisuus- tai kliinisen hoidon järjestelmät
asiakkaiden ja työvoiman identiteetti- ja käyttöoikeuspalvelut
keskeiset sääntely-, selvitys- tai raportointipalvelut.

Kartoita jokaiselle kolme elementtiä:

Sietämätöntä haittaa: – rajat, joita ei voida ylittää: pitkäaikainen käyttökatkos, vakavat turvallisuusriskit, tietyt määräysten rikkomukset tai merkittävät sopimussakot.
Kriittiset riippuvuudet: – konkreettiset pilvialueet, tietovarastot, verkkopolut, kolmannen osapuolen alustat ja asiantuntijaroolit, joihin palvelu perustuu.
Uskottavat epäonnistumisyhdistelmät: – realistisia monitekijäisiä tapahtumia ympäristössäsi, kuten ”ensisijaisen pilvialueen menetys ja pitkäaikainen tallennustilanne” tai ”tunnistepalvelun käyttökatkos suuren salasanan vaihdon aikana”.

Sitten muotoile kaksi tai kolme selkokielistä jättipottiskenaariota palvelua kohdenHyödyllinen malli on:

Jos kokemuksia varten meidän on säilytettävä ainakin sisällä .

Tuo rakenne pitää testisuunnitelmasi sidottuna liiketoiminnan tulokset ja RTO/RPO-sitoumukset sen sijaan, että simuloitaisiin vain dramaattisia teknisiä katkoksia.

Mitkä harjoitustyylit antavat realismia ilman vaarallisia temppuja?

Voit lisätä realismia vähitellen sen sijaan, että hyppäisit suoraan täysiin vikasietoisuuksiin:

Pöytäharjoitukset: – monialaisia läpikäyntejä, joissa tutkitaan skenaariota, selvennetään rooleja, eskalointipolkuja ja päätöksiä. Ne ovat vähäriskisiä ja erinomaiset johtamiskäyttäytymisen testaamiseen.
Läpikäynnit ja simulaatiot: – kriittisten teknisten toimien vaiheittaiset läpikäynnit ei-tuotantoympäristöissä tai huolellisesti valvotuissa ympäristöissä sen tarkistamiseksi, että suorituskirjat ovat käytettävissä todellisella nopeudella.
Kohdennetut harjoitukset: – yksittäisten kontrollien (varmuuskopioiden palautus, DNS-muutos, todennuksen varamenetelmä) kohdennetut testit hiekkalaatikoissa tai kapeissa tuotantolohkoissa.
Osittaiset tai rinnakkaiset vikasietoisuudet: – pienen, huolellisesti valitun osan liikenteestä ohjaaminen toissijaisille reiteille selkeän peruutussuunnitelman avulla.
Täydelliset vikasietoisuudet: – kaiken liikenteen siirtäminen varapoluille, kun sinulla on jo hyvä valvonta, hallinta ja näyttöjä pienemmistä testeistä.

Kaikki tuotantoon mahdollisesti vaikuttavat testit tulisi suorittaa muodollinen muutos, ISO 27001- ja ISO 22301 -odotusten mukainen:

tee harjoituksen muutos-/riskinarviointi
asetettu eksplisiittisiksi keskeytyskriteerit ja nimeä henkilö, jolla on valtuudet keskeyttää testi
Vältä ruuhka-aikoja ja muita tunnettuja riskialttiita ajanjaksoja
varmista, että oikeat tekniset ja liiketoimintaan liittyvät päätöksentekijät ovat käytettävissä koko ajan.

Jos käytät ISMS.onlineVoit linkittää jokaisen skenaarion sen riskimerkintään, muutostietueeseen, testiskriptiin, todisteisiin ja parannustoimenpiteisiin. Tämä antaa sinulle toistettavan mallin jättipottitapahtumien testaukselle ja selkeän yhdenmukaisuuden tietoturvanhallintajärjestelmäsi ja liiketoimintahallinnan (BCMS) kanssa ilman, että tuotannossa tarvitaan vaarallisia "kaaos"-kokeita.

Mitkä ISO 27001- ja ISO 22301 -standardien vaatimukset ovat tärkeimpiä jackpot-tapahtumien suunnittelussa?

Tärkeimmät vaatimukset ovat ne, jotka muokkaavat tapaasi ymmärrä kontekstisi, arvioi äärimmäiset riskit, käytä jatkuvuuskontrolleja ja todista parannuksetEt tarvitse ylimääräisiä standardeja; sinun on varmistettava, että pahimmat uskottavat skenaariosi kattavat kaikki jo noudattamasi skenaariot.

Mitä ISO 27001 -lausekkeita sinun tulisi korostaa vakavissa skenaarioissa?

Viisi aluetta ovat erityisen hyödyllisiä:

4 § – Organisaation ja sidosryhmien tausta:

Kuvaile ulkoisia ja sisäisiä tekijöitä, jotka tekevät jättipottiskenaarioista merkityksellisiä: keskittyminen yhteen pilvipalveluntarjoajaan, rajat ylittävät tietovirrat, sääntelyyn liittyvät käyttöaikavelvoitteet tai riippuvuus pienestä määrästä kriittisiä toimittajia.

6 § – Riskienarviointi ja -käsittely:

Mukauta menetelmääsi niin, että se pystyy järkevästi käsittelemään epätodennäköiset, mutta vaikuttavat tapahtumatSe tarkoittaa yleensä:

käyttämällä strukturoituja skenaariokuvauksia hauraiden numeeristen frekvenssiarvioiden sijaan
soveltamalla laadullisia vaikutusluokkia, kuten ”vakava”, ”merkittävä” ja ”katastrofaalinen”
määrittelemällä hoitoja, jotka kattavat teknologian, ihmiset, sopimukset ja harjoitukset.

8 § – Käyttö:

Varmista toimintamenettelysi ja jatkuvuussuunnitelmasi viittaa nimenomaisesti vakaviin skenaarioihin, ei vain yksittäisten komponenttien vikoja. Vakavien tapahtumien tulisi ohjata todellisia harjoituksia, joilla on selkeät tavoitteet ja onnistumiskriteerit.

9 § – Suorituskyvyn arviointi:

Päätä etukäteen, miten arvioit valmiutta ja suoritusta jättipottitapahtumissa: RTO/RPO-tulokset, suunnitelmien käynnistämiseen kuluva aika, tiimien välisen viestinnän laatu, käyttäytymisen hallinta stressitilanteissa.

10 § – Parannus:

Varmista, että vakavien skenaarioiden testien löydökset näkyvät poikkeamina, korjaavina toimenpiteinä ja suunniteltuina muutoksina, ja että testaat uudelleen varmistaaksesi niiden tehokkuuden.

Asiaankuuluvat liitteen A mukaiset kontrollit (varmuuskopiointi, redundanssi, lokinluku, valvonta, toimittajasuhteet, kapasiteetin hallinta, pääsynhallinta, ICT-valmius liiketoiminnan jatkuvuuden varmistamiseksi) antavat sinulle käytännölliset koukut näiden skenaarioiden muuttamiseen konkreettiseksi suunnittelu- ja testaustyöksi.

Kuinka ISO 22301 auttaa sinua tekemään jättipottisuunnittelusta vankempaa?

Jos käytät virallista BCMS-järjestelmää, ISO 22301 lisää hyödyllisen rakenteen:

Liiketoimintavaikutusten analyysi (BIA): – mallintaa, miten monimutkaiset, usean palvelun tai usean toimipisteen kattavat käyttökatkokset vaikuttavat ajan myötä kuhunkin kriittiseen prosessiin ja millä kynnysarvoilla (taloudellisilla, turvallisuuteen liittyvillä, sääntelyyn liittyvillä) on eniten merkitystä.
Jatkuvuusstrategiat: – valita teknologian, manuaalisten kiertoteiden ja sopimusjärjestelyjen yhdistelmiä, jotka pätevät myös silloin, kun useampi kuin yksi oletus pettää.
Harjoitukset ja kokeet: – suunnittele erilaisia harjoituksia, joissa skenaario ja tavoitteet viittaavat selvästi jättipottiriskeihisi ja BIA-tarjouksiisi.

Tilintarkastajien ja sääntelyviranomaisten vaikutuksen tekevät organisaatiot voivat osoittaa yksinkertaisen ja toistettavan ketjun konteksti ja riski kautta vaikutus ja strategia että suunnitelmat, harjoitukset ja parannustoimet vakaviin skenaarioihinsa.

Käyttäminen ISMS.online ISO 27001- ja ISO 22301 -standardien yhteinen hallinta helpottaa ketjun havainnollistamista. Voit linkittää jokaisen jättipottiriskin sen liiketoiminta-analyyseihin, strategioihin, jatkuvuussuunnitelmiin, testitietoihin ja korjaaviin toimenpiteisiin ja noutaa kyseisen tiedon minuuteissa, kun hallituksen jäsen, asiakas tai tilintarkastaja kysyy, miten olet varautunut erittäin huonoihin päiviin.

Kuinka usein jättipottitapahtumien skenaarioita tulisi testata, ja mitkä todisteet todella vakuuttavat tilintarkastajat ja hallitukset?

Useimmat organisaatiot hyötyvät ainakin yhdestä merkittävästä jättipottiharjoituksesta vuosittain kriittisimpien palveluidensa osalta, ja sitä tuetaan useammin järjestettävillä kohdennetuilla harjoituksilla. Tärkeintä on, että aikataulusi vastaa tarpeitasi. riskiprofiili, muutosvauhti ja sääntelyodotukset, ei yleinen ”vuosittainen testi” -sääntö.

Miten voit valita testitiheyden, joka heijastaa todellista riskiäsi?

Monilla aloilla hyvin toimiva kaava on:

Vuosittain: aja ainakin yksi joukkueiden välinen jättipottitapahtumaharjoitus keskittyen vaikuttavimpiin palveluihisi. Tavoitteena on venyttää päätöksentekoa, toimittajien hallintaa ja viestintää, ei aiheuttaa tuotantohäiriöitä niiden itsensä vuoksi.
Neljännesvuosittain tai kaksi kertaa vuodessa: ajaa kapeammat porat tiettyihin teknisiin tai menettelytapoihin liittyviin valvontatoimiin – esimerkiksi varmuuskopioiden palautukseen, DNS-muutoksiin, todennuksen varamenetelmiin, hätäviestintäreitteihin – jotta nämä ominaisuudet pysyvät tehokkaina.
Suuren muutoksen jälkeen: suunnitelma tapahtumapohjaiset testit kun tapahtuu merkittäviä arkkitehtuurimuutoksia, toimittajan vaihtoja, fuusioita tai uusia sääntelyvelvoitteita.

Jos kuulut operatiivisen sietokyvyn järjestelmien tai kriittisen infrastruktuurin sääntöjen piiriin, sinun on ehkä testattava useammin tai sääntelyviranomaisten määrittelemiä tiettyjä skenaarioita vasten. Silti sinun tulisi pystyä selittämään:

miten harjoitusrutiinisi on linjassa kohdassa 4 ja kohdassa 6 dokumentoimasi riskit
kuinka usein tarkistat ja muutat ohjelmaa johdon katselmuksissa ja sisäisissä auditoinneissa
joissa todelliset tapahtumat ovat johtaneet muutoksiin testaussuunnitelmassasi.

Tämän perustelun kirjaaminen nimenomaisesti tietoturvan hallintajärjestelmän (ISMS) tai liiketoiminnan liiketoiminnan hallintajärjestelmän (BCMS) käytäntöihin helpottaa tilintarkastajien osoittamista, että harjoitusohjelmasi on harkittu, riskiin perustuva päätös pikemminkin kuin tapa.

Mitkä toimenpiteet ja artefaktit tekevät valmiuskertomuksestasi uskottavan?

Sen sijaan, että mittaisit kaikkea, keskity pieneen, vakaaseen joukkoon indikaattoreita, jotka vastaavat kolmeen kysymykseen: Saavutimmeko tavoitteemme? Missä kohtasimme vaikeuksia? Mikä muuttui sen jälkeen?

Hyödyllisiä mittareita ovat:

RTO- ja RPO-suorituskyky: avainpalveluista kunkin jättipottitapahtuman testin aikana
aika tunnistaa tilanne: ja vedota virallisesti suunnitelmiin
aika koota päätöksentekijät ja sopia ensimmäisen aallon toimista:
ilmoitusten ajantasaisuus: asiakkaille, sääntelyviranomaisille ja sisäisille sidosryhmille tiettyjä velvoitteita vastaan
ongelmien määrä ja vakavuus: löytyi, ajoissa päättyneiden toimintojen prosenttiosuus ja se, testattiinko kyseiset korjaukset uudelleen onnistuneesti.

Tilintarkastajat ja hallitukset etsivät numeroiden takaa konkreettisia seikkoja. näyttö:

selkeät testien laajuusalueet ja tavoitteet
läsnäolo- ja rooliluettelot
lokit, kuvakaappaukset, valvontatulosteet ja muutostietueet
keskustelupöytäkirjat ja tiettyihin riskeihin ja valvontatoimiin liittyvät toiminnan seurantatyökalut.

Jos hallitset näitä esineitä ISMS.online, voit siirtyä nopeasti yleisnäkymästä taustalla oleviin yksityiskohtiin. Tämä kyky näyttää sekä yleiskatsaus että todisteet antaa hallituksille, sääntelyviranomaisille ja asiakkaille luottamusta siihen, että jackpot-tapahtumiin liittyvä työsi on kurinalainen selviytymisohjelma, ei kerran vuodessa järjestettävää paloharjoitusta.

Mitä yleisiä epäonnistumismalleja jackpot-tapahtumien testeissä esiintyy, ja miten ISO 27001 voi auttaa sinua sulkemaan ne?

Vakavat skenaarioharjoitukset paljastavat usein, että kirjalliset suunnitelmat näyttävät vahvemmilta kuin tosielämän toiminta. ISO 27001 antaa sinulle rakenteen, jonka avulla voit muuttaa nämä havainnot pysyviksi parannuksiksi sen sijaan, että toistaisit samoja heikkouksia joka kerta testatessasi.

Mitä heikkouksia organisaatiot löytävät toistuvasti vaikeissa testeissä?

Eri toimialoilla esiintyy samankaltaisia teemoja:

Piilotetut oletukset, jotka rikkoutuvat stressin alla: – esimerkiksi suunnitelmat, joissa oletetaan, että tietty henkilöstö on aina käytettävissä, että tietyt toimittajat vastaavat tietyn ajan kuluessa tai että viat ovat yksittäisiä eivätkä koske useita palveluita tai useita alueita.
Epäselvä omistajuus jättipottien suunnittelussa: – ei ole nimettyä henkilöä tai ryhmää, joka olisi vastuussa vakavien skenaarioiden testien suunnittelusta, priorisoinnista ja hyväksymisestä, joten niitä tehdään vain, kun yksi asianajaja niitä ajaa.
Suunnitelmat, joita on vaikea käyttää tällä hetkellä: – pitkiä, yleisiä jatkuvuusasiakirjoja säilytetään hajallaan olevissa paikoissa, mikä saa tiimit improvisoimaan sen sijaan, että noudattaisivat strukturoituja vaiheita.
Heikko tallenne tapahtuneesta: – harjoitukset tehdään epävirallisesti, ja keskeiset päätökset ja opit on haudattu keskustelukanaviin, mikä vaikeuttaa tarkastajille niiden muuttumien näyttämistä.
Toimenpiteiden heikko toteutus: – pureutuu löydöksiin, joista ei kirjata poikkeamia tai rahoitettuja töitä, jotta samat ongelmat ilmenevät jokaisessa merkittävässä harjoituksessa.

Näiden mallien tunnistaminen on arvokasta, koska se kertoo tarkalleen, missä sinun tulee vahvistaa tietoturvan hallintajärjestelmääsi (ISMS) ja liiketoiminnan kehittämisen hallintajärjestelmääsi (BCMS).

Kuinka ISO 27001 -standardin mukainen tietoturvan hallintajärjestelmä auttaa muuttamaan löydökset kestäväksi resilienssiksi?

ISO 27001 -standardi antaa sinulle pohjan jättipottitapahtumiin valmistautumiselle:

Riskienarviointi ja sovellettavuuslausunto (lauseke 6 ja liite A):

Kun pahimmat skenaariot dokumentoidaan riskeinä, joihin liittyy kontrollit, omistajat ja käsittelytavat, ne saavat näkyvyyttä päätöksenteossa. Arkkitehtuurimuutosten, toimittajien monipuolistamisen tai testi-investointien perusteleminen on helpompaa, koska ne ovat näkyvästi ankkuroitu riskirekisteriisi ja palvelumalliisi.

Toiminnan valvonta ja menettelyt (lauseke 8 + liite A):

Varmuuskopiointiin, redundanssiin, käyttöoikeuksiin, lokitietoihin, valvontaan, muutosten ja toimittajien hallintaan sekä liiketoiminnan jatkuvuuden ICT-valmiuteen liittyvät kontrollit muokkaavat vakavien tapahtumien etenemistä. Suunnittelemalla testejä, jotka tarkoituksella testaavat näitä kontrollitoimia yhdessä, siirrytään periaatteesta "kontrolli on olemassa paperilla" periaatteeseen "olemme nähneet tämän kontrollin toimivan – tai epäonnistuvan – realistisen rasituksen alla".

Suorituskyvyn arviointi ja parantaminen (kohdat 9 ja 10):

Kun syötät jättipottitapahtumien tuloksia sisäisiin auditointeihin, johdon arviointeihin, poikkeamien selvittämiseen ja korjaaviin toimenpiteisiin, varmistat, että löydökset johtavat rahoitettuihin ja vastuullisiin parannuksiin. Suunnitellut seurantatestit vahvistavat nämä muutokset, ja johdon arvioinnit seuraavat edistymistä ajan kuluessa.

Tämän suorittaminen alustalla, kuten ISMS.online tekee mekaniikasta paljon vähemmän vaativaa:

jättipottiriskit kulkevat rinnakkain ISO 27001 -standardin mukaisten arkipäiväisten riskien kanssa, ja niihin liittyvät kontrollit ja vastuuhenkilöt on kartoitettu.
jatkuvuus- ja tapahtumasuunnitelmat ovat ajan tasalla hyväksyntöineen ja versiohistorian kanssa, joten tiimit testaavat niitä yhtä ajantasaista lähdettä vasten
harjoitusten laajuudet, todisteet ja purkutilanteet tallennetaan strukturoituihin tietueisiin
Parannukset ja poikkeamat liittyvät suoraan tiettyihin riskeihin ja kontrolleihin, ja niillä on uudelleentestauspäivämäärät.

Tuo rakenteen ja jäljitettävyyden yhdistelmä auttaa tietoturvaviranomaisia, tietosuojavastaavia ja muita toimijoita osoittamaan hallituksille ja sääntelyviranomaisille, että heidän valmiutensa pahimpaan mahdolliseen päivään on kunnossa. systemaattinen ja parantuva, ei riippuvainen muutaman yksilön muistista tai innostuksesta.

Kuinka ISMS.online voi yksinkertaistaa organisaatiosi jättipottitapahtumien jatkuvuustestien suunnittelua, suorittamista ja todentamista?

ISMS.online voi yksinkertaistaa jättipottitapahtumien hallintaa tarjoamalla sinulle yhden paikan skenaarioiden määrittelyyn, niiden yhdenmukaistamiseen ISO 27001- ja ISO 22301 -standardien kanssa, harjoitusten koordinointiin ja kaikkien asiaankuuluvien todisteiden ja toimien säilyttämiseen yhdessä paikassa. Tämä muuttaa vakavien skenaarioiden testauksen satunnaisesta sivuprojektista osaksi jokapäiväistä hallintoa.

Miten ISMS.online tukee jackpot-skenaarioiden kokonaisvaltaista hallintaa?

Käytännössä tiimisi voi käyttää ISMS.onlinea seuraaviin tarkoituksiin:

Jackpot-riskien hyödyntäminen: muiden ISO 27001 -standardin mukaisten riskien rinnalla, mukaan lukien selkeät skenaariokuvaukset, vaikutustenarvioinnit, omistajat, kartoitetut liitteen A kontrollit ja sovitut käsittelytavat.
Ylläpidä jatkuvuus- ja tapahtumasuunnitelmia: hyväksynnöillä ja versiohistorialla, joten ihmiset työskentelevät aina viimeisimmästä sovitusta versiosta testeissä ja todellisissa tapahtumissa.
Suunnittele harjoitukset strukturoituina projekteina: , linkitettyine tehtävineen, tavoitteineen, skenaarioineen, skripteineen ja tukevine artefaktoineen, kuten kaavioineen, tietovuokarttoineen ja yhteyspuineen.
Liitä todisteita harjoitusten suoritettaessa: – lokit, kuvakaappaukset, valvontatulokset, päätökset ja pöytäkirjat voidaan kaikki verrata testitietoihin sen sijaan, että ne olisivat hajallaan eri levyillä ja keskusteluissa.
Kirjaa havainnot ja korjaavat toimenpiteet: suoraan parannustyönkulkuusi, linkitettynä tiettyihin riskeihin ja kontrolleihin, ja aikatauluta uudelleentestaukset, jotta voit osoittaa prosessin päättämisen.

Tietoturvajohtajille ja ylemmälle johdolle tämä luo yksi, yhtenäinen näkemys jackpot-tapahtumien valmiudesta. Se poistaa paljon manuaalista hallintoa ja helpottaa toistuvien harjoitusten suunnittelua ja suorittamista ammattilaisten ja tietosuojavastaavien näkökulmasta.

Kuinka tämä vahvistaa tarinaasi, jonka kerrot hallituksille, tilintarkastajille ja sääntelyviranomaisille?

Varmuuden näkökulmasta ISMS.online auttaa sinua esittämään kokonaiskuvan, joka on linjassa päätöksentekijöiden ajattelutavan kanssa:

voit osoittaa selkeän organisaatiosta tutun langan konteksti ja riskiKautta valvonta, suunnitelmat ja harjoitukset, To opitut asiat ja parannukset
voit vastata yksityiskohtaisiin kysymyksiin tietyistä skenaarioista nopeasti, koska laajuus, todisteet ja toimenpiteet tallennetaan yhdessä
voit osoittaa edistymistäsi ajan kuluessa tärkeimmissä jättipottiskenaarioissasi, etkä vain väittää, että "testaamme resilienssiä vuosittain".

Jos olet vasta tämän työn alkuvaiheessa, käytännöllinen lähtökohta on valita yksi lippulaivaskenaario – esimerkiksi pitkäaikainen käyttökatkos kriittisellä pilvialueella, joka vaikuttaa tärkeimpään asiakaslähtöiseen palveluusi – ja mallintaa se ISMS.online-palvelussa alusta loppuun: riskien kirjaaminen, kartoitetut kontrollit, jatkuvuussuunnitelmat, suunnitellut harjoitukset, todisteet ja parannustoimenpiteet.

Kun olet nähnyt, miten tuo rakenne helpottaa testin suunnittelua, suorittamista ja todistamista, on luonnollista laajentaa kaavaa. Näin siirryt toivosta, että selviäisit pahimpanakin päivänä, siihen, että pystyt osoittamaan rauhallisesti ja itsevarmasti, että olet valmistautunut, harjoitellut ja pystyt todistamaan sen silloin, kun sillä on eniten merkitystä.

Liiketoiminnan jatkuvuuden testaus jättipottitapahtumissa – ISO 27001 -standardin mukainen käsikirja