Guide till register över cybersäkerhetsrelaterade efterlevnadskrav 2026

Maria, informationssäkerhetschef (CISO) för en snabbt växande fintechplattform, hade tjugo minuter kvar innan det kvartalsvisa styrelseunderlaget skulle låsas. Vd:ns meddelande var kort och obekvämt:

”Maria, jag behöver en enda bild som visar att vi har kontroll över våra rättsliga cybersäkerhetskrav för 2026. Inte bara ISO 27001. Jag menar allt. NIS2, DORA, GDPR, våra kundavtal. Uppfyller vi kraven? Var finns underlaget? Vem äger frågan?”

Klockan 08:15 kom tre nya förfrågningar. Juridik ville veta om företaget var en viktig entitet enligt en medlemsstats regler för införlivande av NIS2. Dataskyddsombudet ville veta om en misstänkt databasexport skulle hanteras som en personuppgiftsincident enligt GDPR, en större IKT-relaterad incident enligt DORA, båda eller ingetdera. Upphandling ville ha godkännande för en leverantör av bedrägerianalys som skulle behandla personuppgifter från EU, stödja en kritisk tjänst och använda ett molnbaserat underbiträde utanför EU.

Ingen av dessa frågor är ovanlig 2026. Risken uppstår när organisationen inte kan besvara dem utifrån en gemensam och underhållen källa till sanning.

De flesta företag har policyer. Många har riskregister, leverantörsakter, integritetsregister, åtgärdsplaner för incidenter och en tillämpbarhetsförklaring. Men luckan blir tydlig när en styrelseledamot, revisor, tillsynsmyndighet eller viktig kund ställer en enkel fråga:

”Visa varje tillämpligt rättsligt, regulatoriskt och avtalsmässigt cybersäkerhetskrav, vem som äger det, hur ofta det granskas, vilken kontroll som genomför det, vilket underlag som visar att det uppfylls och hur undantag eskaleras till ledningen.”

Detta är registret över cybersäkerhetsrelaterade efterlevnadskrav.

För informationssäkerhetschefer, complianceansvariga, revisorer och verksamhetsägare är registret inte längre ett administrativt kalkylblad. Det är den operativa mekanism som kopplar samman nationella NIS2-krav, tillsynsförväntningar enligt DORA, ansvarsskyldighet enligt GDPR, krav i ISO/IEC 27001:2022, kundavtal och interna policyer till ett fungerande styrningssystem.

Clarysec behandlar registret som en levande ISMS-artefakt, inte som en juridisk bilaga. I Policy för rättslig och regulatorisk efterlevnad ska compliancefunktionen:

”Underhålla registret över efterlevnadskrav, med förteckning över alla tillämpliga lagar, standarder, certifieringar och avtalsklausuler.”
Från Policy för rättslig och regulatorisk efterlevnad, Roller och ansvar, klausul 4.2.1.

Det viktiga ordet är ”underhålla”. Ett register som skapats inför certifiering och sedan ignoreras fram till nästa revision är inte en efterlevnadsmekanism. Det är underlag för historisk optimism.

Vad ett register över cybersäkerhetsrelaterade efterlevnadskrav ska göra 2026

Ett användbart kravregister fyller fem funktioner.

För det första identifierar det krav. Dessa omfattar lagar, regelverk, standarder, certifieringar och avtalsklausuler. Under 2026 är vanliga källor NIS2 för väsentliga och viktiga entiteter, DORA för omfattade finansiella entiteter och IKT-tredjepartsleverantörer, GDPR för personuppgiftsansvariga och personuppgiftsbiträden som hanterar personuppgifter från EU, ISO/IEC 27001:2022-krav för ISMS, åtaganden om molnsäkerhet, avtalsklausuler om incidentanmälan till kunder, outsourcingsregler och krav på leverantörssäkerhet.

