Cryptografisch sleutelbeheer voor ISO 27001, NIS2 en DORA

Om 08:17 op een maandagochtend ontvangt de CISO van een Europees SaaS-bedrijf een bericht van de technische lead: “We hebben in het weekend de encryptiesleutel van de database geroteerd, maar één integratie kon records niet meer ontsleutelen. We hebben teruggedraaid met een oude sleutel uit de kluis.”

Tien minuten later vraagt de DPO of de getroffen records persoonsgegevens van EU-klanten bevatten. Financiën vraagt of dit een meldingsplichtig operationeel incident voor een gereguleerde klant kan worden. Inkoop vraagt of de cloudprovider of het bedrijf eigenaar is van de door de klant beheerde sleutel. De CEO stelt de enige vraag die in de bestuurskamer telt: “Kunnen we aantonen dat we dit goed hebben beheerst?”

Dat is het moment waarop “wij gebruiken encryptie” ophoudt een geruststellende uitspraak te zijn en verandert in een bewijsvraagstuk.

In 2026 bevindt cryptografisch sleutelbeheer zich op het snijvlak van ISO/IEC 27001:2022-beheersmaatregelen, NIS2-cyberhygiëne, DORA ICT-risicobeheer, bewijsmateriaal voor beveiliging van de verwerking onder GDPR Article 32, gedeelde verantwoordelijkheid in de cloud en planning voor post-quantum-crypto-agility. De werkelijke vraag is niet of encryptie bestaat. De werkelijke vraag is of de organisatie met registraties kan aantonen dat sleutels veilig worden gegenereerd, aan eigenaren worden toegewezen, in goedgekeurde KMS- of HSM-omgevingen worden opgeslagen, volgens schema worden geroteerd, veilig worden hersteld, bij compromittering worden ingetrokken en aan bedrijfsrisico’s zijn gekoppeld.

Clarysec ziet hetzelfde patroon herhaaldelijk bij auditvoorbereiding. Encryptie wordt per systeem geïmplementeerd, maar sleutelgovernance is versnipperd. Certificaten staan in spreadsheets. Cloud-KMS-machtigingen zijn geërfd van oude projecten. Ontwikkelaars weten welke secrets belangrijk zijn, maar het ISMS weet dat niet. Auditors ontvangen schermafbeeldingen in plaats van bewijsmateriaal over de levenscyclus. NIS2- en DORA-teams spreken over weerbaarheid, privacyteams spreken over GDPR-encryptie en pseudonimisering, en niemand is end-to-end eigenaar van de cryptografische beheerlaag.

Een volwassen antwoord is niet méér cryptografie als losstaand onderwerp. Het is beheerst cryptografisch sleutelbeheer dat is verbonden met risicobehandeling, cloudarchitectuur, leverancierstoezicht, toegangscontrole, logging, incidentrespons en regelgevend bewijsmateriaal.

Waarom sleutelbeheer nu een governancevraagstuk is

NIS2 maakt beleid voor cryptografie en encryptie onderdeel van de minimale maatregelen voor cyberbeveiligingsrisicobeheer voor essentiële en belangrijke entiteiten. Article 21 vereist passende en evenredige technische, operationele en organisatorische maatregelen, waaronder risicoanalyse, incidentafhandeling, continuïteit, beveiliging van de toeleveringsketen, veilige ontwikkeling, cyberhygiëne, toegangscontrole, beheer van bedrijfsmiddelen en beleid voor cryptografie en encryptie. Ook moeten bestuursorganen maatregelen voor cyberbeveiligingsrisicobeheer goedkeuren en daarop toezicht houden.

Voor SaaS-, cloud-, managed service- en cyberbeveiligingsproviders kan de toepasselijkheid breder zijn dan veel teams aannemen. NIS2 omvat sectoren zoals digitale infrastructuur, cloudcomputingdiensten, datacenterproviders, DNS-providers, vertrouwensdienstverleners, managed service providers, managed security service providers, online marktplaatsen, zoekmachines en socialenetwerkplatforms wanneer aan omvangs- of kritikaliteitsdrempels wordt voldaan.

