Dataklassificering för ISO 27001, GDPR, NIS2 och DORA
Revisionsögonblicket 2026: ”Visa mig underlaget”
Det är februari 2026 och det kvartalsvisa styrelsemötet på ett snabbväxande SaaS-bolag inom fintech går inte riktigt så smidigt som informationssäkerhetschefen hade förväntat sig.
Företaget har nyligen uppnått ISO/IEC 27001:2022-certifiering. Det har MFA, endpointskydd, sårbarhetsskanningar, åtkomstgranskningar, incidenthanteringsrutiner och en väl genomarbetad DORA-beredskapsrapport. Då ställer VD:n frågan som förändrar mötet.
”Vår huvudinvesterare frågar hur vi kan bevisa att kundernas finansiella data skyddas konsekvent i AWS, Azure, vår SaaS-baserade supportplattform och vårt analyslager. Om en revisor hämtar en fil från objektlagring och en annan från en samarbetsmapp, hur vet vi att de omfattas av samma regler?”
Informationssäkerhetschefen öppnar tillgångsregistret. Det listar databaser, molnkonton, applikationer, SaaS-plattformar och lagringsplatser. Men klassificeringsfältet är ofullständigt. Vissa mappar är namngivna efter avdelning, inte efter känslighet. Kundexporter ligger bredvid interna rapportfiler. Vissa supportkalkylblad innehåller kundidentifierare, betalningsreferenser och ärendeanteckningar, men är märkta ”intern”. DLP-regler finns, men de utlöses bara av uppenbara mönster. Molnpolicyn säger att personuppgifter inom EU ska stanna i godkända regioner, men teamet kan inte visa att regler för dataresidens styrs av klassificeringsmetadata.
Då lägger regelefterlevnadschefen till den regulatoriska vinkeln: ”Kommer detta att uppfylla GDPR Article 32, NIS2 Article 21 och DORA-underlag för IKT-risk?”
Det ärliga svaret är: inte ännu.
Detta är den lucka många organisationer står inför 2026. De har säkerhetskontroller, men inte det styrningslager som talar om för varje kontroll vad som ska skyddas, hur starkt det ska skyddas och hur det ska kunna bevisas. Det styrningslagret är dataklassificering och informationsmärkning.
I ISO/IEC 27001:2022-termer är klassificering och märkning inte kosmetiska rutiner för dokumenthantering. De är den praktiska bryggan mellan riskbedömning, åtkomstkontroll, kryptering, datalagring, DLP, dataresidens i moln, leverantörsgranskning, övervakning och incidentrapportering. I Clarysecs införandemodell ligger de i centrum av underlagskedjan för ledningssystemet för informationssäkerhet: inventera tillgången, tilldela en ägare, klassificera den, märk den, tillämpa hanteringsregler, övervaka undantag och visa spårbarheten för revisorer.
Varför klassificering och märkning nu är kontroller på styrelsenivå
Tillsynsmyndigheter och kunder förväntar sig i allt högre grad att organisationer visar att säkerhetsåtgärderna är anpassade till datans känslighet, tjänstens kritikalitet och verksamhetskonsekvensen vid fel.
GDPR gör detta uttryckligt genom ansvarsskyldighet. Article 5 kräver att personuppgifter behandlas lagligt, korrekt och öppet, begränsas till vad som är nödvändigt, bevaras endast så länge det behövs och skyddas med lämpliga tekniska och organisatoriska åtgärder. Den personuppgiftsansvarige måste också kunna visa efterlevnad. GDPR Article 32 blir därefter svår att styrka utan kunskap om vilka system som behandlar personuppgifter, vilka data som är högrisk eller särskilda kategorier av personuppgifter, var de lagras och vilka skyddsåtgärder som gäller.
NIS2 höjer ribban för styrning. Article 20 kräver att ledningsorgan hos väsentliga och viktiga entiteter godkänner åtgärder för hantering av cybersäkerhetsrisker, utövar tillsyn över genomförandet och får utbildning. Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, säkerhetspolicyer, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säkerhet vid anskaffning och utveckling, effektivitetsbedömning, cyberhygien, utbildning, kryptografi, HR-säkerhet, åtkomstkontroll och tillgångshantering. Klassificering är inte ett separat kontrollkrav i den listan. Det är beslutssystemet som gör dessa åtgärder proportionerliga.
DORA tillämpar samma logik på finansiella entiteter och fintech-ekosystem. Sedan den 17 januari 2025 kräver DORA ett dokumenterat ramverk för IKT-riskhantering, ansvar hos ledningsorganet, policyer för konfidentialitet, riktighet, tillgänglighet och autenticitet, incidentklassificering, resiliensprovning och riskhantering för IKT-tredjepart. För finansiella entiteter som omfattas av DORA kan DORA fungera som den sektorsspecifika unionsrättsakten i stället för överlappande skyldigheter enligt NIS2 avseende riskhantering och rapportering, men förväntan på underlag är densamma: visa hur kritisk information och IKT-tillgångar identifieras, skyddas, testas, övervakas och styrs.
ISO/IEC 27001:2022 lämpar sig väl som operativt system för detta underlag. Clauses 4.1 to 4.4 kräver att organisationen förstår interna och externa frågor, intressentkrav, regulatoriska och avtalsmässiga skyldigheter samt gränssnitt mot andra organisationer. Clauses 6.1.1 to 6.1.3 kräver riskbedömning, riskbehandling, urval av kontroller, en Statement of Applicability och bevarat underlag. ISO/IEC 27001:2022
Om GDPR, NIS2 och DORA frågar: ”Varför tillämpade ni dessa åtgärder?” hjälper ISO/IEC 27001:2022 er att svara: ”Därför att dessa tillgångar, datatyper, risker, skyldigheter och riskbehandlingsbeslut ledde oss hit.”
Klassificering är riskbeslutet. Märkning är den operativa signalen.
Clarysec skiljer mellan klassificering och märkning eftersom revisorer gör det.
Klassificering är handlingen att besluta om informationens känslighet, värde och kritikalitet. Märkning är handlingen att göra beslutet synligt, beständigt och möjligt att tillämpa i den dagliga verksamheten.
Clarysecs policy för dataklassificering och märkning – SME anger syftet tydligt:
Denna policy definierar hur all information som hanteras av organisationen ska klassificeras och märkas för att säkerställa att dess konfidentialitet, riktighet och tillgänglighet upprätthålls under hela livscykeln.
Samma policy för dataklassificering och märkning – SME kräver att organisationer ska:
Kräva att varje datatillgång klassificeras enligt sin känslighet och märks därefter för att styra korrekt hantering, lagring och åtkomst.
För större organisationsmiljöer definierar Clarysecs P13 policy för dataklassificering och märkning den minsta klassificeringsmodellen:
Organisationen ska upprätthålla ett standardiserat klassificeringsschema med tydligt definierade nivåer. Minst följande klassificeringsnivåer ska användas: 5.1.1 Publik: Information avsedd för öppen publicering och obegränsad distribution 5.1.2 Intern: Icke-publik verksamhetsinformation som inte är avsedd för extern spridning 5.1.3 Konfidentiell: Känsliga verksamhetsdata, avtalsdata eller kunddata som kräver strikt åtkomstkontroll 5.1.4 Begränsad (eller mycket konfidentiell): Kritisk eller reglerad information där obehörigt röjande kan orsaka betydande skada eller rättsligt ansvar
Den distinktionen är viktig. En klassificering som ”Konfidentiell” kan kräva kryptering, rollbaserad åtkomst och avtalsmässiga skyddsåtgärder. En klassificering som ”Begränsad” kan utlösa MFA, godkännande av informationssäkerhetschefen för extern delning, utökad loggning, starkare styrning av bevarande, separation och prioriterad incidenteskalering.
Företagspolicyn är tydlig om operativ märkning:
Alla informationstillgångar ska märkas på ett sätt som är: 6.2.1.1 Beständigt: Inte enkelt att ta bort eller åsidosätta 6.2.1.2 Synligt: Tydligt för användare vid användningstillfället 6.2.1.3 Maskinläsbart: Där det är möjligt ska metadatabaserad taggning stödjas
Maskinläsbara etiketter är där programmet mognar från medvetenhet till tillämpning. Om etiketter är metadatabaserade kan molnplattformar, DLP-system, e-postgateways, identitetsverktyg, SIEM-regler, CASB-plattformar och bevarandemotorer agera på dem. Om etiketter bara är en sidfot i ett dokument kan de hjälpa användare, men de kan inte tillförlitligt genomdriva regler i stor skala.
Var klassificering hör hemma i Clarysecs färdplan
Clarysecs Zenith Blueprint: en revisors färdplan i 30 steg placerar klassificering tidigt i riskhanteringslivscykeln, inte efter teknikdriftsättning. I fasen Riskhantering, steg 9, ”Identifiera tillgångar, hot och sårbarheter”, instruerar färdplanen team att inventera informationstillgångar och registrera ägare, plats och klassificering.
Detta förhindrar ett vanligt fel: att ha en molninventering men ingen informationsinventering. En databas, SaaS-klient eller ett datalager är en tekniktillgång. Kundregister, anställdas akter, betalningsloggar, träningsdataset för modeller, supporttranskript och incidentunderlag inuti dem är informationstillgångar. Klassificering hör hemma på informationsnivån.
Vägledningen i Zenith Blueprint om ISO/IEC 27002:2022 kontroll 5.12, Classification of information, förklarar principen:
Varje informationssäkerhetskontroll som någonsin skrivits, åtkomstbegränsning, kryptering, säkerhetskopiering, övervakning eller bortskaffning, förutsätter en sak: att organisationen vet vad den skyddar. Kontroll 5.12 kräver att information klassificeras utifrån sitt värde, sin känslighet och sin kritikalitet, vilket utgör grunden för alla efterföljande beslut inom ledningssystemet för informationssäkerhet.
För ISO/IEC 27002:2022 kontroll 5.13, Labelling of information, gör samma färdplan klassificering till dagligt beteende:
Märkning är hur du omvandlar abstrakt policy till operativ verklighet. Det är ögonblicket när en användare, genom att se ett dokument, ett e-postmeddelande, ett databasfält eller en utskriven rapport, direkt kan avgöra: vad informationen är, hur känslig den är och hur den ska behandlas.
Den sista kopplingen i färdplanen finns i steg 13, ”Planering av riskbehandling och Statement of Applicability”. Zenith Blueprint beskriver SoA som bryggan mellan risker, riskbehandlingar och kontroller. Det är här klassificering blir spårbarhet vid revision. Ett riskscenario som ”obehörigt röjande av kunders finansiella data från delad molnlagring” kan mappas till klassificering, märkning, åtkomstkontroll, kryptering, loggning, DLP, molnanvändning, leverantörskrav och incidenthantering.
De kontrollrelationer revisorer förväntar sig att se
I Clarysecs Zenith Controls: vägledning för korsvis regelefterlevnad mappas ISO/IEC 27002:2022 kontroll 5.12, Classification of information, som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet. Den kopplas till cybersäkerhetskonceptet Identify, den operativa förmågan Information Protection och säkerhetsdomänerna Protection and Defense.
För ISO/IEC 27002:2022 kontroll 5.13, Labelling of information, mappar Zenith Controls kontrollen som förebyggande, med fokus på Protect, med samma informationssäkerhetsegenskaper och samma operativa förmåga inom Information Protection.
Den avgörande insikten är att klassificering och märkning inte är isolerade. De gör omgivande kontroller försvarbara.
| Kontrollområde enligt ISO/IEC 27002:2022 | Varför det beror på klassificering eller märkning | Underlag som en revisor kan begära |
|---|---|---|
| 5.9 Förteckning över information och andra associerade tillgångar | Klassificeringsmetadata bör vara ett kärnfält i tillgångsförteckningen | Tillgångsregister som visar ägare, plats, livscykelstatus och klassificering |
| 5.12 Klassificering av information | Definierar känslighet, värde och kritikalitet | Godkänt klassificeringsschema, kriterier, exempel och granskningsprotokoll |
| 5.13 Märkning av information | Gör klassificering synlig och möjlig att tillämpa | Etikettkonfiguration, exempel på märkta filer, e-postetiketter, SaaS-taggar och användarvägledning |
| 5.14 Informationsöverföring | Avgör om extern delning, kryptering eller godkännande krävs | Överföringsregler per klassificering, godkända kanaler och undantagsuppgifter |
| 5.15 Åtkomstkontroll | Åtkomstbehörigheter bör följa klassificeringsgränser | Rollmatris, åtkomstgranskning, regler för privilegierad åtkomst och godkännandehistorik |
| 5.25 Bedömning av och beslut om informationssäkerhetshändelser | Incidentens allvarlighetsgrad beror delvis på känsligheten hos berörda data | Incidenttriageringskriterier som använder klassificering och tjänstekritikalitet |
| 5.34 Integritet och skydd av PII | Kategorier av personuppgifter behöver integritetsspecifik hantering | PII-register, kartläggning av rättslig grund, bevaranderegler och kontroller för personuppgiftsbiträden |
| 8.15 Loggning | Åtkomst till Begränsade data kräver starkare spårbarhet | Åtkomstloggar för data, inställningar för logglagring och granskningsunderlag |
| 8.16 Övervakningsaktiviteter | Övervakningsprioritet ändras när Begränsade data berörs | SIEM-användningsfall, larmtrösklar och eskaleringsuppgifter |
Zenith Controls mappar kontroll 5.12 till GDPR Article 32 och Recital 83, NIS2 Article 21(2)(a) och 21(2)(f), ISO/IEC 27701 Annex B, NIST SP 800-53 MP-3 och PM-11, FIPS 199 och NIST SP 800-60 samt COBIT 2019 DSS06.06 och APO13.01. Den mappar kontroll 5.13 till GDPR Article 32, NIS2 Article 21(2)(a) och 21(2)(f), DORA Article 9(1) och 9(2), NIST SP 800-53 MP-3 och COBIT 2019 DSS06.06.
Det innebär att en uppsättning underlag kan besvara flera försäkransfrågor.
| Efterlevnadsdrivare | Bidrag från klassificering och märkning | Praktiskt bevis |
|---|---|---|
| GDPR Article 32 | Visar vilka personuppgifter som kräver skyddsåtgärder för konfidentialitet, riktighet, tillgänglighet och resiliens | PII-klassificering, krypteringsregler, åtkomstbegränsningar, bevarandemappning och kriterier för triagering av incidentanmälningar |
| NIS2 Article 21 | Stödjer riskanalys, säkerhetspolicyer, effektivitetsbedömning, åtkomstkontroll, tillgångshantering och proportionerliga åtgärder | Policy godkänd av ledningen, tillgångsförteckning, utbildning, granskningsmätetal och testade hanteringsregler |
| DORA IKT-riskhantering | Stödjer identifiering och skydd av information och IKT-tillgångar, incidentklassificering och IKT-tredjepartsrisk | IKT-tillgångsregister, datakritikalitet, leverantörsavtalskrav, testomfattning och kriterier för incidenters allvarlighetsgrad |
| NIST CSF 2.0 | Stödjer resultaten GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND och RECOVER | Aktuella profiler och målprofiler med klassificeringsluckor och prioriterade åtgärder |
| COBIT 2019 | Stödjer styrnings- och processkontroller för säkerhet, datahantering och kontrolldrift | Kontrollmål, processägarskap, säkerhetstestning och hantering av undantag |
Tillgångsregistret är där klassificering blir underlag
Många klassificeringsprogram misslyckas eftersom klassificeringsschemat endast finns i en policy. Clarysecs arbetssätt börjar med tillgångsförteckningen.
Clarysecs P12 policy för tillgångshantering kräver att tillgångsförteckningen innehåller klassificeringsnivå som minsta fält:
Tillgångsförteckningen ska minst innehålla: 5.3.1 Tillgångs-ID, kategori och typ 5.3.2 Serienummer eller unik tagg (för fysiska tillgångar) 5.3.3 Programvaruversion eller licensnyckel (för programvarutillgångar) 5.3.4 Tillgångsägare 5.3.5 Klassificeringsnivå (Publik, Intern, Konfidentiell, Begränsad) 5.3.6 Plats (fysisk, virtuell, moln) 5.3.7 Livscykelstatus (aktiv, under underhåll, avvecklad)
Detta ligger direkt i linje med riskplaneringen i ISO/IEC 27001:2022. Om du inte kan identifiera informationstillgången, ägaren, platsen och klassificeringen kan du inte konsekvent bedöma sannolikhet, konsekvens, behandlingsprioritet eller kvarstående risk. Du kan inte heller med säkerhet avgöra om ett leverantörsupplägg, en molntjänst eller en SaaS-integration påverkar reglerad information.
För GDPR stödjer detta ansvarsskyldighet. Article 30-register över behandlingsaktiviteter och säkerhetsåtgärder enligt Article 32 blir mer trovärdiga när tillgångsregister identifierar var personuppgifter behandlas och hur de skyddas. För DORA stödjer samma register kritikalitet för IKT-tillgångar och tjänster, omfattning för resiliensprovning och analys av tredjepartsberoenden. För NIS2 stödjer det riskanalys, åtkomstkontroll och tillgångshantering.
| Fält | Exempelpost |
|---|---|
| Tillgångsnamn | Kundfaktureringsdatabas |
| Tillgångsägare | Chef för plattformsteknik |
| Verksamhetsprocess | Abonnemangsdebitering och fakturering |
| Plats | EU-molnregion, hanterad databastjänst |
| Klassificering | Begränsad |
| Datakategorier | Kundidentifierare, faktureringskontaktuppgifter, transaktionsreferenser |
| GDPR-relevans | Personuppgifter, sammanhang för personuppgiftsansvarig och personuppgiftsbiträde |
| Kritikalitet | Stödjer intäktsverksamhet och kundservice |
| Nyckelkontroller | MFA, kryptering i vila, kryptering under överföring, godkännande för privilegierad åtkomst, revisionsloggning, testning av säkerhetskopiering |
| Leverantörsberoende | Molndatabasleverantör, betalningsförmedlare |
| Granskningsfrekvens | Kvartalsvis åtkomstgranskning, årlig klassificeringsgranskning, granskning vid systemändring |
Den här typen av post förändrar tonen i en revision. I stället för att säga ”Vi tror att känsliga data är skyddade” kan organisationen visa vad datan är, vem som äger den, varför den är Begränsad, vilka kontroller som gäller och när dessa kontroller senast granskades.
Etiketter måste styra hanteringsregler för moln och SaaS
De flesta känsliga data rör sig nu genom molnplattformar, SaaS-applikationer, analysflöden och samarbetsverktyg. En policy som säger åt användare att ”hantera konfidentiella data varsamt” räcker inte.
Clarysecs P27 Policy för användning av molntjänster kopplar molnanvändning direkt till klassificering och dataresidens:
Dataklassificering och dataresidens 6.6.1 Inga data får flyttas till en molnplattform utan klassificering i enlighet med policy för dataklassificering och märkning (P13). 6.6.2 Krav på dataresidens ska regleras avtalsmässigt (t.ex. endast EU-lagring för data som regleras av GDPR). 6.6.3 Gränsöverskridande dataöverföringar ska följa GDPR Chapter V och, där tillämpligt, DORA Article 28.
Detta är viktigt eftersom molnrisk ofta uppstår av bekvämlighet. Ett team exporterar ett dataset till ett nytt analysverktyg. Säljteamet synkroniserar kundlistor till en automatiseringsplattform. En utvecklare kopierar produktionsdata till en testmiljö. Utan klassificering och märkning kanske dessa åtgärder inte utlöser juridisk granskning, säkerhetsgodkännande eller leverantörskontroller.
Policy för dataklassificering och märkning – SME ger mindre organisationer ett enkelt genomförandemönster:
Delade mappar eller molnlagringar ska använda mappnamn eller taggar för att ange klassificering (t.ex. ”/Clients_Confidential”).
För mogna miljöer bör mappnamn kompletteras med maskinläsbara etiketter, policyer för villkorad åtkomst, blockering av extern delning, kryptering, bevarandeetiketter, DLP-regler och loggning. Målet är inte bara att märka information. Målet är att göra etiketten handlingsbar.
En etikett för ”Begränsad” kan utlösa blockering av extern delning, kryptering i vila och under överföring, MFA, nedladdningsbegränsningar på ohanterade enheter, bevarande av revisionsloggar, SIEM-larm, bevaranderegler, platsbegränsningar för leverantörer och eskalering av incidenters allvarlighetsgrad.
P13 policy för dataklassificering och märkning fastställer baslinjen:
All datahantering, överföring, åtkomst, lagring och bortskaffning av information ska vara anpassad till dess klassificeringsnivå. Minst följande gäller: 6.3.1.1 Publik: Får röjas fritt; ingen särskild hantering krävs 6.3.1.2 Intern: Delas inom organisationen; lagras i säkra interna system 6.3.1.3 Konfidentiell: 6.3.1.3.1 Åtkomst begränsas endast till behöriga personer 6.3.1.3.2 Ska krypteras under överföring och i vila 6.3.1.3.3 Får endast delas externt enligt ett NDA eller likvärdiga avtalsmässiga skyddsåtgärder 6.3.1.4 Begränsad: 6.3.1.4.1 Högsta säkerhetskrav gäller 6.3.1.4.2 Starka åtkomstkontroller, flerfaktorsautentisering (MFA) och revisionsloggning krävs 6.3.1.4.3 Fysisk och logisk separation där det är möjligt 6.3.1.4.4 Extern delning är förbjuden utan godkännande från informationssäkerhetschefen
Varje etikett har ett beteende. Varje beteende har en kontroll. Varje kontroll har underlag.
Ett praktiskt exempel på tillämpning
Tänk dig en fintech-analytiker som skapar Q3_2026_Customer_Churn_Analysis.xlsx. Kalkylbladet innehåller kund-ID:n, transaktionsvolymer och prediktiv churn-poängsättning.
Analytikern klassificerar det som Konfidentiell eftersom det innehåller kunddata och strategisk analys. Med organisationens verktyg för informationsskydd tillämpar analytikern etiketten Konfidentiell. Eftersom etiketten är beständig, synlig och maskinläsbar aktiveras kontroller automatiskt.
Filen krypteras i vila på enheten och i molnlagring. En synlig rubrik markerar den som Konfidentiell. När analytikern försöker synkronisera den till en personlig molnlagring blockerar en DLP-regel åtgärden och loggar försöket. När analytikern försöker skicka den via e-post till en extern domän som inte tillhör en partner sätter e-postgatewayen meddelandet i karantän och larmar säkerhetsdriften. Om filen senare omklassificeras som Begränsad eftersom den innehåller reglerade finansiella transaktionsdata inaktiveras extern delning om inte informationssäkerhetschefen eller dataägaren godkänner undantaget.
Detta är beviset som VD:n efterfrågade. Det är spårbart, automatiserat och kopplat till en policy som godkänts av styrelsen. Det är också i linje med P27 Policy för användning av molntjänster, eftersom ingen förflyttning till moln är tillåten utan klassificering och gränsöverskridande överföringar måste uppfylla GDPR Chapter V och, där tillämpligt, DORA Article 28.
Bygg en klassificerings- och kontrollmatris på en vecka
Ett fullständigt program tar tid, men en fokuserad sprint kan skapa underlagsryggraden före en revision, kundgranskning eller regulatorisk bedömning.
Dag 1: Bekräfta klassificeringsschemat
Börja med fyra nivåer: Publik, Intern, Konfidentiell och Begränsad. Använd P13 policy för dataklassificering och märkning som baslinje. Definiera kriterier utifrån verksamhetskonsekvens, rättslig påverkan, avtalsmässig känslighet, risk för personuppgifter, tjänstekritikalitet och ekonomisk skada.
| Klassificering | Typiska exempel | Risklogik |
|---|---|---|
| Publik | Godkänt marknadsföringsinnehåll, pressmeddelanden, jobbannonser | Avsedd för obegränsad distribution |
| Intern | Interna rutiner, projektanteckningar, interna meddelanden | Icke-publik verksamhetsinformation |
| Konfidentiell | Kundavtal, HR-akter, icke-publik finansiell rapportering | Känsliga verksamhetsdata, avtalsdata eller kunddata |
| Begränsad | Särskilda kategorier av personuppgifter, betalningsdata, autentiseringshemligheter, produktionsdatabaser med kunddata | Kritisk eller reglerad information med betydande rättslig eller verksamhetsmässig påverkan |
Dag 2: Välj tio kritiska informationstillgångar
Använd Zenith Blueprint steg 9. Inkludera en kunddatabas, ett supportärendesystem, en HR-plattform, en identitetsleverantör, en betalningsexport, ett datalager, en bucket i objektlagring, en styrelserapporteringsmapp, en lagringsplats för källkod och en lagringsplats för incidentunderlag. Registrera ägare, plats, klassificering och GDPR-relevans.
Dag 3: Mappa hanteringsregler
Definiera hanteringskrav för åtkomst, lagring, överföring, övervakning och bortskaffning.
| Klassificering | Åtkomst | Lagring | Överföring | Övervakning | Bortskaffning |
|---|---|---|---|---|---|
| Publik | Öppna eller godkända publiceringsroller | Godkända publika kanaler | Ingen särskild begränsning efter godkännande | Grundläggande övervakning av riktighet | Standardradering |
| Intern | Anställda och godkända uppdragstagare | Hanterade system | Interna kanaler | Standardmässiga åtkomstloggar | Standardschema för bevarande |
| Konfidentiell | Åtkomst efter behovsprövning | Godkända säkra dokumentarkiv | Kryptering och NDA eller avtalsmässiga skyddsåtgärder | Åtkomstgranskning och DLP-larm | Säker radering |
| Begränsad | Minsta privilegium med MFA och ägargodkännande | Separerade eller härdade system | Extern delning förbjuden om den inte godkänts | Utökad revisionsloggning och SIEM-larmning | Verifierad säker förstöring |
Dag 4: Konfigurera en teknisk tillämpningsväg
Välj en plattform, till exempel ett molnbaserat dokumentarkiv, e-postsystem eller objektlagringstjänst. Inför synliga och maskinläsbara etiketter. Konfigurera en regel för Konfidentiella data och en regel för Begränsade data. Kräv till exempel kryptering för externa e-postmeddelanden med Konfidentiellt innehåll och blockera extern delning av Begränsade filer.
Dag 5: Uppdatera riskregistret och SoA
Använd Zenith Blueprint steg 13. Lägg till klassificerings- och märkningskontroller i Statement of Applicability. Koppla dem till risker som obehörigt röjande, felkonfiguration av moln, överexponering via leverantörer, bristande databevarande och underrapportering av incidenter.
Dag 6: Testa kontrollen
Skapa en testfil märkt Begränsad. Försök dela den externt från en ohanterad enhet. Bekräfta om verktyget blockerar, varnar, loggar eller eskalerar. Samla skärmbilder, loggposter och ärendeunderlag. Om kontrollen misslyckas, registrera undantaget och åtgärdsplanen.
Dag 7: Utbilda förstalinjeanvändarna
Utbildningen bör vara rollspecifik. Utvecklare behöver veta när produktionsdata inte får användas i testmiljöer. HR behöver förstå varför anställdas akter är Konfidentiella eller Begränsade. Sälj behöver veta varför kundexporter inte får laddas upp i icke-godkända SaaS-verktyg. Ledande befattningshavare behöver förstå varför styrelsematerial, förvärvsfiler och investerardata kräver starkare hantering.
Denna sprint slutför inte hela programmet, men den skapar underlagsryggraden: policy, förteckning, etiketter, hanteringsregler, tekniskt genomdrivande, riskspårbarhet och utbildning.
Hur revisorer testar klassificering och märkning
Revisorer testar sällan klassificering isolerat. De följer datan.
En ISO/IEC 27001:2022-revisor kopplar klassificering till ledningssystemets omfattning, intressentkrav, rättsliga och avtalsmässiga skyldigheter, riskbedömning och Statement of Applicability. De förväntar sig underlag för ISO/IEC 27002:2022-kontrollerna 5.9, 5.12, 5.13, 5.14, 5.15, 5.34 och relevanta tekniska kontroller. Typiskt underlag omfattar godkända policyer, poster i tillgångsförteckningen, poster i riskregistret, märkta exempel, hanteringsregler, åtkomstgranskningar, internrevisionsiakttagelser och korrigerande åtgärder.
En GDPR-granskare fokuserar på personuppgifter. Granskaren frågar om personuppgifter identifieras, om särskilda kategorier av uppgifter särskiljs, om bevaranderegler är anpassade till ändamålet och om säkerhetsåtgärder enligt Article 32 är lämpliga. Klassificering hjälper till att skilja vanlig verksamhetsinformation från personuppgifter, känsliga personuppgifter, konfidentiella kunddata och reglerade register. Märkning hjälper operativa team att undvika oavsiktligt röjande, överbevarande och obehörig överföring.
En NIST CSF 2.0-bedömare kommer sannolikt att placera klassificering under GOVERN, IDENTIFY och PROTECT. Bedömaren kan fråga om aktuella profiler och målprofiler definierar upptäckt av känsliga data, om etiketttillämpning fungerar över SaaS- och molnsystem, om leverantörer hanterar data enligt klassificering och om övervakningsprioriteter justeras utifrån känslighet.
En COBIT 2019- eller ISACA-liknande revisor betonar styrningsmål, processägarskap, kontrolldesign och operativ effektivitet. Zenith Controls mappar inventeringskontroll 5.9 till COBIT 2019 BAI09.01, BAI09.02 och DSS05.04, och refererar till ISACA ITAF 2204 och 2301. För klassificering mappar Zenith Controls kontroll 5.12 till COBIT 2019 DSS06.06 och APO13.01, medan märkning mappas till DSS06.06. Revisorn frågar vem som äger processen, hur undantag godkänns, om prestation övervakas och om ledningen får rapportering.
En DORA-inriktad granskare frågar vilka informationstillgångar som stödjer kritiska eller viktiga funktioner, vilka data som är Begränsade, vilka IKT-tredjepartsleverantörer som lagrar eller överför dessa data, om avtal definierar platser och säkerhetsåtgärder, om testningens omfattning omfattar kritiska data och om incidenter klassificeras delvis utifrån dataförlust över tillgänglighet, autenticitet, riktighet och konfidentialitet.
Om svaren kommer från en klassificeringsdriven modell för tillgångs- och leverantörsunderlag blir revisioner snabbare, mer konsekventa och mer försvarbara.
Vanliga felmönster
Klassificeringsfel uppstår vanligtvis eftersom organisationer behandlar etiketter som medvetenhetsverktyg i stället för kontrollsignaler.
För det första klassificerar de dokument men inte databaser, API:er, loggar, säkerhetskopior, exporter eller SaaS-poster. Känsliga data i en felsökningslogg kan vara lika skadliga som känsliga data i ett kalkylblad.
För det andra märker de information men kopplar inte etiketter till åtkomstkontroll. En Begränsad etikett med öppen åtkomst visar att organisationen kände till känsligheten men inte tillämpade hanteringsregeln.
För det tredje sker molnmigreringar före klassificering. Team flyttar data till nya SaaS-verktyg utan att bekräfta dataresidens, leverantörsvillkor, åtkomst för underbiträden, krav på gränsöverskridande överföringar eller raderingsrättigheter. P27 Policy för användning av molntjänster adresserar detta direkt genom att förbjuda flytt till molnplattformar utan klassificering.
För det fjärde ignorerar incidenthanteringsplaner klassificering. Om kriterier för allvarlighetsgrad inte omfattar datakänslighet förlorar incidentteam tid på att upptäcka vad som påverkats under en kris. GDPR-analys av incidentanmälan, NIS2-incidenthantering och DORA-incidentklassificering gynnas alla av snabb datakontext.
För det femte förklarar inte SoA varför klassificerings- och märkningskontroller är tillämpliga. Organisationen kan ha infört etiketter, men SoA kopplar dem inte till GDPR Article 32, NIS2 Article 21, DORA IKT-risk, kundavtal eller specifika riskscenarier.
Ledningsrapportering: gör klassificering synlig
NIS2 och DORA gör cybersäkerhet till en fråga om ansvarsskyldighet för ledningen. ISO/IEC 27001:2022 kräver också ledningens åtagande, policyanpassning, resurser, roller och prestationsrapportering. Klassificeringsmätetal bör därför ingå i ledningens genomgång.
Användbara mätetal omfattar:
- Andel kritiska informationstillgångar med tilldelade ägare.
- Andel tillgångar med godkänd klassificering.
- Antal Begränsade tillgångar utan utökad loggning.
- Antal Konfidentiella eller Begränsade dokumentarkiv med extern delning aktiverad.
- Andel leverantörer som behandlar Konfidentiella eller Begränsade data med uppdaterade avtalsklausuler.
- Antal klassificeringsundantag och försenade åtgärder.
- DLP-incidenter per etikett.
- Slutförd åtkomstgranskning för Begränsade tillgångar.
- Molnlagringsplatser för data som regleras av GDPR.
- Incidenthanteringsövningar som använde klassificeringsbaserade kriterier för allvarlighetsgrad.
Dessa mätetal stödjer ledningens genomgång enligt ISO/IEC 27001:2022, NIS2-ledningstillsyn, DORA-styrningsrapportering och kundförsäkran. De gör också klassificering begriplig för ledande befattningshavare. Ledningen kan agera snabbare när den ser att flera Begränsade dokumentarkiv saknar testad återställning eller att kritiska leverantörer behandlar kunddata utan bekräftad EU-lagring.
Från policy till bevis
Clarysecs införandemönster är underlagsdrivet:
- Definiera klassificeringsschemat i P13 policy för dataklassificering och märkning eller börja med policy för dataklassificering och märkning – SME.
- Lägg till klassificering i tillgångsförteckningen med hjälp av P12 policy för tillgångshantering.
- Tillämpa molnbegränsningar och krav på dataresidens genom P27 Policy för användning av molntjänster.
- Använd Zenith Blueprint steg 9 för att identifiera informationstillgångar, ägare, platser och känslighet.
- Använd Zenith Blueprint steg 13 för att mappa risker till kontroller i SoA.
- Använd Zenith Blueprint steg 22 för att införa ISO/IEC 27002:2022-kontrollerna 5.12 och 5.13 i den dagliga verksamheten.
- Använd Zenith Controls för att mappa samma underlag till GDPR, NIS2, DORA, NIST CSF, COBIT 2019 och stödjande standarder.
- Testa tillämpning av etiketter, åtkomstbegränsningar, loggning, DLP och incidenttriage.
- Rapportera klassificeringsprestation till ledningen.
- Granska klassificering efter större system-, process-, leverantörs- eller regulatoriska förändringar.
Detta fungerar eftersom klassificering blir det gemensamma språket mellan verksamhetsvärde, rättslig skyldighet, teknisk kontroll och revisionsunderlag.
Om din organisation förbereder sig för ISO/IEC 27001:2022-certifiering, GDPR-försäkran, NIS2-beredskap, DORA-kundgranskning eller en kombinerad regelefterlevnadsrevision, börja med en fråga:
Kan ni visa, för varje kritisk informationstillgång, vad den är, vem som äger den, var den finns, hur den är klassificerad, hur den är märkt, vem som kan komma åt den, hur den skyddas, hur länge den bevaras, vilken leverantör som hanterar den och vad som händer om den exponeras?
Om svaret är ”inte ännu” kan Clarysec hjälpa er att bygga underlagskedjan snabbt och försvarbart.
Använd policy för dataklassificering och märkning – SME, P13 policy för dataklassificering och märkning, P12 policy för tillgångshantering, P27 Policy för användning av molntjänster, Zenith Blueprint: en revisors färdplan i 30 steg och Zenith Controls: vägledning för korsvis regelefterlevnad för att omvandla klassificering från en statisk policy till ett operativt kontrollager för GDPR Article 32, NIS2-hantering av cyberrisk och DORA-underlag för IKT-risk.
Den bästa tidpunkten att klassificera data var innan revisionsförfrågan kom. Den näst bästa tidpunkten är före nästa molnmigrering, leverantörsintroduktion, kundfrågeformulär eller incident.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