För det andra klassificerar det tillämplighet. NIS2 kan vara tillämpligt eftersom organisationen verkar i en sektor enligt bilaga I eller bilaga II, tillhandahåller digital infrastruktur, är leverantör av hanterade tjänster, tillhandahåller molntjänster eller faller inom en storleksoberoende kategori såsom DNS, TLD eller betrodda tjänster. DORA kan vara tillämpligt eftersom organisationen är en finansiell entitet eller en IKT-tredjepartsleverantör som stödjer finansiella entiteter. GDPR kan vara tillämpligt eftersom organisationen behandlar personuppgifter från EU, erbjuder tjänster till personer i EU eller övervakar beteende i EU.

För det tredje mappar det krav till interna kontroller, policyer, processer och system. Det är här registret blir operativt. Riskhanteringsåtgärder enligt NIS2 Article 21 mappas till riskbedömning, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker utveckling, granskning av kontrolleffektivitet, utbildning, kryptografi, åtkomstkontroll, tillgångshantering och MFA där det är relevant. DORA mappas till ledningsorganets ansvarsskyldighet, IKT-riskhantering, incidentklassificering, resiliensprovning, tredjepartsregister och exitstrategier. GDPR mappas till register över behandlingsaktiviteter, rättslig grund, uppgiftsminimering, datalagring, säkerhet i behandlingen, bedömning av personuppgiftsincident och underlag för ansvarsskyldighet.

För det fjärde tilldelar det ägare och granskningsfrekvens. Utan ägarskap blir efterlevnad ett mötesämne. Med ägarskap blir det en styrd process.

För det femte definierar det underlag. Registret ska besvara vilken artefakt som i dag visar att kravet uppfylls. Underlag kan omfatta styrelseprotokoll, poster från riskbedömningar, incidentärenden, leverantörsgranskningar, avtalsklausuler, krypteringskonfigurationer, sårbarhetsrapporter, åtkomstgranskningar, registreringar från säkerhetskopieringstester, integritetsmeddelanden, DPIA:er, bedömningar av personuppgiftsincidenter och revisionsiakttagelser från internrevision.

Clarysecs policy gör denna spårbarhet uttrycklig:

”Alla rättsliga och regulatoriska krav ska mappas till specifika policyer, kontroller och ägare inom ledningssystemet för informationssäkerhet.”
Från Policy för rättslig och regulatorisk efterlevnad, Krav för genomförande av policyn, klausul 6.2.1.

Den definierar också underlag som en del av samma mekanism:

”Nödvändiga artefakter eller poster för att visa efterlevnad (t.ex. revisionsloggar, krypteringsinställningar, dokumentation av samtycke)”
Från Policy för rättslig och regulatorisk efterlevnad, Krav för genomförande av policyn, klausul 6.2.2.3.

Detta är skillnaden mellan medvetenhet om efterlevnad och säkerställd efterlevnad.

Varför ISO/IEC 27001:2022 är ryggraden

ISO/IEC 27001:2022 behandlas ofta som ett certifieringsmål, men för kravhantering är värdet större. Standarden ger registret en hemvist i ledningssystemet.

Klausulerna 4.1 till 4.4 kräver att organisationen förstår interna och externa förhållanden, identifierar intressenter och fastställer rättsliga, regulatoriska och avtalsmässiga krav som är relevanta för ISMS. Klausulerna 5.1 till 5.3 kräver ledningens åtagande, policyanpassning, resurser och tilldelat ansvar. Klausulerna 6.1 till 6.2 kräver riskbedömning, riskbehandling, tillämpbarhetsförklaring och mätbara mål som utgår från tillämpliga krav. Klausulerna 8, 9 och 10 skapar den operativa cykeln: genomför kontroller, ompröva risker, övervaka prestanda, genomför internrevisioner, gör ledningens genomgång och korrigera avvikelser.