DORA legt de lat hoger voor financiële entiteiten. Vanaf 17 januari 2025 vereist DORA een gedocumenteerd kader voor ICT-risicobeheer, verantwoordingsplicht van het bestuur, ICT-bedrijfscontinuïteit en respons- en herstelplannen, testen van digitale operationele weerbaarheid, ICT-risicobeheer van derde partijen en incidentmelding. Voor financiële entiteiten die onder nationale NIS2-regels zijn aangewezen, fungeert DORA als sectorspecifieke rechtshandeling van de Unie voor gelijkwaardige NIS2-verplichtingen. Een fintech moet geen afzonderlijke cryptogovernance voor NIS2, DORA en ISO voeren. Zij heeft één verdedigbaar beheersingsmodel nodig.

GDPR voegt de privacydimensie van bewijsmateriaal toe. GDPR Article 32 is waar encryptie vaak wordt beoordeeld als waarborg voor beveiliging van de verwerking, maar “de gegevens zijn versleuteld” is geen volledig antwoord. Toezichthouders en auditors vragen wie de sleutels beheert, hoe toegang wordt beperkt, hoe compromittering wordt gedetecteerd, hoe herstel werkt en of het ontwerp aansluit bij het risico voor betrokkenen.

ISO/IEC 27001:2022 geeft organisaties het managementsysteem om deze verplichtingen met elkaar te verbinden. Clausules 4.1 t/m 4.4 vereisen context, eisen van belanghebbenden, ISMS-toepassingsgebied en samenwerkende processen. Clausules 5.1 t/m 5.3 vereisen leiderschap, beleid, middelen en toegewezen verantwoordelijkheden. Clausules 6.1.1 t/m 6.1.3 vereisen risicobeoordeling, risicobehandeling, selectie van beheersmaatregelen, een Verklaring van Toepasselijkheid en goedkeuring door de risico-eigenaar. Clausules 8.1 t/m 8.3 vereisen beheerste uitvoering, herbeoordeling van risico’s wanneer wijzigingen optreden, implementatie van behandelplannen en bewaring van gedocumenteerde resultaten.

Voor cryptografisch sleutelbeheer moet het ISMS vijf vragen beantwoorden:

1. Welke informatieactiva, gegevensstromen en diensten vereisen cryptografische bescherming?
2. Welke sleutels, certificaten, secrets en cryptodiensten beschermen deze?
3. Wie is eigenaar van deze cryptografische bedrijfsmiddelen, wie beheert ze, wie keurt ze goed en wie bewaakt ze?
4. Hoe worden generatie, opslag, gebruik, rotatie, escrow, herstel, intrekking en vernietiging beheerst?
5. Welk bewijsmateriaal toont aan dat de beheersmaatregelen hebben gewerkt zoals ontworpen?

De ISO 27001-beheersmaatregelenketen voor cryptografisch sleutelbeheer

Clarysec behandelt cryptografisch sleutelbeheer als een keten van beheersmaatregelen, niet als één afzonderlijke beheersmaatregel. In Zenith Controls: The Cross-Compliance Guide Zenith Controls wordt het onderwerp primair gekoppeld aan ISO/IEC 27002:2022 beheersmaatregel 8.24, gebruik van cryptografie, met belangrijke ondersteunende relaties naar 5.17, authenticatie-informatie, en 5.23, informatiebeveiliging voor het gebruik van cloudservices.

Die relatie is belangrijk. Een tekortkoming in sleutelbeheer is zelden alleen “slechte encryptie”. Vaak is het een authenticatieprobleem, een probleem in cloudgovernance, een leveranciersprobleem, een logginghiaat of falend wijzigingsbeheer.

De Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint maakt dit operationeel in de fase Risicobeheer, stap 14, beleid voor risicobehandeling en kruisverwijzingen naar regelgeving. Het voorbeeld voor cryptografiebeleid stelt dat de organisatie moet definiëren waar cryptografie nodig is, algoritmen en protocollen moet goedkeuren, sleutelbeheer moet definiëren, use cases zoals volledige schijfversleuteling en beveiligde communicatie moet afdekken en het beleid aan GDPR Article 32 moet koppelen.

“Encryptiesleutels moeten veilig worden opgeslagen (bijv. in een sleutelkluis/HSM) en toegang moet worden beperkt tot geautoriseerd personeel.”
Toeschrijving: Zenith Blueprint, fase Risicobeheer, stap 14, beleid voor risicobehandeling en kruisverwijzingen naar regelgeving Zenith Blueprint

