Styring af kryptografiske nøgler for ISO 27001, NIS2 og DORA

Kl. 08.17 en mandag morgen modtager CISO’en i en europæisk SaaS-virksomhed en besked fra udviklingschefen: “Vi roterede databasekrypteringsnøglen i weekenden, men én integration kunne derefter ikke dekryptere poster. Vi rullede tilbage med en gammel nøgle fra vaulten.”

Ti minutter senere spørger databeskyttelsesrådgiveren (DPO), om de berørte poster omfatter EU-personoplysninger. Økonomi spørger, om dette kan blive en rapporteringspligtig driftsmæssig hændelse for en reguleret kunde. Indkøb spørger, om det er cloududbyderen eller virksomheden, der ejer den kundeadministrerede nøgle. CEO’en stiller det eneste spørgsmål, der betyder noget i bestyrelseslokalet: “Kan vi dokumentere, at vi håndterede dette korrekt?”

Det er dér, “vi bruger kryptering” ophører med at være en beroligende formulering og bliver et dokumentationsproblem.

I 2026 ligger styring af kryptografiske nøgler i krydsfeltet mellem ISO/IEC 27001:2022-kontroller, NIS2-cyberhygiejne, DORA-styring af IKT-risiko, revisionsbevis for behandlingssikkerhed efter GDPR Article 32, delt ansvar i cloud og planlægning af post-kvantum crypto-agility. Det egentlige spørgsmål er ikke, om der findes kryptering. Det egentlige spørgsmål er, om organisationen med registreringer kan vise, at nøgler genereres sikkert, tildeles ejere, opbevares i godkendte KMS- eller HSM-miljøer, roteres efter plan, genoprettes sikkert, tilbagekaldes ved kompromittering og kortlægges til forretningsrisiko.

Clarysec ser det samme mønster igen og igen i arbejdet med revisionsberedskab. Kryptering implementeres system for system, men nøglestyringen er fragmenteret. Certifikater ligger i regneark. Cloud-KMS-rettigheder er nedarvet fra gamle projekter. Udviklere ved, hvilke hemmeligheder der er kritiske, men ISMS’et gør ikke. Revisorer modtager skærmbilleder i stedet for revisionsbevis for livscyklussen. NIS2- og DORA-teams taler om robusthed, databeskyttelsesteams taler om GDPR-kryptering og pseudonymisering, og ingen ejer det kryptografiske kontrolmiljø fra start til slut.

Et modent svar er ikke mere kryptografi isoleret set. Det er styret kryptografisk nøglestyring, koblet til risikobehandling, cloudarkitektur, leverandørtilsyn, adgangsstyring, logning, hændelseshåndtering og regulatorisk revisionsbevis.

Hvorfor nøglestyring nu er et ledelses- og governanceanliggende

NIS2 gør politikker for kryptografi og kryptering til en del af minimumsforanstaltningerne til styring af cybersikkerhedsrisici for væsentlige og vigtige enheder. Article 21 kræver passende og proportionale tekniske, operationelle og organisatoriske foranstaltninger, herunder risikoanalyse, håndtering af hændelser, kontinuitet, sikkerhed i forsyningskæden, sikker udvikling, cyberhygiejne, adgangsstyring, politik for aktivstyring samt politikker for kryptografi og kryptering. Den kræver også, at ledelsesorganer godkender og fører tilsyn med foranstaltninger til styring af cybersikkerhedsrisici.

For SaaS-, cloud-, managed service- og cybersikkerhedsudbydere kan anvendelsesområdet være bredere, end mange teams antager. NIS2 dækker sektorer som digital infrastruktur, cloud computing-tjenester, datacenterudbydere, DNS-udbydere, tillidstjenesteudbydere, managed service providers, managed security service providers, online markedspladser, søgemaskiner og sociale netværksplatforme, hvor tærskler for størrelse eller kritikalitet er opfyldt.

