Sätt KPI:er för säkerhetsorkestrering och automatisering genom att koppla incidenttid, automatiseringsgrad, analystimmar och risk till affärsmål. Jämför vad som bör följas upp före och efter en SOAR-satsning.
Rätt KPI:er för SOAR ska visa mer än hur många ärenden som automatiseras. De ska koppla ihop snabbare incidenthantering, bibehållen kvalitet, lägre risk och den totala kostnaden för plattform, integrationer och drift.
Börja med baslinjevärden och följ sedan varje KPI per incidenttyp eller use case. Det gör det lättare att avgöra om en SOAR-plattform, fler integrationer eller konsultledd implementation faktiskt ger verksamhetsnytta.
MTTD och MTTR är ofta viktiga startmått, men de räcker inte ensamma. Lägg till mått för analystid, felaktiga åtgärder och kostnad så att hög automationsgrad inte belönas på bekostnad av säkerheten.
För ett mindre SOC kan frigjord analystid och färre externa eskaleringar vara mest relevant. För större säkerhetsfunktioner blir även playbook-kvalitet, integrationshälsa och kapacitetsutnyttjande viktiga beslutsunderlag.
Exakta nivåer för bra resultat går inte att sätta utan att känna till organisationens incidentvolym, mognad, datakällor och tekniska miljö.
Överblick
- Välj KPI:er inom hastighet, effektivitet, kvalitet/risk och ekonomi – inte bara antal automatiserade ärenden.
- Dokumentera en baslinje före förändringen för att kunna bedöma effekten av nya playbooks och integrationer.
- Överväg plattformsbyte, fler integrationer eller konsultstöd när data visar ett tydligt problem som den aktuella lösningen inte kan hantera.
| KPI-grupp | Exempel på KPI | Datastöd som krävs | Beslut den kan stödja |
|---|---|---|---|
| Hastighet | MTTD, MTTR, tid till korrekt eskalering | Tidsstämplar från larm, utredning och respons | Prioritering av playbooks, bemanning och integrationer |
| Effektivitet | Automatiserade steg, analystid, hanterade ärenden | Playbook-loggar och ärendehantering | Behov av SOAR-licens, automatisering eller extern drift |
| Kvalitet och risk | Falska positiva, felaktiga blockeringar, täckning | Återställningar, analystgranskning och incidentutfall | Krav på mänskligt godkännande och säkrare regler |
| Ekonomi | Kostnad per incident, kostnad per automatiserat arbetsflöde | Kostnader för licens, drift, utbildning och implementation | Budget för plattform, integration och konsultinsats |
Börja med fyra KPI-grupper som kopplar SOC-arbetet till verksamhetsnytta
En användbar KPI-modell svarar på fyra frågor: Går incidenthanteringen snabbare? Frigörs kapacitet? Håller besluten kvalitet? Och är den samlade satsningen rimlig i förhållande till resultatet? Följ måtten per use case, eftersom phishing, misstänkt kontoövertagande och endpoint-larm har olika arbetsflöden och risker.
Hastighet: MTTD, MTTR och tid till korrekt eskalering
MTTD visar tiden till upptäckt och MTTR tiden till respons. De ger en snabb bild av flödet, men bör kompletteras med tid till korrekt eskalering. Ett snabbt avslut är inte ett bra resultat om ärendet har skickats fel, blockerats felaktigt eller lämnat viktiga undantag obehandlade.
Separera gärna mätningen för olika incidenttyper och allvarlighetsgrader. Annars kan ett stort antal enkla larm dölja att kritiska incidenter fortfarande tar lång tid att utreda.
Effektivitet: automatiserade steg, analystid och hanterade ärenden
Följ hur många moment i ett arbetsflöde som automatiseras, snarare än bara hur många ärenden som passerar genom en playbook. Det kan exempelvis handla om insamling av kontext, berikning av ett larm, skapande av ärende eller förberedelse för eskalering.
Analystid är ofta ett mer användbart verksamhetsmått än ren ärendevolym. Om automatiseringen minskar manuella moment kan teamet lägga mer tid på komplexa händelser. Kontrollera samtidigt om tidsbesparingen beror på automatisering, ändrade rutiner eller förbättrad datakvalitet.
Kvalitet och risk: falska positiva, felaktiga åtgärder och täckning
En hög automationsgrad är inte automatiskt ett framsteg. Följ därför falska positiva, felaktiga blockeringar och manuella återställningar. Dessa mått visar om regler, datakällor och eskaleringsgränser fungerar i praktiken.
Täckning är också viktigt: vilka typer av larm och incidentflöden omfattas av playbooks, och vilka lämnas fortfarande helt manuella? Täckning ska inte användas som ett mål i sig. För känsliga åtgärder kan mänskligt godkännande vara nödvändigt.
Ekonomi: kostnad per incident och kostnad per automatiserat arbetsflöde
Räkna in hela kostnadsbilden: licenser, implementation, integrationer, utbildning, drift och löpande optimering. Då blir det möjligt att följa kostnad per hanterad incident och kostnad per automatiserat arbetsflöde utan att reducera beslutet till licenspriset.
Ekonomiska KPI:er är mest användbara när de läses tillsammans med kvalitet och risk. En billigare process är inte nödvändigtvis bättre om den leder till fler felaktiga blockeringar eller mer manuellt efterarbete.
Jämför KPI:er utifrån datakrav, affärsvärde och investeringsbeslut
Varje KPI behöver en tydlig datakälla och en känd begränsning. På så sätt blir rapporteringen användbar vid budgetbeslut och inte bara en aktivitetslista från SOC.
När varje KPI är användbar och vilka feltolkningar som är vanliga
| KPI | När den är användbar | Vanlig feltolkning |
|---|---|---|
| MTTD | När ni vill följa om larm och upptäckt blir snabbare | Att snabb upptäckt alltid betyder god incidenthantering |
| MTTR | När responsflöden och eskaleringar ska förbättras | Att kort responstid säger något om åtgärdens kvalitet |
| Automatiserade steg | När manuellt repetitivt arbete ska minskas | Att fler automatiserade steg alltid innebär högre värde |
| Falska positiva och återställningar | När blockeringar eller andra åtgärder automatiseras | Att de kan utelämnas för att visa högre automationsgrad |
| Kostnad per incident | När licensmodell, drift eller konsultstöd jämförs | Att en lägre kostnad kan bedömas utan hänsyn till risk och kvalitet |
Baslinje före implementation: vilka siffror som måste dokumenteras
Innan en ny SOAR-plattform, integration eller playbook införs bör ni dokumentera nuvarande MTTD, MTTR, manuella moment, analystid och kvalitetsutfall för de use case som ska förändras. Notera även hur många ärenden som eskaleras, hur återställningar hanteras och vilka datakällor som används.
Baslinjen behöver inte vara perfekt från första dagen. Men utan en dokumenterad utgångspunkt går det inte att skilja faktisk effekt från förändringar i incidentvolym, bemanning eller arbetsprocess.
När tidsbesparing kan motivera licens, integration eller konsultinsats
En SOAR-investering kan vara relevant när samma manuella kontroller återkommer, när data måste samlas från flera system eller när eskaleringar fördröjs av otydliga flöden. Men beslutet bör bygga på era egna baslinjer och riskkrav, inte på generella löften om avkastning.
Jämför alltid om problemet främst är brist på plattform, otillräckliga integrationer, låg datakvalitet eller avsaknad av tydliga processer. En konsultledd implementation kan vara relevant när intern kapacitet saknas för att utforma, testa och förvalta playbooks, men ansvar och löpande optimering måste vara tydliga.
Bygg ett praktiskt KPI-ramverk för playbooks och incidentflöden
Det mest hållbara upplägget börjar smalt. Välj ett avgränsat use case, etablera en baslinje och utvärdera både effekt och oönskade konsekvenser innan fler flöden automatiseras.
Välj ett avgränsat use case, exempelvis phishing eller misstänkt kontoövertagande
Phishing och misstänkt kontoövertagande är exempel på use case där arbetsflödet kan innehålla flera återkommande steg. Kartlägg först vad som sker från larm till beslut: vilken information hämtas, vem granskar, när eskaleras ärendet och vilka åtgärder kräver godkännande?
Undvik att göra ett enda KPI-paket för hela SOC. Ett avgränsat use case gör det lättare att se om en specifik playbook sparar tid utan att skapa fler fel eller undantag.
Definiera mål, mätpunkt, datakälla, ansvarig och uppföljningsintervall
Varje KPI bör ha fem delar: mål, mätpunkt, datakälla, ansvarig och uppföljningsintervall. Exempelvis kan målet vara kortare tid till korrekt eskalering, mätpunkten vara tidsstämplar i incidentflödet och ansvarig vara den funktion som förvaltar playbooken.
Bestäm även vem som granskar avvikelser. Om felaktiga blockeringar eller manuella återställningar ökar behöver det finnas en tydlig väg för att justera regler, integrationslogik eller kravet på mänskligt godkännande.
Separera resultat från automatisering, processförändring och bättre datakvalitet
Om MTTR förbättras efter ett projekt betyder det inte automatiskt att SOAR-plattformen ensam är orsaken. Resultatet kan också bero på tydligare ansvar, bättre datakällor, ändrad prioritering eller utbildning.
Markera därför vilken förändring som infördes när: ny playbook, ny integration, uppdaterade eskaleringsregler eller förändrat arbetssätt. Det ger ett mer trovärdigt underlag inför nästa licensförhandling eller investering.
Undvik vanliga misstag när automatiserad säkerhet ska mätas
Fel KPI:er kan driva fram hög aktivitet men sämre incidenthantering. Sätt därför kvalitetsgränser redan när måtten väljs.
Att bara mäta antal automatiserade ärenden
Antal automatiserade ärenden säger inte om automatiseringen var relevant, korrekt eller säker. Komplettera alltid volym med analystid, eskaleringsutfall och kvalitetsmått för varje use case.
Att sakna mått för felaktiga blockeringar och manuella återställningar
Automatiserade blockeringar kan få konsekvenser om undantag missas. Följ därför hur ofta åtgärder behöver återställas, granskas manuellt eller ändras efteråt. Detta är särskilt viktigt när playbooks påverkar konton, IP-adresser eller e-postmeddelanden.
Att jämföra incidenter med olika allvarlighetsgrad som om de vore likvärdiga
Ett enkelt e-postlarm och en kritisk incident har sällan samma arbetsflöde. Dela upp rapporteringen efter incidenttyp, use case och relevant allvarlighetsgrad. Då minskar risken att genomsnittsvärden döljer köer eller kvalitetsproblem i de mest viktiga flödena.
Anpassa uppföljningen efter teamets storlek och säkerhetsmodell
KPI-ramverket ska spegla vem som gör arbetet, vem som äger verktygen och vem som bär ansvaret när automatisering behöver ändras.
Mindre team: prioritera analystid, kritiska incidenter och externa eskaleringar
Mindre team har ofta mest nytta av få och tydliga KPI:er. Följ analystid i återkommande flöden, tid till hantering av kritiska incidenter och hur ofta ärenden måste skickas externt. Det ger ett konkret underlag för att avgöra om en enklare automatisering, en SOAR-plattform eller extern hjälp är mest relevant.
Eget SOC: följ playbook-kvalitet, integrationshälsa och kapacitetsutnyttjande
Ett eget SOC kan följa fler nivåer: kvalitet i playbooks, om integrationer levererar tillförlitliga data och hur kapaciteten används mellan rutinärenden och komplexa utredningar. När flera system kopplas ihop blir integrationshälsa ett viktigt kontrollmått, eftersom svaga datakällor påverkar automatiseringens kvalitet.
MSSP eller hybridmodell: definiera ansvar, SLA och rapporteringsformat
Vid MSSP- eller hybridmodell bör rapporteringen tydligt skilja mellan leverantörens ansvar och den interna funktionens ansvar. Definiera vilka tidsmått som följs, vilka åtgärder som kräver kundgodkännande och hur avvikelser rapporteras. SLA och rapportformat bör stödja era egna risk- och verksamhetsmål, inte bara leverantörens aktivitetsmått.
Val av plattform och jämförelse inför beslut
En SOAR-plattform bör väljas utifrån konkreta arbetsflöden, datakällor och kontrollbehov. Funktioner som inte kan kopplas till ett tydligt use case riskerar att öka både integrationskostnad och förvaltningsbehov.
Kontrollera integrationsbehov, datakvalitet och krav på mänskligt godkännande
Lista vilka system som behöver bidra med data eller ta emot åtgärder. Bedöm sedan om datakvaliteten räcker för automatiserade beslut och var mänskligt godkännande ska finnas kvar. Fråga särskilt hur playbooks hanterar undantag, misslyckade integrationer och återställningar.
Jämför total kostnad: licens, implementation, drift, utbildning och förändringsarbete
Jämför inte bara licensmodeller. Ta med implementation, integrationer, utbildning, drift och löpande optimering i beslutsunderlaget. Exakta kostnader varierar mellan leverantörer och tekniska miljöer, så offertjämförelsen behöver utgå från samma use case och samma integrationskrav.
Frågor att använda vid leverantörsdemo, offert och konsultupphandling
- Vilka av våra prioriterade use case kan stödjas utan att kvalitet och godkännandekrav tappas bort?
- Vilka integrationer krävs, och vilket ansvar har respektive part för drift och felsökning?
- Hur kan vi mäta automatiserade steg, analystid, felaktiga åtgärder och återställningar?
- Hur hanteras mänskligt godkännande, undantag och ändringar i playbooks?
- Vad ingår i licens, implementation, utbildning och löpande optimering?
- Vilket rapporteringsformat kan användas för att följa våra egna KPI:er per incidenttyp?
Urvalskriterier och jämförelse i korthet
Välj intern drift när teamet kan äga processer, playbooks och löpande optimering. Välj en SOAR-plattform när återkommande arbetsflöden, integrationsbehov och datakällor är tydligt definierade. Överväg konsultledd implementation när ni behöver hjälp att utforma, testa eller integrera lösningen men vill ha tydlighet kring framtida förvaltning.
Kontrollera särskilt baslinjevärden, prioriterade use case, integrationsomfattning, krav på mänskligt godkännande och total kostnadsbild. Vid offertjämförelse bör samma frågor och samma incidentflöden användas för alla alternativ. Officiella villkor och detaljer om funktioner, integrationer och licensupplägg bör kontrolleras på respektive leverantörs sida.
Avslutningsvis
SOAR-KPI:er fungerar bäst när de visar balans mellan snabbhet, arbetsinsats, kvalitet och risk. Börja med en avgränsad playbook, dokumentera baslinjen och följ både positiva och negativa utfall. Då blir det lättare att prioritera nästa integration, justera automatiseringen eller bedöma om en större plattformssatsning är motiverad.
Praktisk information att ta med sig
MTTD och MTTR visar tempo, men behöver kompletteras med mått för korrekthet. Automatiserade steg är ofta mer informativa än antal automatiserade ärenden. Felaktiga blockeringar och återställningar bör alltid följas där åtgärder påverkar användare eller system. Följ dessutom varje KPI per incidenttyp eller use case.
Viktigt att tänka på
Det går inte att ange rimliga KPI-nivåer, säker automationsgrad eller positiv avkastning utan information om organisationens SOC-mognad, incidentvolym, bemanning och tekniska miljö. Exakta licenspriser, implementationstider och integrationskostnader behöver verifieras med aktuella leverantörer eller konsulter. Bedöm alltid vilka åtgärder som kräver mänskligt godkännande i er egen verksamhet.
Vanliga frågor
Q1. Vilka KPI:er är viktigast när ett SOC börjar med SOAR?
A1. Börja med MTTD, MTTR, tid till korrekt eskalering, automatiserade steg, analystid samt mått för falska positiva och felaktiga åtgärder. Välj få KPI:er för ett avgränsat use case och dokumentera en baslinje före förändringen.
Q2. Hur beräknar man om en SOAR-plattform är värd kostnaden?
A2. Jämför den totala kostnaden för licens, implementation, integrationer, utbildning, drift och löpande optimering med era egna baslinjer för analystid, incidenthantering och kvalitetsutfall. Det går inte att avgöra avkastning generellt utan organisationens egna data och risknivå.
Q3. Är det säkert att automatisera blockering av konton, IP-adresser och e-postmeddelanden?
A3. Det beror på datakvalitet, integrationslogik, risknivå och tydliga eskaleringsregler i den aktuella miljön. Följ felaktiga blockeringar och manuella återställningar, och använd mänskligt godkännande där automatiserade åtgärder kan få betydande konsekvenser.
