Riskanalys: Preliminär riskanalys & Allriskansats enligt NIS2
Riskanalys gör du varje dag: Klar med frukost dags för jobbet. Du tittar ut, snöoväder: halka, frysa, krocka, försening. Det blir dunjacka och vinterkängor. Du har gjort en första riskanalys i projektet ta sig til jobbet.
En riskanalys är meningslös om den inte säkrar den samhällsviktiga funktionen. Ension allriskansats (Människa, Process, Teknik, Miljö) i en preliminär riskanalys är första steget mot cybervärdighet och skydd av de samhällsviktiga system. Genom en initial screening hittar vi verksamhetens högriskområden. Resultatet ger er kontroll: ni ser om ni omfattas av cybersäkerhetslagen och vet exakt vilka delar som kräver djupare analys för att skydda både samhället och era intäkter.
Säker arkitektur, lösningen på säkerhetskraven
Den här artikeln berättar hur du gör en preliminär faro och riskanalys. Syftet är att i en förstudie, kontextanalysen, identifiera riker med det du tänker införa.
Jag vänder mig till dig som leder eller ska genomföra arbetet. Du ska förstå vad standardiserade metoder kan hjälpa dig med efterlevnad av cybersäkerhetslagen. När du gjort detta kan du fokusera på rätt system och rätt policys. Detta är grunden för cybersäkerhet genom desired paths. Processen kan anpassas efter era behov
Vad är Riskanalys cybersäkerhet
Cybersäkerhetslagens / NIS2 krav på riskanalysen är ett allriskperspektiv (All-hazards approach)



Cybersäkerhetslagen kräver att samhällsviktiga tjänster fungerar. Riskanalysen ska göras med en allriskansats, Din affärsmodells tjänster är ditt fokus.
NIS2 krav på riskanalys framgår av EU-kommissionens genomförandeförordning. Det innebär att detta även blir cybersäkerhetslagens krav. Den är lik den riskanalys för informationssäkerhet som finns beskriven i ISO 27001 och ISO 27005.
Preliminär riskanalys, riskanalys system och riskberäkning
Genom de detaljerade reglerna för riskhantering krävs rent praktiskt att tre olika metoder följs, i grunden sätter genomförandeförordningen kraven, kraven där är strukturellt lika ISO 27001, men krav sätts även på en säker systemutvecklingscykel (SDLC), här safety & security by design. Det leder till att nyttkja IEC 61508.
De sammanlagda kraven innebär praktiskt att du först måste göra en preliminär riskanalys, etta innan du teknisk designar ditt system. Sedan måste du göra en riskanalys för att uppnå rätt systemdesign.
ANSSI:s metod EBIOS Risk Manager
Franska ANSSI gör samma uppdelning. Deras metod EBIOS Risk Manager börjar i verksamhetens värden. Farliga händelser identifieras, var och en med bedömd allvarlighetsgrad, och sedan byggs händelsekedjorna fram till dem — först på verksamhetsnivå, därefter genom tekniken. Skillnaden är att EBIOS är inriktad på avsiktliga angrepp. Cybersäkerhetslagen kräver att funktionen upprätthålls oavsett orsak.
Ension gör därför en enda process av två som annars går parallellt: systemdesign enligt ISO 15288 och ISO 9001, och safety och security by design enligt genomförandeförordningen, IEC 61508 och ISO 27000-familjen. Utgångspunkten är affärsmodellen, och slutpunkten är ett system som går att bevisa säkert.
"Syftet med denna lag är att uppnå en hög nivå av cybersäkerhet i samhället." – En riskanalys som missar att skydda den samhällsviktiga funktionen fyller inget syfte ur lagens perspektiv.
| Krav i Cybersäkerhetslagen | MCF:s traditionella metod | Ensions Metod (Safety & Security) | Varför Ension uppfyller målet bättre |
|---|---|---|---|
| Mål: Hög nivå av cybersäkerhet i samhället. | Fokus på Information (Konfidentialitet & Riktighet). | Fokus på Funktion & Operativ förmåga. | Om tjänsten stannar hjälper inte kryptering. Vi säkrar leveransen. |
| Allriskperspektiv: Skydd mot alla störningar (Art. 21). | Ofta begränsat till digitala hot och IT-behörighet. | HAZID med Guideord (Människa, Process, Teknik, Miljö). | Vi fångar väder, fysiska fel och mänskliga faktorer som IT-säkerhet missar. |
| Skydd av personer: Skydda nätverk, system och användare. | Fokus på att skydda personuppgifter (GDPR-tänk). | Skydd av användarens förmåga att agera (UX & Safety). | Systemet ska stötta människan i kris. Vi ser människan som en del av arkitekturen. |
| Proportionalitet: Åtgärder lämpliga mot risken. | Generiska kontroller från checklistor (ISO-bilagor). | Affärsdriven riskanalys kopplat till affärsmodellen. | Vi lägger krutet där ett avbrott får katastrofala följder för samhället och affären. |
| Sårbarhetshantering: Skydd under hela livscykeln. | Reaktiv scanning och patchning av befintlig drift. | V-modellen & Security by Design (Eliminering vid ritbordet). | Det är billigare och säkrare att designa bort fel än att plåstra om dem i drift. |
HAZID och HAZOP: Metoder för systematisk riskidentifiering
Process för preliminär riskanalys ur ett allriskperspektiv
Preliminär faro och riskanalys görs i tidigt. Du identifierar övergipande risker och utgår från affärsmodellen:
- HAZID-analys. Identifiera de faror som kan uppstå.
- Bestäm vad som är samhällsviktigt i affärsmodellen.
- Identifiera säkerhetskritiska processer
- HAZOP-analys av processer och systemarkitektur för att hitta orsaker till farliga händelser.
- Syntes av HAZID & HAZOP, en sammanvägning.
- Fastställs risknivå och prioritera riskerna. Detta skapar en riskmatris med prioriteringen av riskerna.
HAZID och HAZOP är metoder för riskanalys:
HAZID (Hazard Identification) och HAZOP (Hazard and Operability Study) är två fundamentala metoder för att säkra komplexa system. Ension anväder dessa i den preliminära riskanalysen för att fånga riskker ur ett allriskperspektiv:
- HAZID är en bred screening. Syftet är att göra en övergripande riskidentifiering för att sätta ramen för säkerhetsåtgärder och policy. Vi identifierar de yttre hoten (brand, strömavbrott, hackers) för att veta vad vi ska skydda. Fokus är risker ur ett allriskperspektiv Du tittar på systemet utifrån som en black box.
- HAZOP är en detaljerad analys av processerna. Vi identifierar systematiska fel i processen (vad händer om data uteblir eller är felaktig?) för att veta hur vi ska skydda det. Fokus är att bedöma driftsproblem. Analysen kräver specifikation av verksamhets och systemprocesser.
Båda bygger på tvärfunktionellt teamarbete och systematiska guideord för att identifiera faror. allriskperspektivet står i centrum och guideord hjälper dig i en allriskansats Nu har AI klivit in i teamet och kan hjälpa dig
1. Identifiera faror och risker för affärsmodell och samhälle (HAZID)
1.1. HAZID, en riskanalys att Identifiera faror och risker

HAZID (Hazard Identification), identifiering av faror, är en riskanalys för att identifiera potentiella faror och hot. Syftet är att i ett tidigt skede för att säkerställa att säkerhetsarbetet beaktar trovärdiga farliga scenarier.
Att tänka på i arbetet innan du startar riskanalysen
- Tänk utanför boxen och betrakta din verksamhet ur olika perspektiv.
- Involvera olika avdelningar: IT, säkerhet, drift, etc.
- Följ med i de senaste trenderna inom hot.
1.2. Resurser för riskanalys med HAZID
Ledaren bör ha god kunskap om cybersäkerhet samt förstå risker förknippade med samhällsviktiga tjänster.
Sekreteraren bör ha teknisk bakgrund inom IT-säkerhet.
Gruppen bör inkludera experter inom affärsmodell, IT, säkerhet, juridisk och kommunikation. Kunskap om attacker riktade mot samhällsviktiga tjänster är mycket bra. Involvera andra organisationer som t.ex. kunder, partners och myndigheter.
1.3. Stödord för riskanalys enligt HAZID för cybersäkerhet
När en HAZID för cybersäkerhet ska genomföras och guideorden anpassas. Grundläggande guideord:
- Människan: Felaktig användning, bristande medvetenhet, social ingenjörskonst, insiderhot.
- Process: Felaktig konfiguration, bristande uppdateringar, obehörig åtkomst, dataförlust.
- Teknik: Hårdvarufel, mjukvarufel, nätverksfel.
- Miljö: Naturkatastrofer, sabotage, terrorism.
Använd guideorden i AI-arbetet samt innan och i workshopen för att skapa scenarier och kreativitet.
1.4 Underlag för HAZID-analysen



