Rapportens anbefalinger set fra SOC, IT‑drift og HR

En red team-rapport skrives som udgangspunkt til sikkerhedsfunktionen, men anbefalingerne skal udføres af flere andre. SOC’en skal ændre sin overvågning, IT-driften sine rettigheder og konfigurationer, HR sin uddannelse og sine processer, og facility sin adgangskontrol. Hvis anbefalingerne sendes videre i rapportens sprog, bliver de læst som kritik eller som uforståelige krav. Oversættelsen hviler på at forstå, hvad hver modtager ejer, hvad den kan ændre, og hvilket sprog den taler.

Kort fortalt: Del anbefalingerne efter ejer, skriv hver enkelt om, så den beskriver den ønskede tilstand i modtagerens egne termer, og forklar med få ord, hvorfor den er vigtig. Detaljerne om angrebsvejen bliver i en lille kreds.

Hvorfor oversættelsen er nødvendig

Red teams anbefalinger tager udgangspunkt i angrebsvejen: her kom holdet ind, her bevægede det sig videre, her blev det ikke set. For den, der skal handle, er angrebsvejen ikke nødvendigvis det nyttige. En driftsleder har brug for at vide, hvilke konti eller systemer der skal ændres, og hvorfor. En HR-chef har brug for at vide, hvilken proces der ikke virkede, ikke hvilken medarbejder der blev snydt.

De tekniske reguleringsstandarder for TLPT kræver, at udbedringsplanen for hvert resultat angiver de medarbejdere eller funktioner, der har ansvaret for tiltagene. Kravet gælder kun de regulerede test, men det understreger pointen: en anbefaling uden en ejer, der forstår den, bliver ikke gennemført. → Handlingsplan efter red teaming

SOC og overvågning

For SOC’en kan anbefalingerne handle om, hvad der burde være set, og hvad der skulle være sket, da det blev set. Oversæt dem til tre spørgsmål: hvilken aktivitet skulle udløse en alarm, hvilke data kræver det, og hvad skal analytikeren gøre?

Detektion · hvilke situationer fra øvelsen bør fremover give en alarm?
Datagrundlag · mangler der logs eller synlighed, som SOC’en ikke selv kan skaffe?
Reaktion · var eskaleringen klar, og vidste analytikeren, hvem der skulle kontaktes?
Leverandøren · hvad skal ændres i aftalen, hvis SOC’en er en ekstern tjeneste?

Det sidste er vigtigt. En ekstern SOC kan kun reagere på det, aftalen dækker. Hvis øvelsen viste et hul i dækningen, er anbefalingen også en sag for den, der ejer kontrakten. → SOC-leverandøren og øvelsen

IT-drift og infrastruktur

IT-driften kan modtage de mest konkrete anbefalinger: færre konti med vide rettigheder, bedre adskillelse mellem net, en mere konsekvent opdatering. Skriv dem på begrebsniveau med en tydelig målsætning, og lad driften selv beskrive, hvordan de opnås. Driften kender afhængighederne og ved, hvad en ændring betyder for brugerne.

Vær opmærksom på, at nogle anbefalinger kan opleves som kritik af en driftsorganisation, der har gjort, hvad den blev bedt om. Gør det klart, at fundet handler om rammerne, ikke om personerne. Hvis driften ligger hos en leverandør, skal anbefalingen gå gennem den, der ejer kontrakten, og ikke direkte til leverandørens teknikere. → Fra fund til processer

HR og mennesker

Fund fra social engineering og fysisk adgang kan ende hos HR, og her er oversættelsen mest følsom. Anbefalingen må aldrig handle om enkeltpersoner. Den skal beskrive, hvilken proces, hvilken uddannelse eller hvilken ramme der gjorde det svært for medarbejderne at handle rigtigt.

Gode anbefalinger til HR handler fx om, hvordan nye medarbejdere lærer at bekræfte henvendelser, hvordan der meldes mistænkelige forhold, og hvordan ledere reagerer, når nogen melder for meget hellere end for lidt. De handler også om, hvordan berørte medarbejdere er blevet debriefet, og om der er brug for opfølgning. → Fund om mennesker i rapporten