I Zenith Blueprint: en revisors färdplan i 30 steg placerar Clarysec detta tidigt i fasen ISMS-grund och ledarskap, steg 2: Intressentbehov och ISMS-omfattning. Blueprint rekommenderar team att identifiera intressentkrav genom att granska rättsliga och regulatoriska krav, extrahera avtalsmässiga säkerhetsklausuler, intervjua intressenter och beakta de branschstandarder som partner förväntar sig.

”Klausul 4.2 kräver inte ett specifikt dokument, men i praktiken är det användbart att skapa en intressentanalystabell. Det kan vara en enkel tabell med kolumnerna: Intressent, behov/förväntningar, hur vi hanterar det.”
Från Zenith Blueprint, fasen ISMS-grund och ledarskap, steg 2.

Den intressentanalysen blir den överordnade inputen till kravregistret. Registret blir därefter bryggan till riskbehandling.

I fasen Riskhantering, steg 13, anger Zenith Blueprint att team ska mappa kontroller till risker, klausuler och externa regelverk:

”Korsreferera regelverk: Om vissa kontroller genomförs specifikt för att uppfylla GDPR, NIS2 eller DORA kan du ange det antingen i riskregistret (som en del av motiveringen av riskpåverkan) eller i SoA-anteckningarna.”
Från Zenith Blueprint, fasen Riskhantering, steg 13: Riskbehandlingsplanering och tillämpbarhetsförklaring.

Det är den spårbarhet som revisorer efterfrågar. Om GDPR driver kontroller för kryptering, datalagring och bedömning av personuppgiftsincidenter, ange det. Om NIS2 driver eskalering av incidentrapportering och åtgärder för leverantörssäkerhet, ange det. Om DORA driver IKT-tredjepartsriskregister och exit-tester, ange det.

De tre kontrollförankringarna i ISO/IEC 27002:2022

Den centrala ISO/IEC 27002:2022-kontrollen för kravhantering är 5.31, Rättsliga, lagstadgade, regulatoriska och avtalsmässiga krav. Clarysecs Zenith Controls: guiden för övergripande efterlevnad klassificerar 5.31 som en förebyggande kontroll kopplad till konfidentialitet, riktighet och tillgänglighet, anpassad till cybersäkerhetskonceptet Identify och verksam inom kapabiliteten juridik och regelefterlevnad över domänerna styrning, ekosystem och skydd.

Budskapet i Zenith Controls är tydligt:

”Säkerhet existerar inte i ett vakuum. Den verkar inom ett nät av skyldigheter, vissa fastställda i lag, andra i avtal och ytterligare andra i sektorsspecifika regelverk.”
Från Zenith Controls, behandling av ISO/IEC 27002:2022-kontroll 5.31.

Kontroll 5.31 fungerar inte ensam. Två stödjande kontroller är avgörande.

Kontroll 5.2, Roller och ansvar för informationssäkerhet, säkerställer att krav inte tilldelas ”verksamheten” eller ”IT” i abstrakt form. Mappningen i Zenith Controls kopplar 5.2 till policyägarskap, övervakning av efterlevnad, incidenthantering, medvetenhet, oberoende granskning, hantering av underlag och styrning av privilegierad åtkomst.

Kontroll 5.36, Efterlevnad av policyer, regler och standarder för informationssäkerhet, sluter cirkeln. Den säkerställer att dokumenterade krav följs, övervakas, rapporteras och korrigeras. Mappningen i Zenith Controls kopplar 5.36 till policyer för informationssäkerhet, disciplinär process, oberoende granskning, roller och ansvar, händelsebedömning, loggning, övervakning och skyddade poster.

Tillsammans besvarar dessa kontroller revisorns kärnfrågor.

För mindre organisationer kan samma struktur vara lättare. Clarysecs Policy för rättslig och regulatorisk efterlevnad – SME anger:

”GM ska underhålla ett enkelt, strukturerat efterlevnadsregister som listar:”
Från Policy för rättslig och regulatorisk efterlevnad – SME, Styrningskrav, klausul 5.1.1.

