ISO 27001 · risikoregistret
Risikoregistret og risikobehandlingsplanen, skrevet ud fra fem svar
De startrisici, en softwarevirksomhed bærer, hver med en sandsynlighed og en konsekvens på en 5-punktsskala, niveauet som deres produkt i 4 bånd, en acceptgrænse, og for hver risiko over den en behandlingsmulighed og de foranstaltninger, der behandler den; registret og planen skrives, som auditoren læser dem, og erklæringen om anvendelighed følger af foranstaltningerne.
Hvor registret står
14 risici i registret, 14 over grænsen og behandlet, 0 accepteret; 59 foranstaltninger i anneks A nævnt af behandlingerne.
Registret (14 risici)
Startrisiciene er produktets eget første udkast til en virksomhed som jeres; ændr scorerne, vælg muligheden, nævn ejeren, fjern det, der ikke gælder, og tilføj det, der mangler.
Phishing fører til kompromitterede legitimationsoplysninger
En medarbejder narres til at afsløre legitimationsoplysninger. · Brugerkonti
A.6.3 Lær folk at arbejde sikkert · A.8.5 Log ind sikkert · A.8.23 Filtrér adgang til risikable websteder
16 · kritiskTab eller tyveri af en endpoint-enhed
En laptop eller telefon med information mistes eller stjæles. · Endpoints
A.8.1 Sikr bærbare, telefoner og stationære · A.7.9 Beskyt udstyr uden for matriklen · A.8.24 Brug kryptering rigtigt og styr nøglerne
9 · middelEn kritisk cloudtjeneste er utilgængelig
En central SaaS- eller cloudleverandør har et nedbrud. · Cloudtjenester
A.5.23 Brug cloudtjenester sikkert · A.8.14 Reservekapacitet så et svigt kan overleves · A.5.30 Hold teknikken kørende gennem forstyrrelser · A.5.29 Hold sammen på sikkerheden under en krise · A.8.6 Nok kapacitet til at blive ved med at køre
12 · højBackups kan ikke gendannes
Der findes backups, men en rigtig gendannelse virker ikke, når der er brug for den. · Data
A.8.13 Tag backup og bevis at genskabelse virker
10 · højFratrædende medarbejder beholder adgang
Adgang inddrages ikke hurtigt, når nogen stopper. · Konti
A.5.11 Få udstyr og data tilbage, når folk holder op · A.6.5 Pligter der varer ud over fratrædelsen · A.5.18 Tildel, gennemgå og fjern rettigheder
9 · middelUdstyr eller medier bortskaffes med data stadig på
En disk, et USB-stik eller en gammel bærbar forlader virksomheden uden at være slettet. · Udstyr og medier
A.7.10 Håndtér diske, drev og flytbare medier · A.7.14 Slet udstyr før bortskaffelse eller genbrug · A.8.10 Slet data I ikke længere har brug for
8 · middelBrud hos en leverandør eller cloududbyder
En leverandør, der opbevarer vores information eller driver en del af vores tjeneste, kompromitteres, og vi hører om det sent eller slet ikke. · Leverandører og cloudtjenester
A.5.19 Styr den risiko, leverandører bringer med sig · A.5.20 Skriv sikkerhedsvilkår ind i leverandørkontrakter · A.5.21 Sikkerhed gennem teknologiens leverandørkæde · A.5.22 Hold øje med leverandørerne, mens de ændrer sig
12 · højHændelse ikke opdaget eller anmeldt i tide
En sikkerhedshændelse bemærkes af ingen, eller af nogen, der ikke ved, hvor den skal anmeldes, og reaktionen begynder dage for sent. · Hændelseshåndtering
A.5.24 Vær klar, før hændelsen indtræffer · A.5.25 Vurdér hvilke begivenheder der er rigtige hændelser · A.5.26 Handl når en hændelse er erklæret · A.5.27 Lær af hændelser bagefter · A.6.8 Gør det let for medarbejderne at melde problemer
12 · højJuridisk eller kontraktligt krav overset
En lov, en forordning, en licens eller en kundekontrakt kræver noget af os, som ingen har skrevet ned, og hullet findes af en auditor, en kunde eller en myndighed. · Forpligtelsesregister
A.5.31 Kend de love og kontrakter, der binder jer · A.5.32 Respektér ophavsret og softwarelicenser · A.5.35 Få sikkerheden gennemgået af en uafhængig · A.5.36 Kontrollér at jeres egne regler faktisk følges · A.8.34 Auditér systemer uden at forstyrre dem
9 · middelSikkerhedsansvar uklart eller uden ejer
En foranstaltning har ingen navngiven ejer, en pligt deles af alle og udføres af ingen, eller én person holder en rolle, der burde være adskilt. · Roller og ansvar
A.5.1 Skriftlige sikkerhedspolitikker, godkendte og opdaterede · A.5.2 Hvem der er ansvarlig for hvad i sikkerheden · A.5.3 Del følsomme opgaver mellem flere mennesker · A.5.4 Hvad ledelsen skal kræve af alle · A.5.37 Skriv ned hvordan tingene faktisk gøres · A.6.2 Sikkerhedspligter skrevet ind i ansættelsesvilkårene
9 · middelFolk kommer eller går uden sikkerhedsgrundlaget
Nogen begynder uden screening, vilkår eller fortrolighedsaftale, eller ingen ved, hvad der sker, når en regel brydes. · Personer
A.6.1 Baggrundstjek før ansættelse · A.6.4 Konsekvenser når reglerne brydes · A.6.6 Fortrolighedsaftaler · A.5.5 Vide hvem man kontakter hos myndighederne · A.5.6 Holde forbindelsen til sikkerhedsfællesskaber
9 · middelInformation delt eller flyttet usikkert
Fortrolig information sendes, overføres eller eksponeres på et netværk eller en tjeneste uden den håndtering, dens klassifikation kræver. · Information under overførsel
A.5.13 Mærk oplysninger med deres følsomhed · A.5.14 Send oplysninger sikkert, internt og eksternt · A.8.3 Begræns hvad den enkelte kan åbne · A.8.21 Aftal sikkerhedsvilkår for netværkstjenester · A.8.19 Styr hvad der installeres i produktion · A.5.8 Byg sikkerhed ind i ethvert projekt
12 · højSårbarhed indført i egen software
Usikker kode eller en usikker afhængighed når produktion. · Applikation
A.8.25 Sikkerhed gennem hele måden software bliver til på · A.8.26 Afgør hvad en applikation sikkert skal kunne · A.8.27 Design systemer på sikre principper · A.8.28 Skriv kode der står imod angreb · A.8.33 Brug ufarlige data når I tester · A.8.8 Find og luk kendte svagheder
12 · højUautoriseret videregivelse af personoplysninger
Kunders personoplysninger eksponeres for den forkerte part. · Personoplysninger
A.5.34 Beskyt personoplysninger · A.8.12 Forhindr data i at slippe ud, hvor de ikke må · A.5.12 Inddel oplysninger efter følsomhed · A.8.11 Skjul data der ikke behøver at blive vist
15 · høj
Tilføj en risiko
Dokumentet
# Informationssikkerhedsrisikovurdering og risikobehandlingsplan Skrevet den 14. september 2026 med den gratis side på getstandardos.com, til et ledelsessystem for informationssikkerhed efter ISO/IEC 27001:2022: kriterierne i punkt 6.1.2 a), risiciene identificeret, analyseret og evalueret efter 6.1.2 c) til e), behandlingsmulighederne og foranstaltningerne i anneks A efter 6.1.3 a) til c) og planen efter 6.1.3 e). Metoden er StandardOS'; foranstaltningernes titler er StandardOS' beskrivelser, ikke standardens tekst. ## Risikokriterier Sandsynlighed og konsekvens scores hver fra 1 til 5; niveauet er deres produkt. En risiko på eller under 4 accepteres og beholdes med en ejer; en risiko over behandles. Båndene: - lav: 1 til 4 - middel: 5 til 9 - høj: 10 til 15 - kritisk: 16 til 25 ## Risikoregister (14 risici) | Risiko | Aktiv | Sandsynlighed | Konsekvens | Niveau | Behandling | Ejer | |---|---|---|---|---|---|---| | Phishing fører til kompromitterede legitimationsoplysninger | Brugerkonti | 4 | 4 | 16 (kritisk) | Ændr med foranstaltninger | | | Tab eller tyveri af en endpoint-enhed | Endpoints | 3 | 3 | 9 (middel) | Ændr med foranstaltninger | | | En kritisk cloudtjeneste er utilgængelig | Cloudtjenester | 3 | 4 | 12 (høj) | Ændr med foranstaltninger | | | Backups kan ikke gendannes | Data | 2 | 5 | 10 (høj) | Ændr med foranstaltninger | | | Fratrædende medarbejder beholder adgang | Konti | 3 | 3 | 9 (middel) | Ændr med foranstaltninger | | | Udstyr eller medier bortskaffes med data stadig på | Udstyr og medier | 2 | 4 | 8 (middel) | Ændr med foranstaltninger | | | Brud hos en leverandør eller cloududbyder | Leverandører og cloudtjenester | 3 | 4 | 12 (høj) | Ændr med foranstaltninger | | | Hændelse ikke opdaget eller anmeldt i tide | Hændelseshåndtering | 3 | 4 | 12 (høj) | Ændr med foranstaltninger | | | Juridisk eller kontraktligt krav overset | Forpligtelsesregister | 3 | 3 | 9 (middel) | Ændr med foranstaltninger | | | Sikkerhedsansvar uklart eller uden ejer | Roller og ansvar | 3 | 3 | 9 (middel) | Ændr med foranstaltninger | | | Folk kommer eller går uden sikkerhedsgrundlaget | Personer | 3 | 3 | 9 (middel) | Ændr med foranstaltninger | | | Information delt eller flyttet usikkert | Information under overførsel | 3 | 4 | 12 (høj) | Ændr med foranstaltninger | | | Sårbarhed indført i egen software | Applikation | 3 | 4 | 12 (høj) | Ændr med foranstaltninger | | | Uautoriseret videregivelse af personoplysninger | Personoplysninger | 3 | 5 | 15 (høj) | Ændr med foranstaltninger | | ## Risikobehandlingsplan (14 risici behandlet) Hver risiko over acceptniveauet 4, med sin behandlingsmulighed, de foranstaltninger, der behandler den, hvor muligheden er at ændre, og sin ejer; 0 risici accepteres og beholdes. ### Phishing fører til kompromitterede legitimationsoplysninger En medarbejder narres til at afsløre legitimationsoplysninger. Niveau: 16 (kritisk). Behandling: Ændr med foranstaltninger. Ejer: endnu ikke nævnt Foranstaltninger, der behandler denne risiko: - A.6.3: Lær folk at arbejde sikkert - A.8.5: Log ind sikkert - A.8.23: Filtrér adgang til risikable websteder ### Tab eller tyveri af en endpoint-enhed En laptop eller telefon med information mistes eller stjæles. Niveau: 9 (middel). Behandling: Ændr med foranstaltninger. Ejer: endnu ikke nævnt Foranstaltninger, der behandler denne risiko: - A.8.1: Sikr bærbare, telefoner og stationære - A.7.9: Beskyt udstyr uden for matriklen - A.8.24: Brug kryptering rigtigt og styr nøglerne ### En kritisk cloudtjeneste er utilgængelig En central SaaS- eller cloudleverandør har et nedbrud. Niveau: 12 (høj). Behandling: Ændr med foranstaltninger. Ejer: endnu ikke nævnt Foranstaltninger, der behandler denne risiko: - A.5.23: Brug cloudtjenester sikkert - A.8.14: Reservekapacitet så et svigt kan overleves - A.5.30: Hold teknikken kørende gennem forstyrrelser - A.5.29: Hold sammen på sikkerheden under en krise - A.8.6: Nok kapacitet til at blive ved med at køre ### Backups kan ikke gendannes Der findes backups, men en rigtig gendannelse virker ikke, når der er brug for den. Niveau: 10 (høj). Behandling: Ændr med foranstaltninger. Ejer: endnu ikke nævnt Foranstaltninger, der behandler denne risiko: - A.8.13: Tag backup og bevis at genskabelse virker ### Fratrædende medarbejder beholder adgang Adgang inddrages ikke hurtigt, når nogen stopper. Niveau: 9 (middel). Behandling: Ændr med foranstaltninger. Ejer: endnu ikke nævnt Foranstaltninger, der behandler denne risiko: - A.5.11: Få udstyr og data tilbage, når folk holder op - A.6.5: Pligter der varer ud over fratrædelsen - A.5.18: Tildel, gennemgå og fjern rettigheder ### Udstyr eller medier bortskaffes med data stadig på En disk, et USB-stik eller en gammel bærbar forlader virksomheden uden at være slettet. Niveau: 8 (middel). Behandling: Ændr med foranstaltninger. Ejer: endnu ikke nævnt Foranstaltninger, der behandler denne risiko: - A.7.10: Håndtér diske, drev og flytbare medier - A.7.14: Slet udstyr før bortskaffelse eller genbrug - A.8.10: Slet data I ikke længere har brug for ### Brud hos en leverandør eller cloududbyder En leverandør, der opbevarer vores information eller driver en del af vores tjeneste, kompromitteres, og vi hører om det sent eller slet ikke. Niveau: 12 (høj). Behandling: Ændr med foranstaltninger. Ejer: endnu ikke nævnt Foranstaltninger, der behandler denne risiko: - A.5.19: Styr den risiko, leverandører bringer med sig - A.5.20: Skriv sikkerhedsvilkår ind i leverandørkontrakter - A.5.21: Sikkerhed gennem teknologiens leverandørkæde - A.5.22: Hold øje med leverandørerne, mens de ændrer sig ### Hændelse ikke opdaget eller anmeldt i tide En sikkerhedshændelse bemærkes af ingen, eller af nogen, der ikke ved, hvor den skal anmeldes, og reaktionen begynder dage for sent. Niveau: 12 (høj). Behandling: Ændr med foranstaltninger. Ejer: endnu ikke nævnt Foranstaltninger, der behandler denne risiko: - A.5.24: Vær klar, før hændelsen indtræffer - A.5.25: Vurdér hvilke begivenheder der er rigtige hændelser - A.5.26: Handl når en hændelse er erklæret - A.5.27: Lær af hændelser bagefter - A.6.8: Gør det let for medarbejderne at melde problemer ### Juridisk eller kontraktligt krav overset En lov, en forordning, en licens eller en kundekontrakt kræver noget af os, som ingen har skrevet ned, og hullet findes af en auditor, en kunde eller en myndighed. Niveau: 9 (middel). Behandling: Ændr med foranstaltninger. Ejer: endnu ikke nævnt Foranstaltninger, der behandler denne risiko: - A.5.31: Kend de love og kontrakter, der binder jer - A.5.32: Respektér ophavsret og softwarelicenser - A.5.35: Få sikkerheden gennemgået af en uafhængig - A.5.36: Kontrollér at jeres egne regler faktisk følges - A.8.34: Auditér systemer uden at forstyrre dem ### Sikkerhedsansvar uklart eller uden ejer En foranstaltning har ingen navngiven ejer, en pligt deles af alle og udføres af ingen, eller én person holder en rolle, der burde være adskilt. Niveau: 9 (middel). Behandling: Ændr med foranstaltninger. Ejer: endnu ikke nævnt Foranstaltninger, der behandler denne risiko: - A.5.1: Skriftlige sikkerhedspolitikker, godkendte og opdaterede - A.5.2: Hvem der er ansvarlig for hvad i sikkerheden - A.5.3: Del følsomme opgaver mellem flere mennesker - A.5.4: Hvad ledelsen skal kræve af alle - A.5.37: Skriv ned hvordan tingene faktisk gøres - A.6.2: Sikkerhedspligter skrevet ind i ansættelsesvilkårene ### Folk kommer eller går uden sikkerhedsgrundlaget Nogen begynder uden screening, vilkår eller fortrolighedsaftale, eller ingen ved, hvad der sker, når en regel brydes. Niveau: 9 (middel). Behandling: Ændr med foranstaltninger. Ejer: endnu ikke nævnt Foranstaltninger, der behandler denne risiko: - A.6.1: Baggrundstjek før ansættelse - A.6.4: Konsekvenser når reglerne brydes - A.6.6: Fortrolighedsaftaler - A.5.5: Vide hvem man kontakter hos myndighederne - A.5.6: Holde forbindelsen til sikkerhedsfællesskaber ### Information delt eller flyttet usikkert Fortrolig information sendes, overføres eller eksponeres på et netværk eller en tjeneste uden den håndtering, dens klassifikation kræver. Niveau: 12 (høj). Behandling: Ændr med foranstaltninger. Ejer: endnu ikke nævnt Foranstaltninger, der behandler denne risiko: - A.5.13: Mærk oplysninger med deres følsomhed - A.5.14: Send oplysninger sikkert, internt og eksternt - A.8.3: Begræns hvad den enkelte kan åbne - A.8.21: Aftal sikkerhedsvilkår for netværkstjenester - A.8.19: Styr hvad der installeres i produktion - A.5.8: Byg sikkerhed ind i ethvert projekt ### Sårbarhed indført i egen software Usikker kode eller en usikker afhængighed når produktion. Niveau: 12 (høj). Behandling: Ændr med foranstaltninger. Ejer: endnu ikke nævnt Foranstaltninger, der behandler denne risiko: - A.8.25: Sikkerhed gennem hele måden software bliver til på - A.8.26: Afgør hvad en applikation sikkert skal kunne - A.8.27: Design systemer på sikre principper - A.8.28: Skriv kode der står imod angreb - A.8.33: Brug ufarlige data når I tester - A.8.8: Find og luk kendte svagheder ### Uautoriseret videregivelse af personoplysninger Kunders personoplysninger eksponeres for den forkerte part. Niveau: 15 (høj). Behandling: Ændr med foranstaltninger. Ejer: endnu ikke nævnt Foranstaltninger, der behandler denne risiko: - A.5.34: Beskyt personoplysninger - A.8.12: Forhindr data i at slippe ud, hvor de ikke må - A.5.12: Inddel oplysninger efter følsomhed - A.8.11: Skjul data der ikke behøver at blive vist ## Foranstaltninger nævnt af planen (59) De foranstaltninger i anneks A, som behandlingsplanen nævner, og som erklæringen om anvendelighed derefter bærer som anvendelige: - A.5.1: Skriftlige sikkerhedspolitikker, godkendte og opdaterede - A.5.2: Hvem der er ansvarlig for hvad i sikkerheden - A.5.3: Del følsomme opgaver mellem flere mennesker - A.5.4: Hvad ledelsen skal kræve af alle - A.5.5: Vide hvem man kontakter hos myndighederne - A.5.6: Holde forbindelsen til sikkerhedsfællesskaber - A.5.8: Byg sikkerhed ind i ethvert projekt - A.5.11: Få udstyr og data tilbage, når folk holder op - A.5.12: Inddel oplysninger efter følsomhed - A.5.13: Mærk oplysninger med deres følsomhed - A.5.14: Send oplysninger sikkert, internt og eksternt - A.5.18: Tildel, gennemgå og fjern rettigheder - A.5.19: Styr den risiko, leverandører bringer med sig - A.5.20: Skriv sikkerhedsvilkår ind i leverandørkontrakter - A.5.21: Sikkerhed gennem teknologiens leverandørkæde - A.5.22: Hold øje med leverandørerne, mens de ændrer sig - A.5.23: Brug cloudtjenester sikkert - A.5.24: Vær klar, før hændelsen indtræffer - A.5.25: Vurdér hvilke begivenheder der er rigtige hændelser - A.5.26: Handl når en hændelse er erklæret - A.5.27: Lær af hændelser bagefter - A.5.29: Hold sammen på sikkerheden under en krise - A.5.30: Hold teknikken kørende gennem forstyrrelser - A.5.31: Kend de love og kontrakter, der binder jer - A.5.32: Respektér ophavsret og softwarelicenser - A.5.34: Beskyt personoplysninger - A.5.35: Få sikkerheden gennemgået af en uafhængig - A.5.36: Kontrollér at jeres egne regler faktisk følges - A.5.37: Skriv ned hvordan tingene faktisk gøres - A.6.1: Baggrundstjek før ansættelse - A.6.2: Sikkerhedspligter skrevet ind i ansættelsesvilkårene - A.6.3: Lær folk at arbejde sikkert - A.6.4: Konsekvenser når reglerne brydes - A.6.5: Pligter der varer ud over fratrædelsen - A.6.6: Fortrolighedsaftaler - A.6.8: Gør det let for medarbejderne at melde problemer - A.7.9: Beskyt udstyr uden for matriklen - A.7.10: Håndtér diske, drev og flytbare medier - A.7.14: Slet udstyr før bortskaffelse eller genbrug - A.8.1: Sikr bærbare, telefoner og stationære - A.8.3: Begræns hvad den enkelte kan åbne - A.8.5: Log ind sikkert - A.8.6: Nok kapacitet til at blive ved med at køre - A.8.8: Find og luk kendte svagheder - A.8.10: Slet data I ikke længere har brug for - A.8.11: Skjul data der ikke behøver at blive vist - A.8.12: Forhindr data i at slippe ud, hvor de ikke må - A.8.13: Tag backup og bevis at genskabelse virker - A.8.14: Reservekapacitet så et svigt kan overleves - A.8.19: Styr hvad der installeres i produktion - A.8.21: Aftal sikkerhedsvilkår for netværkstjenester - A.8.23: Filtrér adgang til risikable websteder - A.8.24: Brug kryptering rigtigt og styr nøglerne - A.8.25: Sikkerhed gennem hele måden software bliver til på - A.8.26: Afgør hvad en applikation sikkert skal kunne - A.8.27: Design systemer på sikre principper - A.8.28: Skriv kode der står imod angreb - A.8.33: Brug ufarlige data når I tester - A.8.34: Auditér systemer uden at forstyrre dem Risiciene er et første udkast til en virksomhed med denne profil, og scorerne er virksomhedens egne; foranstaltningerne læses fra pakkens anneks A-data. Dette er et dokument, ikke et certifikat.
Registret, erklæringen begynder med
StandardOS sår de samme startrisici på dag ét, holder score, ejer og gennemgangsdato på hver, gør hver behandling til en position i erklæringen om anvendelighed og genåbner vurderingen med det interval, punkt 8.2 kræver.
Skalaen, båndene og grænsen er StandardOS' egen metode; standarden kræver kriterier og overlader metoden til organisationen. Startrisiciene læses fra pakken, aldrig tastet på denne side, og deres foranstaltningsreferencer er identifikatorer i anneks A med StandardOS' egne titler. Dette er et dokument, ikke juridisk rådgivning eller certificeringsrådgivning.