DORA hæver barren for finansielle enheder. Fra 17. januar 2025 kræver DORA en dokumenteret styringsramme for IKT-risikostyring, bestyrelsesansvar, IKT-forretningskontinuitet samt respons- og genopretningsplaner, test af digital operationel robusthed, styring af IKT-tredjepartsrisiko og rapportering af hændelser. For finansielle enheder, der er identificeret efter nationale NIS2-regler, fungerer DORA som den sektorspecifikke EU-retsakt for tilsvarende NIS2-forpligtelser. En fintech bør ikke drive separat kryptografisk styring for NIS2, DORA og ISO. Den har brug for én forsvarlig kontrolmodel.

GDPR tilføjer databeskyttelsens dokumentationsdimension. GDPR Article 32 er dér, hvor kryptering ofte vurderes som en sikkerhedsforanstaltning for behandlingssikkerhed, men “dataene er krypteret” er ikke et fuldstændigt svar. Tilsynsmyndigheder og revisorer spørger, hvem der kontrollerer nøglerne, hvordan adgangen er begrænset, hvordan kompromittering opdages, hvordan genopretning fungerer, og om designet matcher risikoen for fysiske personer.

ISO/IEC 27001:2022 giver organisationer ledelsessystemet til at binde disse forpligtelser sammen. Clauses 4.1 to 4.4 kræver kontekst, interessentkrav, ISMS-omfang og samvirkende processer. Clauses 5.1 to 5.3 kræver lederskab, politik, ressourcer og tildelte ansvarsområder. Clauses 6.1.1 to 6.1.3 kræver risikovurdering, risikobehandling, kontroludvælgelse, en anvendelseserklæring og godkendelse fra risikoejer. Clauses 8.1 to 8.3 kræver styret drift, fornyet risikovurdering ved ændringer, implementering af behandlingsplaner og opbevaring af dokumenterede resultater.

For styring af kryptografiske nøgler skal ISMS’et kunne besvare fem spørgsmål:

1. Hvilke informationsaktiver, dataflows og tjenester kræver kryptografisk beskyttelse?
2. Hvilke nøgler, certifikater, hemmeligheder og kryptografitjenester beskytter dem?
3. Hvem ejer, administrerer, godkender og overvåger disse kryptografiske aktiver?
4. Hvordan styres generering, opbevaring, brug, rotation, escrow, genopretning, tilbagekaldelse og destruktion?
5. Hvilket revisionsbevis dokumenterer, at kontrollerne fungerede som designet?

ISO 27001-kontrolkæden for styring af kryptografiske nøgler

Clarysec behandler styring af kryptografiske nøgler som en kontrolkæde, ikke som en enkelt kontrol. I Zenith Controls: vejledningen til tværgående efterlevelse Zenith Controls kortlægges emnet primært til ISO/IEC 27002:2022 kontrol 8.24, brug af kryptografi, med vigtige understøttende relationer til 5.17, autentifikationsoplysninger, og 5.23, informationssikkerhed ved brug af cloudtjenester.

Den relation er vigtig. Et svigt i nøglestyringen er sjældent blot “dårlig kryptering”. Det er ofte et autentifikationsproblem, et problem med cloudstyring, et leverandørproblem, et logningshul eller et svigt i ændringsstyring.

Zenith Blueprint: en revisors 30-trins køreplan Zenith Blueprint gør dette operationelt i risikostyringsfasen, trin 14, politikker for risikobehandling og regulatoriske krydshenvisninger. Eksemplet på kryptografipolitik angiver, at organisationen skal definere, hvor kryptografi er nødvendig, godkende algoritmer og protokoller, definere nøglestyring, dække use cases såsom fuld diskkryptering og sikker kommunikation samt koble politikken til GDPR Article 32.

“Krypteringsnøgler skal opbevares sikkert (f.eks. i en key vault/HSM), og adgang skal begrænses til autoriseret personale.”
Kilde: Zenith Blueprint, risikostyringsfasen, trin 14, politikker for risikobehandling og regulatoriske krydshenvisninger Zenith Blueprint