Den kräver också regelbunden granskning:

”Efterlevnadsregistret ska granskas kvartalsvis och uppdateras när:”
Från Policy för rättslig och regulatorisk efterlevnad – SME, Styrningskrav, klausul 5.1.2.

För små och medelstora företag kan registret börja enkelt. Det behöver ändå ägarskap, frekvens och underlag.

Bygg registret kring krav, inte ramverk

Det vanligaste misstaget är att skapa en uppföljare för NIS2, en annan för DORA, en tredje för GDPR, en fjärde för ISO/IEC 27001:2022 och en femte för kundavtal. Det skapar dubblerade förfrågningar om underlag, motstridiga ägare och utmattade team.

Ett bättre angreppssätt är mappning från krav till kontroll. En säkerhetsförmåga kan uppfylla flera rättsliga drivkrafter om registret bevarar skillnaderna i utlösande händelse, omfattning, tidsfrist och behörig myndighet.

Exempelvis stödjer incidentrespons rapportering av betydande incidenter enligt NIS2, rapportering av större IKT-relaterade incidenter enligt DORA och bedömning av personuppgiftsincidenter enligt GDPR. Leverantörsgranskning stödjer säkerhet i leveranskedjan enligt NIS2, IKT-tredjepartsrisk enligt DORA och styrning av personuppgiftsbiträden enligt GDPR. Loggning och övervakning stödjer incidentdetektering, kontrolleffektivitet och ansvarsskyldighet. Tillgångsregister och dataregister stödjer riskbedömning enligt NIS2, DORA, GDPR och ISO/IEC 27001:2022.

Målet är inte att dölja rättsliga skillnader. Målet är att undvika att samma förmåga införs tre gånger.

En praktisk registermodell du kan införa den här veckan

Ett kravregister enligt Clarysecs modell ska vara tillräckligt enkelt att underhålla och tillräckligt detaljerat för att klara stickprov vid revision. Minsta uppsättning fält är:

1. Krav-ID.
2. Källa, såsom NIS2, DORA, GDPR, ISO/IEC 27001:2022, kundavtal eller intern policy.
3. Specifik artikel, klausul eller avtalsreferens.
4. Sammanfattning av kravet.
5. Motivering av tillämplighet.
6. Berörd verksamhetsprocess eller tjänst.
7. Riskscenario om kravet inte uppfylls.
8. Kontrollmappning, inklusive ISO/IEC 27002:2022-kontroller och interna policyreferenser.
9. Kontrollägare.
10. Ägare av underlag.
11. Granskningsfrekvens.
12. Plats för underlag.
13. Undantag eller öppna luckor.
14. Flagga för eskalering till ledningens genomgång.
15. Senaste granskningsdatum och nästa granskningsdatum.
16. Status.

Här är ett praktiskt exempel för en SaaS-baserad fintechleverantör som verkar i EU.