In de fase Beheersmaatregelen in de praktijk, stap 20, gaat de Zenith Blueprint dieper. Cryptografie gaat niet over “encryptie aanzetten”. Het gaat om het inbedden van cryptografie in ontwerp, beleid en levenscyclusbeheer. Dat omvat gegevens in rust, gegevens tijdens transport, authenticatie van identiteiten en transacties, goedgekeurde algoritmen, sleutelkluizen, HSM’s, geplande rotatie, intrekking en validatie door middel van penetratietesten en code review.

Wat auditors verwachten wanneer zij om sleutelbewijsmateriaal vragen

De meeste auditbevindingen beginnen met een eenvoudige vraag: “Laat uw encryptiebeleid en sleutelbeheerregistraties zien.”

Zwakke antwoorden zijn onder meer:

• “De cloudprovider versleutelt alles standaard.”
• “We gebruiken TLS.”
• “Secrets staan in de kluis.”
• “Het engineeringteam verzorgt de rotatie.”
• “De sleutel wordt door de applicatie beheerd.”

Deze uitspraken kunnen technisch juist zijn, maar vormen geen volledig bewijsmateriaal. Een ISO-auditor zal sleutelbeheer terugkoppelen aan de risicobeoordeling, de Verklaring van Toepasselijkheid, beleidsvereisten, operationele beheersing en bewaarde documentatie. Een NIST CSF-assessor zal vragen of cryptografische activa zijn geïdentificeerd, beschermd, bewaakt en herstelbaar zijn. Een DORA-auditor zoekt naar door het bestuur goedgekeurde ICT-risicogovernance, afhankelijkheden van derde partijen, incidentbeheer en weerbaarheidstesten. Een GDPR-beoordelaar zal vragen of encryptie en scheiding van sleutels het risico voor betrokkenen verlagen en of de verwerkingsverantwoordelijke verantwoordingsplicht kan aantonen.

Clarysec’s Enterprise Beleid inzake cryptografische beheersmaatregelen Beleid inzake cryptografische beheersmaatregelen adresseert de lacune in bewijsmateriaal direct:

“Er moet een centraal sleutelbeheerregister worden onderhouden om alle cryptografische sleutels, hun levenscyclusstatus, toegewezen beheerders en gebruikscontexten vast te leggen.”
Toeschrijving: ondernemingsbeleid, Beleid inzake cryptografische beheersmaatregelen, governancevereisten, clausule 5.2 Beleid inzake cryptografische beheersmaatregelen

Die zin verandert het auditgesprek. In plaats van afhankelijk te zijn van impliciete kennis kan de organisatie een register tonen dat sleutels koppelt aan activa, eigenaren, gegevensclassificaties, systemen, cloudaccounts, rotatiedatums, gebruikscontexten en bewijsmateriaal.

Voor mkb-organisaties schaalt Clarysec’s Beleid inzake cryptografische beheersmaatregelen voor mkb Beleid inzake cryptografische beheersmaatregelen voor mkb dezelfde verwachting:

“De IT-supportverlener moet een actuele inventaris bijhouden van cryptografische tools en certificaten die in gebruik zijn”
Toeschrijving: mkb-beleid, Beleid inzake cryptografische beheersmaatregelen voor mkb, governancevereisten, clausule 5.1.2 Beleid inzake cryptografische beheersmaatregelen voor mkb

Een gereguleerde financiële instelling kan HSM-ceremonies, split knowledge, dual control, formele aanstelling van beheerders en kwartaalgewijze toegangsrechtenbeoordelingen nodig hebben. Een kleine SaaS-provider kan beginnen met een bijgehouden inventaris, goedgekeurde algoritmen, gedocumenteerd KMS-eigenaarschap en rotatiebewijsmateriaal. Beide hebben governance nodig die evenredig is aan het risico.

De sleutellevenscyclus die uw ISMS moet beheersen

Een praktisch programma voor sleutelbeheer volgt de levenscyclus. Elke fase vereist een eigenaar, goedgekeurde methode, technische beheersmaatregel, wijzigingsregistratie en auditbewijsmateriaal.

Het Enterprise Beleid inzake cryptografische beheersmaatregelen versterkt veilige generatie:

