Kryptografisk nyckelhantering för ISO 27001, NIS2 och DORA

Klockan 08.17 en måndagsmorgon får informationssäkerhetschefen på ett europeiskt SaaS-företag ett meddelande från utvecklingschefen: ”Vi roterade databasens krypteringsnyckel under helgen, men en integration slutade dekryptera poster. Vi rullade tillbaka med en gammal nyckel från valvet.”

Tio minuter senare frågar dataskyddsombudet om de berörda posterna innehåller personuppgifter från EU. Ekonomifunktionen frågar om detta kan bli en rapporteringspliktig operativ incident för en reglerad kund. Upphandling frågar om molnleverantören eller företaget äger den kundhanterade nyckeln. VD:n ställer den enda fråga som spelar roll i styrelserummet: ”Kan vi visa att vi hanterade detta korrekt?”

Det är då ”vi använder kryptering” slutar vara en trygg formulering och blir en fråga om dokumenterat underlag.

År 2026 ligger kryptografisk nyckelhantering i skärningspunkten mellan kontroller i ISO/IEC 27001:2022, cyberhygien enligt NIS2, IKT-riskhantering enligt DORA, underlag för säkerhet i behandlingen enligt GDPR Article 32, delat ansvar i molnet och planering för postkvantumrelaterad kryptoagilitet. Den verkliga frågan är inte om kryptering finns. Den verkliga frågan är om organisationen genom dokumenterade poster kan visa att nycklar genereras säkert, tilldelas ägare, lagras i godkända KMS- eller HSM-miljöer, roteras enligt schema, återställs säkert, återkallas vid kompromettering och mappas mot verksamhetsrisk.

Clarysec ser samma mönster återkommande i arbete med revisionsberedskap. Kryptering införs system för system, men styrningen av nycklar är fragmenterad. Certifikat ligger i kalkylark. Behörigheter i molnbaserad KMS ärvs från gamla projekt. Utvecklare vet vilka hemligheter som är viktiga, men ledningssystemet för informationssäkerhet gör det inte. Revisorer får skärmdumpar i stället för livscykelbaserat underlag. NIS2- och DORA-team talar om resiliens, dataskyddsteam talar om kryptering och pseudonymisering enligt GDPR, och ingen äger hela det kryptografiska kontrollplanet från början till slut.

Ett moget svar är inte mer kryptografi isolerat. Det är styrd kryptografisk nyckelhantering kopplad till riskbehandling, molnarkitektur, leverantörsstyrning, åtkomstkontroll, loggning, incidentrespons och regulatoriskt underlag.

Varför nyckelhantering nu är en styrningsfråga

NIS2 gör policyer för kryptografi och kryptering till en del av minimikraven för åtgärder för hantering av cybersäkerhetsrisker för väsentliga och viktiga entiteter. Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, incidenthantering, kontinuitet, säkerhet i leveranskedjan, säker utveckling, cyberhygien, åtkomstkontroll, policy för tillgångshantering samt policyer för kryptografi och kryptering. Artikeln kräver också att ledningsorgan godkänner och utövar tillsyn över åtgärderna för hantering av cybersäkerhetsrisker.

För SaaS-, moln-, managed service- och cybersäkerhetsleverantörer kan tillämpligheten vara bredare än många team antar. NIS2 omfattar sektorer som digital infrastruktur, leverantörer av molntjänster, datacenterleverantörer, DNS-leverantörer, betrodda tjänsteleverantörer, hanterade tjänsteleverantörer (MSP:er), hanterade säkerhetstjänsteleverantörer, nätbaserade marknadsplatser, sökmotorer och sociala nätverksplattformar när tröskelvärden för storlek eller kritikalitet är uppfyllda.

DORA höjer ribban för finansiella entiteter. Från den 17 januari 2025 kräver DORA ett dokumenterat ramverk för IKT-riskhantering, styrelsens ansvarsskyldighet, IKT-verksamhetskontinuitet samt respons- och återställningsplaner, testning av digital operativ resiliens, riskhantering för IKT-tredjepart och incidentrapportering. För finansiella entiteter som identifieras enligt nationella NIS2-regler fungerar DORA som unionsrättsakt med sektorsspecifika regler för motsvarande NIS2-skyldigheter. Ett fintechbolag bör inte driva separata kryptografiska styrmodeller för NIS2, DORA och ISO. Det behöver en och samma försvarbara kontrollmodell.