Underlaget som ska tas fram innan AI gör sin analys och som sedan skickas till intressenterna tillsammans med HAZID med hjälp av AI är följande.
- Affärsmodell med SWOT-analys,
- Intressentanalys med säkerhetskrav
- Anpassade guideord som passar er analys
- Rapporter från tidigare cyberattacker & incidenter
- Scenarier baserat på t ex punkterna ovan. Använd AI för att skapa både scenarier och skapa poddar med NotebookLM om varje sceario.
AI spelar roller tre steg:
- AI-intressenternas säkerhetsanalytiker gör varsin HAZID med stödord och annat underlag som grund.
- AI-säkerhetsanalytikern sammanställer ai-intressenternas resultat till ett diagram.
- AI-angriparen försöker hitta på djävulskap, varför inte ett hybridhot eller två.
Idén med HAZID är att med guideord ge idéer om hur faror kan uppstå i verksamheten. Men hundra kombinationer av guideord orkar ingen gå igenom. Det orkar däremot AI. Och AI är dessutom bra på rollspel.
Som arkitekt får du hjälpa AI med att bygga modell: avvikelser och förlopp som Business Events, kopplade till informationsobjekten och processteg. Resultatet avvikelserna leder till dukumenteras som Outcomes, de kända från HAZID återanvänds, nya läggs till. Och tänk på, modellen är hela tiden facit
Kör prompten en gång per intressent, i separata konversationer. Delar de kontext färgar den första av dem de följande, och då förlorar ni bredden.
Vem du är: Agera som säkerhetsanalytiker med [INTRESSENTENS] erfarenhet och perspektiv. Du analyserar det du kan bäst — [INTRESSENTENS OMRÅDE] — och du ser faror som en generell analys missar.
Bifogat material: Jag har bifogat affärsmodellen för Gipsat.nu AB med värdeerbjudandet, en intressentanalys med säkerhetskrav, verksamhets- och systemarkitektur på översiktsnivå samt vår SWOT-analys. Jag bifogar också rapporter från tidigare incidenter och våra guideord i fyra familjer:
- Människa: felaktig användning, bristande medvetenhet, social ingenjörskonst, insiderhot
- Process: felaktig konfiguration, bristande uppdateringar, obehörig åtkomst, dataförlust
- Teknik: hårdvarufel, mjukvarufel, nätverksfel
- Miljö: naturkatastrofer, sabotage, terrorism
Din uppgift: Genomför en HAZID med värdeerbjudandet i centrum. Gå systematiskt igenom varje guideord mot varje värde och identifiera farliga händelser inom ditt område.
Arbeta uttömmande. Hoppa inte över kombinationer för att de verkar osannolika, men bedöm trovärdigheten i just den här verksamheten.
Utgå särskilt från svagheterna och hoten i SWOT-analysen. De är faror verksamheten redan känner till men kanske inte följt till konsekvens.
För varje farlig händelse, bygg kedjan hela vägen: från faran, via de händelser som följer, fram till det resultat som drabbar en intressent. Ange var i verksamheten eller arkitekturen varje händelse inträffar, och om det finns en barriär i dag.
Håll dig inom ditt område. Andra intressenter analyserar sina, parallellt.
Svarsformat:
FAROR (Driver)
NAMN | BESKRIVNING | GUIDEORD | TROVÄRDIGHET HÄR
HOTAGENTER (Business Role)
NAMN | BESKRIVNING | KOPPLAD TILL FARA
FARLIGA HÄNDELSER (Business Event)
NAMN | BESKRIVNING | INTRÄFFAR I | BEFINTLIG BARRIÄR | ÄR BARRIÄREN ÖVAD
RESULTAT (Outcome)
NAMN | BESKRIVNING | DRABBAR VEM | PÅVERKAT VÄRDE ELLER MÅL
KEDJOR
FRÅN | RELATION (triggering/influence) | TILL
VARFÖR JUST JAG SER DETTA
[kort, per fynd som du tror andra intressenter missar]
Intressenterna att köra:
| Intressent | Område i prompten |
|---|---|
| Vårdbehövande | "Beroendet av tjänsten. Du är patient eller anhörig och behöver hjälp när något hänt." |
| Chaufför | "Ditt eget arbetspass. Du kör, tar emot uppdrag och ska hitta rätt." |
| Sjukhuset som vårdgivare | "Mottagandet. Du tar emot patienter och ska ha bemanning och plats." |
| Driftansvarig | "Drift och förvaltning. Du vet vad som faktiskt går sönder, hur ofta, och vad som händer klockan tre på natten." |
| Support | "Användarnas verklighet. Du tar emot samtalen och vet vad de faktiskt gör, inte vad manualen säger." |
| Tillsynsmyndighet | "Efterlevnad av cybersäkerhetslagen. Din fråga är alltid: hur vet ni det?" |
| Transportör eller annan systemägare | "Ditt eget led i kedjan. Du äger ett av systemen och ser vad som händer hos dig." |
Tips: Kör en intressent i taget och spara svaren separat. Systemägarna är särskilt värdefulla när processen korsar organisationsgränser — de ser sitt led inifrån
Vem du är: Agera som en erfaren säkerhetsanalytiker som ska slå ihop flera HAZID-analyser till en sammanhängande bild.
Bifogat material: HAZID-analyserna från intressenterna, i element- och kedjeform, samt affärsmodellen med värdeerbjudandet.
Din uppgift: Slå ihop analyserna till en modell som kan ritas som ett diagram.
- Identifiera dubbletter. Element med olika namn som beskriver samma sak slås ihop. Behåll det tydligaste namnet och notera vilka intressenter som såg det.
- Kontrollera kedjorna. Går varje kedja hela vägen från en fara till ett resultat, eller saknas led?
- Koppla resultaten till värden. Varje Outcome ska peka på det värde eller mål den drabbar.
- Kontrollera relationstyperna. Där två intressenter ritat samma relation med olika typ — notera det som en konflikt, gissa inte.
- Kontrollera sammanhanget. Resultat utan kedja, faror utan kedja, händelser som förekommer i flera kedjor.
Slå inte ihop element du är osäker på. Hellre två element som visar sig vara samma än ett som döljer en verklig skillnad. Lägg dem i konfliktlistan.
Svarsformat:
MODELL — ELEMENT
TYP | NAMN | BESKRIVNING | SEDD AV INTRESSENTER
MODELL — KEDJOR
FRÅN | RELATION | TILL | SEDD AV INTRESSENTER
A. BEKRÄFTADE AV FLERA INTRESSENTER
ELEMENT ELLER KEDJA | SEDD AV | SAMMANVÄGD KONSEKVENS
B. SEDD AV ENDAST EN INTRESSENT
ELEMENT ELLER KEDJA | SEDD AV | VARFÖR JUST DEN INTRESSENTEN SER DEN
C. DÄR INTRESSENTERNA ÄR OENSE
FRÅGAN | GÄLLER | INTRESSENT A SÄGER | INTRESSENT B SÄGER
E. SAMMANHANG
Resultat utan kedja | Faror utan kedja | Händelser i flera kedjor
SAMMANSLAGNA DUBBLETTER
BEHÅLLET NAMN | ERSATTA NAMN | FRÅN INTRESSENTER
Tips: Avsnitt B är oftare intressant än avsnitt A. Det en enda intressent ser är det era befintliga analyser saknar. Avsnitt C blir workshopens agenda.
Vem du är: Agera som angripare mot den här verksamheten. Du har tid, tålamod och resurser. Du beskriver vad du vill uppnå och vilka vägar dit du ser — inte tekniska detaljer om hur ett angrepp genomförs.
Bifogat material: Den sammanställda riskanalysen som diagram och som element- och kedjelista, samt affärsmodellen med värdeerbjudandet.
Din uppgift: Du ser nu försvararnas egen bild av vad som kan gå fel. Angrip den.
- Hybrider. Vilka av de befintliga kedjorna kan du kombinera så att de tillsammans ger ett värre resultat än var för sig? Beskriv kombinationen som ett scenario med namn.
- Vägar som saknas. Vilka resultat kan du nå på ett sätt som inte finns i diagrammet alls?
- Barriärer. Vilka av de angivna barriärerna skulle du gå runt, och varför tror du att det går?
- Det mest lönsamma målet. Om du bara fick välja ett resultat att åstadkomma, vilket och varför?
Var realistisk. Ett scenario som kräver fem osannolika saker samtidigt är litteratur, inte analys.
Svarsformat:
D. HYBRIDSCENARIER
NAMN | BESTÅR AV KEDJORNA | SAMLAT RESULTAT | VARFÖR KOMBINATIONEN FUNGERAR
RELATIONER TILL RESULTATET (influence/triggering per delkedja)
NYA VÄGAR
TILL RESULTAT | VÄGEN LED FÖR LED | RELATIONER | VARFÖR FÖRSVARARNA MISSAT DEN
BARRIÄRER JAG GÅR RUNT
BARRIÄR | VID ELEMENT | HUR JAG BEDÖMER ATT DEN INTE HÅLLER
MEST LÖNSAMMA MÅLET
RESULTAT | MOTIVERING
Tips: Formulera alltid rollen som mål, aldrig som metod. Det ger användbar analys och håller sig inom vad ni bör ha nedskrivet. En angripare som ombeds beskriva mål producerar dessutom influence-resonemang naturligt: hen behöver inte slå ut hela tjänsten, hen behöver få tre saker att inträffa samtidigt.
Barriärlistan är särskilt användbar i workshopen. En barriär angriparen avfärdar är ofta en som ingen övat.
1.6 Inför Workshop HAZID
Material på gemensam whiteboard
- Diagrammet,
- Lista med öppna frågor
- Scenariepoddar, berättelser om organisationens verksamhet
- Riskanalysen en överblickspodd
Poddarna finns för att tvinga fram långsamt tänkande innan workshopen. En lista på en skärm skummas av System 1. En berättelse i öronen kan inte skummas, den tar sin tid, och under tiden börjar deltagaren invända.
Innan diagrammet öppnas skriver varje deltagare ner tre farliga händelser utifrån sin egen erfarenhet. Ofta kommer de tre farorna direkt ur det som gnagde under poddlyssningen. Därefter granskas diagrammet utifrån vad som inte finns med.
1.7. Workshop HAZID: gallra, komplettera, kedja



