Delning av cyberhotinformation med ISO 27001 under 2026

Klockan 07.40 en tisdagsmorgon får Maria, informationssäkerhetschef för en snabbväxande europeisk betalplattform, en bulletin med hög tillförlitlighet från en ISAC för finansiella tjänster. En kampanj för stöld av autentiseringsuppgifter riktar sig mot betalningsleverantörer som använder en specifik integration med en identitetsleverantör. Säkerhetsmeddelandet innehåller domäner för kommando- och kontrollinfrastruktur, misstänkta OAuth-applikationsnamn, User-Agent-strängar, observerade taktiker och en rekommendation om att rotera hemligheter för berörda klientmiljöer.

Inom några minuter börjar verksamheten ställa de frågor som definierar delning av cyberhotinformation under 2026.

SOC vill omedelbart föra in indikatorerna i SIEM. Juridik frågar om företaget kan dela sin egen telemetri tillbaka till ISAC:en. Dataskyddsombudet (DPO) frågar om IP-adresser, användarnamn, ärendeutdrag, autentiseringsloggar eller slutpunktsuppgifter innehåller personuppgifter. Den operativa chefen vill veta om kunder måste varnas. Verkställande direktören, nyss hemkommen från NIS2-utbildning för ledningen, vidarebefordrar larmet med två ord: ”Vår plan?”

Därefter ställer chefen för regelefterlevnad den viktigaste frågan: ”Om tillsynsmyndigheten frågar nästa månad, kan vi visa att vår delning av cyberhotinformation var laglig, godkänd, ändamålsenlig och kontrollerad?”

Det är den nya verkligheten. DORA har gått från genomförandefrist till tillsynsgranskning. NIS2 har gått från beredskapsprojekt till operativ samverkan. GDPR gäller fortfarande, även när uppgifterna är säkerhetstelemetri. Delning av hotinformation är inte längre ett informellt Slack-utbyte mellan säkerhetsteam. Det är en styrd aktivitet som omfattar konfidentialitet, minimering av personuppgifter, godkännanden för utlämnande, dokumentation, myndighetsförväntningar och revisionsbevis.

För informationssäkerhetschefer, chefer för regelefterlevnad, revisorer och verksamhetsägare är frågan inte om organisationen ska delta i arrangemang för delning av cyberhotinformation. Den verkliga frågan är hur organisationen kan dela tillräckligt snabbt för att hjälpa försvarare och samtidigt förhindra otillåtet utlämnande, brott mot kundsekretess, konkurrenskänsligt informationsläckage, okontrollerat offentliggörande av sårbarheter och bristfälligt underlag.

ISO/IEC 27001:2022 är den styrningsmässiga ryggraden som gör detta möjligt. Inte som ett certifikat på väggen, utan som ett ledningssystem som gör delning av cyberhotinformation till en repeterbar, försvarbar och GDPR-säker operativ modell.

Varför delning av cyberhotinformation förändrades under 2026

Den första vågen av förberedelser för DORA och NIS2 fokuserade på omfattning, tidsfrister för incidentrapportering, IKT-tredjepartsrisk, styrelsens ansvarsskyldighet och gapanalyser. Det arbetet var nödvändigt, men tillsynsmyndigheter och kunder ställer nu mer operativa frågor:

• Vilka ISAC:er, CERT:er, CSIRT:er, leverantörsforum eller betrodda samverkansforum deltar ni i?
• Vem är behörig att företräda organisationen externt?
• Hur avgör ni vad som får delas?
• Hur förhindrar ni att personuppgifter, kundhemligheter, sårbarhetsdetaljer och känslig arkitektur lämnas ut?
• Hur omsätts inflödet av hotinformation i övervakningsregler, patchprioriteringar, riskregister, incidentresponsplaner, leverantörsgranskningar och resiliensövningar?
• Var finns underlaget?

DORA är särskilt tydlig för finansiella entiteter. Förordningen behandlar digital operativ resiliens som ett styrelseägt system för IKT-riskhantering, inte som en IT-checklista. DORA gäller från den 17 januari 2025, vilket innebär att många finansiella entiteter under 2026 bedöms utifrån om deras processer fungerar i praktiken.