“Sleutelgeneratie: uitgevoerd met veilige hardware- of softwaremodules (bijv. HSM’s, FIPS 140-2-gevalideerde systemen).”
Toeschrijving: ondernemingsbeleid, Beleid inzake cryptografische beheersmaatregelen, vereisten voor beleidsimplementatie, clausule 6.3.1 Beleid inzake cryptografische beheersmaatregelen

Het specificeert ook rotatie:

“Sleutelrotatie: vereist met gedefinieerde intervallen of onmiddellijk bij compromittering of rolwijziging.”
Toeschrijving: ondernemingsbeleid, Beleid inzake cryptografische beheersmaatregelen, vereisten voor beleidsimplementatie, clausule 6.3.4 Beleid inzake cryptografische beheersmaatregelen

Voor mkb-organisaties verschijnt hetzelfde principe in eenvoudiger operationele taal:

“Sleutelrotatie moet plaatsvinden volgens vervalschema’s of bij vermoedelijke compromittering”
Toeschrijving: mkb-beleid, Beleid inzake cryptografische beheersmaatregelen voor mkb, vereisten voor beleidsimplementatie, clausule 6.3.4 Beleid inzake cryptografische beheersmaatregelen voor mkb

Deze clausules zijn belangrijk voor NIS2 en DORA omdat verouderde of slecht beheerde sleutels niet alleen zwaktes in vertrouwelijkheid zijn. Zij kunnen blokkades voor incidentrespons, kwesties rond leveranciersafhankelijkheid, falend herstel na verstoringen en problemen bij klantmeldingen veroorzaken.

Cloud-KMS, HSM en BYOK: de valkuil van gedeelde verantwoordelijkheid

Cloudencryptie is een van de meest voorkomende bronnen van schijnzekerheid. Een cloudprovider kan opslag standaard versleutelen, maar dat betekent niet automatisch dat uw organisatie de sleutel heeft beheerst.

De Zenith Blueprint, fase Beheersmaatregelen in de praktijk, stap 23, licht ISO/IEC 27002:2022 beheersmaatregel 5.23 toe met focus op cloudgovernance, zichtbaarheid en gedeelde verantwoordelijkheid. De tekst benadrukt dat de provider de infrastructuur kan beveiligen, maar dat de klant verantwoordelijk blijft voor gegevens, configuraties, toegangsbeleid en gereedheid voor incidentrespons.

“Cloudproviders beveiligen de infrastructuur, maar u blijft verantwoordelijk voor uw gegevens, uw configuraties, uw toegangsbeleid en uw gereedheid voor incidentrespons.”
Toeschrijving: Zenith Blueprint, fase Beheersmaatregelen in de praktijk, stap 23, organisatorische beheersmaatregelen 5.19-5.37 Zenith Blueprint

Hier wordt verantwoordelijkheid voor cloudsleutels een risico op bestuursniveau. Een SaaS-bedrijf kan door de provider beheerde encryptie gebruiken voor logboeken met laag risico, door de klant beheerde sleutels voor klantdatabases, BYOK voor gereguleerde tenants en HSM-ondersteunde rootsleutels voor ondertekening of tokenisatie. Elke keuze heeft implicaties voor compliance.

Clarysec’s Enterprise Beleid inzake gebruik van cloudservices Beleid inzake gebruik van cloudservices geeft een duidelijke richting voor beheersing:

“Door de klant beheerde sleutels (CMK’s) of Bring Your Own Key (BYOK) moeten worden gebruikt waar dit door de cloudprovider wordt ondersteund.”
Toeschrijving: ondernemingsbeleid, Beleid inzake gebruik van cloudservices, vereisten voor beleidsimplementatie, clausule 6.4.2 Beleid inzake gebruik van cloudservices

Dit betekent niet dat elke clouddienst BYOK moet gebruiken. Het betekent dat de organisatie bewust moet beslissen op basis van risico, klantafspraken, contractuele eisen en herstelbaarheid.

DORA Article 28 en Article 30 maken dit bijzonder relevant voor financiële entiteiten. Zij vereisen ICT-risicobeheer van derde partijen, registers van ICT-contractuele regelingen, due diligence, audit- en inspectierechten, incidentondersteuning, gegevensbescherming en toegang, en bepalingen voor herstel en teruggave. Als een cloudprovider of SaaS-leverancier encryptiesleutels beheert voor een kritieke of belangrijke functie, moet die relatie zichtbaar zijn in het ICT-register van derde partijen en in contractuele beheersmaatregelen.

