En SOC-analytiker arbetar med att upptäcka intrång tidigt, rapportera incidenter tydligt och visa hur säkerhetsarbetet fungerar i drift när cybersäkerhetsarbetet i Sverige förändras.
En SOC-analytiker arbetar i ett Security Operations Center och analyserar säkerhetslarm, loggar och misstänkt aktivitet för att avgöra om en organisation är utsatt för ett verkligt hot. Rollen ligger nära den praktiska vardagen i cybersäkerhet: att skilja brus från risk, eskalera rätt händelser, dokumentera beslut och hjälpa incidenthanteringsteamet att begränsa skadan när något händer.
Uppdaterad för 2026. Den här artikeln är skriven för svensk kontext och utgår från hur rollen ofta ser ut i organisationer som påverkas av NIS2, GDPR, MSB:s vägledning och europeiska rekommendationer från exempelvis ENISA. Den innehåller inga löne- eller bristsiffror, eftersom sådana uppgifter snabbt blir missvisande utan aktuell arbetsmarknadsdata.
Vad en SOC-analytiker gör i praktiken
Det enklaste sättet att förstå SOC-rollen är att följa ett larm från början till slut. Ett SIEM-system, till exempel Microsoft Sentinel, Splunk eller QRadar, tar emot loggar från identitetsplattformar, molntjänster, brandväggar, servrar, klienter och säkerhetsverktyg. När en regel eller en beteendeanalys flaggar något avvikande hamnar händelsen hos analytikern, som behöver avgöra om det rör sig om ett falsklarm, ett policybrott, ett pågående angrepp eller något som kräver mer utredning.
I praktiken är rollen mindre dramatisk och mer metodisk än många förväntar sig. En analytiker tittar på tidslinjer, användarkonton, IP-adresser, processer, e-postrubriker, filhashar och autentiseringsmönster. Om larmet gäller misstänkt inloggning i Microsoft 365 kan arbetet börja i identitetsloggar och fortsätta i EDR-verktyg som Microsoft Defender for Endpoint eller CrowdStrike för att se om samma konto använts på en komprometterad dator. Om larmet gäller skadlig kod behöver analytikern förstå vad som kördes, hur det startade, vilka system som påverkades och om aktiviteten passar in i kända tekniker i MITRE ATT&CK.
En viktig del av arbetet är att följa runbooks. En runbook beskriver vad analytikern ska kontrollera, vilka frågor som ska besvaras, när ett ärende ska eskaleras och hur kommunikationen ska dokumenteras. Bra runbooks skyddar SOC-teamet från godtycke under stress. Dåliga runbooks leder ofta till långsamma eskaleringar, ofullständiga incidentrapporter och osäkerhet om vem som äger nästa steg.
Varför svensk efterfrågan ser annorlunda ut nu
Svenska arbetsgivare påverkas av samma hotbild som andra europeiska organisationer, men regelverken gör rollen mer processnära än tidigare. NIS2 innebär ökade krav på styrning, riskhantering och incidentrapportering för fler typer av samhällsviktiga och digitala verksamheter. Det gör att SOC-arbetet inte längre bara handlar om teknisk detektion. Analytikern behöver också förstå varför tidpunkter, bevis, beslutsloggar och eskaleringsvägar kan få betydelse för rapportering och efterlevnad.
MSB har en central roll i svensk cybersäkerhet genom vägledning, samordning och information kopplad till incidentrapportering och samhällsviktig verksamhet. IMY är relevant när en säkerhetsincident kan innebära en personuppgiftsincident enligt GDPR. För SOC-analytikern betyder detta att dokumentationen måste vara begriplig även utanför säkerhetsteamet. Juridik, kommunikation, verksamhetsledning och dataskyddsombud kan behöva förstå vad som hänt, vilka system som berörts och vilka åtgärder som redan har vidtagits.
Typiska arbetsgivare i Sverige finns inom bank och finans, offentlig sektor, vård, energi, telekom, industri, detaljhandel, SaaS-bolag och konsult- eller MSSP-miljöer som driver SOC åt flera kunder. Skillnaden mellan dessa miljöer är stor. En intern SOC-funktion lär känna en organisations system på djupet, medan en MSSP-analytiker ofta behöver växla mellan flera kundmiljöer, olika prioriteringar och varierande mognadsgrad. Båda vägarna kan vara bra, men de utvecklar delvis olika förmågor.
Vardagen i ett SOC: larm, skift och samarbete
Många SOC:er arbetar med någon form av dygnet-runt-täckning, men uppläggen varierar. Vissa har skiftgång på plats eller hybrid, andra använder beredskap, och större organisationer kan kombinera nordiska team med så kallad follow-the-sun-modell där ärenden lämnas över mellan tidszoner. För den som söker sin första SOC-roll är detta mer än en praktisk detalj. Skift påverkar återhämtning, lärande, familjeliv och ibland ersättningsmodell. Beredskap kan ge mer normal kontorstid men kräver att personen kan agera snabbt när en incident eskalerar utanför ordinarie arbetstid.
En L1-analytiker hanterar ofta triage: att bekräfta larm, samla grunddata, bedöma allvarlighetsgrad och avgöra om ärendet ska stängas, övervakas eller eskaleras. L2-analytiker går djupare i utredningar, justerar detektioner, korrelerar flera datakällor och kan föreslå åtgärder som isolering av en enhet eller återställning av kontoåtkomst. L3, incident responders och threat hunters arbetar ofta med mer komplexa intrång, forensik, proaktiv hotjakt och förbättring av detektionslogik.
Samarbetet är avgörande. SOC-teamet är sällan det team som ensam åtgärdar grundorsaken. Om ett konto missbrukas behövs identitets- eller IT-driftsteam. Om en sårbar server exponeras behövs systemägare och patchansvariga. Om kunddata kan vara berörd behövs dataskydd och juridik. En stark SOC-analytiker kan därför översätta tekniska fynd till tydliga beslut: vad som är bekräftat, vad som är osäkert, vilken risk som finns och vilken åtgärd som bör prioriteras.
Teknikstacken: från SIEM till respons
SIEM är ofta navet i SOC-arbetet, men det är inte hela arbetet. SIEM samlar och korrelerar data, medan EDR ger insyn i klienter och servrar. Identitetsplattformar visar autentisering, privilegieändringar och åtkomstmönster. E-postsäkerhet hjälper analytikern att förstå phishingkedjor, och sårbarhetsskannrar visar vilka system som kan vara särskilt riskutsatta. Hotunderrättelser ger kontext, men de ersätter inte analys av den egna miljön.
I Norden är Microsoft 365 och Azure vanligt förekommande i många organisationer. Det gör erfarenhet av Microsoft Sentinel, Defender-portalen, Entra ID-loggar och KQL särskilt användbar för många SOC-roller. Det betyder inte att andra verktyg är oviktiga, men det påverkar vilka praktiska färdigheter som ofta ger snabb nytta i svenska miljöer. En kandidat som kan förklara hur ett larm i Sentinel kopplas till en Defender-utredning och sedan dokumenteras i en incidentprocess visar en mer arbetsnära förståelse än någon som bara kan namnge verktyg.
MITRE ATT&CK används ofta som ett gemensamt språk för angriparbeteenden. I stället för att bara säga att ett larm gäller “misstänkt aktivitet” kan analytikern beskriva om det liknar exempelvis credential access, lateral movement eller persistence. Den precisionen gör det lättare att prioritera rätt loggkällor och avgöra vilka system som behöver kontrolleras härnäst.
Vägen in: utbildning, erfarenhet och de första 90 dagarna
Det finns ingen enda väg in i SOC-yrket. Många kommer från IT-drift, NOC, servicedesk, systemadministration, nätverk, molndrift eller juniora säkerhetsroller. Den gemensamma nämnaren är inte en viss examen, utan förmågan att felsöka strukturerat, förstå systembeteende och dokumentera slutsatser. Systemadministratörer tar ofta med sig kunskap om patchning, Active Directory, behörigheter och skriptning. NOC-tekniker är vana vid övervakning, eskalering och larmflöden. Servicedeskpersoner har ofta stark förståelse för incidentprocesser, användarkommunikation och ärendedokumentation. Alla dessa erfarenheter kan mappas mot L1-triage i ett SOC.
Den vanligaste missen bland nybörjare är att samla certifikat utan att kunna visa praktisk loggförståelse. Arbetsgivare vill ofta se hur kandidaten tänker när informationen är ofullständig. Vad kontrolleras först? Vilka alternativa förklaringar finns? När räcker bevisen för eskalering? Hur dokumenteras en slutsats så att nästa analytiker kan fortsätta utan att börja om?
Bygg en liten labbmiljö med klient, logginsamling och minst en realistisk säkerhetshändelse.
Skapa en enkel runbook som beskriver hur ett larm ska triageras och när det ska eskaleras.
Skriv en kort incidentrapport efter varje övning med tidslinje, fynd, åtgärder och kvarstående frågor.
Öva KQL, PowerShell eller Python på uppgifter som filtrering, korrelation och snabb datainsamling.
Samla projekten i en portfölj som visar resonemang, inte bara skärmbilder från verktyg.
En praktisk första labb kan vara att skicka Windows-händelser och Sysmon-loggar till Log Analytics eller Sentinel, skapa ett larm för misstänkt PowerShell-användning och sedan skriva en runbook för hur larmet ska utredas. Det behöver inte vara en företagslik miljö för att vara värdefullt. Det viktiga är att kandidaten kan visa hela kedjan: datakälla, detektionsidé, triage, slutsats och förbättringsförslag.
Certifieringar som passar SOC-rollen
Certifieringar kan hjälpa en kandidat att strukturera lärandet och visa att vissa begrepp sitter, men de bör inte ersätta praktiska projekt. För en person som siktar på SOC i en Microsoft-tung nordisk miljö är Microsoft SC-200 relevant eftersom den mäter arbete med hotjakt och respons i Microsoft Sentinel och Defender. CompTIA CySA+ är bredare och fokuserar på beteendeanalys, detektion och respons, vilket gör den användbar för roller där verktygsstacken varierar. GIAC GCIH är mer incidenthanteringsinriktad och passar ofta bättre när personen redan arbetar närmare incident response.
CompTIA Security+ kan fungera som grund om personen saknar säkerhetsbakgrund, men den räcker sällan ensam för att visa SOC-förmåga. CISSP är däremot en avancerad certifiering för bred säkerhetsstyrning och erfarenhet; den är värdefull i många karriärer men är normalt inte den mest naturliga första certifieringen för en junior SOC-analytiker. Det klokaste valet beror på vilken miljö personen söker sig till: Microsoft SOC, generell MDR/MSSP, intern säkerhetsfunktion eller mer incidenthanteringsnära arbete.
Utbildningsleverantörer kan vara användbara när certifieringsmålet är tydligt och tiden behöver struktureras. Readynez erbjuder exempelvis utbildning inom säkerhetscertifieringar, men den avgörande frågan för en blivande SOC-analytiker är fortfarande om lärandet kopplas till praktisk triage, logganalys och dokumenterade incidentövningar.
Karriärsteg: från L1 till threat hunting och SOC-ledning
Karriärutvecklingen i ett SOC sker ofta genom att analytikern tar ansvar för mer komplexa beslut. L1 handlar om noggrann triage och konsekvent dokumentation. Nästa steg är att förstå varför larm uppstår, vilka regler som skapar brus och vilka loggkällor som saknas. Den som vill växa mot L2 bör därför inte bara stänga ärenden, utan också bidra till post-incident-lärande: vad borde ha upptäckts tidigare, vilken runbook var otydlig och vilken detektion behöver justeras?
Threat hunting kräver ett mer hypotesdrivet arbetssätt. I stället för att vänta på larm formulerar analytikern en fråga, till exempel om en viss typ av lateral movement kan ha skett utan att befintliga regler fångat det. Därefter används loggar, ATT&CK-tekniker och miljökännedom för att leta efter mönster. Den som har byggt vana vid KQL, tidslinjer och identitetsloggar får ofta ett naturligt försprång.
Incident responder är en närliggande väg för den som vill arbeta mer intensivt med bekräftade intrång, bevisinhämtning, containment och återställning. SOC-ledare behöver i stället kombinera teknisk förståelse med bemanning, process, kvalitetssäkring och kommunikation med verksamhetsledning. I nordiska organisationer kan rollerna ibland överlappa, särskilt i mindre team, vilket gör bred förståelse viktig även för den som senare specialiserar sig.
Vad arbetsgivare ofta letar efter
Vid rekrytering till juniora SOC-roller är det sällan en enskild certifiering som avgör. Arbetsgivare letar ofta efter tecken på att kandidaten kan arbeta lugnt med osäker information, följa process, kommunicera tydligt och förstå tekniska samband. En bra kandidat behöver kunna säga “det här vet vi”, “det här behöver verifieras” och “det här är nästa rimliga steg” utan att överdriva fynden.
Portföljen kan därför vara mer övertygande än ett långt CV. En kort incidentrapport från en labbövning, en enkel KQL-fråga med förklaring, en runbook för phishingtriage eller en analys av ett testlarm visar hur personen tänker. Det är särskilt värdefullt för karriärbytare som ännu saknar SOC-titel men redan har relevant erfarenhet från drift, nätverk eller support.
- Om artikeln: Texten är anpassad för svenska läsare och beskriver SOC-rollen i relation till praktiskt arbete, karriärvägar och regelverk.
- Källor att jämföra med: MSB för svensk cybersäkerhetsvägledning och incidentrapportering, IMY för GDPR och personuppgiftsincidenter, ENISA för europeiska cybersäkerhetsrekommendationer samt MITRE ATT&CK för angripartekniker.
- Avgränsning: Artikeln anger inga löner, passfrekvenser eller jobbgarantier, eftersom sådana uppgifter kräver aktuell och verifierad data.
Att bygga en hållbar väg in i SOC
Den mest robusta vägen in i rollen är att kombinera grundläggande säkerhetskunskap med praktisk analys. Certifieringar kan ge struktur, men de behöver kompletteras med labbar, loggar, runbooks och skriftliga efterhandsrapporter. Den som kan visa hur ett larm undersöks från första signal till tydlig slutsats har något konkret att ta med till intervjun.
Ett rimligt nästa steg är att välja en miljö att öva i, gärna Microsoft Sentinel om målet är många nordiska SOC-roller, och bygga en liten portfölj kring verklighetsnära larmflöden. Readynez kan vara ett alternativ när målet är certifieringsstyrd utbildning, men den långsiktiga utvecklingen avgörs av analytikerns förmåga att förstå hot, förbättra detektioner och kommunicera säkert när incidenter faktiskt inträffar.