I fasen Kontroller i praksis, trin 20, går Zenith Blueprint dybere. Kryptografi handler ikke om at “slå kryptering til”. Det handler om at indbygge kryptografi i design, politik og livscyklusstyring. Det omfatter data i hvile, data under overførsel, autentifikation af identiteter og transaktioner, godkendte algoritmer, key vaults, HSM’er, planlagt rotation, tilbagekaldelse og validering gennem penetrationstest og kodegennemgang.

Hvad revisorer forventer, når de beder om nøglebevis

De fleste revisionskonstateringer begynder med en enkel anmodning: “Vis mig jeres krypteringspolitik og registreringer for nøglestyring.”

Svage svar omfatter:

• “Cloududbyderen krypterer alt som standard.”
• “Vi bruger TLS.”
• “Hemmeligheder ligger i vaulten.”
• “Engineering-teamet håndterer rotation.”
• “Nøglen styres af applikationen.”

Disse udsagn kan være teknisk korrekte, men de er ikke fuldstændigt revisionsbevis. En ISO-revisor vil koble nøglestyring tilbage til risikovurdering, anvendelseserklæring, politikkrav, operationel kontrol og opbevaret dokumentation. En NIST CSF-assessor vil spørge, om kryptografiske aktiver er identificeret, beskyttet, overvåget og kan genoprettes. En DORA-revisor vil se efter bestyrelsesgodkendt styring af IKT-risiko, tredjepartsafhængigheder, hændelsesstyring og robusthedstest. En GDPR-gennemgang vil spørge, om kryptering og nøgleseparation reducerer risikoen for fysiske personer, og om den dataansvarlige kan dokumentere ansvarlighed.

Clarysecs enterprise Politik for kryptografiske kontroller Politik for kryptografiske kontroller adresserer dokumentationshullet direkte:

“Der skal vedligeholdes et centraliseret register for nøglestyring til registrering af alle kryptografiske nøgler, deres livscyklusstatus, tildelte forvaltere og anvendelseskontekster.”
Kilde: Enterprise-politik, Politik for kryptografiske kontroller, styringskrav, clause 5.2 Politik for kryptografiske kontroller

Den sætning ændrer revisionsdialogen. I stedet for at jagte tavs viden kan organisationen vise et register, der knytter nøgler til aktiver, ejere, dataklassificeringer, systemer, cloudkonti, rotationsdatoer, anvendelseskontekster og revisionsbevis.

For SMV’er skalerer Clarysecs Politik for kryptografiske kontroller - SMV Politik for kryptografiske kontroller - SMV samme forventning:

“IT-supportleverandøren skal vedligeholde en ajourført fortegnelse over kryptografiske værktøjer og certifikater i brug”
Kilde: SMV-politik, Politik for kryptografiske kontroller - SMV, styringskrav, clause 5.1.2 Politik for kryptografiske kontroller - SMV

En reguleret finansiel institution kan have behov for HSM-ceremonier, split knowledge, dobbeltkontrol, formelle udpegninger af forvaltere og kvartalsvise gennemgange af adgangsrettigheder. En mindre SaaS-udbyder kan begynde med en vedligeholdt fortegnelse, godkendte algoritmer, dokumenteret KMS-ejerskab og revisionsbevis for rotation. Begge har brug for styring, der er proportional med risikoen.

Den nøglelivscyklus, som jeres ISMS skal styre

Et praktisk program for nøglestyring følger livscyklussen. Hvert trin kræver en ejer, en godkendt metode, en teknisk kontrol, en ændringsregistrering og revisionsbevis.

Enterprise Politik for kryptografiske kontroller understøtter sikker generering:

“Nøglegenerering: Udføres ved hjælp af sikre hardware- eller softwaremoduler (f.eks. HSM’er, FIPS 140-2-validerede systemer).”
Kilde: Enterprise-politik, Politik for kryptografiske kontroller, krav til implementering af politikken, clause 6.3.1 Politik for kryptografiske kontroller