GDPR tillför dimensionen dataskyddsunderlag. GDPR Article 32 är den punkt där kryptering ofta bedöms som skyddsåtgärd för säkerhet i behandlingen, men ”data är krypterade” är inte ett fullständigt svar. Tillsynsmyndigheter och revisorer frågar vem som kontrollerar nycklarna, hur åtkomst begränsas, hur kompromettering upptäcks, hur återställning fungerar och om utformningen motsvarar risken för enskilda personer.

ISO/IEC 27001:2022 ger organisationer ledningssystemet för att knyta samman dessa skyldigheter. Klausulerna 4.1 till 4.4 kräver kontext, intressenters krav, ISMS-omfattning och samverkande processer. Klausulerna 5.1 till 5.3 kräver ledarskap, policy, resurser och tilldelade ansvarsområden. Klausulerna 6.1.1 till 6.1.3 kräver riskbedömning, riskbehandling, urval av kontroller, en tillämpbarhetsförklaring och godkännande från riskägare. Klausulerna 8.1 till 8.3 kräver styrd drift, förnyad riskbedömning när ändringar sker, genomförande av riskbehandlingsplaner och bevarande av dokumenterade resultat.

För kryptografisk nyckelhantering måste ISMS kunna besvara fem frågor:

1. Vilka informationstillgångar, dataflöden och tjänster kräver kryptografiskt skydd?
2. Vilka nycklar, certifikat, hemligheter och kryptotjänster skyddar dem?
3. Vem äger, administrerar, godkänner och övervakar dessa kryptografiska tillgångar?
4. Hur styrs generering, lagring, användning, rotation, escrow, återställning, återkallelse och destruktion?
5. Vilket underlag visar att kontrollerna fungerade som avsett?

ISO 27001-kontrollkedjan för kryptografisk nyckelhantering

Clarysec behandlar kryptografisk nyckelhantering som en kontrollkedja, inte som en enskild kontroll. I Zenith Controls: den tvärgående efterlevnadsguiden Zenith Controls mappas området främst mot ISO/IEC 27002:2022 kontroll 8.24, användning av kryptografi, med viktiga stödjande relationer till 5.17, autentiseringsinformation, och 5.23, informationssäkerhet vid användning av molntjänster.

Den relationen är viktig. Ett fel i nyckelhantering är sällan bara ”dålig kryptering”. Det är ofta ett autentiseringsproblem, ett problem i molnstyrning, ett leverantörsproblem, en loggningslucka eller ett fel i ändringshanteringen.

Zenith Blueprint: en 30-stegs färdplan för revisorer Zenith Blueprint gör detta operativt i riskhanteringsfasen, steg 14, riskbehandlingspolicyer och regulatoriska korsreferenser. Exemplet på kryptografipolicy anger att organisationen ska definiera var kryptografi behövs, godkänna algoritmer och protokoll, definiera nyckelhantering, täcka användningsfall som heldiskkryptering och säker kommunikation samt koppla policyn till GDPR Article 32.

”Krypteringsnycklar måste lagras säkert (t.ex. i ett nyckelvalv/HSM) och åtkomst begränsas till behörig personal.”
Källa: Zenith Blueprint, riskhanteringsfasen, steg 14, riskbehandlingspolicyer och regulatoriska korsreferenser Zenith Blueprint

I fasen Kontroller i praktiken, steg 20, går Zenith Blueprint djupare. Kryptografi handlar inte om att ”slå på kryptering”. Det handlar om att bygga in kryptografi i design, policy och livscykelhantering. Det omfattar data i vila, data under överföring, autentisering av identiteter och transaktioner, godkända algoritmer, nyckelvalv, HSM, schemalagd rotation, återkallelse och validering genom penetrationstestning och kodgranskning.

Vad revisorer förväntar sig när de begär nyckelunderlag

De flesta revisionsiakttagelser börjar med en enkel begäran: ”Visa er krypteringspolicy och era poster för nyckelhantering.”

Svaga svar är till exempel:

• ”Molnleverantören krypterar allt som standard.”
• ”Vi använder TLS.”
• ”Hemligheter finns i valvet.”
• ”Utvecklingsteamet hanterar rotation.”
• ”Nyckeln hanteras av applikationen.”