| Krav-ID | Källa och krav | Intern mappning | Ägare | Granskningsfrekvens | Underlag | |—|—|—|—|—| | OBL-001 | NIS2-tillämplighet och entitetsklassificering för digital infrastruktur eller verksamhet med hanterade tjänster | Policy för rättslig och regulatorisk efterlevnad, kontroll 5.31, ISMS-omfattning | Complianceansvarig | Kvartalsvis och vid tjänsteförändring | Tillämplighets-PM, uppgifter om entitetsregistrering, styrelsegenomgång | | OBL-002 | DORA IKT-tredjepartsriskhantering för kritiska eller viktiga IKT-tjänster | Rutin för leverantörssäkerhet, kontrollerna 5.19 till 5.23, DORA-leverantörsregister | Ägare av leverantörsrisk | Kvartalsvis och före ny kritisk leverantör | Leverantörsregister, leverantörsgranskning, avtalsklausuler, exit-test | | OBL-003 | GDPR-bedömning av personuppgiftsincident och ansvarsskyldighet | Incidenthanteringsplan, integritetsrutin, kontrollerna 5.24 till 5.28 och 5.34 | Dataskyddsombud och incidentansvarig | Per incident, kvartalsvis trendgranskning | Bedömning av personuppgiftsincident, incidentärende, beslut om anmälan, erfarenhetsåterföring | | OBL-004 | ISO/IEC 27001:2022 övervakning, internrevision och ledningens genomgång | Process för revision och efterlevnadsövervakning, kontroll 5.36 | ISMS-ansvarig | Årlig revisionsplan, kvartalsvis övervakning | Internrevisionsrapport, KPI-panel, logg över korrigerande åtgärder | | OBL-005 | Kundavtal kräver avisering av säkerhetsincident inom 24 timmar | Avtalsregister, åtgärdsplan för incidentkommunikation | Customer Success och juridik | Vid avtalsändring och per incident | Utdrag ur avtalsklausul, registrering av incidentkommunikation |

Observera hur varje rad går att agera på. Den säger inte bara ”följ DORA”. Den identifierar kravet, intern mappning, ägare, granskningsrytm och underlag.

Clarysecs Policy för styrningsroller och ansvar – SME förstärker denna ägarskapsdisciplin:

”Styrningsansvar (t.ex. policygranskning, undantagsgodkännande, tillsyn av leverantörer) ska tilldelas specifika personer eller roller.”
Från Policy för styrningsroller och ansvar – SME, Styrningskrav, klausul 5.3.

För företagsmiljöer bör samma koncept återspeglas i en RACI-matris, ett register över kontrollägarskap och ett rapporteringspaket till ledningen.

Exempel på incidentrapportering: en åtgärdsplan, flera krav

En SaaS-leverantör bedömer att den kan omfattas av NIS2 eftersom den tillhandahåller molntjänster eller hanterade tjänster i EU och uppfyller relevanta storleks- eller sektorkriterier. Organisationen har redan en incidenthanteringsplan, men har inte mappat NIS2-rapportering till eskaleringsrutiner.

Registerposten bör beskriva kravet exakt:

• Källa: NIS2 Article 23.
• Krav: underrätta CSIRT eller behörig myndighet utan onödigt dröjsmål vid betydande incidenter, med tidig varning inom 24 timmar, anmälan inom 72 timmar och slutrapport inom en månad.
• Tillämplighet: potentiellt tillämpligt på grund av tjänstekategori och verksamhet i medlemsstater.
• Risk om kravet inte uppfylls: regulatorisk överträdelse, försenad underrättelse till intressenter, förlorat kundförtroende.

Mappa sedan detta till kontroller. ISO/IEC 27002:2022-kontrollerna 5.24 till 5.28 täcker planering av incidenthantering, bedömning, respons, lärande och bevisinsamling. Kontroll 5.31 täcker uppföljning av rättsliga krav. Kontroll 5.2 täcker rolltilldelning. Kontroll 5.36 täcker övervakning av om processen följs.

Ägarskapet ska vara tydligt. Incidentansvarig äger klassificering och eskalering. Juridik eller compliancefunktionen äger tolkning gentemot tillsynsmyndighet och godkännande av anmälan. Kommunikation äger kundkommunikation. Ägaren av underlag underhåller incidentakten.

Underlaget bör omfatta posten för incidentklassificering, tidslinje, tidpunkt för kännedom, tidpunkt för triagering, tidpunkt för eskalering, beslut om anmälan, inlämning till tillsynsmyndighet om tillämpligt, beslut om kundkommunikation, erfarenhetsåterföring och korrigerande åtgärder.

