ISO 27001 · kontinuitetsplanen
Kontinuitetsplanen, skrevet ud fra nogle få svar
En forstyrrelse er den ene dag, hvor virksomheden ikke kan skrive en plan, så auditoren beder om den, der blev skrevet før: hvor længe produktet må være nede, hvor mange data der må gå tabt, hvem der erklærer forstyrrelsen og på hvilken kanal, hvordan sikkerheden holder, mens alle genopretter, og hvornår planen sidst blev øvet; denne side skriver den plan ud fra nogle få svar, og tjenestelisten og nødkanalen bliver på siden.
Planen
Elleve afsnit i den rækkefølge, en forstyrrelse udspiller sig; et tomt felt skrives som et hul, der skal udfyldes, ikke springes over.
# Kontinuitetsplan: [virksomhed] Ejer: [planens ejer] · Godkendt af: [topledelsen] Skrevet den med den gratis side på getstandardos.com op imod foranstaltningerne i bilag A til ISO/IEC 27001:2022 om informationssikkerhed under en forstyrrelse, IKT-beredskab til forretningskontinuitet, sikkerhedskopiering af information og redundans i informationsbehandlingsfaciliteter. Formuleringen er StandardOS' egen. ## 1. Formål og omfang Denne plan siger, hvad [virksomhed] gør, når en tjeneste, den afhænger af, standser, så virksomheden holder sine tilsagn til kunderne, holder sine informationer sikre, mens den genopretter, og er tilbage inden for den tid, den har besluttet, den kan tåle. Den dækker de tjenester, der nævnes nedenfor, de mennesker, der driver dem, de data, de rummer, og de leverandører, de hviler på. De dækkede tjenester: [udfyldes, de produkter og interne systemer, virksomheden ikke kan undvære]. ## 2. Genoprettelsesmål Genoprettelsestid: hver dækket tjeneste er genoprettet inden for 24 timer efter, at forstyrrelsen er erklæret. Genoprettelsespunkt: for ingen dækket tjeneste går mere end 24 timers data tabt. De to tal er virksomhedens beslutning, ikke udbyderens løfte; en dækket tjeneste, hvis udbyder ikke kan opfylde dem, opføres med hullet og den foranstaltning, der lukker det, eller tallene ændres af den, der godkender. ## 3. Roller [planens ejer] ejer denne plan, holder den ajour og gennemfører øvelsen. [forstyrrelseslederen] leder en forstyrrelse: erklærer den, beslutter rækkefølgen for genoprettelsen, godkender enhver afvigelse fra sikkerhedsreglerne og erklærer tilbagevenden til normal drift. Stedfortrædende leder: [udfyldes]. Den, der først når nødkanalen, når lederen ikke kan nås inden for tredive minutter, handler som leder, indtil lederen eller stedfortræderen tager over. ## 4. De scenarier, planen dækker Planen er skrevet til fem måder, en tjeneste standser på; en forstyrrelse, der ikke passer på nogen af dem, håndteres med de samme roller, den samme kanal og de samme mål. - cloududbyderen eller den region, produktet kører i, er utilgængelig; - dataene er krypteret, slettet eller beskadiget, af ransomware, af en fejl eller af en dårlig udrulning; - kontoret, dets netværk eller de mennesker, der arbejder der, er utilgængelige; - en kritisk leverandør holder op med at levere, bliver angrebet eller opsiger kontrakten uden varsel; - identitetsudbyderen eller administratorkontiene er tabt eller låst. ## 5. Erklæring af en forstyrrelse og den første time Enhver, der ser en dækket tjeneste nede ud over en normal hændelse, giver besked til [forstyrrelseslederen], som erklærer forstyrrelsen, navngiver scenariet og åbner en log med tidspunktet for erklæringen. Fra det øjeblik gælder denne plan, og beredskabsplanen for hændelser fortsætter ved siden af for sikkerhedsdelen. Kanalen, når de sædvanlige værktøjer er nede: [nødkanalen, udfyldes]. Dens kontaktoplysninger opbevares, hvor de kan læses uden virksomhedens systemer, og tjekkes ved hver øvelse. I den første time fastslår lederen, hvem der er til rådighed, hvilke tjenester der er ramt, fortæller kunderne via statuskanalen, at virksomheden er bekendt med det, og hvornår næste opdatering kommer, og starter genoprettelsen i den rækkefølge, de næste afsnit fastlægger. ## 6. Sikkerhed under forstyrrelsen Adgangsreglerne, flerfaktorgodkendelsen og logningen gælder fortsat under en forstyrrelse. En afvigelse fra dem, såsom en nødkonto, en delt adgangskode eller en genoprettelse til et nyt miljø uden den sædvanlige gennemgang, godkendes af [forstyrrelseslederen], skrives i loggen med begrundelsen og rulles tilbage, så snart tjenesten er tilbage. Sikkerhedskopier og kopier, der laves under genoprettelsen, beskyttes som originalerne, og enhver genoprettelse sker fra en kopi, som den samme begivenhed, der forårsagede forstyrrelsen, ikke kan ændre. ## 7. Sikkerhedskopier, redundans og rækkefølgen for genoprettelse Hver dækket tjeneste sikkerhedskopieres mindst hver 24. time, til et sted, som tjenestens egne adgangsoplysninger ikke kan slette, og en genoprettelse fra sikkerhedskopien testes ved hver øvelse. Produktet kører i én cloudregion. Genoprettelse inden for 24 timer hviler på udbyderens redundans inden for den region og på evnen til at genopbygge tjenesten i en anden region ud fra sikkerhedskopierne og infrastrukturkoden, hvilket øvelsen tester. Rækkefølgen for genoprettelse: identiteter og adgang først, så folk kan arbejde; dernæst de tjenester, kunderne betaler for; dernæst de interne tjenester; dernæst alt andet. En tjeneste genoprettes til den seneste sikkerhedskopi inden for genoprettelsespunktet, og dataene mellem den sikkerhedskopi og forstyrrelsen indtastes igen eller hentes fra kundernes side, hvor det kan lade sig gøre. ## 8. Leverandører, kunder og myndigheder For hver kritisk leverandør noterer leverandørregistret dens kontinuitetstilsagn og den kontakt, der bruges under en forstyrrelse; en leverandør, der selv er forstyrrelsen, håndteres efter exit-reglerne i leverandørpolitikken. Kunderne informeres via statuskanalen ved erklæringen, ved hver ændring og ved tilbagevenden til normal drift, i klare ord og uden spekulation om årsagen. Hvor forstyrrelsen også er en sikkerhedshændelse, gælder fristerne i beredskabsplanen for hændelser, og lederen og hændelsesplanens leder beslutter sammen, hvad der sendes til hvem. ## 9. Tilbagevenden til normal drift og evalueringen bagefter [forstyrrelseslederen] erklærer tilbagevenden til normal drift, når hver dækket tjeneste er tilbage inden for sine mål, og afvigelserne fra sikkerhedsreglerne er rullet tilbage. Inden for ti arbejdsdage holder lederen en evaluering med de involverede, læser loggen, noterer, hvad der virkede, hvad der ikke gjorde, og hvad der ændres, og ændringerne går ind i denne plan, beredskabsplanen for hændelser eller risikoregistret. ## 10. Øvelse af planen Planen øves én gang om året, ledet af [planens ejer]: ét scenarie gennemspilles med de mennesker, der ville handle, én genoprettelse udføres fra en sikkerhedskopi, nødkanalen bruges, og den tid, hvert trin tog, skrives ned op imod målene. En øvelse, der ikke når et mål, er ikke en fejlslagen øvelse; den er det fund, planen findes for at frembringe, og den bliver til en handling med en ejer og en dato. ## 11. Registreringer Denne plan, øvelsesregistreringerne, forstyrrelsesloggene, evalueringerne efter hver forstyrrelse og genoprettelsestestene opbevares som virksomhedens bevis for, at den er klar, og er det, den interne audit og certificeringsauditten læser. Godkendt af [topledelsen] den [dato]; ejet af [planens ejer]; gennemgået mindst én gang om året, efter hver øvelse og efter hver forstyrrelse. Denne plan er skrevet ud fra de givne svar. Den er ikke certificeringsrådgivning; certificeringsorganet læser planen for dens mål og roller og beder derefter om den øvelse og den genoprettelsestest, der beviser dem, og den registrering, det accepterer, er den, virksomheden fører.
I StandardOS står øvelsen i kalenderen
StandardOS gemmer planen som en registrering med ejer og gennemgangsdato, lægger øvelsen i kalenderen i den kadence, denne plan sætter, og holder registreringen af hver øvelse ved siden af planen til auditoren.
Beredskabsplanen for hændelserLeverandørpolitikkenNIS2, som også kræver kontinuitetForanstaltningerne i bilag A