GDPR:s 72-timmars handlingsplan för personuppgiftsincidenter för informationssäkerhetschefer
Klockan är 02:13 en tisdagsmorgon när larmet utlöses.
Maria, informationssäkerhetschef för en snabbväxande fintech-SaaS-plattform, väcks av en eskalering från SOC: avvikande databasfrågor kommer från ett utvecklarkonto. Kontot har berört tabeller med kundnamn, e-postadresser, transaktionshistorik och nationella identitetsnummer. Inom några minuter bekräftar teamet att utvecklarens autentiseringsuppgifter har stulits genom en nätfiskeattack. Exponeringsfönstret är oklart. Angriparens avsikt är okänd. Incidentens omfattning håller fortfarande på att fastställas.
Fristen börjar nu.
Enligt GDPR kan Maria ha 72 timmar på sig att anmäla incidenten till en tillsynsmyndighet om incidenten sannolikt medför en risk för enskilda personer. Enligt NIS2, om företaget är en väsentlig eller viktig entitet och incidenten är betydande, kan en tidig varning krävas inom 24 timmar och en formell anmälan inom 72 timmar. Enligt DORA kan även rapportering av IKT-incidenter i finanssektorn och skyldigheter kopplade till operativ resiliens aktualiseras. Kunder, försäkringsgivare, juridiska rådgivare, ledande befattningshavare och revisorer kommer alla att kräva svar.
Det är här en generisk incidenthanteringsplan ofta brister. En åtgärdsplan för skadlig kod kan beskriva isolering av värdar. En SOC-rutin kan beskriva bevarande av loggar. Men en process för hantering av personuppgiftsincidenter enligt ISO/IEC 27701:2025 måste kunna besvara svårare frågor under tidspress:
- Har personuppgifter exponerats, ändrats, förlorats, förstörts eller åtkommits utan behörighet?
- Agerar organisationen som personuppgiftsansvarig, personuppgiftsbiträde, gemensamt personuppgiftsansvarig eller underbiträde?
- När uppstod kännedom, och vilket underlag visar det?
- Krävs regulatorisk anmälan enligt GDPR Article 33?
- Löper de berörda personerna hög risk enligt GDPR Article 34?
- Om organisationen agerar som personuppgiftsbiträde, hur snabbt måste den personuppgiftsansvarige underrättas?
- Vilket underlag kommer att styrka beslutet sex månader senare vid en revision?
Skillnaden mellan kaos och kontroll är inte antalet säkerhetsverktyg i teknikstacken. Det avgörande är om organisationen har byggt ett disciplinerat ledningssystem för hantering av integritetsinformation, PIMS, som kopplar samman incidentrespons, dataskyddsstyrning, underlagshantering, leverantörseskalering och regulatorisk rapportering i en enda försvarbar livscykel.
Incidenthantering börjar innan någon säger ”personuppgiftsincident”
Det första operativa misstaget är att anta att hantering av personuppgiftsincidenter börjar först när juridik bekräftar en personuppgiftsincident. I praktiken börjar processen när en person, ett system, en leverantör eller en kund upptäcker något som kan beröra personuppgifter.
Clarysecs Zenith Blueprint: revisorns 30-stegskarta Zenith Blueprint placerar denna mänskliga utlösare i fasen Kontroller i praktiken, steg 16: Personrelaterade kontroller II. Guiden anger:
”Ett effektivt incidenthanteringssystem börjar inte med verktyg, utan med människor. Kontroll 6.8 betonar vikten av att säkerställa att varje anställd, uppdragstagare eller intressent vet hur en potentiell säkerhetsincident ska identifieras och rapporteras, och känner sig trygg och har mandat att göra det.”
Detta är viktigt eftersom många integritetsincidenter inte först upptäcks av en SIEM. De börjar med att en supportmedarbetare ser en annan kunds bilaga, en löneadministratör upptäcker ett feladresserat kalkylblad, en kund rapporterar en annan användares faktura eller en leverantör rapporterar en borttappad bärbar dator.
Policy för dataskydd och integritet för små och medelstora företag Policy för dataskydd och integritet för små och medelstora företag, avsnittet Efterlevnad och tillämpning, klausul 8.3.1, gör detta till en omedelbar skyldighet:
”Alla personuppgiftsincidenter eller misstänkta incidenter måste omedelbart rapporteras till integritetssamordnaren”
För större program tilldelar Policy för dataskydd och integritet Policy för dataskydd och integritet, avsnittet Efterlevnad och tillämpning, klausul 8.3.2, ansvar till ledningen:
”Dataskyddsombudet (DPO) ska leda begränsning, analys och eskalering av personuppgiftsincidenter i enlighet med ISO/IEC 27035 och GDPR Article 33 och Article 34.”
Det är skiftet från ”IT tittar på det” till ”PIMS-livscykeln för personuppgiftsincidenter har aktiverats.”
Första tryckpunkten: händelse, säkerhetsincident, integritetsincident eller personuppgiftsincident
Klockan 02:13 har Marias team ett larm. De har ännu inte en bekräftad anmälningspliktig incident. Det första kritiska beslutet är klassificering.
Zenith Blueprint, fasen Kontroller i praktiken, steg 23: Organisatoriska kontroller, förklarar ISO/IEC 27002:2022 kontroll 5.25, bedömning och beslut om informationssäkerhetshändelser:
”Inte varje avvikelse är en katastrof. Inte varje larm signalerar kompromettering. I verkligheten översköljs säkerhetsteam och verksamhetsenheter av brus, inloggningsförsök, loggavvikelser, mindre policyöverträdelser och skugg-IT-aktivitet. Den verkliga utmaningen ligger inte bara i detekteringen, utan i att skilja det ofarliga från det skadliga och veta vad som kräver eskalering.”
En livscykel för integritetsincidenter måste göra denna åtskillnad upprepbar. Den ska inte bero på vem som råkar ha beredskap, vilken jurist som kopplas in först eller om informationssäkerhetschefen är bekväm med osäkerhet.
En praktisk klassificeringsmodell från Clarysec delar upp detta i fyra steg:
| Klassificeringssteg | Fråga | Typisk ägare | Obligatoriskt underlag |
|---|---|---|---|
| Händelse | Har något ovanligt hänt? | Helpdesk, SOC, verksamhetsägare | Ärende, rapport, larm, e-post, loggutdrag |
| Säkerhetsincident | Hotade eller komprometterade händelsen informationssäkerheten? | Incidenthanteringskoordinator | Incidentärende, triageringsanteckningar, berörda system |
| Integritetsincident | Kan händelsen beröra personuppgifter eller dataskyddsskyldigheter? | Dataskyddsansvarig eller DPO | Kategorier av personuppgifter, registrerade, behandlingsroll |
| Bekräftad eller misstänkt personuppgiftsincident | Har personuppgifter exponerats, förlorats, ändrats, förstörts eller åtkommits olagligen eller oavsiktligt? | DPO, dataskyddsansvarig, juridik, verksamhetsägare | Riskbedömning, anmälningsbeslut, underlagsregister |
Ordet ”misstänkt” är avgörande. Clarysec rekommenderar inte att organisationen väntar på fullständig visshet innan arbetsflödet för integritetsincidenter öppnas. Incidentregistret bör öppnas när en personuppgiftsincident rimligen kan misstänkas och därefter uppdateras i takt med att fakta klargörs.
Policy för hantering av incidenter som rör personuppgifter och personuppgiftsincidenter Policy för hantering av incidenter som rör personuppgifter och personuppgiftsincidenter, avsnittet Klassificering och bedömning av personuppgiftsincidenter, klausul 4.2.3, kräver att personuppgiftsansvariga dokumenterar beslutet innan extern åtgärd vidtas:
”[Personuppgiftsansvarig] Dataskyddsombudet / integritetsrådgivaren MÅSTE bedöma risken för berörda registrerade för varje bekräftad eller rimligen misstänkt personuppgiftsincident och dokumentera rekommendation om anmälan, riskmotivering och rådgivning i REG10 innan beslut om extern anmälan fattas.”
Den klausulen är den operativa kärnan i incidentrespons enligt GDPR med revisionsberedskap: bedöm risken, dokumentera motiveringen, fånga rådgivningen, fatta beslut och bevara underlaget i REG10.
72-timmarsfristen är ett underlagsproblem, inte en kalenderpåminnelse
Många team behandlar GDPR:s 72-timmarskrav för anmälan som en tidsfrist i en projektplan. I en verklig incident är den svåra delen att visa när kännedom uppstod, vad som var känt vid den tidpunkten, hur snabbt organisationen agerade och varför anmälningsbeslutet var rimligt.
Policy för incidenthantering för små och medelstora företag Policy för incidenthantering för små och medelstora företag, avsnittet Syfte, klausul 1.2, beskriver målet:
”Denna policy gör det möjligt för organisationen att minimera skada, skydda kunddata och uppfylla regulatoriska skyldigheter, såsom GDPR:s krav på anmälan av personuppgiftsincident inom 72 timmar.”
Policy för dataskydd och integritet för små och medelstora företag, avsnittet Efterlevnad och tillämpning, klausul 8.3.3, anger:
”När det krävs ska anmälan till myndigheter och berörda personer ske inom 72 timmar”
För större program anger Policy för dataskydd och integritet, avsnittet Efterlevnad och tillämpning, klausul 8.3.3:
”Incidenter som uppfyller den rättsliga tröskeln för anmälan ska rapporteras till tillsynsmyndigheter inom 72 timmar.”
Poängen är inte att anmäla varje avvikelse. Poängen är att fatta ett försvarbart beslut tillräckligt snabbt för att en obligatorisk anmälan ska kunna göras i tid. Ett moget PIMS använder därför interna tidsfrister som är kortare än externa rättsliga tidsfrister.
| Tid från kännedom | PIMS-åtgärd | Underlag som ska fångas i REG10 |
|---|---|---|
| 0 till 4 timmar | Öppna incidentpost för personuppgifter, tilldela ägare, bevara initialt underlag, identifiera behandlingsroll | Inkommande rapport, tidpunkt för kännedom, tilldelade roller, initiala system och data som berörs |
| 4 till 12 timmar | Begränsa exponering, identifiera kategorier av personuppgifter, fastställ skyldigheter som personuppgiftsansvarig eller personuppgiftsbiträde | Begränsningsåtgärder, berörda datatyper, rollbedömning, leverantörs- eller kundberoenden |
| 12 till 24 timmar | Genomför preliminär riskbedömning och besluta om anmälan till tillsynsmyndighet sannolikt krävs | Riskmotivering, sannolik påverkan, osäkerhet, DPO-rådgivning, juridisk input |
| 24 till 48 timmar | Förbered anmälan eller motivering till att inte anmäla, samordna kundkommunikation eller kommunikation till personuppgiftsansvarig | Utkast till anmälan, beslutslogg, godkännanden, kundaviseringar, underlagsreferenser |
| 48 till 72 timmar | Skicka in obligatorisk anmälan, dokumentera eventuell motivering till fördröjning, förbered kommunikation till enskilda om risken är hög | Inlämningsunderlag, referens från tillsynsmyndighet, slutligt beslut, kommunikationsplan |
| Efter 72 timmar | Fortsätt utredning, uppdatera tillsynsmyndighet vid behov, underrätta enskilda där så krävs, slutför erfarenhetsåterföring | Uppföljningsrapporter, korrigerande åtgärder, godkännande av stängning, förbättringsbacklogg |
Policy för hantering av incidenter som rör personuppgifter och personuppgiftsincidenter, avsnittet Anmälan och kommunikation, klausul 4.4.1, gör dokumentationskravet uttryckligt:
”[Personuppgiftsansvarig] Dataskyddsansvarig / PIMS-ansvarig MÅSTE ta fram ett dokumenterat regulatoriskt anmälningsbeslut för varje bekräftad personuppgiftsincident utan onödigt dröjsmål och inom en intern tidsfrist som stödjer tillämpliga externa anmälningstidsfrister, och MÅSTE bevara anmälan, motiveringen till att inte anmäla eller motiveringen till fördröjning i REG10.”
En tillsynsmyndighet kan ifrågasätta ett beslut. En revisor kan testa om processen följdes. Men om organisationen kan visa aktuellt underlag, strukturerade kriterier, DPO-rådgivning och en dokumenterad motivering står den betydligt starkare än ett team som säger: ”Vi diskuterade det på ett möte.”
Personuppgiftsansvariga och personuppgiftsbiträden behöver olika incidentvägar
Moderna SaaS-bolag agerar ofta i mer än en dataskyddsroll. Marias fintech-plattform kan vara personuppgiftsansvarig för sina direkta abonnenter och personuppgiftsbiträde för företagskunder. I ett annat scenario kan en B2B-supportportal vara personuppgiftsbiträde för kunders ärendebilagor men personuppgiftsansvarig för sina egna interna supportmetadata.
Den skillnaden ändrar anmälningsvägen.
| Skyldighet | Roll som personuppgiftsansvarig | Roll som personuppgiftsbiträde |
|---|---|---|
| Primär skyldighet | Gentemot tillsynsmyndigheten och berörda personer när tröskelvärden uppfylls | Gentemot den berörda personuppgiftsansvarige eller kunden |
| Mottagare av anmälan | Relevant tillsynsmyndighet och, vid hög risk, berörda personer | Kund eller personuppgiftsansvarig som anges i avtalet |
| Utlösare för anmälan | Risk för fysiska personers rättigheter och friheter | Kännedom om en incident som påverkar kundens personuppgifter |
| Tidslinje | Utan onödigt dröjsmål och, om möjligt, inom 72 timmar efter kännedom | Utan onödigt dröjsmål och inom avtalade tidsfrister, ofta 24 eller 48 timmar |
| Riskbedömning | Måste bedöma risk för enskilda och besluta om anmälan enligt Article 33 och Article 34 | Tillhandahåller fakta så att den personuppgiftsansvarige kan bedöma risken |
För personuppgiftsbiträden anger Policy för hantering av incidenter som rör personuppgifter och personuppgiftsincidenter, avsnittet Anmälan och kommunikation, klausul 4.4.4:
”[Personuppgiftsbiträde] Dataskyddsansvarig / PIMS-ansvarig MÅSTE underrätta den berörda personuppgiftsansvarige eller kunden utan onödigt dröjsmål och inom eventuell tillämplig avtalad tidsfrist efter att ha fått kännedom om en personuppgiftsincident som påverkar kundens personuppgifter, och MÅSTE registrera initiala aviseringar och uppföljningsaviseringar i REG08 och REG10.”
Ett personuppgiftsbiträde bör inte vänta på att slutföra den personuppgiftsansvariges riskanalys enligt GDPR. Det ska underrätta den personuppgiftsansvarige med tillgängliga fakta och lämna uppdateringar i takt med att utredningen fortsätter. Den personuppgiftsansvarige beslutar därefter om anmälan till tillsynsmyndighet och kommunikation till berörda personer för sin behandling.
Vid hög risk för enskilda måste den personuppgiftsansvarige även bedöma direkt kommunikation. Policy för hantering av incidenter som rör personuppgifter och personuppgiftsincidenter, klausul 4.4.3, anger:
”[Personuppgiftsansvarig] Dataskyddsansvarig / PIMS-ansvarig MÅSTE samordna kommunikation till berörda registrerade när bedömningen av personuppgiftsincidenten identifierar en hög risk eller likvärdig kommunikationsutlösare, och MÅSTE dokumentera kommunikationens innehåll, målgrupp, tidpunkt, leveransmetod och godkännandeunderlag i REG10.”
Den större organisationens Policy för dataskydd och integritet, avsnittet Efterlevnad och tillämpning, klausul 8.3.4, förstärker detta:
”Om en hög risk för enskilda identifieras ska berörda registrerade underrättas utan onödigt dröjsmål, om inte ett undantag gäller (t.ex. att stark kryptering finns på plats).”
Det undantaget måste vara underlagsbaserat. Det räcker inte att säga ”uppgifterna var krypterade”. Organisationen måste kunna visa att de exponerade uppgifterna var oläsbara för obehöriga parter och att relevanta nycklar inte komprometterades.
Leverantörer kan avgöra de första 24 timmarna
Tredje parter har ofta de fakta som behövs för klassificering och anmälan. En molnleverantör kan ha åtkomstloggar. Ett löneadministrerande personuppgiftsbiträde kan veta vilka anställda som berördes. En leverantör av förvaltade tjänster kan ha utfört konfigurationsändringen. Ett underbiträde kan ha forensisk telemetri.
Avtalsvillkor om leverantörers incidentrapportering måste därför utformas innan incidenten inträffar.
Policy för leverantörs- och tredjepartssäkerhet Policy för leverantörs- och tredjepartssäkerhet, avsnittet Styrningskrav, klausul 5.3.3, omfattar avtalsstyrning av:
”Tidsramar för anmälan av incidenter (t.ex. inom 24 eller 72 timmar, beroende på kritikalitet och regulatoriska krav)”
För mindre organisationer stödjer Policy för leverantörs- och tredjepartssäkerhet för små och medelstora företag Policy för leverantörs- och tredjepartssäkerhet för små och medelstora företag på motsvarande sätt tidslinjer för incidentanmälan inom leverantörsstyrning.
Clarysec rekommenderar att leverantörsavtal och personuppgiftsbiträdesavtal definierar:
- Vad som utgör en misstänkt personuppgiftsincident
- Vem som ska underrättas och via vilken kanal
- Initial anmälningsfrist, ofta kortare än den personuppgiftsansvariges regulatoriska tidsfrist
- Minsta uppsättning fakta som krävs i den första anmälan
- Uppdateringsfrekvens under utredningen
- Skyldigheter att bevara underlag
- Vidareföring av anmälningsskyldigheter till underbiträden
- Stöd för kommunikation med tillsynsmyndighet och registrerade
- Skyldigheter avseende korrigerande åtgärder efter incidenten
Om leverantörsavtal använder vaga formuleringar som ”så snart som praktiskt möjligt” kan den personuppgiftsansvariges GDPR-frist bero på en annan organisations interna diskussion. Det är inte en försvarbar operativ modell.
Underlag gör responsen till försvarbar efterlevnad
Under Marias incident behöver teamet autentiseringsloggar, databasfrågeposter, phishingunderlag, ändringar i åtkomstkontroll, listor över berörda kunder, begränsningsåtgärder, DPO-rådgivning och kommunikationsutkast. I scenariot med B2B-SaaS-portalen kan teamet behöva skärmdumpar, behörigheter för objektlagring, supportärende-ID:n, IAM-ändringar och åtkomstloggar mellan tenantmiljöer.
Underlaget måste bevaras korrekt. Lösa skärmdumpar, chattexporter och personliga mappar räcker inte.
Zenith Blueprint, fasen Kontroller i praktiken, steg 23, behandlar ISO/IEC 27002:2022 kontroll 5.28, insamling av bevisning:
”När en informationssäkerhetsincident inträffar är ett av de mest kritiska, men ofta förbisedda, delarna av responsen underlag. Inte loggar, inte skärmdumpar, inte lösa berättelser, utan korrekt bevarat, beviskedjerespekterande och manipulationsskyddat underlag.”
Policy för bevisinsamling och forensik Policy för bevisinsamling och forensik, avsnittet Styrningskrav, klausul 5.5, anger:
”All insamlad bevisning ska identifieras unikt, märkas och lagras i ett säkert dokumentarkiv med:”
Policy för hantering av incidenter som rör personuppgifter och personuppgiftsincidenter, avsnittet Underlag, registerföring och konfidentialitet, klausul 4.5.1, kopplar detta underlag till PIMS-posten:
”[Båda] Incidenthanteringskoordinatorn MÅSTE upprätthålla en fullständig REG10-post för varje misstänkt eller bekräftad incident som rör personuppgifter från mottagning till stängning, inklusive fakta, tidpunkter, klassificering, bedömning, åtgärder, beslut, aviseringar, underlagsreferenser och stängningsstatus.”
REG10 blir den gemensamma sanningskällan för incidenten. REG08 fångar kundaviseringar eller aviseringar till personuppgiftsansvarig när det är tillämpligt. Tillsammans gör de att säkerhet, dataskydd, juridik och revision kan arbeta utifrån en gemensam underlagskedja.
| REG10-fält | Exempelpost |
|---|---|
| Incident-ID | PII-2026-034 |
| Tidpunkt för kännedom | 2026-06-23 02:13 UTC, SOC-larm bekräftat |
| Behandlingsroll | Personuppgiftsansvarig för direkta abonnenter, personuppgiftsbiträde för företagskunders dataset |
| Berörda personuppgifter | Namn, arbetsrelaterade e-postadresser, transaktionshistorik, nationella identitetsnummer |
| Initial klassificering | Bekräftad säkerhetsincident med misstänkt personuppgiftsincident |
| Begränsning | Utvecklarens autentiseringsuppgifter återkallade, sessioner avslutade, berörd databasåtkomst begränsad |
| Riskbedömning | Icke-publika identifierare åtkomna, risk för identitetsbedrägeri kan inte uteslutas |
| Anmälningsbeslut | Anmälan till tillsynsmyndighet godkänd för personuppgifter där organisationen är personuppgiftsansvarig, företagskunder underrättade som personuppgiftsansvariga |
| Underlagsreferenser | Autentiseringslogg E-034-01, frågeexport E-034-02, phishingartefakt E-034-03 |
| Stängning | Rotorsak åtgärdad, MFA-kontroller förstärkta, phishingutbildning uppdaterad, kunduppföljning slutförd |
Syftet är inte byråkrati. Syftet är att hindra organisationen från att behöva rekonstruera minnet utifrån spridda Slack-meddelanden när tillsynsmyndigheten hör av sig.
Mappning av PIMS-respons enligt ISO 27701 till ISO 27001 och ISO 27002
En mogen process för personuppgiftsincidenter ligger i skärningspunkten mellan dataskyddsstyrning och ledning av informationssäkerhet.
ISO/IEC 27001:2022 klausulerna 4.1 till 4.4 kräver att organisationer förstår kontext, intressenter, ISMS-omfattning och ledningssystemets processer. För hantering av personuppgiftsincidenter innebär detta att processen måste spegla regulatoriska skyldigheter, kundavtal, behandlingsroller, leverantörsberoenden och sektorsspecifika skyldigheter innan en incident inträffar.
Zenith Controls: guiden för mappning mellan efterlevnadskrav Zenith Controls hjälper till att mappa incidentkontroller till en bredare försäkransmodell. De mest relevanta kontrollerna i ISO/IEC 27002:2022 är:
| ISO/IEC 27002:2022-kontroll | Behandling i Zenith Controls | Varför den är viktig för hantering av personuppgiftsincidenter |
|---|---|---|
| 5.24 Planering och förberedelse av incidenthantering för informationssäkerhet | Korrigerande kontroll, Respond and Recover, styrning och hantering av informationssäkerhetshändelser | Definierar planer, roller, eskaleringsvägar, kommunikationsmallar och beredskap för integritetsincidenter |
| 5.25 Bedömning och beslut om informationssäkerhetshändelser | Detekterande kontroll, Detect and Respond, hantering av informationssäkerhetshändelser | Skapar den strukturerade beslutspunkten för klassificering av integritetsincidenter och misstänkta personuppgiftsincidenter |
| 5.26 Respons på informationssäkerhetsincidenter | Korrigerande kontroll, Respond and Recover, hantering av informationssäkerhetshändelser | Aktiverar begränsning, samordning, stöd för anmälan, återställning och kommunikation med intressenter |
| 5.28 Insamling av bevisning | Bevarande av underlag och tillförlitlighet i utredningar genom incidentens livscykel | Stödjer ansvarsskyldighet enligt GDPR, forensisk kvalitet, frågor från tillsynsmyndigheter och försvarbarhet vid revision |
| 6.8 Rapportering av informationssäkerhetshändelser | Persondriven rapporteringskanal och medvetandehöjande utbildning | Säkerställer att misstänkta incidenter som rör personuppgifter rapporteras snabbt av anställda, uppdragstagare och intressenter |
ISO/IEC 27035 stödjer strukturerad incidenthantering. ISO/IEC 27037 stödjer hantering av digital bevisning. ISO/IEC 29134 kan stödja logiken för konsekvensbedömning avseende dataskydd när åtgärder efter incidenten visar behov av en djupare DPIA-granskning. ISO/IEC 27701:2025 för sedan in dataskyddsrollens kontext, påverkan på registrerade, skyldigheter för personuppgiftsansvariga och personuppgiftsbiträden samt PIMS-krav på underlag i ledningssystemet.
En incident, flera regulatoriska perspektiv
Marias incident är inte bara en GDPR-fråga. Eftersom företaget tillhandahåller molntjänster till kunder i finanssektorn kan NIS2 och DORA också vara tillämpliga. Kundavtal kan kräva avisering inom 24 timmar. Cyberförsäkring kan kräva snabb anmälan. Intern styrning kan kräva rapportering till styrelsen.
Att skapa separata berättelser för varje ramverk skapar risk för motsägelser. Clarysecs metod är att upprätthålla en gemensam underlagskedja och därefter skapa ramverksspecifika underlag från den.
| Ramverk eller regelverk | Incidentperspektiv | Utdata från Clarysecs underlagskedja |
|---|---|---|
| GDPR | Personuppgiftsincident, risk för enskilda, anmälan till tillsynsmyndighet, kommunikation till berörda personer | REG10-beslutsunderlag, DPO-rådgivning, motivering enligt Article 33 och 34, kommunikationsunderlag |
| ISO/IEC 27701:2025 | PIMS-styrning, skyldigheter för personuppgiftsansvarig och personuppgiftsbiträde, risk för registrerad, integritetsunderlag | Klassificering av incident som rör personuppgifter, rollbedömning, REG08 och REG10, korrigerande åtgärder |
| ISO/IEC 27001:2022 | ISMS-kontext, intressenter, incidenthanteringsprocess, ständig förbättring | Incidentpost, uppdateringar av riskbehandling, underlag till ledningens genomgång, underlag för kontrolleffektivitet |
| NIS2 | Hantering av betydande incidenter, stegvis rapportering, allriskbaserade säkerhetsåtgärder | Underlag för tidig varning inom 24 timmar, anmälningspaket för incident inom 72 timmar, stöd för slutrapport inom en månad |
| DORA | Hantering av IKT-relaterade incidenter för finansiella entiteter och digital operativ resiliens | Fakta om IKT-påverkan, tredjepartsberoenden, återkoppling från resiliensövningar, stöd för incidentrapportering |
| NIST CSF 2.0 | Current Profile och Target Profile, prioriterad åtgärdsplan, riskkommunikation | Uppdateringar av luckor, målbildsförbättringar, riskbeskrivning för styrelsenivå |
| COBIT 2019 | Styrning, ledningsmål, ansvarsskyldighet, kontrollprestanda | RACI, beslutsloggar, processmätetal, uppföljning av korrigerande åtgärder |
NIS2 Article 21 fastställer åtgärder för hantering av cybersäkerhetsrisker, inklusive incidenthantering, verksamhetskontinuitet, leveranskedjesäkerhet, effektivitetsbedömning, cyberhygien, kryptografi, åtkomstkontroll, tillgångshantering, MFA och säker kommunikation. NIS2 Article 23 skapar stegvis rapportering för betydande incidenter, inklusive tidig varning inom 24 timmar, incidentanmälan inom 72 timmar, uppdateringar på begäran och en slutrapport senast en månad efter incidentanmälan.
DORA gäller från den 17 januari 2025 och fastställer enhetliga krav för IKT-riskhantering, rapportering av IKT-relaterade incidenter, testning av digital operativ resiliens, informationsdelning och IKT-tredjepartsriskhantering för finansiella entiteter. För en fintech-leverantör kan en enskild incident därför samtidigt vara en personuppgiftsincident enligt GDPR, en betydande incident enligt NIS2, en DORA-relevant IKT-händelse för kunder och en avtalsstyrd anmälningshändelse.
Hur revisorer testar livscykeln
Revisorer stannar sällan vid ”visa mig er incidenthanteringspolicy”. De testar om livscykeln fungerar under underlagspress.
En revisor enligt ISO/IEC 27701:2025 eller ISO/IEC 27001:2022 kommer att fråga hur integritetsincidenter förs in i ISMS och PIMS, vem som klassificerar händelser, hur skyldigheter för personuppgiftsansvarig och personuppgiftsbiträde skiljer sig åt och hur incidenter leder till korrigerande åtgärder.
En GDPR-revisor eller tillsynsmyndighet kommer att fokusera på tidpunkt för kännedom, risk för enskilda, DPO-involvering, anmälningsmotivering, kommunikation till berörda personer och ansvarsskyldighet. De kan granska ett urval incidenter som inte anmäldes för att testa om motiveringen till att inte anmäla dokumenterades.
En granskning enligt NIS2 eller DORA kommer att pröva trösklar för betydande incidenter, stegvis rapportering, IKT-påverkan, tredjepartsberoenden, resilienskonsekvenser och om rapporteringen var anpassad till relevant behörig myndighet eller kundkrav.
En bedömare enligt NIST CSF 2.0 kommer att fråga om incidenten ändrade organisationens Current Profile och Target Profile. En granskare enligt COBIT 2019 kommer att fokusera på styrning, ansvarsskyldighet, processägarskap, mätetal och uppföljning av korrigerande åtgärder.
Ett starkt underlagspaket för revision bör omfatta:
| Underlagsobjekt | Varför revisorer begär det |
|---|---|
| REG10-incidentpost | Visar mottagning, tidpunkter, klassificering, bedömning, beslut, aviseringar och stängning |
| REG08-post för kundavisering eller avisering till personuppgiftsansvarig | Visar kommunikation från personuppgiftsbiträde och historik över kunduppdateringar |
| Ursprunglig rapport eller ursprungligt larm | Fastställer hur incidenten upptäcktes och när kännedom började |
| Tidslinje över nyckelåtgärder | Visar begränsning, bedömning, godkännanden och anmälningsbeslut |
| Bedömning av behandlingsroll | Visar åtskillnad mellan skyldigheter för personuppgiftsansvarig och personuppgiftsbiträde |
| Kategorier av personuppgifter och berörda registrerade | Stödjer riskbedömning och anmälans omfattning |
| Rekommendation från DPO eller integritetsrådgivare | Visar ansvarstagande dataskyddsrådgivning före externt beslut |
| Anmälan eller motivering till att inte anmäla | Stödjer ansvarsskyldighet enligt GDPR Article 33 och 34 |
| Index över underlagsarkiv | Visar underlagets integritet och disciplin i beviskedjan |
| Rotorsak och plan för korrigerande åtgärder | Visar ständig förbättring och granskning av kontrolleffektivitet |
Det är här Zenith Controls är kommersiellt och operativt värdefullt. Det hjälper till att mappa samma underlag till incidentkontroller i ISO/IEC 27002:2022, ansvarsskyldighet enligt GDPR, incidenthantering enligt NIS2, resiliensförväntningar enligt DORA, kommunikation enligt NIST CSF och COBIT-styrning utan att revisionsberättelsen behöver byggas om varje gång.
En operativ rytm för de första 24 timmarna
En realistisk handlingsplan för personuppgiftsincidenter ska kännas praktisk, inte teoretisk. Tänk dig en SaaS-exponering mellan tenantmiljöer som rapporteras av en kund klockan 08:12.
Klockan 08:12 tar kundteamet emot rapporten och följer rapporteringsbeteendet från Zenith Blueprint steg 16. Ärendet taggas som misstänkt incident som rör personuppgifter.
Klockan 08:25 öppnar incidenthanteringskoordinatorn REG10. Posten innehåller tidpunkt för kännedom, rapportör, system, misstänkta datatyper och ägare.
Klockan 09:02 återställer teknikteamet behörighetsändringen. Loggar exporteras före loggrotation. Underlagsansvarig märker kundrapporten, IAM-ändringen, exporten av åtkomstloggar och bekräftelsen på begränsning i det säkra dokumentarkivet.
Klockan 10:30 fastställer dataskyddsansvarig att organisationen agerar som personuppgiftsbiträde för bilagor i kundsupportärenden. Enligt Policy för hantering av incidenter som rör personuppgifter och personuppgiftsincidenter, klausul 4.4.4, måste berörda kunder som är personuppgiftsansvariga underrättas utan onödigt dröjsmål och inom avtalade tidsfrister. REG08 öppnas.
Klockan 12:00 bedömer DPO risken för registrerade. Uppgifterna verkar begränsade, men vissa bilagor kan innehålla anställdas namn och interna ID:n. DPO dokumenterar riskmotiveringen och rekommendationen i REG10.
Klockan 15:00 får berörda kunder som är personuppgiftsansvariga den initiala aviseringen: vad som hände, när det upptäcktes, vad som har begränsats, vilka personuppgifter som kan beröras, vad som fortfarande analyseras och när nästa uppdatering kommer.
Klockan 18:00 får ledningen en kort lägesbild: kundaviseringar har skickats, regulatoriska anmälningsbeslut ligger hos de personuppgiftsansvariga för kundernas personuppgifter, intern behandling som personuppgiftsansvarig utreds fortfarande, underlag är bevarat och rotorsaksanalys pågår.
Den rytmen förebygger de vanligaste incidentbristerna: missade tidsfrister, oklara roller, odokumenterad rådgivning och okontrollerad kommunikation.
Vanliga bristmönster att åtgärda före nästa larm
De mest skadliga bristerna vid integritetsincidenter orsakas sällan av ett enda saknat dokument. De orsakas av glapp mellan säkerhet, dataskydd, juridik, leverantörer och verksamhetsägare.
Clarysec ser ofta följande mönster:
- Incidenthanteringsplaner finns, men klassificering av personuppgiftsincidenter saknas.
- GDPR:s 72-timmarsanmälan nämns, men interna tidsfrister är inte kortare än den rättsliga tidsfristen.
- Eskalering från personuppgiftsbiträde försenas eftersom team väntar på fullständig rotorsaksanalys.
- Leverantörsavtal kräver inte snabb incidentanmälan eller stöd för underlag.
- DPO-rådgivning ges muntligt och förs aldrig in i incidentregistret.
- Kommunikation till enskilda vid hög risk övervägs för sent.
- Underlag lagras i personliga mappar, chattrådar eller ärendekommentarer.
- Beslut om att inte anmäla dokumenteras inte.
- Erfarenhetsåterföring uppdaterar inte kontroller, utbildning, leverantörsklausuler eller riskbehandlingsplaner.
Zenith Blueprint, steg 23, fångar varför struktur är viktigt:
”Incidentrespons utan struktur blir ett hafsigt reaktivt arbete. E-post skickas, möten kallas in och beslut fattas känslomässigt eller inkonsekvent. Men ett moget ISMS omvandlar respons till disciplin.”
Den disciplinen är syftet med hantering av personuppgiftsincidenter enligt ISO/IEC 27701:2025.
Bygg Clarysecs livscykel för personuppgiftsincidenter
Clarysecs metod kombinerar tre lager.
För det första ger Zenith Blueprint en färdplan för genomförande. Steg 16 säkerställer att människor känner igen och rapporterar misstänkta incidenter. Steg 23 operationaliserar bedömning, beslut, respons och bevisinsamling genom ISO/IEC 27002:2022 kontrollerna 5.25, 5.26 och 5.28.
För det andra definierar policyuppsättningen befogenheter och skyldigheter. Policyer för små och medelstora företag gör rapportering, 72-timmarsmedvetenhet och incidentregister praktiskt genomförbara för mindre organisationer. Enterprise-policyer tilldelar DPO-ledning, incidenttrösklar, kommunikation till berörda personer, villkor för leverantörsavisering, underlagshantering och forensisk styrning. Den PIMS-specifika Policy för hantering av incidenter som rör personuppgifter och personuppgiftsincidenter lägger till rollbaserade skyldigheter för personuppgiftsansvariga och personuppgiftsbiträden, REG08, REG10, anmälningsmotivering och stängningsunderlag.
För det tredje fungerar Zenith Controls som kompass för mappning mellan efterlevnadskrav. Det mappar incidentplanering, bedömning, respons och underlag till en integrerad vy över ISO/IEC 27002:2022, GDPR, NIS2, DORA, NIST CSF 2.0 och COBIT-liknande försäkransförväntningar.
För informationssäkerhetschefer minskar detta operativ osäkerhet. För DPO:er skapar det ett försvarbart beslutsspår för dataskydd. För complianceansvariga kopplar det en incidentpost till flera regulatoriska utdata. För revisorer skapar det spårbart underlag. För ledande befattningshavare minskar det risken att en hanterbar integritetsincident utvecklas till en regulatorisk kris och anseendekris.
Ditt nästa steg
Vänta inte på larmet klockan 02:00 för att upptäcka om er process för personuppgiftsincidenter fungerar.
Börja denna vecka med tre åtgärder:
- Granska om er incidentmottagning uttryckligen fångar misstänkta incidenter som rör personuppgifter.
- Bekräfta att skyldigheter för personuppgiftsansvarig och personuppgiftsbiträde vid incidenter är separerade i policyer, avtal och underlagsregister.
- Genomför en skrivbordsövning med ett realistiskt scenario, till exempel komprometterade autentiseringsuppgifter, exponering mellan tenantmiljöer, en feladresserad lönefil, en borttappad krypterad bärbar dator eller en leverantörskompromettering.
Clarysec kan hjälpa dig att operationalisera detta genom Zenith Blueprint: revisorns 30-stegskarta Zenith Blueprint, Zenith Controls: guiden för mappning mellan efterlevnadskrav Zenith Controls och policyuppsättningen för ISO/IEC 27701:2025 PIMS, inklusive Policy för hantering av incidenter som rör personuppgifter och personuppgiftsincidenter Policy för hantering av incidenter som rör personuppgifter och personuppgiftsincidenter, Policy för dataskydd och integritet Policy för dataskydd och integritet, Policy för incidenthantering för små och medelstora företag Policy för incidenthantering för små och medelstora företag, Policy för leverantörs- och tredjepartssäkerhet Policy för leverantörs- och tredjepartssäkerhet och Policy för bevisinsamling och forensik Policy för bevisinsamling och forensik.
Ladda ner Clarysecs PIMS-verktygslåda, boka en bedömning av incidentberedskap eller schemalägg en demo för att omvandla er 72-timmarsrespons enligt GDPR från ett hafsigt reaktivt arbete till en disciplinerad och revisionsklar process.
Bli PECB ISO/IEC 27701-certifierad och bygg upp ditt PIMS
- ✓ Officiellt PECB-kursmaterial och två provförsök
- ✓ Certifieringsavgift och första årets AMF ingår, där det är tillämpligt
- ✓ Självstudier eller live online · kursen tilldelas inom 1 arbetsdag
Frequently Asked Questions
Om författaren
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