En skrivbordsövning gör därefter registret verkligt. Använd ett scenario där en felkonfiguration i en molnmiljö orsakar potentiell exponering av kunddata och tjänstestörning. Testa om teamet kan identifiera 24-timmarsfristen enligt NIS2, avgöra om bedömning av personuppgiftsincident enligt GDPR krävs, klassificera potentiell DORA-påverkan om finansiella tjänster berörs och ta fram en fullständig incidentakt med underlag.

Det är så kravregistret blir en kontroll. Det förändrar det operativa beteendet.

Underlagshantering är där revisioner ofta misslyckas

Många organisationer kan visa upp ett register. Färre kan visa att underlaget är fullständigt, aktuellt, skyddat och länkat.

Clarysecs Policy för revision och efterlevnadsövervakning – SME anger grundkravet:

”Allt underlag ska lagras i en centraliserad revisionsmapp.”
Från Policy för revision och efterlevnadsövervakning – SME, Krav för genomförande av policyn, klausul 6.2.1.

Den meningen löser ett vanligt revisionsproblem. Underlag som är utspritt över e-post, Jira-ärenden, SharePoint-mappar, leverantörsportaler och personliga enheter är inte revisionsklart. Den centraliserade mappen behöver inte vara en bokstavlig mapp för varje fil, men det måste finnas ett kontrollerat revisionsarkiv eller index som visar revisorn var den auktoritativa artefakten finns.

För varje krav bör underlag namnges konsekvent, mappas till krav-ID och kontroll-ID, ägas av en namngiven person eller roll, skyddas mot obehörig ändring, bevaras enligt rättsliga och avtalsmässiga krav, granskas med fastställd frekvens och länkas till undantag och korrigerande åtgärder.

Behandlingen av kontroll 5.31 i Zenith Controls kopplar rättsliga krav till bevarande av poster genom kontroll 5.33, integritet och skydd av PII genom kontroll 5.34, oberoende granskning genom kontroll 5.35 och intern efterlevnad genom kontroll 5.36. Detta är viktigt eftersom underlaget i sig kan innehålla reglerad information, såsom personuppgifter, forensiska indikatorer, loggar över privilegierad åtkomst eller konfidentiella kunddata.

Revisionsperspektivet: hur olika granskare testar registret

Ett starkt register klarar flera revisionsperspektiv.

En ISO/IEC 27001:2022-revisor börjar med kontext, intressenter, omfattning, riskbehandling, tillämpbarhetsförklaring, övervakning, internrevision och ledningens genomgång. För kontroll 5.31 förväntar sig revisorn att tillämpliga rättsliga och avtalsmässiga krav identifieras, hålls aktuella och återspeglas i kontroller. För kontroll 5.2 testar revisorn om ansvar är tilldelat och förstått. För kontroll 5.36 söker revisorn efter övervakning, avvikelser och korrigerande åtgärder.

En granskare som följer NIST fokuserar på styrningsresultat. NIST Cybersecurity Framework 2.0 GOVERN omfattar GV.OC-03, som förutsätter att rättsliga, regulatoriska och avtalsmässiga cybersäkerhetskrav, inklusive skyldigheter avseende integritet och medborgerliga friheter, förstås och hanteras. Granskaren kan begära en organisationsprofil, gapanalys och prioriterad åtgärdsplan och därefter stickprova om kraven omsätts i tillgångshantering, åtkomstkontroll, dataskydd, loggning, respons och återställning.

En COBIT 2019- eller ISACA-revisor granskar genom styrnings- och ledningsmål. MEA03, Managed Compliance With External Requirements, är särskilt relevant. Revisorn kan testa om externa krav identifieras genom MEA03.01, om åtgärder optimeras genom MEA03.02, om efterlevnad bekräftas genom MEA03.03 och om säkerhet erhålls genom MEA03.04.

En ISACA ITAF-baserad revisor betonar tillräckligt och ändamålsenligt underlag. Revisorn kan välja ett krav på anmälan av personuppgiftsincident enligt GDPR, ett krav på leverantörsregister enligt DORA och ett krav på incidentrapportering enligt NIS2 och därefter begära hela revisionsspåret från början till slut.