Den specificerer også rotation:

“Nøglerotation: Kræves med definerede intervaller eller straks ved kompromittering eller rolleændring.”
Kilde: Enterprise-politik, Politik for kryptografiske kontroller, krav til implementering af politikken, clause 6.3.4 Politik for kryptografiske kontroller

For SMV’er fremgår samme princip i enklere driftsmæssigt sprog:

“Nøglerotation skal ske i overensstemmelse med udløbsplaner eller ved mistanke om kompromittering”
Kilde: SMV-politik, Politik for kryptografiske kontroller - SMV, krav til implementering af politikken, clause 6.3.4 Politik for kryptografiske kontroller - SMV

Disse clauses er vigtige for NIS2 og DORA, fordi forældede eller dårligt styrede nøgler ikke kun er svagheder for fortrolighed. De kan blive blokeringer i hændelseshåndtering, problemer med leverandørafhængighed, svigt i genopretning efter alvorlige hændelser og kundevendte underretningsproblemer.

Cloud-KMS, HSM og BYOK: fælden i delt ansvar

Cloudkryptering er en af de mest almindelige kilder til falsk tryghed. En cloududbyder kan kryptere lagring som standard, men det betyder ikke automatisk, at jeres organisation har styret nøglen.

Zenith Blueprint, fasen Kontroller i praksis, trin 23, forklarer ISO/IEC 27002:2022 kontrol 5.23 ved at fokusere på cloudstyring, synlighed og delt ansvar. Den understreger, at udbyderen kan sikre infrastrukturen, men at kunden fortsat er ansvarlig for data, konfigurationer, adgangspolitikker og beredskab for hændelseshåndtering.

“Cloududbydere sikrer infrastrukturen, men I er stadig ansvarlige for jeres data, jeres konfigurationer, jeres adgangspolitikker og jeres beredskab for hændelseshåndtering.”
Kilde: Zenith Blueprint, fasen Kontroller i praksis, trin 23, organisatoriske kontroller 5.19-5.37 Zenith Blueprint

Det er her, ansvar for cloudnøgler bliver en bestyrelsesrisiko. En SaaS-virksomhed kan bruge udbyderstyret kryptering til lavrisiko-logfiler, kundeadministrerede nøgler til kundedatabaser, BYOK til regulerede tenants og HSM-understøttede rotnøgler til signering eller tokenisering. Hvert valg har konsekvenser for efterlevelse.

Clarysecs enterprise Politik for brug af cloudtjenester Politik for brug af cloudtjenester giver en klar kontrolretning:

“Kundeadministrerede nøgler (CMK’er) eller Bring Your Own Key (BYOK) skal anvendes, hvor cloududbyderen understøtter det.”
Kilde: Enterprise-politik, Politik for brug af cloudtjenester, krav til implementering af politikken, clause 6.4.2 Politik for brug af cloudtjenester

Det betyder ikke, at alle cloudtjenester skal bruge BYOK. Det betyder, at organisationen skal træffe et bevidst valg baseret på risiko, kundespecifikke forpligtelser, kontraktlige krav og mulighed for gendannelse.

DORA Article 28 og Article 30 gør dette særligt relevant for finansielle enheder. De kræver styring af IKT-tredjepartsrisiko, registre over IKT-kontraktlige aftaler, due diligence, revisions- og inspektionsrettigheder, bistand ved hændelser, databeskyttelse og adgang samt bestemmelser om genopretning og tilbagelevering. Hvis en cloududbyder eller SaaS-leverandør administrerer krypteringsnøgler for en kritisk eller vigtig funktion, skal relationen være synlig i IKT-tredjepartsregisteret og i kontraktlige kontroller.