Sådana uttalanden kan vara tekniskt korrekta, men de är inte fullständigt underlag. En ISO-revisor kopplar nyckelhantering tillbaka till riskbedömning, tillämpbarhetsförklaring, policykrav, operativ styrning och bevarad dokumentation. En NIST CSF-bedömare frågar om kryptografiska tillgångar är identifierade, skyddade, övervakade och återställningsbara. En DORA-revisor söker efter styrelsegodkänd IKT-riskstyrning, tredjepartsberoenden, incidenthantering och resiliensövningar. En GDPR-granskare frågar om kryptering och nyckelseparering minskar risken för enskilda personer och om den personuppgiftsansvarige kan visa ansvarsskyldighet.

Clarysecs Enterprise Policy för kryptografiska kontroller Policy för kryptografiska kontroller adresserar underlagsgapet direkt:

”Ett centralt register för nyckelhantering måste upprätthållas för att registrera alla kryptografiska nycklar, deras livscykelstatus, tilldelade förvaltare och användningskontexter.”
Källa: Enterprise Policy, Policy för kryptografiska kontroller, Styrningskrav, klausul 5.2 Policy för kryptografiska kontroller

Den meningen förändrar revisionsdialogen. I stället för att jaga muntlig kunskap kan organisationen visa ett register som kopplar nycklar till tillgångar, ägare, dataklassificeringar, system, molnkonton, rotationsdatum, användningskontexter och underlag.

För små och medelstora företag skalar Clarysecs Cryptographic Controls Policy-sme Cryptographic Controls Policy-sme - SME samma förväntan:

”IT-supportleverantören måste upprätthålla en aktuell förteckning över kryptografiska verktyg och certifikat som används”
Källa: SME Policy, Cryptographic Controls Policy-sme, Styrningskrav, klausul 5.1.2 Cryptographic Controls Policy-sme - SME

Ett reglerat finansinstitut kan behöva HSM-ceremonier, split knowledge, dubbel kontroll, formella utnämningar av förvaltare och kvartalsvisa åtkomstgranskningar. En mindre SaaS-leverantör kan börja med en underhållen förteckning, godkända algoritmer, dokumenterat KMS-ägarskap och rotationsunderlag. Båda behöver styrning som står i proportion till risken.

Nyckellivscykeln som ditt ISMS ska styra

Ett praktiskt program för nyckelhantering följer livscykeln. Varje steg behöver en ägare, en godkänd metod, en teknisk kontroll, en ändringspost och revisionsbevis.

Enterprise Policy för kryptografiska kontroller stärker kraven på säker generering:

”Nyckelgenerering: utförs med säkra hårdvaru- eller programvarumoduler (t.ex. HSM, FIPS 140-2-validerade system).”
Källa: Enterprise Policy, Policy för kryptografiska kontroller, Krav för genomförande av policyn, klausul 6.3.1 Policy för kryptografiska kontroller

Den anger också rotation:

”Nyckelrotation: krävs vid definierade intervall eller omedelbart vid kompromettering eller rolländring.”
Källa: Enterprise Policy, Policy för kryptografiska kontroller, Krav för genomförande av policyn, klausul 6.3.4 Policy för kryptografiska kontroller

För små och medelstora företag uttrycks samma princip på enklare driftsspråk:

”Nyckelrotation måste ske enligt utgångsscheman eller vid misstänkt kompromettering”
Källa: SME Policy, Cryptographic Controls Policy-sme, Krav för genomförande av policyn, klausul 6.3.4 Cryptographic Controls Policy-sme - SME

Dessa klausuler är viktiga för NIS2 och DORA eftersom inaktuella eller bristfälligt styrda nycklar inte bara är svagheter i konfidentialitet. De kan bli hinder för incidentrespons, problem med leverantörsberoenden, fel i katastrofåterställning och problem med kundaviseringar.

Molnbaserad KMS, HSM och BYOK: fällan med delat ansvar

Molnkryptering är en av de vanligaste källorna till falsk trygghet. En molnleverantör kan kryptera lagring som standard, men det betyder inte automatiskt att din organisation har styrt nyckeln.

Zenith Blueprint, fasen Kontroller i praktiken, steg 23, förklarar ISO/IEC 27002:2022 kontroll 5.23 genom att fokusera på molnstyrning, insyn och delat ansvar. Den betonar att leverantören kan säkra infrastrukturen, men att kunden fortfarande ansvarar för data, konfigurationer, åtkomstpolicyer och beredskap för incidentrespons.