Tillidsrepræsentanten kan være en god samarbejdspartner, når anbefalingerne skal omsættes til praksis, fordi tilliden mellem medarbejdere og ledelse er en forudsætning for, at nye procedurer bliver fulgt.

Facility, servicedesk og leverandører

Anbefalinger om fysisk adgang går til facility og eventuelt til vagtselskabet og udlejeren. De skal beskrive, hvilken del af adgangskontrollen der ikke virkede efter hensigten, og hvilket ansvar der skal placeres. Servicedesken skal have anbefalinger om, hvordan henvendelser bekræftes, formuleret som en ændring i procedure, ikke som en fejl hos den enkelte.

Leverandører, der indgik i øvelsen, har krav på at få de anbefalinger, der vedrører dem, men ikke hele rapporten. Del den del, der er relevant for leverandørens ansvar, og aftal, hvordan opfølgningen dokumenteres. Tjek kontrakten først. Den kan sige, hvad leverandøren skal udbedre for egen regning, hvad der kræver en ændringsordre, og hvem der må se resultatet. Det er også her, I opdager, om aftalen mangler noget til næste gang.

Én kilde, flere udgaver

Hold den samlede liste over anbefalinger ét sted, med ejer, status og en henvisning til det fund, den bygger på. Lav derefter en kort udgave til hver modtager med kun de anbefalinger, der vedrører den, skrevet i modtagerens sprog. Så kan sikkerhedsfunktionen følge helheden, mens hver afdeling arbejder med sit eget.

Giv hver udgave samme opbygning: hvad blev observeret, hvad er målet, hvem ejer opgaven, og hvornår følges der op. Når alle afdelinger kender formen, bliver det lettere at sammenligne status på tværs og at samle den til ledelsen.

Opdater begge niveauer, når status ændres. Hvis en afdeling vælger at acceptere en risiko i stedet for at gennemføre en anbefaling, skal beslutningen stå i den samlede liste med begrundelse og godkendelse. → Rodårsager efter red teaming

Når modtageren er uenig

En afdeling, der får en anbefaling, kan være uenig i den. Driften kan mene, at ændringen vil skade brugerne mere end den gavner, eller SOC-leverandøren kan mene, at den ønskede overvågning ligger uden for aftalen. Uenighed er ikke nødvendigvis modstand. Den kan bygge på viden, som red team ikke havde.

Tag derfor dialogen, før anbefalingen låses i handlingsplanen. Lad modtageren foreslå en anden måde at nå samme mål på, og vurder forslaget ud fra den rodårsag, anbefalingen skulle løse. Hvis uenigheden ikke kan løses, skal den op til den, der ejer risikoen, og beslutningen skal skrives ned med begrundelse. Så er det tydeligt bagefter, hvorfor organisationen valgte, som den gjorde.

Det skal I lade være med

At sende hele rapporten til alle · hver modtager skal have sin del.
At skrive anbefalinger til HR om enkeltpersoner · det skader tilliden og ændrer ikke processen.
At diktere den tekniske løsning til driften · beskriv målet, og lad ejeren vælge vejen.
At glemme leverandørerne · de kan eje en del af løsningen.
At miste overblikket · den samlede liste skal holdes ajour.

Hvad kan og ikke kan konkluderes

En god oversættelse gør det sandsynligt, at anbefalingerne bliver forstået og gennemført. Den kan ikke sikre, at de virker efter hensigten. Det kræver, at effekten senere efterprøves, fx i en purple team-session eller en ny øvelse. Anbefalingerne dækker heller kun de svagheder, øvelsen afdækkede.

Kilder

Kommissionens delegerede forordning (EU) 2025/1190: artikel 13, stk. 2, litra b og d, om afhjælpende foranstaltninger, herunder forbedring af identifikations-, beskyttelses-, detektions- og indsatskapacitet, og om ansvarlige medarbejdere eller funktioner; artikel 1, nr. 4, om blåt team-opgaver som SOC, IKT-infrastruktur og helpdesk.

Senest gennemgået: oktober 2026.