DORA Article 45 tillåter delning av information och underrättelser om cyberhot mellan finansiella entiteter när syftet är att stärka digital operativ resiliens. Delningen bör ske inom betrodda samverkansforum och enligt arrangemang som skyddar känslig affärsinformation, personuppgifter, konfidentialitet, immateriella rättigheter och konkurrensrättsliga gränser. Enkelt uttryckt betyder DORA inte ”dela allt”. Det betyder ”dela säkert, medvetet och under kontrollerade former”.

NIS2 skapar ett liknande tryck utanför finanssektorn. Direktivet gäller många väsentliga och viktiga entiteter inom högkritiska och andra kritiska sektorer, inklusive digital infrastruktur, leverantörer av hanterade tjänster (MSP:er), leverantörer av hanterade säkerhetstjänster, molntjänstleverantörer, datacenterleverantörer, onlinemarknadsplatser, sökmotorer, sociala nätverksplattformar, bankverksamhet och infrastrukturer för finansmarknaden. NIS2 Article 20 gör ledningsorgan ansvariga för att godkänna riskhanteringsåtgärder för cybersäkerhet, övervaka genomförandet och genomgå utbildning. Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, sårbarhetshantering, effektivitetsbedömning, cyberhygien, utbildning, kryptografi, HR-säkerhet, åtkomstkontroll, tillgångshantering, MFA och säker kommunikation. Article 23 kräver stegvis rapportering av betydande incidenter, inklusive en tidig varning inom 24 timmar, en incidentanmälan inom 72 timmar och en slutrapport senast en månad efter incidentanmälan.

GDPR tillför integritetsbegränsningen. Personuppgifter omfattar all information som avser en identifierad eller identifierbar fysisk person. Säkerhetsloggar, IP-adresser, användarnamn, e-postadresser, slutpunktsnamn, autentiseringshändelser, supportärenden, prover på skadlig kod, skärmdumpar och anteckningar från bedrägeriutredningar kan alla utgöra personuppgifter. GDPR kräver behandling som är laglig, korrekt, transparent, ändamålsbegränsad, uppgiftsminimerad, korrekt, lagringsbegränsad och säker. GDPR kräver också ansvarsskyldighet, vilket innebär att organisationen måste kunna visa efterlevnad.

Resultatet är ett styrningsproblem. Delning av hotinformation måste vara tillräckligt snabb för att förbättra försvaret, tillräckligt kontrollerad för att tillfredsställa tillsynsmyndigheter och tillräckligt disciplinerad för att undvika överträdelser av integritet och konfidentialitet.

ISO 27001 som nav för efterlevnad vid delning av hotinformation

ISO/IEC 27001:2022 lämpar sig väl för denna utmaning eftersom standarden börjar med kontext, intressenter, omfattning, risk, ledarskap, operativ styrning, övervakning, internrevision, ledningens genomgång och ständig förbättring.

Klausulerna 4.1 till 4.4 kräver att organisationer förstår interna och externa förutsättningar, identifierar intressenter och deras krav, definierar ISMS-omfattning och upprätthåller ledningssystemet. För en DORA- eller NIS2-organisation kan intressenter omfatta behöriga myndigheter, CSIRT:er, kunder, IKT-leverantörer, ISAC:er, branschgrupper, personuppgiftsbiträden, personuppgiftsansvariga, försäkringsgivare, internrevision och styrelsen.

Klausulerna 5.1 till 5.3 kräver ledningens åtagande, policyriktning, ansvarsskyldighet, resurser och tilldelade ansvarsområden. Detta är viktigt eftersom delning av hotinformation misslyckas när den lämnas åt informella tekniska bedömningar. Om SOC-analytikern, juridisk rådgivare, DPO, informationssäkerhetschef, PR-ansvarig och verksamhetsägare tillämpar olika antaganden kommer organisationen antingen att dela för mycket, låsa sig eller reagera för sent.

Klausulerna 6.1.1 till 6.1.3 omvandlar den regulatoriska frågan till riskbedömning, riskbehandling, urval av kontroller, beslut i tillämpbarhetsförklaring, riskbehandlingsplaner och acceptans av kvarstående risk. Typiska risker vid delning av hotinformation omfattar:

• Personuppgifter delas utan rättslig grund eller uppgiftsminimering.
• Konfidentiell kundinformation lämnas ut i ett forum.
• Sårbarhetsdetaljer offentliggörs innan riskreducering finns tillgänglig.
• Indikatorer tas emot men omsätts aldrig operativt.
• ISAC-deltagande återspeglas inte i incidentrespons, loggning, sårbarhetshantering eller leverantörsriskhantering.
• Brist på underlag som visar vem som godkände utlämnande och varför.
• Konkurrensrättslig risk genom delning av kommersiellt känslig marknadsinformation.
• Inkonsekvent regulatorisk kommunikation och kundkommunikation under en betydande incident.

Klausul 8.1 kräver därefter att planerade processer genomförs och styrs, med dokumenterad information som är tillräcklig för att visa att processerna fungerade som planerat. Klausulerna 9 och 10 kräver övervakning, mätning, internrevision, ledningens genomgång, hantering av avvikelser, korrigerande åtgärder och ständig förbättring. Kort sagt gör ISO/IEC 27001:2022 delning av cyberhotinformation till en operativ modell som går att granska.

De två ISO-kontrollerna som gör delning möjlig

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint behandlar detta ämne som en del av fasen Controls in Action, steg 22: organisatoriska kontroller. Två ISO/IEC 27002:2022-kontroller är centrala: 5.6, kontakt med särskilda intressegrupper, och 5.7, hotinformation.

Zenith Blueprint är tydlig med att ISAC-deltagande inte är symboliskt nätverkande:

Deltagande i sådana grupper är inte en symbolisk gest. Det är en strategisk investering i hotinformation, samverkan och gemensam resiliens.

För kontroll 5.6 kan särskilda intressegrupper omfatta nationella eller sektorspecifika nätverk för cyberhotinformation, ISAC:er, regulatoriska forum, leverantörers säkerhetsrådgivningsgrupper, öppen källkods-communityn och akademiska arbetsgrupper. Extern delning måste dock vara avsiktlig, laglig och godkänd. Zenith Blueprint lägger till mognadsförväntningen:

Mogna ISMS-införanden behandlar SIG-deltagande som en styrd aktivitet, inte som en informell förmån.

Det innebär att föra register över grupper och forum som organisationen deltar i, utse officiella deltagare, dokumentera protokoll eller sammanfattningar och integrera insikter i interna granskningar eller uppdateringar av kontroller.

Kontroll 5.7 omvandlar extern information till åtgärd. Zenith Blueprint anger:

En organisation kan inte försvara sig mot det den inte förstår.

Den varnar också för att blanda ihop patchflöden med hotinformation. Verklig hotinformation omfattar profilering av hotaktörer, taktiker, tekniker och procedurer, indikatorer på kompromettering, sektorspecifika varningar, sårbarhetskontext och strategisk verksamhetspåverkan. Användbar hotinformation kombinerar intern övervakning, externa partnerskap, CERT- eller ISAC-relationer, kommersiella flöden och öppna källor, men endast när någon granskar, prioriterar och översätter den till åtgärder.

Clarysecs Zenith Controls: The Cross-Compliance Guide Zenith Controls förstärker värdet för flera regelverk. Den mappar kontroll 5.6 som förebyggande och korrigerande, med stöd för konfidentialitet, riktighet och tillgänglighet, där styrning är den primära operativa förmågan. Den kopplar 5.6 till 5.7 Threat intelligence, 5.5 Kontakt med myndigheter, 5.31 Rättsliga, lagstadgade, regulatoriska och avtalsmässiga krav samt 8.8 Hantering av tekniska sårbarheter. Den mappar 5.7 som förebyggande, upptäckande och korrigerande, kopplad till Identify, Detect och Respond, med operativ förmåga inom hot- och sårbarhetshantering.

Budskapet är enkelt: ett moget program för delning av cyberhotinformation har två delar. För det första kontrollerade relationer. För det andra kontrollerad användning av det som tas emot och delas.

En praktisk operativ modell för styrd delning

En försvarbar operativ modell för 2026 bör besvara sex frågor innan den första indikatorn delas.

Clarysec inför normalt detta som ett lättviktigt men formellt arbetsflöde:

1. Ta emot och klassificera hotinformationen.
2. Validera relevans för tillgångar, leverantörer, tjänster, geografier och kunder.
3. Omvandla hotinformationen till åtgärder, exempelvis övervakningsregler, sårbarhetsärenden, användarlarm, leverantörsfrågor eller riskuppdateringar.
4. Besluta om utgående delning är nödvändig, laglig, säker och tillåten enligt medlemsregler.
5. Tillämpa maskering, aggregering, pseudonymisering eller anonymisering.
6. Inhämta nödvändiga godkännanden.
7. Dela via en godkänd kanal.
8. Registrera vad som delades, med vem, varför, när och under vems befogenhet.
9. Granska utfall och uppdatera kontroller.

Detta förhindrar de två klassiska felen: säkerhetsteamet tar emot användbar hotinformation men inget förändras, eller säkerhetsteamet delar användbar hotinformation men skapar rättslig, avtalsmässig eller integritetsmässig exponering.

DORA Article 45: kontrollerad delning utan att förlora konfidentialitet

För finansiella entiteter bör DORA Article 45 omsättas i en intern standard för delning av cyberhotinformation. En praktisk tolkning omfattar fem villkor.

För det första måste syftet vara resiliens. Delning ska bidra till att förebygga, upptäcka, hantera eller återhämta sig från cyberhot. Den får inte glida över i prissättning, kundlistor, marknadsstrategi eller kommersiellt känslig information.

För det andra måste samverkansforumet vara betrott. Det innebär tydliga medlemsregler, sekretesskyldigheter, säkra kanaler, åtkomstkontroller och begränsningar för vidareutlämnande. ISO/IEC 27010:2015 stödjer säkert informationsutbyte i betrodda samverkansforum, inklusive sekretessregler, ömsesidighet och betrodda kommunikationskanaler. ISO/IEC 27032:2023 stödjer informationsdelning om cybersäkerhet och situationsmedvetenhet. ISO/IEC 27035-2:2023 kopplar informationsdelning till planering av incidentrespons, inklusive deltagande i CERT:er och branschgrupper.

För det tredje måste känslig information skyddas. Detta omfattar affärshemligheter, arkitekturdiagram, sårbarhetsdetaljer, autentiseringsuppgifter, kundidentifierare och personuppgifter. Clarysecs SME policy för dataklassificering och märkning policy för dataklassificering och märkning - SME anger:

Extern delning ska vara uttryckligen godkänd och loggad.

Den meningen är kontrollprincipen bakom ett arbetsflöde för DORA Article 45. Organisationen måste veta vilken klassificering som gäller, vem som godkände utlämnandet och var posten finns.

För det fjärde måste personuppgifter minimeras. Företagsversionen av Policy för dataskydd och integritet Policy för dataskydd och integritet anger:

Endast data som är nödvändiga för ett specifikt och legitimt verksamhetsändamål får samlas in och behandlas.

SME-motsvarigheten, Policy för dataskydd och integritet-sme Policy för dataskydd och integritet - SME, anger:

Endast de minsta nödvändiga personuppgifterna ska samlas in och bevaras

Detta är viktigt eftersom hotinformation ofta lockar team att kopiera råa loggar till externa kanaler. I stället ska de endast dela det mottagaren behöver, exempelvis en skadlig domän, en hash, ett tidsstämpelintervall, ett generellt mönster eller en pseudonymiserad ärendereferens.

För det femte måste organisationen bevara underlag. DORA bygger på dokumenterad IKT-riskhantering, incidentklassificering, rapportering, testning, tredjepartsstyrning och ledningens ansvarsskyldighet. Om delning påverkar incidentrespons, ett scenario för resiliensövning eller ett beslut om leverantörsrisk ska detta framgå av ISMS-posterna.

NIS2-samverkan: från rättslig omfattning till operativa relationer

NIS2 breddar diskussionen utanför finansiella entiteter. Direktivet gäller utifrån sektor, storlek och kritikalitet, och kan även gälla oavsett storlek för vissa entiteter, såsom tillhandahållare av betrodda tjänster, DNS-tjänsteleverantörer, TLD-register, kritiska entiteter och tjänster för domännamnsregistrering.

För delning av hotinformation är den viktigaste lärdomen styrning. Article 20 gör ledningsorgan ansvariga för att godkänna och övervaka riskhanteringsåtgärder för cybersäkerhet. Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder. Article 23 kräver stegvis rapportering av betydande incidenter.

