Kattava jatkuvuussuunnittelu sisältää valmius-, jatkuvuus- ja palautumissuunnitelmat, kutsumme tätä jatkuvuussuunnittelun kokonaisuudeksi. Olemme Mint Securityssä huomanneet, että terminologia ei ole täysin yhtenevä suomeksi käännetyssä dokumentaatiossa. On kuitenkin tärkeää ymmärtää eri termien erot, kun lähdetään tekemään kattavaa jatkuvuussuunnitelua. Valmiussuunnittelu (Contingency planning) on varautumista laajoihin, yhteiskunnallisiin kriiseihin, kuten sähkön jakeluverkon tai vesihuollon totaaliongelmiin. Jatkuvuussuunnittelun (Continuity planning) tarkoitus on tunnistaa yrityksen liiketoiminnalliseen jatkuvuuteen vaikuttavat tekijät sekä määritellä yrityksen liiketoiminnalliset prioriteetit häiriön tapahtuessa. Häiriötilanteista palautumisen suunnittelu (Disaster Recovery Planning) sisältää operatiiviset ohjeet ylläpidolle, miten häiriön aikana minimoidaan vahingot ja palataan normaaliin toimintaan. Kaikkia kolmea osa-aluetta voi lähestyä skenaariopohjaisella suunnittelulla.
Jokaisen yirtyksen tulisi tehdä omaan kokoluokkaansa ja riskitasoonsa soveltuva jatkuvuussuunnittelun kokonaisuus. Skenaarioiden määrittely lähtee lähes aina liiketoimintakriittisyyden määrittelystä. Organisaation on tunnistettava liiketoiminta-alueensa, jotka ovat elintärkeitä organisaation toiminnan jatkumiselle.
Valmiusuunnittelun häiriöt ovat lähes kaikille organisaatioille yhteiset ja siihen kuulu joukko esimerkkiskenaarioita, jotka päivitetään vastaamaan organisaation liiketoimintaa.
Jatkuvuussuunnittelun lähtökohtana on aina yrityksen tärkein liiketoiminta. Jatkuvuussuunnttelun skenaariot ovat myös pohjana palautumissuunnitelman skenaarioille. Jos yrityksella on insidentti- tai riskikirjanpitoa, nämä kannattaa ottaa pohjaksi jatkuvuussuunnittelua aloitettaessa. Esimerkiksi tieto tapahtuneista insidenteistä auttaa tunnistamaan skenaarioita, joita kannattaa testata säännöllisesti tai joista aiheutuneiden vahinkojen minimointia tulee harjoitella.
Palautumissuunnitelma jää usein IT:n vastuulle ja yleensä palautumissuunnitelmaan tehdään skenarioita IT:n näkökulmasta ja operatiivisiin ohjeisiin viitataan linkein. Näin saadaan luotua pohja palautumisen testaukselle, kun voidaan käyttää kirjoitettuja skenaarioita kriisiharjoitusten pohjalla. Jos organisaatiolla on jo liiketoiminnan jatkuvuussuunnitelmat, mutta IT:n sitoituminen niihin puuttuu, palautumisskenaarioiden määrittely on hyvä keino sitoa liiketoiminta ja IT yhteen.
Miltä skenaario sitten näyttää?
Esimerkiksi tältä:
”Vakava liikenneonnettomuus estää suurinta osaa työntekjöita tulemasta töihin. Kolmella Helsinkiin johtavalla pääväylällä on tapahtunut vakavia liikenneonnettomuuksia klo 07, jotka estävät kaiken liikenteen kaupunkiin. Suurin osa työntekijöistä käyttää omaa autoa ja asuu kaupungin ulkoupuolella. Aamun aikana klo 8-9 piti tehdä yöllä käyttöönotetun järjestelmän XYZ testi omalla henkilökunnalla, jotta palvelu voidaan avata asiakkaille aiemmin tiedotetun mukaisesti. Viranomaisarvio on, että kestää 3-4 tuntia ennen kuin liikenne saadaan jälleen kulkemaan.”
Skenaariolle määritelläään lisäksi mm. vaikutus, todennäköisyys, linkit mahdollisiin olemassa oleviin riskeihin ja insidentteihin sekä ensisijainen vastuullinen taho sekä vara- tai toipumissuunnitelma.
Kiinnostuitko jatkuvuussuunnittelun kokonaisuuden tai jonkin osa-alueen parantamisesta? Ota yhteyttä meihin, niin kerromme lisää.