NIS2 kræver også sikkerhed i forsyningskæden, herunder leverandørspecifikke sårbarheder, cybersikkerhedspraksisser og sikre udviklingsprocedurer. Hvis en kritisk leverandør opbevarer jeres nøgler, driver jeres KMS, leverer jeres HSM, styrer jeres certifikatlivscyklus eller hoster krypterede sikkerhedskopier, er leverandøren en del af jeres kryptografiske kontrolmiljø.

Algoritmegodkendelse og crypto-agility i 2026

En nøglestyringspolitik i 2026 skal ikke kun opliste “AES-256” og “TLS 1.2 eller nyere”. Den skal etablere en godkendelses- og gennemgangsproces, der understøtter crypto-agility. Crypto-agility betyder, at organisationen kan identificere, hvor algoritmer, protokoller, certifikater og nøglelængder anvendes, vurdere eksponering mod svagheder eller udfasning og migrere uden panik.

Clarysecs SMV-politik angiver:

“Kun algoritmer og protokoller efter industriens bedste praksis, som er godkendt af IT-supportleverandøren, må anvendes (f.eks. AES-256, RSA 2048, TLS 1.2 eller nyere)”
Kilde: SMV-politik, Politik for kryptografiske kontroller - SMV, krav til implementering af politikken, clause 6.2.1 Politik for kryptografiske kontroller - SMV

Den kræver også dokumentation:

“Alle krypteringsmetoder (f.eks. AES-256, TLS 1.2+) og nøglestyringsprocesser skal dokumenteres”
Kilde: SMV-politik, Politik for kryptografiske kontroller - SMV, styringskrav, clause 5.3.1 Politik for kryptografiske kontroller - SMV

Den revisionsklare version er en godkendt kryptografisk standard med:

• Tilladte algoritmer og protokoller for data i hvile, data under overførsel, signaturer, adgangskodehashing, tokenisering og backups.
• Ikke-tilladte algoritmer, protokoller og biblioteker.
• Minimumsnøglelængder og certifikatgyldighedsperioder.
• Godkendte KMS-, HSM-, certifikatudsteder- og platforme til håndtering af hemmeligheder.
• Krav til sikker generering af tilfældige tal.
• Udviklervejledning for kryptografiske biblioteker.
• Undtagelsesproces for legacy-systemer.
• Udløsende forhold for gennemgang ved sårbarheder, regulatoriske ændringer, leverandørændringer og planlægning af post-kvantum-overgang.

Post-kvantum-planlægning kræver ikke, at alle organisationer straks udskifter al kryptografi. Den kræver en fortegnelse. Uden en kryptografisk fortegnelse kan I ikke vide, hvilke systemer der bruger langlivet public-key-kryptering, hvilke certifikater der beskytter kritiske tjenester, hvor signeringsnøgler opbevares, eller hvilke leverandører der skal understøtte migrering. Nøglestyringsregisteret er ikke bureaukrati. Det er fundamentet for crypto-agility.

Et 90-minutters sprint for nøglestyringsbevis

Clarysec bruger ofte et kort evidenssprint med ledelse, sikkerhed, cloud- og compliance-teams. Målet er hurtigt at omsætte spredt nøgleviden til revisionsbevis.

Trin 1: Vælg én kritisk tjeneste

Vælg et system, der er relevant for NIS2, DORA eller GDPR. Eksempler omfatter kundeidentitet, betalingsbehandling, transaktionsovervågning, produktionskundedatabase, krypteret backupplatform eller kundevendt API.

Trin 2: Åbn nøglestyringsregisteret

Brug kravet i Politik for kryptografiske kontroller om et centraliseret register som struktur. Hvis I endnu ikke har et, skal I oprette et simpelt register med disse felter:

Trin 3: Spor adgang og dobbeltkontrol

For kryptografiske operationer med høj påvirkning skal dobbeltkontrol og mindst mulige rettigheder anvendes. Enterprise Politik for kryptografiske kontroller angiver:

“Principperne om dobbeltkontrol og mindst mulige rettigheder skal anvendes på følsomme kryptografiske operationer (f.eks. import af rotnøgler, HSM-administration).”
Kilde: Enterprise-politik, Politik for kryptografiske kontroller, krav til implementering af politikken, clause 6.6.2 Politik for kryptografiske kontroller

Spørg:

• Hvem kan deaktivere eller slette nøglen?
• Hvem kan ændre nøglepolitikken?
• Hvem kan dekryptere data direkte?
• Overvåges break-glass-roller, og er de tidsbegrænsede?
• Håndhæves MFA for privilegerede nøgleoperationer?
• Logges og gennemgås privilegerede handlinger?

Trin 4: Hent fem registreringer med revisionsbevis

Indsaml fem registreringer, der dokumenterer, at kontrollen fungerer:

1. Log for oprettelse eller import af nøgle.
2. Aktuel adgangspolitik for KMS eller HSM.
3. Seneste ændringssag for nøglerotation.
4. SIEM-forespørgsel, der viser nøglebrug eller administrative handlinger.
5. Revisionsbevis for genopretnings- eller gendannelsestest.

Trin 5: Kortlæg til risiko og regulering

Tilføj en kort risikoerklæring: “Uautoriseret brug eller tab af denne nøgle kan eksponere EU-personoplysninger, afbryde kundeservice og svække genopretning af kritiske systemer.” Kortlæg den derefter til de relevante forpligtelser.

På 90 minutter kan teamet normalt identificere, om nøglestyringen er reel eller blot antaget.

Hændelsesrapportering: når kompromittering af nøgler starter uret

En mistanke om kompromittering af nøgler er ikke automatisk et indberetningspligtigt brud, men den kan starte den regulatoriske tidsfrist.

Under NIS2 skal væsentlige og vigtige enheder uden unødig forsinkelse underrette om væsentlige hændelser, der påvirker levering af tjenester. Den trinvise model omfatter en tidlig advarsel inden for 24 timer efter kendskab, en hændelsesunderretning inden for 72 timer, statusopdateringer efter anmodning og en endelig rapport senest én måned efter hændelsesunderretningen.

Under DORA skal finansielle enheder detektere, styre og underrette om IKT-relaterede hændelser, registrere hændelser og væsentlige cybertrusler, klassificere hændelser efter alvorlighed og den berørte tjenestes kritikalitet, kommunikere med interessenter, rapportere større hændelser til øverste ledelse og kompetente myndigheder, udføre rodårsagsanalyse og afhjælpe. Outsourcing af rapportering kan være mulig, men ansvaret forbliver hos den finansielle enhed.

Under GDPR bliver spørgsmålet, om der er sket et brud på persondatasikkerheden, dvs. utilsigtet eller ulovlig destruktion, tab, ændring, uautoriseret videregivelse af eller adgang til personoplysninger. Stærk kryptering med ukompromitterede nøgler kan ændre risikovurderingen af brud væsentligt. Svag nøglestyring kan underminere dette argument.

Playbooks for kompromittering af nøgler skal definere:

• Hvordan mistanke om nøgleeksponering detekteres.
• Hvem der erklærer en kryptografisk hændelse.
• Hvordan berørte data, tjenester, kunder og jurisdiktioner identificeres.
• Hvordan nøgler tilbagekaldes eller roteres.
• Hvordan afhængige systemer gendannes.
• Hvordan bevismaterialets integritet bevares.
• Hvordan beslutninger om juridiske, regulatoriske og kundevendte underretninger træffes.

Nøglestyringsregisteret bliver afgørende i denne proces. Uden det spilder respondenter tid på at identificere, hvad en nøgle beskyttede. Med det kan de hurtigt afgrænse påvirkningen.

Revisionsperspektivet: ét kontrolsæt, mange modtagere af revisionsbevis

Forskellige revisorer går til styring af kryptografiske nøgler fra forskellige faglige vinkler, men de samles om det samme revisionsbevis.