Delning av hotinformation berör alla dessa delar. Om ett ISAC-säkerhetsmeddelande visar att en leverantörs hanterade tjänst utnyttjas blir Article 21:s förväntningar på leveranskedjan relevanta. Om hotinformation indikerar en pågående betydande incident kan arbetsflöden för Article 23-rapportering och kundkommunikation utlösas. Om ett betydande cyberhot kan påverka tjänstemottagare behöver organisationen en kontrollerad varningsprocess.

Zenith Blueprint behandlar detta i fasen ISMS Foundation and Leadership, steg 5, Kommunikation, medvetenhet och kompetens. Den rekommenderar planering av extern kommunikation som identifierar kunder, tillsynsmyndigheter, partner och allmänheten, och därefter definierar vad som kommuniceras, när, av vem och med vilket godkännande. Den ger det praktiska exemplet med en rutin för incidentkommunikation där informationssäkerhetschefen utformar ett meddelande, juridik granskar det och verkställande direktören godkänner det före utskick.

SME Incidenthanteringspolicy Incidenthanteringspolicy - SME anger:

Verkställande chef (GM) är ansvarig för att godkänna alla beslut om incidenteskalering, regulatoriska anmälningar och extern kommunikation.

För större organisationer fastställer företagsversionen av Incidenthanteringspolicy Incidenthanteringspolicy baslinjen för underlag:

Alla incidenter ska registreras i system för hantering av säkerhetsincidenter (SIMS), inklusive:

När hotinformation blir en incident, kundvarning, myndighetsanmälan eller externt säkerhetsmeddelande får den inte enbart finnas i inkorgar och chattrådar. Den hör hemma i incidenthanteringssystemet med klassificering, åtgärder, godkännanden, bevismaterial och erfarenhetsåterföring.

GDPR-säkert utlämnande: dela hotinformation, inte onödiga personuppgifter

GDPR tillåter säkerhetsarbete, men skapar inte en frizon för okontrollerad delning av telemetri. Många artefakter inom hotinformation kan innehålla personuppgifter:

• IP-adresser kopplade till användaraktivitet.
• E-postadresser som används i nätfiskeförsök.
• Användarnamn, enhetsnamn, slutpunkts-ID:n eller kunders tenant-ID:n.
• Autentiseringsloggar.
• Supportärenden.
• Skärmdumpar.
• Anteckningar från bedrägeriutredningar.
• Prover på skadlig kod som innehåller dokument eller personliga filer.
• Sårbarhetsrapporter som omfattar exponering av kunddata.

I Clarysecs modell passerar varje beslut om utgående delning genom ett filter för integritet och konfidentialitet.

I Zenith Controls mappas ISO/IEC 27002:2022 kontroll 5.34, integritet och skydd av PII, som förebyggande och kopplad till klassificering, tillgångsförteckning, datamaskering, molnsäkerhet, informationsöverföring, åtkomstkontroll, identitetshantering och projekt- eller ändringsgranskning. Den mappas även till GDPR Articles 25 och 32 genom inbyggt dataskydd, säkerhet i behandlingen, kryptering, pseudonymisering, åtkomstkontroll och verifierbar styrning. Stödjande standarder omfattar ISO/IEC 27701:2021 för ledningssystem för integritetsinformation, ISO/IEC 27018:2019 för skydd av PII i publika molnmiljöer för personuppgiftsbiträden och ISO/IEC 29100:2011 för integritetsprinciper.

För delning av hotinformation bör DPO och säkerhetsteamet inte mötas för första gången under en kris. De bör förhandsgodkänna mönster, mallar, maskeringsregler och eskaleringströsklar.

Praktiskt exempel: ett ISAC-larm blir evidensbaserad resiliens

Återvänd till Marias betalplattform. ISAC-säkerhetsmeddelandet innehåller skadliga domäner, misstänkta OAuth-applikationsnamn, User-Agent-strängar och en notering om att flera medlemmar har observerat försök till kontoövertagande mot användare inom ekonomifunktioner. Företaget hittar också tre misstänkta inloggningsförsök i sina egna loggar.

Så här skulle Clarysec operationalisera responsen med ISO/IEC 27001:2022, Zenith Blueprint, Zenith Controls och policyverktygslådan.