NIS2 vereist ook beveiliging van de toeleveringsketen, inclusief leveranciersspecifieke kwetsbaarheden, cyberbeveiligingspraktijken en procedures voor veilige ontwikkeling. Als een kritieke leverancier uw sleutels bewaart, uw KMS exploiteert, uw HSM levert, uw certificaatlevenscyclus beheert of versleutelde back-ups host, maakt die leverancier deel uit van uw cryptografische beheersingsomgeving.

Algoritmegoedkeuring en crypto-agility in 2026

Een beleid voor sleutelbeheer in 2026 moet niet alleen “AES-256” en “TLS 1.2 of hoger” opsommen. Het moet een goedkeurings- en beoordelingsproces vaststellen dat crypto-agility ondersteunt. Crypto-agility betekent dat de organisatie kan identificeren waar algoritmen, protocollen, certificaten en sleutellengten worden gebruikt, blootstelling aan zwaktes of uitfasering kan beoordelen en zonder paniek kan migreren.

Clarysec’s mkb-beleid stelt:

“Alleen algoritmen en protocollen volgens beste praktijken van de sector die zijn goedgekeurd door de IT-supportverlener mogen worden gebruikt (bijv. AES-256, RSA 2048, TLS 1.2 of hoger)”
Toeschrijving: mkb-beleid, Beleid inzake cryptografische beheersmaatregelen voor mkb, vereisten voor beleidsimplementatie, clausule 6.2.1 Beleid inzake cryptografische beheersmaatregelen voor mkb

Het vereist ook documentatie:

“Alle encryptiemethoden (bijv. AES-256, TLS 1.2+) en sleutelbeheerprocessen moeten worden gedocumenteerd”
Toeschrijving: mkb-beleid, Beleid inzake cryptografische beheersmaatregelen voor mkb, governancevereisten, clausule 5.3.1 Beleid inzake cryptografische beheersmaatregelen voor mkb

De auditgereede versie is een goedgekeurde cryptografische standaard met:

• Toegestane algoritmen en protocollen voor gegevens in rust, gegevens tijdens transport, handtekeningen, wachtwoordhashing, tokenisatie en back-ups.
• Niet-toegestane algoritmen, protocollen en bibliotheken.
• Minimale sleutellengten en geldigheidsperioden voor certificaten.
• Goedgekeurde KMS-, HSM-, certificaatautoriteit- en secretsmanagementplatforms.
• Eisen voor veilige generatie van willekeurige getallen.
• Richtlijnen voor ontwikkelaars over cryptografische bibliotheken.
• Uitzonderingsproces voor legacy-systemen.
• Triggers voor beoordeling bij kwetsbaarheden, wijzigingen in regelgeving, leverancierswijzigingen en planning voor post-quantumtransitie.

Post-quantumplanning vereist niet dat elke organisatie onmiddellijk alle cryptografie vervangt. Het vereist wel inventarisatie. Zonder cryptografische inventaris weet u niet welke systemen langlevende public-key-encryptie gebruiken, welke certificaten kritieke diensten beschermen, waar ondertekeningssleutels zich bevinden of welke leveranciers migratie moeten ondersteunen. Het sleutelbeheerregister is geen bureaucratie. Het is de basis van crypto-agility.

Een bewijssprint van 90 minuten voor sleutelbeheer

Clarysec gebruikt vaak een korte bewijssprint met leiderschap, beveiliging, cloud- en complianceteams. Het doel is om verspreide kennis over sleutels snel om te zetten in auditbewijsmateriaal.

Stap 1: Selecteer één kritieke dienst

Kies een systeem dat relevant is voor NIS2, DORA of GDPR. Voorbeelden zijn klantidentiteit, betalingsverwerking, transactiemonitoring, productiedatabase met klantgegevens, versleuteld back-upplatform of klantgerichte API.

Stap 2: Open het sleutelbeheerregister

Gebruik de eis uit het Beleid inzake cryptografische beheersmaatregelen voor een centraal register als structuur. Als u er nog geen hebt, maak dan een eenvoudig register met deze velden:

Stap 3: Traceer toegang en dual control

Voor cryptografische operaties met hoge impact moeten dual control en het principe van minimale privileges worden toegepast. Het Enterprise Beleid inzake cryptografische beheersmaatregelen stelt:

“Dual control en principes van minimale privileges moeten worden toegepast op gevoelige cryptografische operaties (bijv. import van rootsleutels, HSM-beheer).”
Toeschrijving: ondernemingsbeleid, Beleid inzake cryptografische beheersmaatregelen, vereisten voor beleidsimplementatie, clausule 6.6.2 Beleid inzake cryptografische beheersmaatregelen

Vraag:

• Wie kan de sleutel uitschakelen of verwijderen?
• Wie kan het sleutelbeleid wijzigen?
• Wie kan gegevens direct ontsleutelen?
• Worden break-glass-rollen bewaakt en tijdgebonden toegekend?
• Wordt MFA afgedwongen voor geprivilegieerde sleuteloperaties?
• Worden geprivilegieerde handelingen gelogd en beoordeeld?

Stap 4: Verzamel vijf bewijsregistraties

Verzamel vijf registraties die aantonen dat de beheersmaatregel werkt:

1. Logboek van sleutelcreatie of -import.
2. Huidig KMS- of HSM-toegangsbeleid.
3. Laatste wijzigingsticket voor sleutelrotatie.
4. SIEM-query die sleutelgebruik of beheerdershandelingen toont.
5. Bewijsmateriaal van een herstel- of restoretest.

Stap 5: Koppel aan risico en regelgeving

Voeg een korte risicoverklaring toe: “Ongeautoriseerd gebruik of verlies van deze sleutel kan persoonsgegevens van EU-klanten blootstellen, de dienstverlening aan klanten verstoren en herstel van kritieke systemen belemmeren.” Koppel dit vervolgens aan de relevante verplichtingen.

Binnen 90 minuten kan het team meestal vaststellen of sleutelgovernance daadwerkelijk bestaat of slechts wordt aangenomen.

Incidentmelding: wanneer sleutelcompromittering de klok start

Een vermoeden van sleutelcompromittering is niet automatisch een meldingsplichtige inbreuk, maar kan de regelgevende klok wel starten.

Onder NIS2 moeten essentiële en belangrijke entiteiten significante incidenten die de dienstverlening beïnvloeden zonder onnodige vertraging melden. Het gefaseerde model omvat een vroegtijdige waarschuwing binnen 24 uur na kennisname, een incidentmelding binnen 72 uur, statusupdates wanneer daarom wordt verzocht en een eindrapport uiterlijk één maand na de incidentmelding.

Onder DORA moeten financiële entiteiten ICT-gerelateerde incidenten detecteren, beheren en melden, incidenten en significante cyberdreigingen registreren, incidenten classificeren naar ernst en kritikaliteit van de getroffen dienst, communiceren met stakeholders, majeure incidenten melden aan hoger management en bevoegde autoriteiten, oorzaakanalyse uitvoeren en remediëren. Uitbesteding van rapportage kan mogelijk zijn, maar de verantwoordelijkheid blijft bij de financiële entiteit.

Onder GDPR wordt de vraag of er sprake is van een inbreuk in verband met persoonsgegevens: een accidentele of onrechtmatige vernietiging, verlies, wijziging, ongeoorloofde verstrekking van of toegang tot persoonsgegevens. Sterke encryptie met niet-gecompromitteerde sleutels kan de risicoanalyse van een inbreuk wezenlijk veranderen. Zwak sleutelbeheer kan dat argument ondermijnen.

Draaiboeken voor sleutelcompromittering moeten definiëren:

• Hoe vermoedelijke blootstelling van sleutels wordt gedetecteerd.
• Wie een cryptografisch incident verklaart.
• Hoe getroffen gegevens, diensten, klanten en jurisdicties worden geïdentificeerd.
• Hoe sleutels worden ingetrokken of geroteerd.
• Hoe afhankelijke systemen worden hersteld.
• Hoe integriteit van bewijsmateriaal wordt behouden.
• Hoe juridische, regelgevende en klantmeldingsbesluiten worden genomen.

Het sleutelbeheerregister wordt tijdens dit proces essentieel. Zonder register verspillen responders tijd aan het achterhalen wat een sleutel beschermde. Met het register kunnen zij de impact snel afbakenen.

De auditbril: één set beheersmaatregelen, veel gebruikers van bewijsmateriaal

Verschillende auditors benaderen cryptografisch sleutelbeheer vanuit verschillende achtergronden, maar komen uit op hetzelfde bewijsmateriaal.