”Molnleverantörer säkrar infrastrukturen, men ni ansvarar fortfarande för era data, era konfigurationer, era åtkomstpolicyer och er beredskap för incidentrespons.”
Källa: Zenith Blueprint, fasen Kontroller i praktiken, steg 23, organisatoriska kontroller 5.19-5.37 Zenith Blueprint

Det är här ansvar för molnnycklar blir en risk på styrelsenivå. Ett SaaS-företag kan använda leverantörshanterad kryptering för lågriskloggar, kundhanterade nycklar för kunddatabaser, BYOK för reglerade tenants och HSM-stödda rotnycklar för signering eller tokenisering. Varje val har konsekvenser för efterlevnad.

Clarysecs Enterprise Policy för användning av molntjänster Policy för användning av molntjänster ger tydlig kontrollriktning:

”Kundhanterade nycklar (CMK) eller Bring Your Own Key (BYOK) ska användas där detta stöds av molnleverantören.”
Källa: Enterprise Policy, Policy för användning av molntjänster, Krav för genomförande av policyn, klausul 6.4.2 Policy för användning av molntjänster

Det betyder inte att varje molntjänst måste använda BYOK. Det betyder att organisationen ska fatta ett medvetet beslut utifrån risk, kundåtaganden, avtalskrav och återställningsförmåga.

DORA Article 28 och Article 30 gör detta särskilt relevant för finansiella entiteter. De kräver riskhantering för IKT-tredjepart, register över IKT-avtalsarrangemang, leverantörsgranskning, revisions- och inspektionsrättigheter, incidentstöd, dataskydd och åtkomst samt bestämmelser om återställning och återlämnande. Om en molnleverantör eller SaaS-leverantör hanterar krypteringsnycklar för en kritisk eller viktig funktion måste relationen synas i tredjepartsregistret för IKT och i avtalsmässiga kontroller.

NIS2 kräver också säkerhet i leveranskedjan, inklusive leverantörsspecifika sårbarheter, cybersäkerhetspraxis och rutiner för säker utveckling. Om en kritisk leverantör håller era nycklar, driver er KMS, tillhandahåller er HSM, hanterar er certifikatlivscykel eller driftar krypterade säkerhetskopior är leverantören en del av er kryptografiska kontrollmiljö.

Algoritmgodkännande och kryptoagilitet under 2026

En policy för nyckelhantering år 2026 bör inte bara lista ”AES-256” och ”TLS 1.2 eller senare”. Den bör etablera en godkännande- och granskningsprocess som stödjer kryptoagilitet. Kryptoagilitet innebär att organisationen kan identifiera var algoritmer, protokoll, certifikat och nyckellängder används, bedöma exponering för svagheter eller utfasning och migrera utan panik.

Clarysecs SME-policy anger:

”Endast algoritmer och protokoll enligt bästa branschpraxis som godkänts av IT-supportleverantören får användas (t.ex. AES-256, RSA 2048, TLS 1.2 eller senare)”
Källa: SME Policy, Cryptographic Controls Policy-sme, Krav för genomförande av policyn, klausul 6.2.1 Cryptographic Controls Policy-sme - SME

Den kräver också dokumentation:

”Alla krypteringsmetoder (t.ex. AES-256, TLS 1.2+) och nyckelhanteringsprocesser måste dokumenteras”
Källa: SME Policy, Cryptographic Controls Policy-sme, Styrningskrav, klausul 5.3.1 Cryptographic Controls Policy-sme - SME

Den revisionsklara versionen är en godkänd kryptografisk standard med:

• Tillåtna algoritmer och protokoll för data i vila, data under överföring, signaturer, lösenordshashning, tokenisering och säkerhetskopior.
• Otillåtna algoritmer, protokoll och bibliotek.
• Minsta nyckellängder och giltighetstider för certifikat.
• Godkända KMS-, HSM-, certifikatutfärdar- och plattformar för hemlighetshantering.
• Krav på säker generering av slumptal.
• Utvecklarvägledning för kryptografiska bibliotek.
• Undantagsprocess för äldre system.
• Granskningsutlösare för sårbarheter, regulatoriska ändringar, leverantörsändringar och planering för postkvantumövergång.

Postkvantumplanering kräver inte att varje organisation ersätter all kryptografi omedelbart. Den kräver inventering. Utan en kryptografisk inventering kan ni inte veta vilka system som använder långlivad kryptering med publika nycklar, vilka certifikat som skyddar kritiska tjänster, var signeringsnycklar finns eller vilka leverantörer som måste stödja migrering. Registret för nyckelhantering är inte byråkrati. Det är grunden för kryptoagilitet.