Det utgående meddelandet innehåller ursprungligen tidsstämplar, käll-IP-adresser, målanvändarnamn, kunders tenant-ID:n och skärmdumpar. Efter granskning av DPO och juridik reduceras det till:

• Tidsfönster i UTC.
• Angreppsmönster.
• Observerad skadlig domän.
• Generell berörd rolltyp, till exempel användare inom ekonomifunktioner.
• Inga användarnamn.
• Inga kunders tenant-ID:n.
• Inga skärmdumpar.
• Inga kundnamn.
• Inga råa loggar om de inte begärs via en kontrollerad kanal.

Om aktiviteten blir en incident tar kontrollerna i Incidenthanteringspolicy över. Om forensiska artefakter samlas in gäller Policy för bevisinsamling och forensik-sme Policy för bevisinsamling och forensik - SME:

Varje enskild digital bevisning ska loggas med:

Policyn fortsätter internt med metadatakrav för bevisning, men revisionsprincipen är tydlig: varje artefakt som används för utredning, delning, rapportering till tillsynsmyndighet eller kundkommunikation behöver spårbarhet.

Sårbarhetsrapportering är inte samma sak som delning av hotinformation

Ett vanligt misstag är att behandla sårbarhetsrapportering, incidentanmälan och delning av hotinformation som samma process. De överlappar, men de är inte identiska.

Delning av hotinformation kan omfatta indikatorer, taktiker, branschvarningar, motståndarbeteende, riskreducerande åtgärder eller observerade försök. Samordnad sårbarhetsrapportering avser en specifik svaghet i en produkt eller tjänst, ofta med en rapportör, tidsplan för åtgärd, säkerhetsmeddelande och beslut om offentligt offentliggörande. Incidentanmälan avser regulatorisk eller avtalsmässig rapportering om en händelse som påverkar tjänster, data eller kunder.

Clarysec separerar dessa arbetsflöden men håller dem samman genom ISMS. Företagsversionen av Policy för samordnad sårbarhetsrapportering Policy för samordnad sårbarhetsrapportering anger:

Samordning och offentliggörande: Organisationen ska samordna offentligt offentliggörande med rapportören. Som standard får inga sårbarhetsdetaljer offentliggöras förrän en korrigering eller riskreducerande åtgärd finns tillgänglig eller åtminstone pågår. För kritiska frågor där en korrigering inte kan levereras snabbt får organisationen utfärda ett säkerhetsmeddelande med vägledning om alternativa åtgärder för att varna användare, i samråd med relevanta myndigheter där så krävs. Rapportören förväntas avstå från offentligt offentliggörande tills organisationen lämnar klartecken eller publicerar ett säkerhetsmeddelande. Som huvudregel strävar organisationen efter att publicera ett säkerhetsmeddelande inom 90 dagar från mottagandet av rapporten, eller inom en annan ömsesidigt överenskommen tidsram, i linje med bästa branschpraxis, inklusive erkännande av rapportören där samtycke har lämnats.

Samma policy anger också:

Konfidentialitet: Fram till offentligt offentliggörande ska all information som rör en rapporterad sårbarhet behandlas som Mycket konfidentiell. Detaljer ska endast delas internt enligt Need-to-know-principen med personal som behöver validera eller åtgärda problemet. Rapportörens identitet ska hållas konfidentiell där detta begärs. All kommunikation med rapportören bör vara krypterad, inklusive genom användning av organisationens PGP-nyckel, för att skydda känsliga sårbarhetsdetaljer.

Detta är avgörande för DORA Article 45 och NIS2-samverkan. Ett betrott samverkansforum kan vara rätt plats för att dela riskreducerande åtgärder eller övergripande indikatorer, men inte nödvändigtvis exploitdetaljer, kundspecifika data eller information om opatchade sårbarheter.

Extern kommunikation kräver samma disciplin. Företagsversionen av Policy för sociala medier och extern kommunikation Policy för sociala medier och extern kommunikation tilldelar granskningsansvar för innehåll för att säkerställa efterlevnad av lagar som reglerar konfidentialitet, insiderinformation, immateriella rättigheter och förtal. Det är viktigt när ett tekniskt säkerhetsmeddelande blir ett offentligt uttalande, kundmeddelande, webbplatsuppdatering eller meddelande till tillsynsmyndighet.

