När en incident slår till kollapsar de flesta ”incident response plans” till en rörig mix av Slack-pingar, halvt ihågkomna steg och motstridiga åsikter om vem som bestämmer. Dokumentationen finns, men den är policy-tung och operativt tunn. Och mitt i allt det här bruset måste teamet fortfarande triagera, begränsa, briefa ledningen och klara rapporteringsdeadlines.
Den här incident response plan är byggd för säkerhetsledare som behöver ett NIST 800-61-anpassat program som faktiskt går att köra, IT-/driftchefer som måste samordna begränsning utan att slå ut produktion, och konsulter som etablerar incidenthanteringsförmåga för kunder under verklig tidspress. Resultatet är ett flerfasigt (6–11 faser) incidenthanteringsprogram med roller, triggers, checklistor, RACI-liknande ansvarskartläggning, operativa playbooks, kommunikationsvägar och underhållscadens.
Vad gör den här AI-prompten och när ska du använda den?
| Vad den här prompten gör | När du ska använda den här prompten | Vad du får |
|---|---|---|
|
|
|
Hela AI-prompten: NIST 800-61-byggare för incidenthanteringsprogram
Fyll i fälten nedan för att anpassa prompten efter dina behov.
| Variabel | Vad du ska ange | Anpassa prompten |
|---|---|---|
[KONTEXT] |
Ge en utförlig översikt av organisationen, inklusive uppdrag, struktur, kärnverksamhet samt relevanta affärsmål eller utmaningar. Till exempel: "En medelstor vårdorganisation med fokus på hantering av patientdata, verksam i tre delstater med 15 anläggningar och 2 000 anställda."
|
|
[BRANSCH] |
Ange vilken bransch organisationen verkar inom, eftersom det påverkar regelkrav och hotbild. Till exempel: "Finansiella tjänster, med inriktning på investment banking och förmögenhetsförvaltning."
|
|
[MALGRUPP] |
Beskriv de viktigaste intressenterna som kommer att använda eller införa incidenthanteringsprogrammet, inklusive deras roller och prioriteringar. Till exempel: "CIO, CISO, IT-säkerhetsteam och regelefterlevnadsansvariga som ansvarar för hantering av intrång samt regulatorisk rapportering."
|
|
[DATATYPER] |
Lista vilka typer av känslig eller verksamhetskritisk data organisationen hanterar, eftersom detta styr responsstrategin. Till exempel: "Personuppgifter (PII), finansiella register samt egenutvecklad forskningsdata."
|
|
[ORGANISATIONSSTORLEK] |
Ange organisationens storlek, exempelvis antal anställda, antal platser/kontor eller årsomsättning. Till exempel: "500 anställda, 3 kontorsplatser och 50 MUSD i årsomsättning."
|
|
[SAKERHETSMOGNADSNIVA] |
Beskriv organisationens nuvarande cybersäkerhetsmognad, till exempel om det finns formella styrdokument, verktyg och utbildad personal på plats. Till exempel: "Medelnivå med grundläggande endpoint-skydd, begränsad utbildning i incidenthantering och ad hoc-styrdokument."
|
|
[INCIDENTHISTORIK] |
Sammanfatta tidigare säkerhetsincidenter, inklusive påverkan och hur de hanterades. Till exempel: "Drabbades av en ransomware-attack 2021 som ledde till 24 timmars driftstopp och 100 000 USD i återställningskostnader."
|
|
[NUVARANDE_IR_RUTINER] |
Ge detaljer om organisationens befintliga processer för incidenthantering, inklusive dokumenterade planer eller informella arbetssätt. Till exempel: "Ad hoc-hantering ledd av IT-teamet, inga formella playbooks eller fördefinierade eskaleringsvägar."
|
|
[EFTERLEVNADSKRAV] |
Lista relevanta regelverk eller branschstandarder som organisationen måste följa för cybersäkerhet och dataskydd. Till exempel: "Krav kopplade till HIPAA, GDPR och PCI DSS."
|
|
[VERKTYG_OCH_TEKNIKSTACK] |
Ge en översikt över organisationens nuvarande IT- och säkerhetsverktyg, plattformar och tekniker. Till exempel: "Microsoft Azure, Splunk för SIEM, CrowdStrike för endpoint-skydd och Cisco-brandväggar."
|
|
[KRITISKA_TILLGANGAR] |
Identifiera de system, data eller den infrastruktur som är kritisk för organisationens verksamhet och säkerhetsläge. Till exempel: "System för hantering av patientdata, faktureringsservrar och egna forskningsdatabaser."
|
|
[TILLGANGLIGA_RESURSER] |
Ange vilken personal, budget och vilka verktyg som finns tillgängliga för att införa och förvalta incidenthanteringsprogrammet. Till exempel: "Dedikerat IT-säkerhetsteam på 3 personer, årlig cybersäkerhetsbudget på 150 000 USD samt befintliga licenser för endpoint-skydd."
|
|
[RISKTOLERANS] |
Beskriv organisationens riskaptit, inklusive hur den balanserar säkerhetsinvesteringar mot verksamhetens behov. Till exempel: "Låg risktolerans på grund av regulatorisk exponering och immateriella tillgångar med högt värde."
|
|
[TIDSRAM] |
Ange önskad tidsplan för att införa incidenthanteringsprogrammet eller genomföra specifika faser. Till exempel: "3 månader för att färdigställa programutveckling och inledande testning."
|
|
[TON] |
Definiera önskad kommunikationsstil för leveranser, till exempel formell, teknisk eller mer samtalstonad. Till exempel: "Pragmatisk och rak, med fokus på tydlighet och konkreta åtgärder."
|
|
[FORMAT] |
Ange önskat format för leveranser, till exempel dokument, presentation eller playbook. Till exempel: "Operatörsanpassad playbook med tydliga checklistor och diagram."
|
Proffstips för bättre resultat med AI-prompten
- Mata in verkliga begränsningar, inte ambitioner. Om teamet är två personer och en MSP, säg det rakt ut så att planen inte antar en SOC dygnet runt. Lägg till detaljer som ”vi förlitar oss på M365 Defender och en liten beredskapsrotation” så att verktyg och ansvar blir realistiska.
- Definiera ”kronjuveler” i affärsspråk först. Namnge datamängderna och de affärsprocesser de möjliggör (betalningar, orderhantering, patientbokning), och mappa system i andra hand. Följdfråga: ”Lista de 5 viktigaste kronjuveltillgångarna och rangordna dem efter påverkan om de är otillgängliga i 24 timmar.”
- Be om beslutspunkter i varje fas. Många planer faller för att de hoppar över ”om/så”-ögonblicken. Efter första körningen, be: ”För varje fas, lägg till 3 go/no-go-beslut (till exempel: isolera host vs hålla online för forensik) och vem som godkänner dem.”
- Tvinga fram testbarhet med ett övningsscenario. När du har faserna, tryck in dem i en tabletop-övning för att se om stegen håller i en riktig diskussion. Testa: ”Skapa en 90-minuters tabletop-övning för ett misstänkt credential-stuffing-intrång med injects var 10:e minut och förväntade artefakter.”
- Gör kommunikationen konkret och återanvändbar. Be om meddelandemallar som matchar era faktiska målgrupper: ledning, juridik, drabbade kunder och intern personal. Om du också behöver hjälp att snabbt anpassa tonläget, kör ditt utkast genom https://nodenordic.se/prompts/skriv-om-budskap-for-valfri-malgrupp-med-ai-prompt så att samma fakta landar rätt hos varje grupp.
Vanliga frågor
CISO:er och säkerhetschefer använder den för att översätta NIST 800-61 till ett program som håller för granskning från ledning, revisorer och försäkringsbolag, med tydliga faser och ägarskap. incident response managers och SOC-leads förlitar sig på den för kriterier för inträde/utträde per fas, beslutspunkter och vilka specifika artefakter som ska fångas under triage och begränsning. IT-/driftchefer tjänar på att den tydliggör överlämningar, backupansvar och vilka förändringar som är tillåtna under begränsning utan att slå ut produktion. GRC- och compliance-ansvariga använder compliance-beröringspunkterna och rapporteringsdeadlines för att matcha responsåtgärder med regulatoriska förväntningar och bevisbehov.
SaaS-bolag använder den för att synka molnloggning, incidentallvar och kundkommunikation så att incidenter inte blir churn-händelser. Den hjälper att definiera vad som ska samlas in (auth-loggar, audit trails, API-händelser) och vem som beslutar begränsningsåtgärder som token-revokering. E-handel och retail tillämpar den på signaler för card-not-present-bedrägerier, credential stuffing och risk i tredjepartsplugin, där snabb begränsning är avgörande och budskap inte kan improviseras. Hälso- och sjukvård samt life science får värde av betoningen på reglerad rapportering, bevis-/spårhantering och återställningssteg som skyddar patienttjänster medan utredningen pågår. Professionella tjänsteföretag använder den för att bygga en repeterbar playbook över många kundmiljöer, inklusive tydliga scope-gränser och antaganden när informationen är ofullständig.
En typisk prompt som ”Write me an incident response plan for a data breach” misslyckas eftersom den: saknar organisatorisk kontext (teamstorlek, verktyg, regulatorisk exponering, riskaptit) så att ”planen” inte går att genomföra; inte ger någon fasarkitektur med inträdes-/utträdeskriterier, så responders inte vet när de ska gå från triage till begränsning till återställning; ignorerar nödvändiga artefakter och loggkällor, vilket leder till svag bevisning och missade detektionsvägar; producerar generiska roller utan backup-täckning eller överlämningar, vilket kollapsar under en verklig beredskapshändelse; och missar scope-gränser, så det blir ett uppblåst policydokument i stället för operativa checklistor och runbooks.
Ja. Prompten är designad för att anpassa antal faser (6–11) och den operativa detaljnivån utifrån din organisations storlek, komplexitet, mognad, regulatoriska landskap, tillgängliga resurser och affärens riskaptit. För att anpassa den, ange konkreta detaljer som er nuvarande loggstack, vem som har beredskap, vilka system som innehåller känsliga data och vilka regelverk som gäller (eller säg att du är osäker). Om du inte har alla detaljer, låt den ställa riktade frågor och svara på dem i en andra vända. Följdfråga: ”Revidera planen utifrån att vi inte har en SOC 24/7, vi använder Microsoft 365 + Entra ID, och vi måste kunna briefa ledningen inom 60 minuter från detektion.”
Det största misstaget är att inte ge någon organisatorisk verklighet, vilket tvingar AI:n att hitta på förmågor; i stället för ”medelstort företag”, säg ”350 anställda, en säkerhetsingenjör, outsourcad SOC, AWS + Okta, och vi hanterar kunddata i EU.” Ett annat vanligt fel är att lämna kronjuvelerna odefinierade; ”kunddata” är otydligt, medan ”faktureringsdatabas med fakturor + korttokens, plus bilagor i supportärenden” leder till bättre triage- och begränsningssteg. Team glömmer också att ange riskaptit och tolerans för nedtid, vilket gör att begränsningsplanen blir orealistisk; ”vi kan ta ner kundportalen i 2 timmar” går att agera på, ”vi kan inte ha nedtid” gör det oftast inte. Till sist hoppar många över compliance- och rapporteringskrav, vilket skapar kaos i slutet; lägg in det du vet och låt prompten markera okända delar som antaganden.
Den här prompten är inte optimal för team som bara vill ha en ensidig mall och inte tänker iterera, eftersom den är byggd för att ta fram ett operativt program med faser, artefakter och övningar. Den är inte heller en ersättning för juridisk rådgivning eller råd om incident-/intrångsanmälan, särskilt när tolkning av regelverk ingår. Och om du inte ens har identifierat era kärnsystem, systemägare eller grundläggande loggning kan du få en plan som mest består av antaganden. I så fall: börja med att inventera system och åtkomstvägar, och kom sedan tillbaka för att generera hela programmet.
En respons på ett intrång ska kännas repeterad, inte uppfunnen i realtid. Klistra in den här prompten i ditt AI-verktyg, svara ärligt på förtydligandefrågorna och gå därifrån med en incident response plan som du kan köra och förbättra.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.