En stærk revisionspakke for styring af kryptografiske nøgler indeholder typisk:

• Godkendt politik for kryptografiske kontroller.
• Godkendt politik for brug af cloudtjenester, hvor cloudkryptering er relevant.
• Kryptografisk standard og algoritmeliste.
• Nøglestyringsregister.
• Fortegnelse over certifikater og hemmeligheder.
• KMS-, HSM- og vault-arkitektur.
• Revisionsbevis for IAM og gennemgang af privilegeret adgang.
• Registreringer for rotation og tilbagekaldelse.
• Revisionsbevis for backup, escrow og genopretningstest.
• Regler for logning og overvågning af nøgleaktivitet.
• Kortlægning af leverandører og delt cloudansvar.
• Hændelsesplaybook for mistanke om kompromittering af nøgler.
• Undtagelser og risikoaccept.
• Ledelsens gennemgang og registreringer for revisionsafhjælpning.

Denne pakke omsætter en kontrolpåstand til dokumentation.

Almindelige konstateringer i revisioner af nøglestyring

De mest almindelige konstateringer kan undgås:

1. Ingen samlet fortegnelse over nøgler, certifikater og kryptografiske værktøjer.
2. Cloududbyderens standardkryptering behandles som fuld nøglestyring.
3. Ingen ejer eller forvalter er tildelt produktionsnøgler.
4. Rotation findes for certifikater, men ikke for applikationsnøgler eller database-CMK’er.
5. Hemmeligheder og nøgler blandes i samme vault uden klassificering.
6. Udviklere kan oprette nøgler uden for godkendte mønstre.
7. Intet revisionsbevis for, at KMS-administratorer gennemgås.
8. Genopretningsprocedurer findes, men er aldrig blevet testet.
9. Kompromittering af nøgler indgår ikke i playbooks for hændelseshåndtering.
10. Legacy-algoritmer forbliver i interne tjenester, fordi ingen ejer afhjælpningen.
11. BYOK-forpligtelser indgås i kundekontrakter, men afspejles ikke i driften.
12. Leverandørstyret kryptering indgår ikke i leverandørrisikogennemgange.

Hver konstatering peger tilbage på styring. Derfor kan kryptografi ikke behandles som et rent engineering-projekt. Det skal kobles til ISMS-omfang, risikobehandling, politik, leverandører, cloud, adgang, logning, hændelser og forretningskontinuitet.

Gør nøglestyring revisionsklar før den næste hændelse

Hvis jeres organisation forbereder sig på NIS2, DORA, revisionsbevis for GDPR Article 32, ISO/IEC 27001:2022-certificering eller post-kvantum crypto-agility, skal I begynde med ét spørgsmål: Kan I fremlægge et komplet nøglestyringsregister i dag?

Hvis ikke, kan Clarysec hjælpe jer med at opbygge kontrolsystemet omkring det.

Brug Zenith Blueprint Zenith Blueprint til at strukturere arbejdet gennem risikostyringsfasen trin 14 og fasen Kontroller i praksis trin 20. Brug Zenith Controls Zenith Controls til at kortlægge ISO/IEC 27002:2022-kontroller 8.24, 5.17 og 5.23 på tværs af NIS2, DORA, GDPR, NIST og revisionsforventninger. Brug Clarysecs Politik for kryptografiske kontroller Politik for kryptografiske kontroller, Politik for kryptografiske kontroller - SMV Politik for kryptografiske kontroller - SMV og Politik for brug af cloudtjenester Politik for brug af cloudtjenester til at omsætte krav til driftsregler.

Det praktiske næste skridt er enkelt: Vælg én kritisk tjeneste, registrér dens nøgler, dokumentér ejerskab, validér adgang, hent revisionsbevis for rotation og test genopretning. Hvis det tager mere end en dag, kræver jeres kryptografiske styring opmærksomhed, før tilsynsmyndigheden, revisoren eller hændelseshåndteringsteamet stiller samme spørgsmål under pres.