Kartläggning mellan regelverk: ett arbetsflöde, många skyldigheter

Ett starkt arbetsflöde för delning av cyberhotinformation bör uppfylla flera ramverk utan att skapa dubbla processer.

NIST CSF 2.0 är användbart som ett neutralt organiserande lager eftersom dess GOVERN-funktion behandlar intressenter, rättsliga skyldigheter, beroenden, riskaptit, roller, policyer och tillsyn. Funktionerna DETECT och RESPOND förutsätter övervakning, integrering av hotinformation, incidentdeklaration, bevarande av bevismaterial, avisering och extern kommunikation.

COBIT 2019 tillför ledningens ansvarsskyldighet. Praxis som DSS05.04 Hantera säkerhetshot, APO12 Hantera risk, MEA03 Hanterad efterlevnad av externa krav och APO13 Hanterad säkerhet hjälper revisorer att testa om hotinformation förbättrar kontrollprestanda och styrningsrapportering.

Hur revisorer kommer att testa ert delningsprogram

En ISO/IEC 27001:2022-revisor börjar med ledningssystemet. Revisorn frågar hur rättsliga, regulatoriska, avtalsmässiga och intressentrelaterade krav identifierades enligt klausulerna 4.1 och 4.2. Revisorn kontrollerar om delning av hotinformation ingår i omfattningen, om riskerna har bedömts, om kontrollerna 5.6, 5.7, 5.31, 5.34, 5.24, 5.28, 8.8, 8.15 och 8.16 är inkluderade eller motiverade i tillämpbarhetsförklaring, och om underlag visar att processen fungerade som planerat.

En DORA-inriktad revisor eller tillsynsmyndighet söker efter styrning, styrelsens ansvarsskyldighet, integrering med IKT-risk, incidentklassificering, resiliensövningar, tredjepartsimplikationer och villkoren i Article 45. De frågar om deltagande i informationsdelningsarrangemang är dokumenterat, om känsliga data och personuppgifter skyddas, om hotinformation uppdaterar ramverket för IKT-riskhantering och om den påverkar testscenarier.

En NIS2-inriktad granskare fokuserar på styrelsens tillsyn, åtgärder enligt Article 21, incidenthantering, leverantörsberoenden, sårbarhetshantering, kommunikation med kunder eller tjänstemottagare samt samverkan med CSIRT:er eller behöriga myndigheter. Granskaren testar om hotinformation är kopplad till bedömning av betydande incidenter och stegvis rapportering.

En integritetsrevisor fokuserar på GDPR-principer. Revisorn frågar om delade data var personuppgifter, vilken rättslig grund som tillämpades, om uppgiftsminimering genomfördes, om pseudonymisering eller maskering var möjlig, om bevarande styrdes och om organisationen kan visa ansvarsskyldighet.

Bra underlag omfattar:

• Godkänt ISAC- eller SIG-register.
• Namngivna deltagare och ersättare.
• Medlemsvillkor och sekretesskyldigheter.
• Mottagningslogg för hotinformation.
• Triagerings- och relevansbedömningar.
• Ärenden för utveckling av detekteringar.
• Ändringar i sårbarhetsprioritering.
• Eskaleringar av leverantörsrisker.
• Poster över godkännanden för utlämnande.
• Anteckningar från DPO- eller integritetsgranskning.
• Maskerade utgående meddelanden.
• Incidentposter i SIMS.
• Loggar över beviskedjan.
• Protokoll från ledningens genomgång.
• Internrevisionsiakttagelser och korrigerande åtgärder.

Vanliga fallgropar som Clarysec ser i praktiken

Det vanligaste felet är informellt deltagande. En säkerhetsingenjör går med i ett privat forum, tar emot användbar hotinformation och delar interna observationer utan formellt godkännande. Avsikten är god, men revisionsspåret är svagt och konfidentialitetsrisken är hög.

Det andra felet är passiv konsumtion. Organisationen prenumererar på flöden, deltar i ISAC-samtal och vidarebefordrar säkerhetsmeddelanden, men ingen kan visa hur hotinformationen förändrade kontrollerna. Hotinformation måste uppdatera detekteringslogik, patchprioriteringar, åtgärdsplaner, riskregister, leverantörsgranskningar, medvetenhetskampanjer eller resiliensövningar.