Een sterk auditpakket voor cryptografisch sleutelbeheer bevat doorgaans:

• Goedgekeurd Beleid inzake cryptografische beheersmaatregelen.
• Goedgekeurd Beleid inzake gebruik van cloudservices wanneer cloudencryptie relevant is.
• Cryptografische standaard en algoritmelijst.
• Sleutelbeheerregister.
• Inventaris van certificaten en secrets.
• KMS-, HSM- en kluisarchitectuur.
• Bewijsmateriaal van IAM- en geprivilegieerde toegangsbeoordelingen.
• Rotatie- en intrekkingsregistraties.
• Bewijsmateriaal van back-up-, escrow- en hersteltests.
• Logging- en monitoringregels voor sleutelactiviteit.
• Mapping van leveranciers en gedeelde verantwoordelijkheid in de cloud.
• Incidentdraaiboek voor vermoedelijke sleutelcompromittering.
• Uitzonderingen en risicoacceptaties.
• Registraties van directiebeoordeling en herstel van auditbevindingen.

Dit pakket zet een beheersingsclaim om in bewijs.

Veelvoorkomende bevindingen bij audits van sleutelbeheer

De meest voorkomende bevindingen zijn te voorkomen:

1. Geen enkele inventaris van sleutels, certificaten en cryptografische tools.
2. Standaardencryptie door de cloudprovider wordt behandeld als volledige sleutelgovernance.
3. Geen eigenaar of beheerder toegewezen aan productiesleutels.
4. Rotatie bestaat voor certificaten, maar niet voor applicatiesleutels of database-CMK’s.
5. Secrets en sleutels staan zonder classificatie in dezelfde kluis.
6. Ontwikkelaars kunnen sleutels aanmaken buiten goedgekeurde patronen.
7. Geen bewijsmateriaal dat KMS-beheerders worden beoordeeld.
8. Herstelprocedures bestaan, maar zijn nooit getest.
9. Sleutelcompromittering is niet opgenomen in incidentresponsdraaiboeken.
10. Legacy-algoritmen blijven in interne diensten bestaan omdat niemand eigenaar is van remediatie.
11. BYOK-verplichtingen worden in klantcontracten aangegaan, maar niet in de operatie weerspiegeld.
12. Door leveranciers beheerde encryptie wordt niet meegenomen in beoordelingen van leveranciersrisico.

Elke bevinding leidt terug naar governance. Daarom mag cryptografie niet als een puur engineeringproject worden behandeld. Zij moet verbonden zijn met ISMS-toepassingsgebied, risicobehandeling, beleid, leveranciers, cloud, toegang, logging, incidenten en continuïteit.

Maak sleutelgovernance auditgereed vóór het volgende incident

Als uw organisatie zich voorbereidt op NIS2, DORA, bewijsmateriaal voor GDPR Article 32, ISO/IEC 27001:2022-certificering of post-quantum-crypto-agility, begin dan met één vraag: kunt u vandaag een volledig sleutelbeheerregister opleveren?

Zo niet, dan kan Clarysec u helpen het beheersingssysteem eromheen op te bouwen.

Gebruik de Zenith Blueprint Zenith Blueprint om het werk te structureren via de fase Risicobeheer stap 14 en de fase Beheersmaatregelen in de praktijk stap 20. Gebruik Zenith Controls Zenith Controls om ISO/IEC 27002:2022 beheersmaatregelen 8.24, 5.17 en 5.23 te mappen op NIS2, DORA, GDPR, NIST en auditverwachtingen. Gebruik Clarysec’s Beleid inzake cryptografische beheersmaatregelen Beleid inzake cryptografische beheersmaatregelen, Beleid inzake cryptografische beheersmaatregelen voor mkb Beleid inzake cryptografische beheersmaatregelen voor mkb en Beleid inzake gebruik van cloudservices Beleid inzake gebruik van cloudservices om eisen om te zetten in operationele regels.

De praktische vervolgstap is eenvoudig: kies één kritieke dienst, inventariseer de sleutels, toon eigenaarschap aan, valideer toegang, verzamel rotatiebewijsmateriaal en test herstel. Als dat meer dan een dag kost, heeft uw cryptografische governance aandacht nodig voordat de toezichthouder, auditor of het incidentresponsteam onder druk dezelfde vraag stelt.