En 90-minuters underlagssprint för nyckelhantering

Clarysec använder ofta en kort underlagssprint med ledning, säkerhet, molnteam och regelefterlevnadsfunktioner. Målet är att snabbt omvandla spridd nyckelkunskap till revisionsbevis.

Steg 1: Välj en kritisk tjänst

Välj ett system som är relevant för NIS2, DORA eller GDPR. Exempel är kundidentitet, betalningshantering, transaktionsövervakning, produktionsdatabas för kunder, krypterad säkerhetskopieringsplattform eller kundvänt API.

Steg 2: Öppna registret för nyckelhantering

Använd kravet i Policy för kryptografiska kontroller på ett centralt register som struktur. Om ni inte redan har ett, skapa ett enkelt register med följande fält:

Steg 3: Spåra åtkomst och dubbel kontroll

För kryptografiska operationer med hög påverkan ska dubbel kontroll och principen om minsta privilegium tillämpas. Enterprise Policy för kryptografiska kontroller anger:

”Principerna om dubbel kontroll och minsta privilegium måste tillämpas på känsliga kryptografiska operationer (t.ex. import av rotnycklar, HSM-administration).”
Källa: Enterprise Policy, Policy för kryptografiska kontroller, Krav för genomförande av policyn, klausul 6.6.2 Policy för kryptografiska kontroller

Fråga:

• Vem kan inaktivera eller radera nyckeln?
• Vem kan ändra nyckelpolicyn?
• Vem kan dekryptera data direkt?
• Övervakas break-glass-roller och är de tidsbegränsade?
• Krävs MFA för privilegierade nyckeloperationer?
• Loggas och granskas privilegierade åtgärder?

Steg 4: Hämta fem underlagsposter

Samla fem poster som visar att kontrollen fungerar:

1. Logg för skapande eller import av nyckel.
2. Aktuell åtkomstpolicy för KMS eller HSM.
3. Senaste ändringsärendet för nyckelrotation.
4. SIEM-fråga som visar nyckelanvändning eller administrativa åtgärder.
5. Underlag från återställnings- eller restore-test.

Steg 5: Mappa mot risk och reglering

Lägg till en kort riskbeskrivning: ”Obehörig användning eller förlust av denna nyckel kan exponera EU-personuppgifter, störa kundtjänster och försämra återställningen av kritiska system.” Mappa den sedan mot relevanta skyldigheter.

På 90 minuter kan teamet normalt avgöra om nyckelstyrningen är verklig eller bara antagen.

Incidentrapportering: när nyckelkompromettering startar klockan

En misstänkt nyckelkompromettering är inte automatiskt en rapporteringspliktig incident, men den kan starta den regulatoriska klockan.

Enligt NIS2 måste väsentliga och viktiga entiteter utan onödigt dröjsmål anmäla betydande incidenter som påverkar tillhandahållandet av tjänster. Den stegvisa modellen omfattar en tidig varning inom 24 timmar från kännedom, en incidentanmälan inom 72 timmar, statusuppdateringar där sådana begärs och en slutrapport senast en månad efter incidentanmälan.

Enligt DORA måste finansiella entiteter upptäcka, hantera och anmäla IKT-relaterade incidenter, registrera incidenter och betydande cyberhot, klassificera incidenter efter allvarlighetsgrad och berörd tjänstekritikalitet, kommunicera med intressenter, rapportera större incidenter till högsta ledningen och behöriga myndigheter, genomföra rotorsaksanalys och vidta åtgärder. Utlagd rapportering kan vara möjlig, men ansvaret ligger kvar hos den finansiella entiteten.

Enligt GDPR blir frågan om en personuppgiftsincident har inträffat, det vill säga oavsiktlig eller olaglig förstöring, förlust eller ändring, obehörigt röjande av eller obehörig åtkomst till personuppgifter. Stark kryptering med okomprometterade nycklar kan väsentligt förändra riskanalysen vid incident. Svag nyckelhantering kan underminera det argumentet.

Åtgärdsplaner för nyckelkompromettering bör definiera:

• Hur misstänkt exponering av nycklar upptäcks.
• Vem som deklarerar en kryptografisk incident.
• Hur berörda data, tjänster, kunder och jurisdiktioner identifieras.
• Hur nycklar återkallas eller roteras.
• Hur beroende system återställs.
• Hur integriteten i underlaget bevaras.
• Hur beslut om juridisk, regulatorisk och kundrelaterad avisering fattas.

Registret för nyckelhantering blir avgörande under denna process. Utan det slösar incidenthanterare tid på att identifiera vad en nyckel skyddade. Med det kan de snabbt avgränsa påverkan.

Revisionsperspektivet: en kontrolluppsättning, många mottagare av underlag

Olika revisorer närmar sig kryptografisk nyckelhantering från olika bakgrunder, men de landar i samma underlag.

Ett starkt revisionspaket för kryptografisk nyckelhantering innehåller normalt:

• Godkänd Policy för kryptografiska kontroller.
• Godkänd Policy för användning av molntjänster där molnkryptering är relevant.
• Kryptografisk standard och algoritmlista.
• Register för nyckelhantering.
• Inventering av certifikat och hemligheter.
• KMS-, HSM- och valvarkitektur.
• Underlag från IAM- och privilegierade åtkomstgranskningar.
• Rotations- och återkallelseposter.
• Underlag från säkerhetskopiering, escrow och återställningstester.
• Regler för loggning och övervakning av nyckelaktivitet.
• Mappning av leverantörer och delat ansvar i molnet.
• Åtgärdsplan för misstänkt nyckelkompromettering.
• Undantag och riskacceptanser.
• Poster från ledningens genomgång och revisionsåtgärder.

Detta paket omvandlar ett kontrollpåstående till bevis.

Vanliga iakttagelser vid revisioner av nyckelhantering

De vanligaste iakttagelserna går att undvika:

1. Ingen samlad förteckning över nycklar, certifikat och kryptografiska verktyg.
2. Molnleverantörens standardkryptering behandlas som fullständig nyckelstyrning.
3. Ingen ägare eller förvaltare har tilldelats produktionsnycklar.
4. Rotation finns för certifikat, men inte för applikationsnycklar eller CMK:er för databaser.
5. Hemligheter och nycklar blandas i samma valv utan klassificering.
6. Utvecklare kan skapa nycklar utanför godkända mönster.
7. Det saknas underlag för att KMS-administratörer granskas.
8. Återställningsrutiner finns men har aldrig testats.
9. Nyckelkompromettering ingår inte i åtgärdsplaner för incidentrespons.
10. Äldre algoritmer finns kvar i interna tjänster eftersom ingen äger åtgärdandet.
11. BYOK-åtaganden görs i kundavtal men återspeglas inte i driften.
12. Leverantörshanterad kryptering ingår inte i granskningar av leverantörsrisk.

Varje iakttagelse pekar tillbaka på styrning. Därför kan kryptografi inte behandlas som ett rent utvecklingsprojekt. Den måste kopplas till ISMS-omfattning, riskbehandling, policy, leverantörer, moln, åtkomst, loggning, incidenter och kontinuitet.

Gör nyckelstyrningen redo för revision före nästa incident

Om din organisation förbereder sig för NIS2, DORA, underlag enligt GDPR Article 32, ISO/IEC 27001:2022-certifiering eller postkvantumrelaterad kryptoagilitet, börja med en fråga: kan ni ta fram ett komplett register för nyckelhantering i dag?

Om inte kan Clarysec hjälpa er att bygga kontrollsystemet runt det.

Använd Zenith Blueprint Zenith Blueprint för att strukturera arbetet genom riskhanteringsfasens steg 14 och fasen Kontroller i praktiken, steg 20. Använd Zenith Controls Zenith Controls för att mappa ISO/IEC 27002:2022 kontrollerna 8.24, 5.17 och 5.23 mot NIS2, DORA, GDPR, NIST och revisionsförväntningar. Använd Clarysecs Policy för kryptografiska kontroller Policy för kryptografiska kontroller, Cryptographic Controls Policy-sme Cryptographic Controls Policy-sme - SME och Policy för användning av molntjänster Policy för användning av molntjänster för att omvandla krav till operativa regler.

Nästa praktiska steg är enkelt: välj en kritisk tjänst, inventera dess nycklar, visa ägarskap, validera åtkomst, hämta rotationsunderlag och testa återställning. Om det tar mer än en dag behöver er kryptografiska styrning ses över innan tillsynsmyndigheten, revisorn eller incidenthanteringsteamet ställer samma fråga under press.