Det tredje felet är delning av råa loggar. Team skickar skärmdumpar, SIEM-exporter, e-posthuvuden eller paketfångster externt utan uppgiftsminimering. Detta kan exponera personuppgifter, kundidentifierare, interna värdnamn, token eller konfidentiell arkitektur.

Det fjärde felet är att blanda ihop PR med reglerad kommunikation. Ett LinkedIn-inlägg om en angreppstrend är inte samma sak som en kundvarning, myndighetsanmälan, CSIRT-uppdatering eller samordnat säkerhetsmeddelande. Clarysec separerar dessa kanaler, tilldelar godkännandeägare och kräver poster.

Det femte felet är att ignorera leverantörer. Många larm från hotinformation gäller tredjepartsprogramvara, molnplattformar, leverantörer av hanterade tjänster eller identitetsintegrationer. Enligt DORA, NIS2, NIST CSF, COBIT 2019 och leverantörskontrollerna i ISO/IEC 27002:2022 måste hotinformation mata in i leverantörsriskhanteringen.

Bygg ert paket för delning av hotinformation 2026

De flesta organisationer behöver ingen tung fristående byråkrati. De behöver ett kompakt styrningspaket som fungerar under en verklig incident. Clarysec rekommenderar:

• Rutin för delning av hotinformation.
• Register över godkända samverkansforum för delning.
• Formulär för mottagning och triagering av hotinformation.
• Formulär för godkännande av utgående utlämnande.
• Checklista för integritets- och konfidentialitetsgranskning.
• Extern kommunikationsmatris.
• Mall för sammanfattning av ISAC-möte.
• Regler för koppling mellan bevismaterial och incidenter.
• Mätetalspanel.
• Testplan för internrevision.

Rutinen bör hänvisa till klausulerna i ISO/IEC 27001:2022 om riskhantering, kommunikation, operativ styrning, utvärdering av prestanda, internrevision och ständig förbättring. Den bör mappas till ISO/IEC 27002:2022-kontrollerna 5.6, 5.7, 5.31, 5.34, 5.24, 5.28, 8.8, 8.15, 8.16 och relevanta leverantörskontroller. Den bör även hänvisa till DORA Article 45, NIS2-samverkan och skyldigheter för incidentkommunikation samt GDPR-principerna.

Framför allt måste den kunna användas under press. Om processen kräver ett möte med 12 personer innan en skadlig domän delas med en betrodd ISAC kommer den att misslyckas. Om den tillåter att råa kundloggar klistras in i en samverkansportal kommer den också att misslyckas. Målet är kontrollerad snabbhet.

Gör delning av hotinformation till evidensbaserad resiliens

Delning av cyberhotinformation under 2026 är inte bara ett märke på säkerhetsmognad. För finansiella entiteter är den kopplad till DORA Article 45 och digital operativ resiliens. För väsentliga och viktiga entiteter stödjer den NIS2-samverkan, incidenthantering, sårbarhetsrespons, leverantörssäkerhet och varning till tjänstemottagare. För varje organisation som behandlar personuppgifter i EU måste den vara GDPR-säker genom design.

Clarysec hjälper organisationer att bygga denna operativa modell utan att bromsa försvararna. Vi kopplar samman Zenith Blueprint Zenith Blueprint, policyverktygslådan och Zenith Controls Zenith Controls till en fungerande ISMS-process: godkända samverkansforum, tydliga roller, integritetssäkert utlämnande, incidentkoppling, bevisposter, revisionsberedskap och kartläggning mellan ramverk.

Om er organisation deltar i en ISAC, tar emot cybersäkerhetsmeddelanden, delar indikatorer med branschkollegor, rapporterar till myndigheter eller hanterar sårbarhetsrapportering är det dags att formalisera arbetsflödet. Börja med en entimmes granskning av era nuvarande delningsarrangemang och mappa dem sedan till ISO/IEC 27001:2022, DORA Article 45, NIS2 och GDPR.

Clarysec kan hjälpa er att bygga det register, de policyklausuler, godkännandemallar, den modell för revisionsbevis och det rapporteringspaket till ledningen som behövs för att göra delning av cyberhotinformation snabb, laglig och försvarbar.