Börja med att presentera av övergripande så alla förstår föremålet för analys. Håll mötet ganska kort.
- 10 min, presentation av syfte, avgränsning och metod
- 15 min De egna farorna. Varje deltagare presenterar sina tre, medan uppmärksamheten är som störst.
- 20 min Där rollerna är oense. Avsnitt C ur sammanställningen. Här ligger de verkliga luckorna.
- 15 min Gallring. Vilka kandidater är inte trovärdiga
- 20 min Kedjor. Håller de kedjor AI byggt?
- 15 min Hybrider. Avsnitt D, plus det teamets egna.
- 5 min sammanfattning
Facilitatorns tre uppgifter.
- Se till att gallringen faktiskt sker; grupper är obekväma med att stryka, och en lista ingen tror på slutar användas.
- Se till att drift- och supportfolk hörs, de vet hur systemen beter sig i verkligheten.
- Låt inte diskussionen glida in i tekniska lösningar; det är inte det här steget.
Vid stort scope delas workshopen i två: en för oenighet och gallring, en för kedjor och hybrider.
1.8. Formalisering i modellen
Efter workshopen uppdateras modellen baserat på resultatet på den digitala tavlan.
Relationer är det som avslöjar att två faror egentligen är samma, att en kedja saknar ett led, eller att ett resultat inte träffar något värde. En outcome utan koppling till ett värde betyder antingen att resultatet inte spelar någon roll, eller att kontextanalysen missat ett värde.
Öppna frågor markeras som öppna på whiteboarden med instruktioner till teamet och kallelse till en ny workshop..
Här är en HAZID-analys (Hazard Identification) utformad med Archimate-ramverket.
Diagrammet är en visuell riskanalys som utgår från ett centralt värdeerbjudande. Det kartlägger på ett systematiskt sätt hur olika händelser, tekniska fel, processbrister och mänskliga faktorer kan leda till allvarliga negativa konsekvenser.
Kärnan i analysen: Värdeerbjudandet
I mitten av diagrammet finns det centrala Värdeerbjudandet (orange rektangel), vilket är "Förmedling av vård och transport". Målet med tjänsten är att efter en "Godkänd/nekad beställning" kunna erbjuda "Transport till akut med kortast kö". Detta är det positiva utfall som tjänsten ska leverera. Hela analysen kretsar kring vad som kan gå fel i och runt leveransen av detta värde.
Identifierade Riskområden och Orsakskedjor
Analysen kan delas in i flera logiska områden som visar hur risker uppstår:
1. Operativa och Fysiska Risker (vänster sida) Detta område fokuserar på misslyckandet att fysiskt få patienten till sjukhuset.
-
Grundproblem: "Patienten kommer inte till sjukhus".
-
Orsaker: Detta kan bero på flera saker:
-
Tekniska fel: "Servicetekniker inte på plats" eller att "Tjänsten stoppad" på grund av "Överströmning".
-
Administrativa fel: "Extra administration" som leder till att "Betalning uteblir".
-
-
Huvudkonsekvens: "Patienter får inte transport till vård".
-
Slutgiltig Risk (röd box): Den allvarligaste konsekvensen i hela analysen: "Skadad person/död".
2. Resurs- och Kompetensrisker (höger sida) Detta område behandlar problem som uppstår när patienten visserligen transporteras, men till fel plats eller med fel förutsättningar.
-
Grundproblem: "Larmknappen larmar vid fel tillfälle", vilket leder till flera problem:
-
Felaktig dirigering: Patienten hamnar på "samma sjukhus" (underförstått att det är fel sjukhus), vilket kan bero på att "Alla sjukhus ges samma adress" (en datakvalitetsbrist). Detta leder till risken "Kapacitetsbrist".
-
Bemanningsproblem: Larmet kan gå till ett sjukhus som är "underbemannat", kanske på grund av en "Slumpmässig nybörjare" eller "Obehöriga hyrdröttar" (troligen inhyrd personal utan rätt behörighet).
-
-
Underliggande orsak: En genomgående orsak är "Bristande kompetens i larmkedjan".
3. Tekniska, Informations- och Cybersäkerhetsrisker (nedre del) Detta område fokuserar på de tekniska systemen och plattformarna som stöder värdeerbjudandet.
-
Grundkomponent: Allt vilar på en "Säker plattform".
-
Problem:
-
Regelefterlevnad: Om man inte kan visa att "cybersäkerhetskrav efterlevs", leder det till risken för "Sanktionsavgift".
-
Dataskydd: "Bristande persondatalagsskydd" leder direkt till att "Personuppgifter läckta".
-
Systemutveckling: En "Bristfällig kravställning mot system" är en rotorsak som kan leda till att "Dokumentation ej underhållen" och att "Modell för krav design och test" blir korrupt. Detta skapar en ond cirkel av teknisk skuld och bristande kvalitet.
-
4. Kommunikationsrisker (övre del) Detta område handlar om fel i kommunikationen med intressenter, främst anhöriga.
-
Grundproblem: Värdeerbjudandet är beroende av att status meddelas korrekt. Fel uppstår när en "Anhörig får ej status meddelad" eller får "felaktig status".
-
Rotorsak: Detta kan kopplas till en "Målvaktsroll" (en funktion som agerar mellanhand) och en "Larmknapp" som "fungerar inte", vilket leder till ett totalhaveri ("Naveriskåda").
2. Identifiera samhällsviktiga tjänster
2.1. Skapa beslutsunderlag med riskscenarier
HAZID-arbetet i kapitel 1 gav en modellerad bild av vad som kan gå fel. Nu ska den användas för att besluta vilka tjänster som är samhällsviktiga. Scenarierna är bästa underlaget, de visar konsekvensen i stället för att beskriva den.
En hybridattack sker mot Gipsat.nu, vårdens uber:
- Alla sjukhus ges samma fysiska adress så alla körningar av skadade hamnar på samma sjukhus.
- Planeringssystemet hos sjukhuset som de skadade kommer till är hackat så det är underbemannat
- Kundernas telefoner har en malware så att telefonerna larmar utan att kunden tryckt på knappen.
Resultat: Överbalastat sjukhus och falska vårdkörningar.
2.2. Workshop för att bedöma vilka tjänster som är kritiska
Här görs en bedömning av vilka tjänster som är kritiska, beslutet är ledningens. Dagordning för workshopen.
- 15 min. Genomgång av HAZID och scenarierna.
- 20 min. Bedömning per tjänst enligt riskkriterierna.
- 15 min. Beslut om vilka tjänster som går till kapitel 3.
- 5 min. Riskbeslut. beslutade samhällsviktiga tjänster
Det är här ni bekräftar eller justerar viktningen av värden från kontextanalysen. Den var en hypotes byggd på affärsförståelse; nu har ni analysen. Resultatet städas och skickas ut efter workshop.
| Värde | Intressent | SVT | PI | MI | KN | Vikt | Motivering |
|---|---|---|---|---|---|---|---|
| Skadad person vårdad | Kund, samhälle | 5 | 2 | 4 | 5 | 5 | Utebliven vård kan leda till personskada eller dödsfall. |
| Patient på plats triggat av larm | Kund, vårdgivare | 5 | 1 | 3 | 5 | 5 | Ingången till hela vårdflödet. Utan larm sker ingen förmedling. |
| Patientuppgifter hanteras korrekt | Patient, myndighet | 2 | 5 | 4 | 4 | 5 | Röjda vårduppgifter är oåterkalleligt. Brott mot patientdatalagen. |
| Transport till akut med kortast kö | Kund, vårdgivare | 4 | 1 | 3 | 4 | 4 | Fel sjukhus ger fördröjd vård och överbelastad mottagning. |
| Geolokaliserad beställning | Kund, chaufför | 4 | 3 | 2 | 4 | 4 | Fel upphämtningsplats gör att patienten inte nås i tid. |
| Bevisat säker tjänst | Myndighet, kund | 3 | 3 | 4 | 4 | 4 | Utan efterlevnad hotas sanktionsavgift och rätten att leverera. |
| Automatisk betalning | Kund, partner | 1 | 2 | 3 | 2 | 3 | Kassaflödespåverkan. Manuell rutin finns. |
| Riskdelning med försäkringspartner | Partner | 1 | 1 | 3 | 2 | 3 | Ekonomiskt värde. Ingen patient påverkas. |
| Status meddelad till anhörig | Anhörig | 1 | 2 | 1 | 2 | 2 | Oro hos anhörig. Ingen patient skadas. |
2.3. Viktningen hos det totala värdeerbjudandets förmågor
Ledningen känner igen förmågor, det är dessa som finns i affärsmodellen och intressentanalysen. En förmåga implementerar en eller flera flera värden. Förmågan får vikten efter värdet med den högsta vikten. Redovisa sedan förmågorna som profiler, vilka vikter implementerade värden har och förmågans resulterande vikt.
| Förmåga | Värdenas vikt | Högsta | Vad profilen säger |
|---|---|---|---|
| Förmedling och matchning av körning | 5, 5, 4 | 5 | Genomgående kritisk. Inga lågviktade värden att spara på. |
| Kundhantering | 5, 4, 2 | 5 | Delad. Larmvägen får inte fallera, statusvägen får det. |
| Partnerhantering | 5, 4 | 5 | Kritisk. Utan chaufförer ingen transport. |
| Informationshantering och journalföring | 5, 4 | 5 | Kritisk av integritetsskäl, inte av tillgänglighetsskäl. |
| Utveckling av app, tjänst och utbildning | 4 samt realiserar samtliga | 5 | Här uppstår de systematiska felen. |
| Betalning och avräkning | 3, 3 | 3 | Jämn. Manuella rutiner bär den. |
| Marknadsföring | – | 1 | Fritt att experimentera. |
2.4. De samhällsviktiga tjänsterna

