Hændelsessvarmønstre
Læs mere om Well-Architected Trust → Security Incident Response
Sikkerhedshændelser forekommer på trods af forebyggende foranstaltninger. Trust arkitektur kræver design for detekterbarhed, hurtig reaktion, retsmedicinsk undersøgelse og genopretning. Denne side konsoliderer hændelsessvarmønstre fra Trust afsnit Hændelsessvar, der dækker registreringsarkitektur, svarprocedurer, retsmedicinske funktioner og læring efter hændelse.
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Begivenhedsovervågning | ✅ Aktiver Begivenhedsovervågning, der registrerer loginmønstre, massedataeksport, tilladelsesændringer og API-aktivitet med distribution til SIEM-platforme for bevarelse, der overskrider de oprindelige bevarelsesgrænser |
| Politikker for transaktionssikkerhed | ✅ Konfigurer politikker, der evaluerer begivenheder i realtid for at blokere mistænkelige handlinger, kræve trinvis godkendelse eller udløse adviseringer baseret på adfærdsmæssige basislinjer |
| Revisionsspor for opsætning | ✅ Overvåg administrative konfigurationsændringer, der aktiverer registrering af uautoriserede ændringer med 180-dages bevarelse |
| Tilpasset applikationslogføring | ✅ Implementer sikkerhedsrelevant begivenhedslogføring i Apex, der registrerer godkendelsesfejl, autorisationsnægtelser og mistænkelige inputmønstre |
| Overvågning af tilstandscheck | ✅ Konfigurer automatisk registrering af konfigurationsforskydning fra sikkerhedsbasislinjer, der kan angive uautoriserede ændringer |
| SIEM-integration | ✅ Distribuer begivenhedsovervågningslogfiler til virksomheds-SIEM-platforme til korrelation med virksomhedssikkerhedstelemetri og adfærdsmæssige analyser |
| Advarselsregler | ✅ Design advarselsregler, der registrerer mistænkelige mønstre (masseadgang uden for arbejdstiden, login fra nye geografiske områder, hurtig tilladelseseskalering) med adfærdsmæssige basislinjer for at minimere falske positive |
| Adfærdsmæssige analyser | ✅ Etabler adfærdsmæssige basislinjer, der aktiverer afvigelsesregistrering for usædvanlige datadgangsmængder, off-time administrativ aktivitet og API-forbrugsmønstre |
| Flerkanaleregistrering | ✅ Implementer registrering gennem begivenhedsovervågning, transaktionssikkerhed, revisionsspor for opsætning, tilpasset logføring og tilstandscheck, der leverer flere uafhængige registreringssignaler |
| Uændret loglagring | Distribuer logfiler til uforanderligt eksternt lager, som angribere ikke kan redigere, selv med administrativ Salesforce-adgang, hvilket sikrer forensisk bevisintegritet |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Kun oprindelig logbevarelse | ⚡️ Afhængig udelukkende af oprindelige Salesforce-revisionssporbevarelsesvinduer (begivenhedsovervågning - oprindelige grænser, 180 dages revisionsspor for opsætning) uden ekstern arkivering, opdagelse af logfiler, der er udløbet, når undersøgelse kræver historisk analyse |
| Ingen adfærdsmæssige basislinjer | ⚡️ Ingen adfærdsmæssige basislinjer for afvigelsesregistrering, der genererer for mange falske positive advarsler, der træner sikkerhedsteams til at ignorere adviseringer |
| Ingen SIEM-integration | ⚡️ Manglende SIEM-integration for virksomheden, manglende korrelationsmuligheder med sikkerhedstelemetri fra andre systemer, der ville afsløre bredere kompromismønstre |
| Manuel loggennemgang | ⚡️ Afhængig af periodisk manuel logggennemgang i stedet for automatiseret advarsel, kan du finde hændelser uger eller måneder efter forekomsten, når skaden er omfattende |
| Ingen transaktionssikkerhedspolitikker | ⚡️ Ingen transaktionssikkerhedspolitikker i realtid, manglende mulighed for at blokere mistænkelige handlinger, der forhindrer skade, før den forekommer |
| Ufuldstændig dækning | ⚡️ Kun overvågning af undersæt af sikkerhedsrelevante begivenheder (login, men ikke dataadgang, konfigurationsændringer, men ikke tilladelsesændringer) oprettelse af blinde pletter |
| Advar træthed | ⚡️ Generering af for mange falske positive advarsler uden at justere, træning af teams til at ignorere adviseringer, herunder lovlige sikkerhedsbegivenheder |
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Isolationsgrænser | ✅ Designarkitektur, så kompromitterede komponenter kan isoleres gennem tilbagekaldelse af tilladelsessæt, IP-begrænsningsændringer eller sessionsafslutning uden at afbryde vigtige forretningsfunktioner |
| Sessionsstyring | ✅ Implementer funktioner til hurtig sessionsafslutning for kompromitterede konti, herunder håndhæv logout og sessionsgodkendelse på tværs af alle aktive sessioner |
| Tilbagekaldelse af tilladelse | ✅ Tildel rettigheder gennem tilladelsessæt i stedet for basislinjeprofiler, så tilbagekaldelse sker hurtigt: fjernelse af tilladelsessættildelingen tilbagekalder adgang, når ingen profil eller anden tildeling uafhængigt tildeler den samme tilladelse |
| IP-begrænsninger | ✅ Konfigurer IP-loginområder på profilniveau for berettigede konti, så logins fra andre adresser afvises direkte, hvilket aktiverer hurtig isolering på netværksniveau til kendte administrative placeringer |
| Frysning af brugerkonto | ✅ Implementer kontofrysningsprocedurer, der forhindrer godkendelse, mens du bevarer data til undersøgelse uden at slette den kompromitterede konto |
| API-adgangskontroller | ✅ Design API-godkendelse med tokentilbagekaldelsesfunktioner, der aktiverer hurtig isolering af kompromitterede integrationskonti |
| Multi-Org-isolering | ✅ For aktiver af høj værdi skal du evaluere multi-organisationsarkitektur, der giver størst isolering for kritiske komponenter på bekostning af øget driftskompleksitet |
| Emergency Break-Glass-procedurer | ✅ Vedligehold dokumenterede gennemgangsprocedurer for administrativ adgang i nødstilfælde med efterbrugsovervågning og validering |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Ingen isolationsgrænser | ⚡️ Manglende arkitektoniske isolationsgrænser, der kræver fuldstændig systemnedlukning for at indeholde ethvert kompromis, hvilket forstyrrer alle forretningsfunktioner |
| For tilladende adgang | Tildeling af brede tilladelserne Rediger alle data, der forhindrer tilbagekaldelse af detaljeret rettighed uden at afbryde flere forretningsprocesser |
| Delte servicekonti | ⚡️ Brug af enkelt delt “API-bruger” eller “integrationsbruger”-konto på tværs af flere systemer forhindrer isolering af specifik kompromitteret integration uden at afbryde alle integrationer |
| Ingen IP-begrænsninger | ⚡️ Ingen IP-tilladelsesliste for rettighedskonti, mangler begrænsningsfunktioner på netværksniveau, når konti kompromitteres |
| Ingen sessionsstyring | ⚡️ Manglende sessionsafslutningsfunktioner, der kræver nulstilling af adgangskode som den eneste måde at gennemtvinge logout på, hvilket introducerer forsinkelser under vigtige svarvinduer |
| Ingen nødprocedurer | ⚡️ Ikke have nogen dokumenterede brudglas- eller nødadgangsprocedurer, improvisere vigtige beslutninger under pres under aktive hændelser |
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Begivenhedsovervågningslogfiler | ✅ Registrer detaljerede aktivitetslogfiler, herunder brugerhandlinger, API-kald, godkendelsesbegivenheder og dataadgangsmønstre med tilstrækkelige detaljer til retsmedicinsk analyse |
| Feltrevisionsspor | ✅ Aktiver feltrevisionsspor, der bevarer dataændringshistorik for begrænsede og fortrolige felter med bevarelse, der matcher bestemmelseskrav (understøtter ubestemt bevarelse, bekræft den krævede periode i forhold til den gældende bestemmelse) |
| Uændret lager | Distribuer logfiler til eksternt, uforanderligt lager, som angribere ikke kan redigere, hvilket sikrer forensisk bevisintegritet gennem undersøgelsen |
| Revisionsspor for opsætning | ✅ Bevar ændringshistorik for administrativ konfiguration, der aktiverer undersøgelse af uautoriserede systemændringer med 180-dages bevarelse |
| Anvendelsesområdevurdering | ✅ Design tilladelsesmodeller og dataadgangskontroller, der aktiverer hurtig vurdering af dataeksponeringsomfang baseret på kompromitterede kontorettigheder |
| Skift korrelation | ✅ Vedligehold korrelation mellem ændringer af konfigurationen af revisionsspor for opsætning og aktivitetsmønstre for begivenhedsovervågning, der aktiverer undersøgelse af angriberteknikker |
| Dataadgangslogføring | ✅ Registrer al adgang til begrænsede og fortrolige data, der aktiverer undersøgelse af, hvilke data der blev vist under kompromisperioden |
| Integrationsrevisionsspor | ✅ Registrer API-godkendelse, autorisation og dataudvekslingsmønstre for integrerede systemer, der aktiverer undersøgelse af krydssystemkompromiser |
| Bevarelse af beviser | ✅ Distribuer logfiler og revisionsspor kontinuerligt til uforanderligt eksternt lager, så retsmedicinsk beviser bevares og er tilgængelig, når en hændelse undersøges |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Variabel loglagring | ⚡️ Lagring af logfiler kun i Salesforce, hvor angribere med administrativ adgang kan slette eller redigere forensisk bevis |
| Utilstrækkelige logdetaljer | Registrering af begivenheder på højt niveau uden tilstrækkelige detaljer til undersøgelse (login registreret, men ikke IP-adresse, dataadgang registreret, men ikke specifikke registreringer) |
| Ingen dataadgangslogføring | ⚡️ Manglende detaljeret logføring af adgang til begrænsede og fortrolige data, der ikke kan vurdere dataeksponeringsomfang under brudadvisering |
| Manglende feltrevisionsspor | ⚡️ Ikke aktivere feltrevisionsspor for følsomme felter, kan ikke bestemme, hvilke dataværdier der blev vist under kompromis |
| Ingen ændringsforbindelse | ⚡️ Ingen korrelationsfunktionalitet mellem ændringer af konfigurationen af revisionsspor for opsætning og efterfølgende aktivitetsmønstre for Begivenhedsovervågning |
| Slettet revisionshistorik | ⚡️ Tilladelse til, at revisionshistorikken udløber, før den regulerende bevarelsesminimum angiver de regulerende bestemmelser for din implementering, hvilket skaber overtrædelser af overensstemmelse |
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Mål for gendannelsestid | ✅ Definer og test Recovery Time Objective (RTO) og Recovery Point Objective (RPO) for sikkerhedshændelsesscenarier, ikke kun katastroferescenarier |
| Testede gendannelsesprocedurer | ✅ Dokumentgendannelsesprocesser for kompromitterede konti, massedataudløb, uautoriserede implementeringer, rettighedseskalering og pakkekompromitter med kvartalsvis test |
| Sikkerhedsvalidering | ✅ Valider sikkerhedskopieringsintegritet regelmæssigt, så du sikrer, at gendannelsesfunktioner fungerer under sikkerhedshændelser, ikke kun ved driftsmæssige fejl |
| Tilbagerulningsfunktioner | ✅ Design implementeringspipelines med testede tilbagerulningsprocedurer for uautoriserede kodeimplementeringer eller ondsindede konfigurationsændringer |
| Rotation af legitimationsoplysninger | ✅ Implementer hurtige roteringsprocedurer for legitimationsoplysninger for kompromitterede integrationskonti, API-brugere og navngivne legitimationsoplysninger |
| Tilladelsesgenoprettelse | ✅ Dokumentprocedurer til gendannelse af relevant adgang efter overdrevent brede isoleringshandlinger under hændelsessvar |
| Datagendannelse | ✅ Design datagendannelsesfunktioner, der håndterer datakorruption eller sletning, der er et resultat af sikkerhedshændelser, adskilt fra katastrofegendannelse |
| Servicekontinuitet | ✅ Architect løsninger, så sikkerhedshændelsessvarprocedurer vedligeholder kontinuitet af vigtig forretningsfunktion under undersøgelse og rettelse |
| Validering af gendannelse | ✅ Test gendannelsesprocedurer kvartalsvis, der validerer, at gendannede systemer fungerer korrekt, og at kompromiset ikke har været vedvarende gennem gendannelse |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Ikke-testede procedurer | ⚡️ Har dokumenteret gendannelsesprocedurer, der aldrig er testet gennem øvelser, og opdager under faktiske hændelser, at procedurer er ufuldstændige eller ukorrekte |
| Ingen RTO/RPO for sikkerhed | ⚡️ Definering af målsætninger for gendannelsestid kun for katastrofegendannelse uden at tage sikkerhedshændelsesscenarier med i betragtning, der kræver forskellige gendannelsesprocedurer |
| Ingen tilbagerulningsfunktion | ⚡️ Manglende implementeringsrulningsprocedurer for uautoriserede kodeimplementeringer, der kræver fuld omudvikling for at fjerne ondsindede ændringer |
| Ikke-validerede sikkerhedskopier | ⚡️ Test aldrig sikkerhedskopigendannelse, og find ud af under hændelser, at sikkerhedskopier er ødelagte eller ufuldstændige |
| Ingen roteringsprocedurer for legitimationsoplysninger | ⚡️ Ingen hurtige roteringsprocedurer for legitimationsoplysninger for kompromitterede integrationskonti, hvilket efterlader kompromitterede legitimationsoplysninger aktive under undersøgelse |
| Manuel gendannelsesprocesser | ⚡️ Afhænger udelukkende af manuelle gendannelsesprocedurer under hændelser, introducerer fejl og forsinkelser, når hastighed er vigtig |
| Ingen gendannelsest | Valider aldrig, at gendannede systemer fungerer korrekt efter gendannelse, potentielt genindfører kompromis eller datakorruption |
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Kompromitteret svar på brugerkonto | ✅ Dokumentprocedurer: fryse bruger, håndhæve nulstilling af legitimationsoplysninger, gennemse revisionsspor for opsætning og dataadgangslogfiler for kompromisperiode, vurdere dataeksponeringsomfang, udføre brudadvisering, hvis begrænsede data er tilgået |
| Massedataudfiltreringssvar | ✅ Dokumentprocedurer: tilbagekalde session med det samme, begrænse tilladelser, identificere påvirkede registreringer og klassificeringsniveauer, udføre regulerende overtrædelsesadviseringer inden for tidslinjen for de regulerende bestemmelsessæt for din implementering |
| Uautoriseret kodeimplementeringssvar | ✅ Dokumentprocedurer: tilbagerulningsimplementering med det samme, overvåg alle ændringer fra kompromitterede legitimationsoplysninger, gennemse pipeline-sikkerhed for autorisationsomgåelse, scan implementeret kode for vedvarende bagdøre |
| Rettighedseskaleringssvar | ✅ Dokumentprocedurer: tilbagekalde eskalerede rettigheder med det samme, revidere aktiviteter, der er udført med forhøjet adgang, undersøge, hvordan eskalering tilsidesatte godkendelseskontroller, implementere kompenserende kontroller |
| Kompromisssvar for AppExchange | ✅ Dokumentprocedurer: isolere pakketilladelser, vurdere data, der er tilgået af pakke, evaluere indstillinger for pakkeerstatning, dokumentlærred for pakkevalueringskriterier |
| Registreringssignaler | ✅ Konfigurer overvågning, der registrerer hvert scenarie: loginafvigelser for kompromitterede konti, rapporteksportmængde for udfiltrering, implementeringsovervågning for uautoriseret kode, overvågning af tilladelsesændring for eskalering |
| Tastaturøvelser | ✅ Udfør tabulatorøvelser til at teste svarprocedurer for platformsspecifikke scenarier, der validerer teamparathed og procedurefuldstændighed |
| Svarautomatisering | ✅ Politikker for transaktionssikkerhed i realtid blokerer automatisk mistænkelige handlinger, kræver trinvis godkendelse eller adviserer respondenter om registreringssignaler med høj konfidens, hvilket giver automatisk begrænsning, der reducerer svartiden |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Kun generiske svarplaner | ⚡️ Kun generiske hændelsessvarprocedurer uden Salesforce-specifik vejledning, improvisere platformsspecifikke handlinger under aktive hændelser |
| Ingen registreringskonfiguration | ⚡️ Ikke at have nogen overvågning konfigureret til at registrere platformsspecifikke scenarier (masseeksport, rettighedseskalering, uautoriseret implementering), opdage hændelser gennem brugerrapporter eller revisioner |
| Ingen bordtræning | ⚡️ Aldrig udføre bordøvelser, der validerer teamets fortrolighed med platformsspecifikke svarprocedurer, opdager Knowledge huller under faktiske hændelser |
| Ingen automatisering | ⚡️ Fuldstændigt manuelt svar for alle hændelser uden nogen transaktionssikkerhedspolitikker i realtid for automatiseret begrænsning, der introducerer forsinkelser, når øjeblikkelig blokering kan reducere skader |
| Manglende svar-afspilningsfelter | Manglende dokumenterede svarpluklister for almindelige scenarier (kompromitteret brugerkonto, dataudløb, ikke-autoriseret kodeimplementering) |
| Ingen adviseringsprocedurer for overtrædelse | ⚡️ Ingen procedurer for krav til regulerende overtrædelsesadviseringer, der har problemer med at forstå forpligtelser under faktiske hændelser, når tidslinjerne er stramme |
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Ikke-på-bånd-kommunikation | ✅ Etabler kommunikationskanaler, der ikke er afhængige af potentielt kompromitterede systemer (telefontræer, eksterne meddelelsesplatforme) til koordinering af svar |
| Eskaleringsprocedurer | ✅ Dokumenteskaleringsstier fra indledende registrering gennem ledelsesadvisering med kontaktoplysninger og eskaleringskriterier |
| Adviseringsskabeloner | ✅ Vedligehold forhåndkladde adviseringsskabeloner for almindelige hændelsestyper, der aktiverer hurtig kommunikation til interessenter, kunder og regulatorer |
| Interessentidentifikation | ✅ Identificer interessenter, der kræver advisering for forskellige hændelsestyper, herunder ledere, juridiske, compliance, påvirkede brugere og regulerende myndigheder |
| Tidslinjer for regulerende adviseringer | ✅ Dokumenter hver jurisdiktions krav til regulerende adviseringer, bekræftet i forhold til den regulerende bestemmelse for din implementering med procedurer, der sikrer rettidig overholdelse |
| Intern koordination | ✅ Design hændelseskoordinationsprocedurer, der angiver roller og ansvarsområder (hændelseschef, teknisk emne, kommunikationsemne, juridisk kontakt) |
| Ekstern koordination | ✅ Etabler procedurer for at koordinere med Salesforce Support, eksterne forensiske efterforskere, juridiske rådgivere og håndhævelse efter behov |
| Statuskommunikation | ✅ Implementer regelmæssig statuskommunikationskadence under aktive hændelser for at holde interessenter informeret uden overvældende undersøgelsesteam |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Ingen uden for-bånd-kommunikation | ⚡️ Afhængigt helt af potentielt kompromitteret mail eller interne meddelelser for hændelseskoordination, mister kommunikationsfunktionalitet, når primære kanaler kompromitteres |
| Uklare eskaleringsstier | ⚡️ Ikke at have nogen dokumenterede eskaleringsprocedurer, hvilket forårsager forsinkelser og forvirring om, hvem der skal adviseres, og hvornår |
| Ingen adviseringsskabeloner | ⚡️ Improvisering af hændelsesadviseringer under aktive hændelser under tidstryk, hvilket resulterer i ufuldstændig eller ukorrekt kommunikation |
| Manglende interessentlister | ⚡️ Ikke have nogen forhåndsidentificerede interessentlister, opdage under hændelser, at vigtige parter (juridiske, compliance, ledere) ikke blev adviseret |
| Ingen regulerende tidslinjebevidsthed | ⚡️ Uvidende om de regulerende adviseringstidslinjer, der gælder for din implementering under hændelsessvar, manglende deadlines og oprettelse af yderligere overtrædelser af overensstemmelse |
| Tvetydige roller | ⚡️ Har uklare hændelsessvarroller og ansvarsområder, der forårsager forvirring om, hvem der har autoritet til at træffe begrænsningsbeslutninger |
| Ingen eksterne koordineringsprocedurer | ⚡️ Har ingen etablerede relationer eller procedurer til at engagere Salesforce Support, forensiske efterforskere eller håndhævelse, når der er behov for det |
Mønstre
| Hvor skal du se | Hvordan godt ser ud |
|---|---|
| Skamløs kultur | ✅ Fokuser på efterhændelsesgennemgange på systemforbedringer i stedet for individuel skyld, så du aktiverer organisatorisk læring uden frygt for konsekvenser |
| Hændelsestidslinjedokumentation | ✅ Dokumenter fuldfører hændelsens tidslinje inklusive indledende kompromis, registrering, svarhandlinger og løsning med præcise tidsstempler |
| Kontroller fejlanalyse | ✅ Identificer, hvilke forebyggende og detektive kontroller der ikke kunne forhindre eller registrere hændelsen, og informer arkitektoniske forbedringer |
| Dokumentation om arkitektoniske svagheder | ✅ Dokumentarkitektoniske svagheder, der er afsløret af hændelsen i ADR’er (Architecture Decision Records), der registrerer sikkerhedsændringer |
| Korrigeringsprioritering | ✅ Prioriter afhjælpning baseret på risikoreduktionspotentiale, håndtere grundlæggende årsager snarere end symptomer |
| Lærredeling | ✅ Del de lærte erfaringer på tværs af teams og forretningsenheder, der forhindrer lignende hændelser i andre dele af organisationen |
| Opdateringer til registreringsregler | ✅ Opdater registreringsregler og adfærdsmæssige basislinjer baseret på angrebsteknikker, der er observeret under undersøgelse |
| Justering af svarprocedure | ✅ Opdater hændelsessvarprocedurer baseret på, hvad der fungerede, og hvad der ikke fungerede under det faktiske hændelsessvar |
| Metriksporing | ✅ Spor MTTD (medium time to detect), MTTR (medium time to respond) og omfanget af påvirkning over tid, der identificerer tendenser, der kræver arkitektonisk investering |
| Gennemse kadence | ✅ Udfør en rettidig efterhændelsesgennemgang, mens detaljerne forbliver opdaterede, og der er skub i forbedring |
Anti-mønstre
| Hvor skal du se | Hvad ser dårligt ud |
|---|---|
| Ignorerede anmeldelser | ⚡️ Ignorering af efterhændelsesgennemgange, flytte direkte til den næste hændelse uden at registrere lærdomme eller arkitektoniske forbedringer |
| Skyldkultur | ⚡️ Fokusering efter hændelsesgennemgange på individuel skyld i stedet for systemforbedringer, der forårsager hændelsesskjulning og forhindrer organisatorisk læring |
| Ingen arkitektonisk dokumentation | ⚡️ Ikke at dokumentere ændringer af sikkerhedsarkitektur drevet af hændelseslæring i ADR’er (Architecture Decision Records) |
| Symptombehandling | ⚡️ Håndterer kun hændelsessymptomer (kompromitteret adgangskode) uden at rette grundlæggende årsager (manglende MFA), hvilket tillader, at lignende angreb lykkes |
| Ingen læringsdeling | ⚡️ Bevarelse af hændelseslæring i svarteamet i stedet for at dele på tværs af organisationen og tillade lignende hændelser i andre forretningsenheder |
| Ingen registreringsopdateringer | ⚡️ Ikke at opdatere registreringsregler eller adfærdsmæssige basislinjer baseret på observerede angrebsteknikker, forbliver sårbare over for lignende angreb |
| Ingen metriksporing | ⚡️ Ikke sporing af MTTD (median time to detect), MTTR (median time to respond) eller omfangstendenser, manglende salgsmuligheder til at identificere systemiske svagheder |
| Forsinkede gennemgange | ⚡️ Udførelse af efterhændelsesgennemgange måneder efter hændelsesløsning, når detaljer glemmes, og forbedringstendens går tabt |
| Ingen rettelsesgennemgang | ⚡️ Identificering af forbedringer under efterhændelsesgennemgang, men mislykkes i at implementere dem, så lignende hændelser kan gentages |