En teknisk granskare kan validera kontroll 5.36 genom konfigurationsunderlag. Om registret anger att NIS2 och kundavtal kräver MFA för privilegierad åtkomst kan granskaren kontrollera inställningar hos identitetsleverantören. Om det anger att GDPR och avtal kräver kryptering kan granskaren inspektera databaskryptering, poster för nyckelhantering och dataflödesdiagram. Om DORA kräver övervakning av IKT-tredjepartstjänster kan granskaren inspektera tjänstegranskningar, SLA-rapporter och poster från exit-tester.

Registret behöver både styrningsunderlag och tekniskt underlag.

Ledningens genomgång sluter ansvarsskyldighetens kretslopp

Ett register över efterlevnadskrav ska inte ägas tyst av compliancefunktionen. Det måste nå ledningens genomgång eftersom NIS2, DORA, GDPR och ISO/IEC 27001:2022 alla bygger på ansvarsskyldighet.

NIS2 kräver att ledningsorgan godkänner cybersäkerhetsåtgärder för riskhantering och övervakar genomförandet. DORA lägger det yttersta ansvaret för IKT-riskhantering på ledningsorganet. GDPR kräver att personuppgiftsansvariga kan visa efterlevnad. ISO/IEC 27001:2022 kräver att ledningens genomgång beaktar förändringar i kontext, intressentbehov, revisionsresultat, övervakningsresultat, riskbedömningsresultat, status för riskbehandling och förbättringsmöjligheter.

Clarysecs Informationssäkerhetspolicy ligger i linje med denna förväntan:

”Ledningens genomgångsaktiviteter (enligt ISO/IEC 27001 klausul 9.3) ska genomföras minst årligen och ska omfatta:”
Från Informationssäkerhetspolicy, Styrningskrav, klausul 5.3.

SME-policyn för revision lägger till den operativa kopplingen:

”Revisionsiakttagelser och statusuppdateringar ska ingå i processen för ledningens genomgång av ISMS.”
Från Policy för revision och efterlevnadsövervakning – SME, Styrningskrav, klausul 5.4.3.

Ledningens genomgång behöver inte varje rad. Den behöver trender, riskbeslut, undantag, resurser och ansvarsskyldighet.

Detta omvandlar registret från en efterlevnadsakt till ett ledningsverktyg.

Vanliga felmönster och hur de undviks

Det första felmönstret är att juridik äger lagen, säkerhet äger kontrollerna och ingen äger mappningen. Clarysec motverkar detta genom att kräva att krav mappas till policyer, kontroller och ägare i ISMS.

Det andra är att följa upp ramverk i stället för krav. En registerpost som säger ”DORA” går inte att agera på. En registerpost som säger ”DORA Article 28 IKT-tredjepartsriskhantering kräver leverantörsgranskning, avtalsbestämmelser, övervakning och exitstrategier” går att agera på.

Det tredje är avsaknad av frekvens. Kvartalsvis granskning är en praktisk baslinje för många organisationer, med händelsestyrda uppdateringar vid nya tjänster, nya länder, nya leverantörer, incidenter, revisioner och avtalsändringar.

Det fjärde är underlag som finns men inte kan hittas. Principen om en centraliserad revisionsmapp hanterar detta direkt.

Det femte är informella undantag. Om en kontroll tillfälligt inte kan uppfylla ett krav ska undantaget dokumenteras, riskbedömas, godkännas, tidsbegränsas och granskas.

Det sjätte är ceremoniel ledningsgenomgång. Registret ska driva beslut om budget, bemanning, leverantörsåtgärder, avtalsförhandling, riskacceptans och korrigerande åtgärder.

Hur Clarysec gör registret till en operativ mekanism

Clarysecs 30-stegsmodell gör kravhantering praktisk.