Samtliga resultat pekar mot samma förmåga och samma values i värdeerbjudandet: förmedling av vård och transport med geolokaliserad beställning, transport till akut med kortast kö, larmknappen som utlöser flödet. Transport triggat av larm utförs av partnern taxi.
Övriga values i erbjudandet har inga resultat riktade mot sig. Slutsatsen är att förmedling av vård och transport är den samhällsviktiga tjänsten, en gallring som kommer ur analysen, inte ur en bedömning av vad som känns viktigt.
3. Identifiera säkerhetskritiska processer och allokera vikt
HAZID-analysen visar vilka outcomes som hotar vilka delar av erbjudandet. För Gipsat pekar "patienten kommer inte till sjukhus", "patienter får inte transport till vård" och "vårdkaos" alla mot samma värden: förmedling av vård och transport. Det är den samhällsviktiga tjänsten.
Inför detta steg vet du vilken tjänst som är kritisk, och processen som krävs för att leverera tjänsten. Men du vet inte vilken del av processen som är säkerhetskritisk, vet du det kan du navigera dig fram till säkerhetskritiska system.
3.1. Kartan över de viktiga tjänsterna ger de säkerhetskritiska processen.
Processbilden här visar hela vårdprocessen: akutflödet, hemtransporten, återbesöket och avslutningen. Alla fyra realiserar erbjudandet, Nu skall du ska du ta reda på vilka processteg som är säkerhetskritiska.
I kontextanalysen viktade ledningen vad som är kritiskt på en skala 1–5, där 5 betyder noll tolerans för att processen inte fungerar.
Första steget är att vikta stegen i verksamhetsprocessen. Det görs nedan, men för gipsat.nu inses det lätt att akutflödet är viktigast, de första fem processstegen.
3.2. Hitta kritiska huvudspår i affärsprocessen
Försök dela upp processen i större delar. Gipsat,nu kan dela vårdprocessen i fyra delar: akutflödet, hemtransporten, återbesöket och avslutningen. Alla fyra realiserar erbjudandet. men de har olika kritikallitet. Tre frågor skiljer dem åt.
- Vilka outcomes från HAZID träffar delen? Det är den hårdaste frågan, eftersom svaret kommer ur analysen och inte ur en bedömning.
- Hur snabbt måste den fungera? Det är tidskravet som gör en tjänst samhällsviktig, inte innehållet. Samma tjänst kan vara kritisk i ett flöde och trivial i ett annat.
- Vad kostar en väntan? Om det finns en väg runt, hur mycket sämre blir utfallet med den?
| Processdel | Outcomes från HAZID | Tidskrav | Kostnad för väntan |
|---|---|---|---|
| Akutflödet | Patienten kommer inte till sjukhus. Patienter får inte transport till vård. Vårdkaos. | Minuter | Personskada eller dödsfall |
| Hemtransport efter akutvård | Inga | Timmar | Patienten väntar på sjukhuset. Obekvämt, inte farligt |
| Återbesök | Inga | Dygn | Ny tid bokas per telefon |
| Avslutning och utskrivning | Inga | Dygn | Administrativ fördröjning |
3.3 Från verksamhetsprocess till säkerhetskritisk process
Processbilden har två halvor. Den gula visar vad människor gör, den vårdbehövande larmar, taxiföraren kör, sjukhuset tar emot. Den blå visar processen i systemstödet: användarappen, förmedlarservern, chaufförsappen och sjukhusintegrationen.
Det är den blå halvan som ska analyseras i HAZOP, eftersom det är där de systematiska felen uppstår. Men vikten kommer från den gula, för det är där värdet levereras. Det är dessa vikter ni använder när ni i 3.6 identifierar den säkerhetskritiska processen.
3.4 Förberedelser inför workshop och enskild bedömning
Första steget är att skapa ett underlag för workshopen så att deltagarna kan förbereda sig. Prompten kopplar ihop verksamhetslager och applikationslager och beskriver vad ett bortfall skulle innebära. Den föreslår ingen vikt. En siffra i underlaget gör att deltagarna bedömer om AI:s siffra i stället för att själva bedöma steget.
Vem du är: Agera som verksamhetsarkitekt med erfarenhet av funktionssäkerhet.
Bifogat material: Jag har bifogat verksamhetsprocessen för Gipsat.nu AB med både verksamhetslager och applikationslager, samt de värden processen levererar med deras vikt på skalan 1–5. Akutflödet bär värdet "skadad person vårdad" med vikt 5, vilket är taket för samtliga steg i flödet.
Din uppgift: Koppla varje applikationsprocess till de verksamhetssteg den stödjer, och skriv ett bedömningsunderlag för varje koppling.
Underlaget ska göra det möjligt för en människa att själv avgöra hur tungt applikationsprocessen väger. Beskriv därför:
- Vad systemet gör i steget. Vilken del av verksamhetsstegets funktion utförs av applikationsprocessen?
- Vad som händer utan den. Om applikationsprocessen inte fungerar — vad stannar, och vad fortsätter?
- Vilken väg runt som finns beskriven. Manuell rutin, telefon, papper, annan kanal. Ange var den är dokumenterad om du kan se det.
- Vad som ändå inte skulle fungera. Även med vägen runt: vad går förlorat i tid, kvalitet eller spårbarhet?
Föreslå ingen vikt och ingen siffra. Deltagarna bedömer själva.
Bedöm inte om barriären är övad. Det vet du inte. Markera den som obekräftad.
Svarsformat:
PER KOPPLING
Verksamhetssteg:
Applikationsprocess:
Vad systemet gör i steget:
Vad som stannar utan den:
Vad som fortsätter utan den:
Väg runt som finns beskriven:
Barriärens status: obekräftad
Vad som ändå inte fungerar:
APPLIKATIONSPROCESSER UTAN KOPPLING TILL NÅGOT VERKSAMHETSSTEG
NAMN | KOMMENTAR
VERKSAMHETSSTEG UTAN SYSTEMSTÖD
NAMN | KOMMENTAR
FRÅGOR JAG INTE KAN BESVARA UR UNDERLAGET
FRÅGAN | VEM SOM TROLIGEN VET
| Applikationsprocess | Vad händer om den inte fungerar | Din vikt (1–5) |
|---|---|---|
| Skicka larm om vårdbehov | Ingen får veta att någon ligger skadad. Kedjan startar aldrig, och ingenting i vårt system ringer för att berätta det. Den skadade ligger kvar tills någon råkar gå förbi. | |
| Beställa transport till sjukhus | Larmet kommer in och blir liggande. Ingen bil får veta att någon behöver hämtas. Ur den skadades perspektiv är det samma sak som att larmet aldrig gick fram. | |
| Väljer körning till sjukhus | Bilen får ett uppdrag men fel destination, eller samma destination som alla andra bilar. Det här är felet som inte syns: systemet fungerar, bilen kör, patienten transporteras. Bara till fel ställe. Ingen larmar, för allt ser normalt ut. | |
| Publicera kölängd | Vi vet inte vilket sjukhus som har kortast väntan, så valet blir en gissning. Vid en större olycka gissar alla likadant, och då blir vår gissning en del av problemet. | |
| Visa taxiförare vägen | Chauffören ser inte rutten i appen och måste orientera sig själv. Ett par minuter går förlorade, mer om området är obekant. | |
| Avsluta körning till sjukhus | Ingen rapport skapas. Patienten är redan framme, så vården påverkas inte, men rapporten bär vårduppgifter, och det som inte registreras finns inte när någon senare frågar vad som hände. | |
| Skriva in patient | Sjukhuset får ingen förvarning och patienten dyker upp oanmäld. Uppgifterna kommer fram muntligt i stället för digitalt, och vem som hör med i receptionen vet vi inte. | |
| Journalföra patient | Uppgifterna hamnar inte i journalen. Den akuta vården är redan utförd, men journalen är bestående, det som blir fel där följer patienten i decennier. |
Gör en podd av underlaget. Podden ska verksamheten processen implementerar och berätta vad som händer när stegen inte fungerar. Deltagaren lyssnar och triggar långsamt tänkande "då skulle vi ju kunna ringa" eller "nej, det skulle inte hjälpa". och det är precis den bedömning hon ska göra i nästa steg:
3.5. Förberedelser till workshop
Skicka underlaget och podden några dagar i förväg. Varje deltagare sätter en vikt 1–5 per applikationsprocess. Motiveringen är det viktiga.
Sammanställ svaren före mötet. Där alla landat lika tar diskussionen två minuter. Där svaren spretar från 2 till 5 ligger antingen en okänd barriär eller en missuppfattning om vad steget gör, och det är där mötets tid ska läggas.
3.6 Workshopen, analysera förberedelserna och komma överens om resultat
Workshopens syfte är att synkronisera förberedelserna till säkerhetskritisk process. Agenda:
- 10 min. Gå igenom de enskildas resultat utan att diskutera, notera var det spretar.
- 20 min. Där rösterna spretar. Vad vet den som röstade lågt som de andra inte vet?
- 15 min. Processen, vilken är säkerhetsprocessen.
Resultatet är dels en tabell med allokerad vikt per applikationsprocess men framför allt är det den säkerhetskritiska processen.
| Verksamhetssteg | Applikationsprocess | Konsekvens vid bortfall | Vikt |
|---|---|---|---|
| Vårdbehövande trycker på larmknappen | Skicka larm om vårdbehov | Vårdkedjan startar aldrig. | 5 |
| Taxiförare kör vårdbehövande till sjukhus | Beställa transport till sjukhus | Ingen bil skickas. Samma utfall som uteblivet larm. | 5 |
| Väljer körning till sjukhus | Patienten körs till fel sjukhus utan att någon märker det. | 5 | |
| Publicera kölängd | Sjukhusvalet blir en gissning. Vid större händelser gissar alla likadant. | 4 | |
| Visa taxiförare vägen | Fördröjning i minuter, mer i obekant område. | 3 | |
| Taxiförare avslutar och rapporterar | Avsluta körning till sjukhus | Vården opåverkad, men vårduppgifter registreras inte. | 3 |
| Sjukhus tar emot vårdbehövande | Skriva in patient | Ingen förvarning. Uppgifter överförs muntligt. | 3 |
| Sjukhus skriver ut vårdbehövande | Journalföra patient | Akutvården opåverkad. Journalen blir ofullständig och det är bestående. | 2 |
4. Riskanlys av faror inifrån (HAZOP)
4.1. Riskanalys enligt HAZOP hittar faror och risker utifrån din organisations processer
HAZID tittade utifrån och frågade vad som kan hota tjänsten. HAZOP tittar inifrån och frågar vad som kan gå fel i arbetet. Olika riktning ger två olika sorters fynd. HAZOP hittar orsakerna till i HAZID funna outcomes . Men den hittar också nya outcomes, konsekvenser ingen såg utifrån.
HAZOP (Hazard and Operability Study) är en riskanalys utifrån processer och system. Riskanalysen enligt HAZOP hittar faror och hot inifrån. Här är HAZOP övergripande anpassat för cybersäkerhet.
4.2. Ta fram underlaget för riskanalys enligt HAZOP baserat på resultatet från HAZID
Du kan inte köra HAZOP på hela processen på en gång. Avgränsning till säkerhetskritisk process gjordes kapitel 3.
För Gipsat.nu går den från att den skadade trycker på larmknappen till att patienten är inskriven på sjukhuset. Den startar i den skadades mobiltelefon, går via Gipsats förmedlarserver ut till taxiförarnas telefoner, och slutar i sjukhusets vårdsystem.
Fyra systemägare delar kedjan. Det avgör hur analysen läggs upp, ingen av dem har det kompletta flödet men tillsammans ser dom helheten.
4.3. Guideord inom cybersäkerhet för riskanalys enligt HAZOP
Applicera guideord för att hitta riskerna t ex :
- Mer trafik, data, åtkomst eller användare.
- Mindre trafik, data, åtkomst eller användare.
- Ingen trafik, data, åtkomst, eller användare.
- Omvänd: Data flödar åt fel håll, åtkomst sker från oväntat håll, användare utför otillåtna aktiviteter.
- Felaktig data, användning eller autentisering.
- För mycket trafik, data, användare, eller privilegier.
- För lite: För lite trafik, data, åtkomst eller övervakning.
- Oauktoriserad åtkomst, användning eller ändring.
4.4. Mall för HAZOP, informationsorienterade guideord och processen i mitten
Mallen har processen i mitten, precis som HAZID hade värdeerbjudandet. Informationsobjekten längs flödet, avvikelserna runt om, och de resultat de leder till ytterst.
Guideorden appliceras på informationen mellan aktiviteterna.
Håll analysen på logisk nivå. Systemägarna har riktiga system i huvudet och glider lätt in i teknik. Frågan är vad som lämnas över och vad mottagaren gör med det, inte hur överföringen sker. Protokoll och integrationer hör till systemriskanalysen.
4.5. AI i tar tre steg fram avvikelser
AI arbetar i samma tre steg dessa roller:
- AI-systemägare säkerhetsanalytiker gör varsin HAZOP med HAZID stödord och annat underlag som grund.
- AI-säkerhetsanalytikern sammanställer ai-intressenternas resultat till ett diagram.
- AI-angriparen försöker hitta på djävulskap, varför inte ett hybridhot eller två.
Kombinatoriken är hårdare här än i HAZID. Sex avvikelsetyper med flera guideord vardera mot åtta processteg blir långt över hundra kombinationer. Vi låter återigen AI göra jobbet. Intressenterna är utbytta mot systemägare, de ser det inifrån vad som händer hos dem.
Det gör oenigheten i steg 2 särskilt värdefull. När två systemägare har olika bild av vad som lämnas över har ni hittat en lucka. En vanlig orsak till att kedjor går sönder, och den syns aldrig i en analys gjord av en part ensam.
En kontroll när sammanställningen är klar: hittade HAZOP några resultat som HAZID missade? Om inte har analysen körts för snävt. Det är inifrånperspektivet som ser det utifrånblicken inte kan se, transportrapporten som uteblir ser ut som en fungerande körning.
Kör en gång per systemägare, i separata konversationer. Lägg till integratörsrollen som ett eget pass.
Vem du är: Agera som riskanalytiker hos [SYSTEMÄGAREN]. Du känner ditt eget system inifrån — hur det beter sig när det är belastat, vad som händer vid uppdateringar, vilka fel som återkommer. Du vet mindre om de andra systemen i kedjan.
Bifogat material: Jag har bifogat den säkerhetskritiska processen för Gipsat.nu AB med applikationsprocesserna och deras allokerade vikt, samt arkitekturen. Jag bifogar också våra guideord grupperade i sex avvikelsetyper: mängd, tid, riktning, kvalitet, behörighet och insyn.
Från den tidigare HAZID-analysen finns dessa resultat identifierade: [lista].
Din uppgift: Applicera varje guideord på varje processteg som ditt system äger eller är beroende av. Arbeta uttömmande — gå igenom kombinationerna systematiskt, även de som verkar osannolika, men bedöm trovärdigheten.
För varje avvikelse du hittar:
- Vad avvikelsen innebär konkret i ditt system
- Vad som händer i nästa led — vad ser de andra systemen
- Vilket resultat det leder till
- Om felet syns, eller om allt ser normalt ut
Tvinga inte in avvikelser i de kända resultaten. Leder en avvikelse till något som inte finns i listan, beskriv det som ett nytt resultat och märk det som sådant. Det är ofta där de intressanta fynden ligger.
Räkna inte in befintliga skydd. Att ni har övervakning eller en reservrutin bedöms senare, i riskbehandlingen. Här beskrivs vad som händer.
Svarsformat:
AVVIKELSER
Processteg:
Avvikelsetyp och guideord:
Vad avvikelsen innebär i mitt system:
Vad nästa led ser:
Syns felet:
Leder till resultat:
Nytt resultat (ja/nej):
Trovärdighet här:
GRÄNSSNITT MOT ANDRA SYSTEM
Gränssnitt | Vad jag skickar | Vad jag antar att mottagaren gör | Vad jag inte vet
NYA RESULTAT
Namn | Beskrivning | Varför HAZID missade det
Systemägarna för Gipsat:
| Roll | Formulering |
|---|---|
| Användarappen | "Du ansvarar för appen i den vårdbehövandes telefon. Du vet hur den beter sig vid dålig täckning, låg batterinivå och när användaren gör fel." |
| Gipsats förmedlarserver | "Du ansvarar för matchning och förmedling. Du vet vad som händer vid belastningstoppar och vid deploy." |
| Transportörens system | "Du ansvarar för chaufförsappen och körningarna. Du vet hur chaufförerna faktiskt använder den." |
| Sjukhusets vårdsystem | "Du ansvarar för inskrivning och journalföring. Du vet hur integrationen beter sig och vad personalen gör när den strular." |
| Integratören | "Du ansvarar för gränssnitten mellan systemen. Du ser vad som skickas och vad som antas i andra änden." |
Om integratörsrollen. Den finns för att gränssnitten är ingens hemmaplan. Varje systemägare beskriver sitt led; integratören är den enda som frågar vad som händer i mellanrummet.
Vem du är: Agera som en erfaren riskanalytiker som ska slå ihop flera HAZOP-analyser till en sammanhängande bild.
Bifogat material: HAZOP-analyserna från systemägarna och integratören, den säkerhetskritiska processen, samt HAZID-resultaten.
Din uppgift:
- Slå ihop avvikelser som beskriver samma sak från olika håll. Behåll det tydligaste namnet och notera vilka systemägare som såg den.
- Bygg kedjor. Koppla avvikelser till de resultat de leder till, och märk relationerna triggering eller influence.
- Koppla mot HAZID. Vilka avvikelser förklarar resultat som redan var kända? Det är HAZOP:s verifierande funktion.
- Lyft de nya resultaten. Vilka avvikelser leder till något HAZID inte hittade? Redovisa dem separat.
- Granska gränssnitten. Där en systemägares "vad jag antar att mottagaren gör" inte stämmer med mottagarens egen beskrivning — det är en integrationsrisk.
Svarsformat:
A. AVVIKELSER SOM FLERA SYSTEMÄGARE SER
B. AVVIKELSER SOM BARA EN SER
C. DÄR SYSTEMÄGARNA ÄR OENSE
Särskilt: gränssnitt där avsändarens antagande inte stämmer med mottagarens beskrivning
D. NYA RESULTAT SOM HAZID MISSADE
E. SAMMANHANG
Kända resultat utan förklarande avvikelse | Avvikelser utan resultat | Avvikelser i flera kedjor
Tips: Avsnitt D är kapitlets viktigaste utdata. Är det tomt har analysen körts för snävt. Avsnitt E:s första lista är också värd att titta på — ett känt resultat som ingen avvikelse förklarar betyder antingen att orsaken ligger utanför den analyserade processen, eller att resultatet inte är tekniskt realiserbart.
Vem du är: Agera som angripare mot den här processen. Du har tid, tålamod och resurser. Du beskriver vad du vill uppnå och vilka vägar dit du ser — inte tekniska detaljer.
Bifogat material: Den sammanställda HAZOP-analysen med avvikelser, kedjor och resultat, samt processen med systemägare.
Din uppgift:
- Vilken avvikelse skulle du framkalla med flit? Försvararna har listat vad som kan gå fel av misstag. Vilka av dem kan du orsaka?
- Vilka kombinationer? Vilka avvikelser i olika systemägares led kan du utlösa samtidigt för ett värre resultat än var för sig?
- Var i gränssnitten? Systemgränser är där ansvaret är oklart. Vilket gränssnitt skulle du gå på?
- Vad syns inte? Vilken avvikelse skulle du välja just för att ingen märker den?
Svarsformat:
AVVIKELSER JAG KAN FRAMKALLA
Avvikelse | Hur jag ser att det går | Vad det ger mig
KOMBINATIONER
Namn | Ingående avvikelser | Samlat resultat | Varför kombinationen fungerar
GRÄNSSNITT JAG SKULLE GÅ PÅ
Gränssnitt | Varför just det | Vad jag uppnår
DET SOM INTE SYNS
Avvikelse | Varför ingen märker den
Tips: Fråga 4 ger oftast mest. En avvikelse som ingen märker kan pågå länge, och det är den angriparen väljer när målet är påverkan snarare än avbrott.
Den berättar vad som händer när informationen mellan aktiviteterna uteblir, kommer för sent eller är fel. Den som lyssnar i bilen börjar invända automatiskt, och det är de invändningarna workshopen ska handla om.
4.6. Deltagarnas förberedelser
Skicka ut diagrammet, listan över öppna frågor och en podd några dagar före workshopen.
Varje deltagare hänger sina notiser direkt på kedjorna, vid den punkt de gäller. Sätt deadline ett par dagar före mötet så att workshopledaren hinner sortera. En kedja med många notiser blir mötets tyngdpunkt. En kedja helt utan betyder antingen att den är uppenbart riktig eller att ingen orkat titta.
4.7. Workshop HAZOP
Samma upplägg som HAZID-workshopen: diagrammet på tavlan, enskild förberedelse, och mötet ägnat åt det AI inte kan avgöra. Agenda:
- 10 min. Genomgång av den sammanslagna bilden. Vad är hypotes, vad är verifierat.
- 45 min. Kedja för kedja med notiserna från förberedelsen. Vad har ni hängt upp, och vad gör vi med det?
- 10 min. Vad saknas, hittade vi något HAZID missade?
- 5 min. Sammanfattning och öppna frågor.
Efter workshpen formaliserar arkiyekten workshpresultatet i modellen.
Detta diagram är en detaljerad och systematisk riskanalys enligt HAZOP-metoden (Hazard and Operability Study). I mitten ser vi den säkerhetskritiska processen från den föregående bilden, och runt omkring den har man applicerat HAZOP:s "guideord" för att identifiera potentiella avvikelser, deras orsaker och deras konsekvenser.
Förstå diagrammets uppbyggnad
-
Den centrala processen: Kärnan i diagrammet är samma processflöde som tidigare, uppdelat i sina fyra systemlager:
Vårdbehövandes telefon,Sjukhusets vårdsystem,Gipsat FörmedlarserverochTransportörens system. Detta är systemet som studeras. -
Guideorden (i bakgrunden): Som en vattenstämpel i bakgrunden ser man svagt de svenska guideorden som är grunden för en HAZOP-analys:
mer,mindre,ingen,felaktig,oauktoriserad,för mycket,för lite,för sent, etc. Dessa ord används för att systematiskt ifrågasätta varje del av processen (t.ex. "Vad händer om vi får för lite data?", "Vad händer vid oauktoriserad åtkomst?"). -
Avvikelserna (röda boxar): De röda rektanglarna runt processen representerar de avvikelser och faror som har identifierats med hjälp av guideorden. De beskriver vad som konkret kan gå fel.
-
Orsak och verkan (pilar): Pilarna visar sambanden. De går från en orsak (t.ex.
För många privilegier), till en avvikelse i processen (t.ex.Missbruk av larm-appen), till en konsekvens (t.ex.Överbelastning på gipsat.nu).
Analys av de identifierade riskerna (teman)
Analysen har identifierat flera kritiska felscenarier som kan grupperas i olika teman baserat på guideorden:
Tema: Oauktoriserad (Unauthorized)
-
Orsak:
Oauktoriserad användningelleråtkomst. -
Avvikelse: Detta kan leda till
Missbruk av larm-appen(t.ex. falsklarm) eller attAppen låsthos transportören. -
Konsekvens:
Överbelastning på gipsat.nueller att föraren inte kan slutföra sin körning (Det går inte att avsluta körning).
Tema: Felaktig (Incorrect)
-
Orsak:
Fel på autentisering i appenellerFelaktig datafrån sjukhuset. -
Avvikelse: Detta kan resultera i att
Den skadade kan inte larmaeller attTransportrapport skickas inte. -
Konsekvens:
Patient blir inte inskriven i förväg, vilket är en av tjänstens kärnfunktioner.
Tema: Ingen (No/None)
-
Orsak:
Ingen eleller att integrationen misslyckas. -
Avvikelse: Detta leder till allvarliga avbrott som att
Gipsat.nu får inte köinformationeller attVårdlarm kommer inte fram. -
Konsekvens: Den yttersta konsekvensen är att
Patienten kommer inte till sjukhus.
Tema: Mer / Mindre / För mycket / För lite (More/Less/Too much/Too little)
-
Orsak: Obalans i systemet, t.ex.
För mycket trafik,För lite dataellerFör lite övervakning. -
Avvikelse: Kan leda till allt från
Överbelastningtill attPatienten kommer inte till sjukhus(om kritisk data saknas). -
Intressant observation: Analysen visar att både för lite och mer data kan vara ett problem.
Mer datapekar också mot attTransportrapport skickas inte, vilket antyder att systemet kanske inte kan hantera oväntade eller för stora datamängder.
Sammanfattning och slutsats
Denna HAZOP-analys är en utmärkt fördjupning av de tidigare riskanalyserna. Den går från övergripande risker (HAZID) till att systematiskt och detaljerat granska en specifik, kritisk process.
Genom att använda guideord har man tvingat fram ett kreativt men strukturerat tänkande för att identifiera ett brett spektrum av potentiella fel. Diagrammet visar på ett mycket effektivt sätt hur en till synes liten teknisk orsak (som Ingen el eller Felaktig data) kan få en dominoeffekt genom hela kedjan och leda till allvarliga konsekvenser för patienten.
Detta är ett kraftfullt underlag för att designa och implementera specifika kontroller och skyddsåtgärder för att hantera just de avvikelser som identifierats. Man vet nu exakt vilka svaga punkter i processen som behöver stärkas.
5. Syntes av HAZID & HAZOP
5.1 Slå ihop blackboxtänket med processanalysen,
Skapa en syntes av HAZID och HAZOP. Lägg din HAZID utanför HAZOP. Lägg därefter in alla relationer mellan HAZOP och HAZID.
Efter detta analyseras resultatet med Intressenternas säkerhetskrav i åtanke. Leta efter händelser du missat och potentiella konsekvenser: Dataintrång, systemfel, förlust av affärsvärde, rykteskada.
Försök både att hitta konsekvensen hybridattacker från enskilda konsekvenser och enskilda konsekvenser av hybridattacker. Här gäller bredd i analysen.
Detta är den mest kraftfulla av analyserna eftersom den skapar en komplett, spårbar kedja från övergripande, strategiska risker till specifika, operativa fel. Diagrammets struktur är uppbyggd i lager:
-
Kärnan (Mitten): I centrum finns fortfarande den säkerhetskritiska processen med sina fyra systemlager. Detta är "patienten" som analyseras.
-
Det inre skiktet (HAZOP): Närmast processen ligger de röda rektanglarna från HAZOP-analysen. Dessa representerar de specifika, tekniska och processnära avvikelserna, som till exempel
Gipsat.nu får inte köinformation,Transportrapport skickas inteellerPatienten blir inte inskriven i förväg. De svarar på frågan: Hur kan processen gå fel? -
Det yttre skiktet (HAZID): Längst ut i periferin ligger de gula, blå och röda boxarna från den första HAZID-analysen. Dessa representerar de övergripande orsakerna, sårbarheterna och de slutgiltiga konsekvenserna, som
Hårdvarufel,Slumpmässig nybörjare,Brist mot persondatalagenochSkadad person/död. De svarar på frågan: Vad är de stora riskerna och orsakerna?
Styrkan i syntesen: Spårbara orsakskedjor
Det geniala med detta diagram är hur det binder samman de yttre och inre skikten. Det visar exakt hur en övergripande risk (HAZID) kan orsaka en specifik processavvikelse (HAZOP), som i sin tur saboterar den kritiska processen.
Här är några exempel på dessa kedjor:
Exempel 1: Kedjan för tekniskt fel
-
HAZID (Yttre): Ett
HårdvarufelellerÖverströmningleder till attTjänsten stoppad. -
HAZOP (Inre): Detta orsakar den specifika avvikelsen
Källarapplikation stannar på ett sjukhus. -
Processen (Kärnan): Denna avvikelse slår direkt mot sjukhusets förmåga att
Publicera kolängd. -
Konsekvens: Utan köinformation kan en patient skickas fel, vilket leder till riskerna
Patienter får inte transport till vårdoch i värsta fallSkadad person/död.
Exempel 2: Kedjan för mänsklig faktor
-
HAZID (Yttre): En
Slumpmässig nybörjareanställs, vilket leder tillBristande kompetens. -
HAZOP (Inre): Detta leder till att
Gipsat.nu får inte köinformation för ett sjukhus(kanske för att personen inte kan hantera systemet korrekt). -
Processen (Kärnan): Detta slår mot förmedlarserverns kärnprocess
Beställa transport.... -
Konsekvens: Samma som ovan – felaktig dirigering och allvarlig patientrisk.
Exempel 3: Kedjan för dataskydd
-
HAZID (Yttre): Det finns en övergripande risk för
Brist mot persondatalagen. -
HAZOP (Inre): Detta kan förverkligas genom en
Oauktoriserad åtkomst till personuppgifter. -
Processen (Kärnan): Detta kan ske genom att någon kommer åt de dataobjekt som flödar i systemet, till exempel
Transportrapport. -
Konsekvens: Den slutgiltiga konsekvensen är
Skada på individens rätt till skydd av personuppgifter.
Sammanfattning och slutsats
Denna syntes är höjdpunkten av riskanalysarbetet. Den skapar en holistisk och extremt kraftfull bild av risklandskapet. Istället för att ha en lista på övergripande risker och en separat lista på tekniska fel, visar detta diagram exakt hur de hänger ihop.
För beslutsfattare är detta ovärderligt. Man kan se hela kedjan från en abstrakt risk som "bristande kompetens" till exakt var i mjukvaruprocessen det kommer att gå sönder och vad den slutgiltiga, mänskliga eller legala, konsekvensen blir. Detta gör det möjligt att designa och prioritera motåtgärder som adresserar de verkliga rotorsakerna, inte bara symptomen.
5.2 Single point of failure
En SPOF är något som flera kedjor beror på samtidigt. Den är svår att se i en enskild analys, eftersom varje kedja ser rimlig ut var för sig — det är först när de ligger bredvid varandra som det gemensamma träder fram.
Fyra sorter att leta efter:
- Gemensamt element. En farlig händelse eller avvikelse som förekommer i flera kedjor. Insidern i Gipsat-exemplet bidrar till två kedjor samtidigt, och det gör att två oberoende scenarier plötsligt har en gemensam startpunkt.
- Gemensam leverantör. Flera led beror på samma part. För Gipsat äger transportören både körningsval och rapportering — faller den ut träffas både vårdkedjan och integritetskedjan.
- Gemensam infrastruktur. Samma nätverk, samma molntjänst, samma identitetshantering. Redundans som ligger hos samma leverantör är ingen redundans.
- Gemensam person. Den som är ensam om att kunna något. Semester och sjukdom räcker för att utlösa den.
Hur ni hittar dem. Gå igenom elementen i den sammanslagna bilden och räkna hur många kedjor var och ett förekommer i. Allt som finns i mer än en är en kandidat. Ställ sedan frågan baklänges: om det här fallerar, vilka kedjor rör sig samtidigt?
Varför det spelar roll i nästa steg. En SPOF gör att risker ni bedömt som oberoende inträffar tillsammans. Det ändrar inte den enskilda risknivån, men det ändrar sannolikheten för att flera inträffar samtidigt — och det är precis vad ett hybridhot är. Vårdkaos är tre förlopp som ser oberoende ut och delar angripare.
5.3 Beskriv faror, konsekver och risker
Sätt nu den enskilda konsekvensen i centrum. Utifrån den placerar du in de farliga händelserna som kan leda till den. Analysera konsekvensen, diskutera och dokumentera:
- Möjliga konsekvenser: Dataintrång, systemfel, förlust av affärsvärde, rykteskada.
- Sannolikhet: Hur troligt är det att avvikelsen inträffar?
- Se till att berörda tjänster finns med.
- Analysera befintliga kontroller och hur dessa påverkar och påverkas av olika guideord. Exempel på guideord anpassade för cybersäkerhet.
Befintliga skydd noteras, men räknas inte in i riskanlysen här, det kommer vid säkerhetsbeviset. Kommer det upp att något redan finns på plats, skriv upp det vid risken, det används i riskbehandlingen. Här bedöms risken som den är, annars går det inte att senare visa vad åtgärderna gav.
6. Fastställa risknivå och prioritera bland riskerna
6.1. Bedöm sannolikhet för och konsekvens i en riskmatris
Riskerna har identifierats med händelsekedjor samt de resultat riskerna leder till. Nu ska du för varje risk bedöma konsekvenserna av risken samt sannolikheten för att den inträffar. Detta gör du traditionellt genom att bedöma riskernas sannolikhet och konsekvens i en riskmatris.
Riskmatrisen är det första steget i att fastställa risknivån och en bra grafisk ingång. Men riskmatrisen räcker inte för att prioritera. Tio risker kan hamna i samma ruta, och matrisen säger ingenting om vilken av dem som betyder mest för just er verksamhet. Nästa avsnitt visar hur du löser detta.
6.2. Prioritera riskerna med WPRF
Weighted Prioritised Risk First (WPRF) rangordnar och prioritera riskerna. Genom att bedöma varje risk från 1–5 i fyra konsekvensområden, och sedan väga ihop dem, prioriterar WPRF mellan riskerna. Tänk på att siffrorna är ett verktyg för prioritering, det innebär att om du ger alla risker en 5:a, har du i praktiken inte gjort någon prioritering alls. Metoden och hur resultatet används beskrivs i detalj på sidan om Weighted Prioritised Risk First. Nedan ser du resultatet för gipsat.nu
Riskanalysen enligt HAZID och HAZOP gav en lång lista farliga händelser. Efter syntesen och sammanvägningen ser prioriteringen ut så här:
| Risk | SVT | PI | MI | KN | Poäng | Prioritet |
|---|---|---|---|---|---|---|
| Vårdkaos vid hybridattack | 5 | 2 | 4 | 5 | 3,90 | 1 |
| Enskild patient får inte vård | 4 | 5 | 2 | 3 | 3,80 | 2 |
| Brott mot patientdatalagen | 2 | 5 | 4 | 4 | 3,60 | 3 |
| Transportrapport skickas inte | 3 | 2 | 5 | 4 | 3,25 | 4 |
| Trasig QR-kod på hållplats | 1 | 1 | 1 | 2 | 1,15 | 5 |
Gipsat.nu har valt följande viktning av riskpoäng: Riskpoäng = SVT×0,35 + PI×0,30 + MI×0,20 + KN×0,15.
Tre saker är värda att stanna vid.
Brott mot patientdatalagen ligger trea trots låg SVT-poäng. Integritetsdimensionen väger 30 procent, och det räcker för att lyfta en risk som inte hotar vårdflödet alls. Risken kommer från integritetskedjan, som blir synlig först när patientuppgifternas väg genom processen följs separat.
- Vårdkaos och "patient får inte vård" ligger nästan lika. De ska hanteras tillsammans i policyarbetet, eftersom flera strategier täcker båda.
- QR-koden faller ur. Med poäng 1,15 mot 3,90 behöver ingen argumentera om var analysinsatsen ska läggas. Det är hela poängen med att räkna i stället för att tycka.
- Vad som händer sedan. Listan går in i policyarbetet, där varje tänkbar säkerhetsstrategi ställs mot de risker den täcker. Där visar det sig att "safety by design" och "rimlighetskontroll av resultat" tillsammans adresserar de tre översta riskerna, medan "skydd mot skadlig kod" bara når en av dem — men till en bråkdel av insatsen.
6.3 Riskbeslutspunkt 1 och vägen vidare
Det här var den första av två WPRF-körningar. Här prioriterades risker på verksamhetsnivå, innan ni vet något om tekniken. Den andra görs i systemriskanalysen, mot den funktionella och logiska arkitekturen.
Riskbeslutspunkt 1. Räcker underlaget för att avgöra vad som krävs för att få ner riskerna till acceptabel nivå? Om inte görs en ny iteration — med ändrad omfattning, annan expertis eller kompletterat underlag.
För Gipsat var svaret nej första gången. Integritetskedjan saknades, och patientuppgifternas väg genom transportledet hade inte följts. Efter en kompletterande genomgång tillkom risken som nu ligger trea.
Här bekräftas också viktningen från kapitel 2. Den byggde på HAZID; nu har ni hela analysen.
Risklistan är inte målet. Den går in i policyarbetet, där varje tänkbar säkerhetsstrategi ställs mot de risker den täcker. För Gipsat visar det sig att safety by design och rimlighetskontroll av resultat tillsammans adresserar de tre översta riskerna, medan skydd mot skadlig kod bara når en av dem — men till en bråkdel av insatsen.
En strategi som tar bort en femtedel av tre risker slår en som tar bort hälften av en, och det syns inte när man arbetar risk för risk. Hur strategierna väljs beskrivs i policyartikeln.
FAQ riskanalys: Preliminär riskanalys och vägen till säkerhetskrav
Vi använder båda metoderna i den inledande fasen för att få en komplett bild. HAZID identifierar de yttre farorna (allriskansats), medan HAZOP hittar systematiska avvikelser i hur processen är tänkt att fungera. Tillsammans utgör de den screening som krävs för att veta var vi behöver göra en detaljerad systemanalys.
Målet är att uppfylla Cybersäkerhetslagens krav på en hög säkerhetsnivå genom att snabbt hitta de "elefanter i rummet" som kan sänka en samhällsviktig funktion. Vi identifierar risker på policynivå så att ledningen kan prioritera rätt resurser från start.
Den preliminära analysen pekar ut vilka systemdelar som är kritiska (t.ex. en specifik transportledning). I nästa steg, den detaljerade systemanalysen, går vi djupt in på hur dessa delar tekniskt ska skyddas mot specifika cyberhot och sårbarheter.
Det innebär att vi inte bara tittar på IT-attacker. Vi använder guideord för att hitta risker i dimensionerna Människa, Process, Teknik och Miljö. Det inkluderar allt från elavbrott och översvämning till insiderhot och felaktiga rutiner.
Enligt genomförandeförordningen (2.1.2 d) är identifiering av felkritiska delar ett lagkrav. Om vi hittar en SPOF i den preliminära fasen kan vi direkt styra systemdesignen mot redundans, vilket sparar stora kostnader jämfört med att upptäcka det i ett sent skede.
Säkerhetskraven är den direkta medicinen mot de risker vi hittat. När riskanalysen identifierar ett hot (t.ex. avbrott i mobilnätet), skapar vi ett säkerhetskrav (t.ex. dubblerad kommunikation via SMS och Internet). Kraven blir styrande för hela den tekniska implementeringen.
Ja. I kritiska miljöer (som en cockpit) kan MFA vara en säkerhetsrisk i sig. Genom riskanalysen kan vi visa att friktionen är farlig och istället ställa krav på likvärdig säkerhet via certifikat och logiska kontroller, vilket är helt i linje med lagens krav på proportionalitet.
Då riskerar ni "lapp-och-lagning-säkerhet". Ni lägger pengar på skydd som kanske inte adresserar de faktiska riskerna för er affärsmodell, samtidigt som ni riskerar att missa kritiska beroenden som sänker hela tjänsten vid en kris.
Vi använder V-modellen. Varje säkerhetskrav som härleds från riskanalysen mappas mot en test- och verifieringsfas. Det innebär att vi tekniskt kan bevisa för en myndighet att vi har identifierat riskerna och att våra åtgärder faktiskt fungerar.
Ledningen ansvarar för att godkänna resultatet av den preliminära analysen och besluta om risktolerans. Genom att följa vår metodik får ledningen ett begripligt underlag för att ta sitt lagstadgade ansvar för verksamhetens cybersäkerhet.

















