Et rammeverk for operasjonell robusthet er driftsmodellen en organisasjon bruker for å holde sine viktigste tjenester i gang gjennom forstyrrelser, bygget rundt navngitte tjenester, avtalte toleranser for hvor lenge de kan være svekket, og bevis på at begge har blitt testet. Det er ikke et policydokument. Det er strukturen som gjør en regulatorisk forventning til noe en organisasjon faktisk kjører, måned etter måned, og kan vise frem på forespørsel.
- Viktige forretningstjenester, navngitt fra kundens synspunkt i stedet for organisasjonskartet.
- Konsekvenstoleranser som angir maksimalt tolererbar forstyrrelse for hver enkelt, i tall.
- Avhengighetskartlegging som sporer menneskene, systemene, leverandørene og lokalene bak hver tjeneste.
- Scenarietesting mot alvorlige, men plausible hendelser, ikke komfortable.
- En utbedringsplan for avdekkingene av gaptesting, med eiere og datoer.
- Styring og en skriftlig selvvurdering som holder det hele oppdatert og forsvarlig.
Hva er et rammeverk for operativ robusthet?
Et rammeverk svarer på et spørsmål som en policy ikke kan: hvordan holder denne organisasjonen seg operativ når noe går i stykker, og hvordan kan vi vite det før det skjer? Britiske regulatorer kom frem til et konsistent svar. I stedet for å be bedrifter om å forhindre enhver feil, ber de dem om å anta at feil vil oppstå og bevise at de kan håndtere den innenfor en grense de har satt og forsvart.
Dette skiftet endrer hva rammeverket må inneholde. Forebyggingsrammeverk katalogiserer kontroller. Et rammeverk for operativ robusthet starter med tjenesten kunden er avhengig av, jobber bakover gjennom alt tjenesten er avhengig av, og setter en forsvarlig grense for hvor lenge den kan forringes før skaden blir uakseptabel. Kontroller er fortsatt viktige, men de er bevis snarere enn målet.
Denne siden dekker selve rammeverket. For definisjonen, det regulatoriske landskapet og hvordan fagfeltet forholder seg til forretningskontinuitet, se operasjonell robusthet.
Hva er komponentene i et rammeverk for operativ robusthet?
Seks komponenter, i rekkefølge. Hver av dem avhenger av den forrige, og det er derfor rammeverk som er satt sammen i feil rekkefølge, har en tendens til å kollapse under testing.
- Identifiser: List opp tjenestene hvis feil ville forårsake uakseptabel skade for kunder eller markedets integritet. De fleste organisasjoner starter med for mange og finpusser nedover.
- kartSpor hver tjeneste fra ende til ende gjennom menneskene, prosessene, teknologien, fasilitetene, dataene og tredjepartene den er avhengig av. Kartlegging er der skjulte enkeltstående feilpunkter dukker opp.
- Toleranser: angi maksimalt tolerabelt forstyrrelse for hver tjeneste, uttrykt som tid og volum i stedet for et adjektiv.
- TestKjør alvorlige, men plausible scenarier og observer om tjenesten holder seg innenfor toleransenivået. En test som krever at alt består, var ikke alvorlig nok.
- avhjelpe: fikse det testingen avdekket, med navngitte eiere, datoer og en oversikt over hva som ble endret.
- Styre: hold det under styrets tilsyn, gjennomgå det i sykluser, og vedlikehold den skriftlige selvvurderingen som forklarer dine vurderinger.
Hvilke bevis produserer hver komponent?
Hver komponent i rammeverket produserer en spesifikk artefakt, og disse artefaktene er det en veileder, en revisor eller en storkunde faktisk ber om å se. Dette er den mest nyttige testen for om et rammeverk kjører: hvis en komponent ikke produserer noe, fungerer den ikke, uansett hva dokumentasjonen sier.
| Komponent | Bevis etterspurt | Hvor det kommer fra |
|---|---|---|
| Identifiser | Listen over viktige forretningstjenester og begrunnelsen bak hver enkelt av dem | En styregodkjent oversikt, som gjennomgås på nytt når virksomheten endres i stedet for årlig |
| kart | Et aktuelt avhengighetskart for hver tjeneste, som når ut til leverandører og lokaler | Data om eiendeler, leverandører og prosesser vedlikeholdes som en del av normal drift |
| Toleranser | Toleransen for hver tjeneste og analysen som rettferdiggjorde antallet | Konsekvensanalyse, avtalt på nivået som eier risikoen |
| Test | Scenarietestrapporter som viser datoer, deltakere og hva som faktisk skjedde | Treningslogger registrert under testen, ikke skrevet ned etterpå |
| avhjelpe | Hver sårbarhet som er funnet, eieren, måldatoen og gjeldende status | En logg over korrigerende tiltak knyttet til testen som fant det |
| Styre | En skriftlig selvvurdering som forklarer vurderingene du har gjort | Vedlikeholdes kontinuerlig mens rammeverket kjører |
Det som skiller et rammeverk som holder mål fra et som ikke gjør det, er sjelden om disse artefaktene eksisterer i det hele tatt. Det handler om hvorvidt toleransene kan forsvares, om kartleggingen gjenspeiler virksomheten slik den opererer i dag, og om selvvurderingen beskriver organisasjonen som faktisk eksisterer. Alle som undersøker rammeverket har en tendens til å komme frem til disse tre spørsmålene, enten de er en veileder, en ekstern revisor eller en stor kunde som utfører due diligence. De regulatoriske detaljene bak fagfeltet ligger på siden om operasjonell robusthet , med sektorspesifikke forventninger til robusthet for finans.
Det er et større bilde bak dette.
Denne siden dekker én del av forretningsrobusthet. Real Resilience – IOs rammeverk for å koble sammen sikkerhet, personvern og AI-styring – er der hele bildet kommer sammen.
Hvordan bygger man et rammeverk for operativ robusthet?
Rekkefølgen nedenfor gjenspeiler hvor organisasjoner står fast, snarere enn en idealisert prosjektplan. De vanskelige delene er det andre og tredje trinnet, og å hoppe over dem er det som gir et rammeverk som leses godt og ikke stryker i testing.
- Definer tjenester utenfra og inn: beskriver hva kunden mottar, ikke hvilken avdeling som leverer det. En tjeneste som passer perfekt inn i den interne strukturen din er vanligvis en prosess, ikke en tjeneste.
- Sett toleransen før du vet om du kan oppfylle den: avgjør punktet hvor skade blir uutholdelig på egenhånd. Å jobbe bakover fra nåværende evne gir en toleranse du alltid kan møte, og det sier deg ingenting.
- Kart til dybden der beslutninger endresnok detaljer til å se de enkelte feilpunktene og konsentrasjonsrisiko hos leverandørene dine, og ikke mer. Kartleggingsprosjekter mislykkes ved å strebe etter fullstendighet.
- Velg scenarier som faktisk kan skje med degsvikt hos en navngitt kritisk leverandør, tap av et datasenter, en løsepengevirus-hendelse, avgangen til det eneste teamet som forstår et eldre system.
- Registrer feilene ærligEn testlogg som viser sikkerhetsbrudd og påfølgende rettelser er sterkere bevis enn en ubrutt rekke med gjennomganger, noe som hovedsakelig reiser spørsmålet om scenariene var alvorlige nok.
- Tildel sårbarheteneHvert gap får en eier, en utbedringsdato og en rute til brettet når det glipper.
- Skriv selvvurderingen underveis: satt sammen én gang i året fra minnet, det er et dokument. Vedlikeholdt kontinuerlig er det rammeverkets revisjonsspor.
Hvordan er dette forskjellig fra et rammeverk for robusthet i bedrifter?
De to blir ofte blandet sammen, og skillet er praktisk snarere enn akademisk. Operasjonell robusthet er en regulatorisk disiplin med et definert omfang: viktige forretningstjenester og toleransene knyttet til dem. Forretningsrobusthet er bredere og dekker organisasjonens evne til å absorbere endringer av enhver art, inkludert sikkerhets-, personvern- og AI-risiko i tillegg til forstyrrelser.
I praksis sitter den ene inni den andre. Operasjonell robusthet gir deg tjenesteperspektivet og toleransene. Det bredere rammeverket for forretningsrobusthet gir deg kontrollsettet som tjenesteperspektivet er avhengig av, og mekanismen som hindrer at hver nye forskrift besvares med et separat program. Hvis du velger hvor du skal starte og du er underlagt regler for operasjonell robusthet, start der, fordi omfanget og grensene settes eksternt snarere enn av deg. Hvis du ikke er det, er det bredere rammeverket det bedre inngangspunktet.
Kontinuitetsplanlegging er den tredje relaterte disiplinen. Den leverer planer og gjenopprettingsmål som lar en tjeneste holde seg innenfor toleransen, og er dekket av forretningskontinuitet.
Kom enkelt i gang med en personlig produktdemo
En av våre onboarding-spesialister vil veilede deg gjennom plattformen vår for å hjelpe deg med å komme i gang med selvtillit.
Hvordan støtter robusthetsløkken operasjonell robusthet?
Hver komponent i et rammeverk for operasjonell robusthet hviler på kontroller som allerede finnes et sted i organisasjonen. Tilgangsstyring, sikkerhetskopiering og gjenoppretting, leverandørvurdering, hendelsesrespons og endringskontroll er maskineriet som gjør en toleranse oppnåelig. Problemet er sjelden at disse kontrollene mangler. Det er at hvert rammeverk ber om dem separat, slik at den samme kontrollen dokumenteres tre ganger og ingen av dem dokumenteres godt nok.
Resilience Loop kjører informasjonssikkerhet i henhold til ISO 27001 , databeskyttelse i henhold til ISO 27701 og AI-styring i henhold til ISO 42001 som ett sammenkoblet system. Operasjonell robusthet blir et ytterligere blikk på det samme kontrollsettet i stedet for et parallelt program. En leverandørvurdering som utføres én gang, tjener kartleggingsøvelsen, sikkerhetsstandarden og personvernstandarden sammen. Kontinuitetskapasitet er spesifisert og sertifiserbar i henhold til ISO 22301 , som leverer styringssystemet som holder planene eide og testet.
Hvordan holder du bevisene oppdaterte?
Ethvert rammeverk produserer de riktige artefaktene minst én gang. Vanskeligheten er at de forfaller stille og rolig. Et avhengighetskart er nøyaktig den dagen det tegnes og feil i det øyeblikket en leverandør skifter. En toleranse som ble avtalt for to år siden, samsvarer kanskje ikke lenger med skaden den ble satt opp mot. Ingenting varsler noe av dette, så gapet mellom det dokumenterte rammeverket og det operative har en tendens til å åpne seg stille og komme til overflaten i verst tenkelig øyeblikk.
Forskjellen ligger i når bevisene skapes. Produsert som et biprodukt av å kjøre rammeverket, er det per definisjon aktuelt, og det er ingenting å rekonstruere. Samlet før en gjennomgang, registrerer det hva organisasjonen trodde om seg selv i stedet for hvordan den opererer, og det er nettopp det en nærmere undersøkelse avslører. Metoden er beskrevet i hvordan man dokumenterer motstandskraft , og motstandskraftsscoren gir deg et grunnlag før du starter.
Hvorfor velge ISMS.online for et rammeverk for operativ robusthet?
Et rammeverk er bare så godt som det er aktuelt. ISMS.online er bygget for å holde tjenesteperspektivet, kartleggingen og bevisene i takt med hvordan du faktisk opererer.
- Ett kontrollsett, hvert rammeverk: kartlegg kontroller én gang og bruk dem om igjen på tvers av operasjonell robusthet, ISO 27001, ISO 27701, ISO 42001 og ISO 22301 i stedet for å gjenoppbygge for hver enkelt.
- Tjenester knyttet til det de er avhengige avKoble viktige forretningstjenester til kontrollene, leverandørene og eiendelene bak dem, slik at en endring i den ene overlapper med den andre.
- Testrapporter og funn på ett stedPlanlegg scenariotester, registrer hva som mislyktes og spor utbedring til avslutning sammen med selve rammeverket.
- Bevis klar på forespørsel: produsere det nåværende bildet for en veileder, en revisor eller en kunde uten en rekonstruksjonsøvelse.
- Tredjepartsrisiko i samme systemVurder og overvåk leverandørene toleransene dine i stillhet avhenger av.
- Informert av dyp ekspertiseVeiledet implementering fra spesialister som har kjørt disse rammeverkene i regulerte organisasjoner.
- Bygget for britiske og regulerte markeder: utviklet for organisasjoner som må bevise motstandskraft overfor veiledere og vinne kontrakter.
Se hvordan det passer sammen på plattformen for forretningsrobusthet , eller bestill en demonstrasjon.
Spørsmål og svar
Hva er et rammeverk for operativ robusthet, enkelt sagt?
Det er måten en organisasjon identifiserer tjenestene kundene ikke kan klare seg uten, bestemmer hvor lenge hver enkelt kan bli forstyrret før skaden blir uakseptabel, regner ut alt disse tjenestene er avhengige av, og tester deretter om grensene holder. Rammeverket er strukturen som holder disse fire tingene oppdaterte og dokumenterte i stedet for å være skrevet ned én gang.
Hva er en støttoleranse?
En konsekvenstoleranse er det maksimale nivået av forstyrrelser i en viktig forretningstjeneste som en organisasjon er villig til å akseptere, angitt som en målbar grense, for eksempel antall timer eller et volum av mislykkede transaksjoner. Den er bevisst satt fra det punktet hvor skaden blir uakseptabel, ikke fra hva organisasjonen for øyeblikket kan oppnå, og det er derfor en godt fastsatt toleranse ofte er ubehagelig i starten.
Er et rammeverk for operativ robusthet kun for finansielle tjenester?
Den regulatoriske forpliktelsen ligger hovedsakelig på finansielle tjenester, men det gjør ikke metoden. Telekom-, helse- og administrerte tjenesteleverandører står overfor tilsvarende forventninger under sine egne regimer, og enhver organisasjon med kontraktsmessige forpliktelser om tilgjengelighet drar nytte av samme disiplin. Tjenesteperspektivet og toleransen er nyttige styringsverktøy uavhengig av hvem som veileder deg.
Hvilken standard bør et rammeverk for operativ robusthet bygges på?
Ingen enkelt standard dekker det, fordi kravene kommer fra regulatorer snarere enn fra en sertifiserbar spesifikasjon. I praksis trekker rammeverket på flere: ISO 22301 for kontinuitetsstyring, ISO 27001 for sikkerhetskontrollene tjenestene er avhengige av, og ISO/IEC 27031 for IKT-beredskap. Å arbeide i henhold til disse standardene gir deg mesteparten av bevisene en veileder ber om, i en form som allerede er uavhengig revidert.
Hvor ofte bør rammeverket gjennomgås?
Minst årlig i hele syklusen, med scenariotesting etter en plan gjennom hele året og kartlegging oppdatert når noe vesentlig endres. En ny leverandør, en systemmigrering, et oppkjøp eller en lærdom fra en hendelse bør alle utløse en gjennomgang i stedet for å vente på den årlige datoen. Kartlegging som henger etter organisasjonen er en vanlig svakhet, og den undergraver alle komponenter som er avhengige av den.