I Zenith Blueprint identifierar steg 2 intressentbehov och tillämpliga krav. Steg 13 mappar kontroller till risker, klausuler och tillämpbarhetsförklaringen. Steg 23 behandlar organisatoriska kontroller, inklusive kravet att bygga och underhålla ett register över rättsliga och regulatoriska krav.

Blueprint anger:

”Arbeta med juridik, compliancefunktionen eller extern juridisk rådgivare för att bygga ett register över tillämpliga lagar, regelverk och avtalsmässiga skyldigheter kopplade till informationssäkerhet (5.31). Det bör omfatta dataskyddslagar (t.ex. GDPR), sektorsspecifika krav och certifieringskrav. Säkerställ att ISMS-teamet vet var registret finns och att ändringar granskas minst kvartalsvis.”
Från Zenith Blueprint, fasen Kontroller i praktiken, steg 23.

Clarysecs policyer tillhandahåller styrningsreglerna: underhåll registret, tilldela ansvar, centralisera underlag, granska iakttagelser och inkludera status i ledningens genomgång.

Zenith Controls tillhandahåller kompassen för övergripande efterlevnad. För kontroll 5.31 mappar den kravhantering till ansvarsskyldighet enligt GDPR, cybersäkerhetsskyldigheter enligt NIS2, IKT-riskhantering enligt DORA, NIST CSF-styrning, programhantering och kontinuerlig övervakning enligt NIST SP 800-53 samt extern efterlevnadsövervakning enligt COBIT 2019. För kontroll 5.2 kopplar den rollbaserad ansvarsskyldighet till GDPR, NIS2, DORA, NIST och COBIT. För kontroll 5.36 kopplar den policyefterlevnadsövervakning till ansvarsskyldighet enligt GDPR, förväntningar på cyberhygien och åtkomstkontroll enligt NIS2, operativ resiliens enligt DORA, kontinuerlig övervakning enligt NIST och övervakning av överensstämmelse enligt COBIT.

Värdet är enkelt: ett register, en kontrollarkitektur, många efterlevnadsresultat.

Nästa steg: gör ditt kravregister revisionsklart

De organisationer som hanterar efterlevnad väl under 2026 kommer inte att vara de med flest kalkylblad. Det kommer att vara de som har spårbarhet: krav till ägare, ägare till kontroll, kontroll till underlag, underlag till granskning och granskning till förbättring.

Börja med dessa åtgärder:

1. Skapa eller uppdatera ert register över cybersäkerhetsrelaterade efterlevnadskrav.
2. Lägg till NIS2, DORA, GDPR, ISO/IEC 27001:2022 och viktiga avtalsmässiga kundkrav.
3. Mappa varje krav till policyer, ISO/IEC 27002:2022-kontroller, ägare, granskningsfrekvens och underlag.
4. Identifiera luckor, undantag och utgånget underlag.
5. Lägg till registrets status i nästa ledningsgenomgång av ISMS.
6. Använd Clarysecs Zenith Blueprint för att placera registret i den 30-stegiga ISMS-färdplanen.
7. Använd Zenith Controls för att korsmappa krav till förväntningar enligt ISO, NIST, COBIT, GDPR, NIS2 och DORA.
8. Använd Clarysecs Policy för rättslig och regulatorisk efterlevnad, Policy för rättslig och regulatorisk efterlevnad – SME, Policy för styrningsroller och ansvar – SME, Policy för revision och efterlevnadsövervakning – SME och Informationssäkerhetspolicy för att formalisera ägarskap, granskning, lagring av underlag och ledningens ansvarsskyldighet.

Clarysec kan hjälpa er att bygga in den spårbarheten i ert ISMS innan revisorn, tillsynsmyndigheten, styrelseledamoten eller kunden efterfrågar den. Ladda ned relevanta Clarysec-policymallar, mappa era första tio krav den här veckan och omvandla efterlevnad från brandsläckning till ett operativt system.