ISO 27001-styrning av datalivscykeln 2026

Maria, informationssäkerhetschef på ett snabbt växande fintechbolag, fick den sortens fredagseftermiddag som förvandlar en efterlevnadslucka till en styrelsefråga.

Bolaget hade precis expanderat till nya EU-marknader. Intäkterna ökade, kundonboardingen gick snabbare och nya SaaS-verktyg lades till varje vecka. Sedan kom tre meddelanden nästan samtidigt.

Juridik varnade för att dataskyddsmyndigheter skärpte tillsynen av lagringsminimering enligt GDPR. Regelefterlevnad påminde henne om att bolagets DORA-skyldigheter för IKT-risk nu var en konkret operativ realitet. Styrelsen frågade om organisationens NIS2-exponering, inklusive leverantörskrav och cyberhygien, var under kontroll.

Därefter begärde en kund radering av sitt konto och alla tillhörande personuppgifter.

Den till synes enkla begäran blev snabbt en akut tvärfunktionell insats. Juridik sade att vissa poster kunde behövas för en avtalstvist. Ekonomi sade att lagstadgat underlag måste bevaras. Produkt bekräftade att kundens data fanns i produktionsdatabasen, analyssystemet, supportärenden, objektlagring, Kubernetes-loggar, databasögonblicksbilder och ett tredjepartsverktyg för kunduppföljning. Molnarkitektur frågade vilka säkerhetskopior som innehöll uppgifterna. Dataskyddsombudet frågade om någon kopia fortfarande behandlades utanför EU. Maria bad om bevisunderlag.

Till slut sade någon meningen som visade den verkliga frågan:

”Vi har ingen samlad plats där den här livscykeln är synlig.”

Det är kärnan i styrning av datalivscykeln 2026. Det handlar inte bara om databevarande. Det handlar om klassificering, ägarskap, rättslig grund, åtkomst, plats, replikering, bevarande av säkerhetskopior, bevarandespärr, avveckling av molntjänster, leverantörsradering, arkivgranskning, incidentunderlag och försvarbart bortskaffande.

För små och medelstora företag, fintechbolag, hanterade tjänsteleverantörer, molnorienterade företag och reglerade organisationer är risken inte längre att data saknas. Risken är att data finns överallt, är duplicerade, inaktuella, överbehöriga, underklassificerade och omöjliga att bevisa som raderade.

Ett moget program för ISO 27001-styrning av datalivscykeln gör denna akuta insats till ett kontrollerat arbetsflöde.

Varför styrning av datalivscykeln förändrades 2026

GDPR, NIS2 och DORA behandlas ofta som tre separata checklistor för regelefterlevnad. Det är fel operativ modell. De är olika regulatoriska uttryck för samma verksamhetskrav: känn dina data, skydda dem utifrån risk, bevara dem av rätt skäl och kunna visa vad som hände med dem.

GDPR Article 5 kräver att personuppgifter behandlas lagligt, korrekt och öppet, samlas in för specificerade ändamål, begränsas till vad som är nödvändigt, är korrekta, inte bevaras längre än nödvändigt och skyddas mot obehörig eller olaglig behandling samt oavsiktlig förlust, förstöring eller skada. Article 5(2) lägger till ansvarsskyldighet, vilket innebär att den personuppgiftsansvarige måste kunna visa efterlevnad. Styrning av bevarande enligt GDPR är därför inte en övning i kalkylblad. Den kräver operativa bevis.

NIS2 gör cybersäkerhet till en fråga för ledningsorganet. Article 20 anger styrningsförväntningar för ledningsorgan, medan Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder. Dessa omfattar riskanalys, policyer för informationssystemsäkerhet, incidenthantering, verksamhetskontinuitet, säkerhet i leveranskedjan, säker utveckling, effektivitetsbedömning, cyberhygien, utbildning, kryptografi, åtkomstkontroll och policy för tillgångshantering. Okända eller föråldrade data är inte bara ett integritetsproblem. De är ett angreppsyteproblem.

DORA gör IKT-riskhantering, operativ resiliens och IKT-tredjepartsrisk direkt verkställbara för finansiella entiteter. Articles 5 och 6 lägger ansvar på ledningsorganet och kräver ett dokumenterat ramverk för IKT-riskhantering. DORA förväntar sig också att finansiella entiteter skyddar datas tillgänglighet, autenticitet, riktighet och konfidentialitet, upprätthåller förmåga för incidenthantering, testar resiliens och styr IKT-tredjepartsberoenden.

DORA fungerar i allmänhet som det sektorsspecifika regelverket för överlappande operativa cybersäkerhetsskyldigheter för finansiella entiteter, medan NIS2 fortsatt är relevant för det bredare ekosystemet, inklusive molnleverantörer, hanterade tjänsteleverantörer och många organisationer inom digital infrastruktur. Detta är viktigt eftersom ett fintechbolag kan omfattas direkt av DORA, medan dess SaaS-leverantör eller hanterade tjänsteleverantör kan ligga inom NIS2-perimetern.

ISO/IEC 27001:2022 är ledningssystemet som kan hålla ihop dessa skyldigheter. Klausulerna 4.1–4.4 kräver att organisationen förstår sitt sammanhang, intressenter, rättsliga och avtalsmässiga krav samt omfattningen för sitt ledningssystem för informationssäkerhet. Klausulerna 5.1–5.3 kräver ledarskap, roller och ansvar. Klausulerna 6.1.2 och 6.1.3 kräver riskbedömning för informationssäkerhet, riskbehandling, kontrollval, jämförelse med bilaga A och bevarad dokumenterad information.

Denna struktur är skälet till att ISO 27001 inte är ”ännu en checklista”. Det är operativsystemet för styrning av datalivscykeln.

Livscykelmodellen: sju frågor varje dataägare måste kunna besvara

En praktisk modell för styrning av datalivscykeln ska besvara sju frågor för varje viktig datakategori:

1. Vilka data är det?
2. Varför behandlar vi dem?
3. Vem äger dem?
4. Hur känsliga är de?
5. Var finns de och var replikeras de?
6. Hur länge måste de bevaras, eller undantas från radering?
7. Hur skyddar, granskar, raderar och bevisar vi dem?

Clarysecs metod kopplar dessa frågor till ISO 27001-kontroller och operativa bevis. I Zenith Blueprint: An Auditor’s 30-Step Roadmap behandlar fasen Controls in Action tillgångsförteckning och klassificering som operativa fundament, inte som pappersarbete. Steg 22 förklarar att förteckningen bör omfatta fysiska tillgångar, digitala tillgångar, logiska tillgångar, tjänsterelaterade tillgångar och personer utifrån ansvar, åtkomst och exponering.

Zenith Blueprint anger:

”Varje tillgång ska ha en definierad ägare, inte den person som använder den, utan den som är ansvarig för dess användning, skydd och livscykel.”

Den meningen är vändpunkten. Styrning av datalivscykeln misslyckas när ägarskap tilldelas ”IT” eller ”verksamheten”. Den fungerar när en namngiven ansvarig ägare kan godkänna klassificering, bevarande, åtkomst, beslut om bevarandespärr, arkivgranskning och bevis på radering.

Clarysecs policy för tillgångshantering – SME förstärker samma disciplin:

”Ägarskap, syfte, åtkomstbehörigheter och tidsplaner för förnyelse ska dokumenteras.”

Detta krav finns i policy för tillgångshantering – SME, avsnittet ”Krav för genomförande av policyn”, klausul 6.6.2. Utan ägarskap och syfte blir bevarande en gissning och radering riskfylld.

Klassificering är den första kontrollen för bevarande

Många organisationer försöker skapa bevarandescheman innan de har tillförlitlig klassificering. Det misslyckas oftast.

Om en export från kundsupport, ett HR-dokument, en transaktionspost eller en applikationslogg inte är klassificerad kan organisationen inte konsekvent avgöra vem som ska ha åtkomst, var den får lagras, om den får användas i testning, hur starkt den måste krypteras, om den kräver skydd genom bevarandespärr eller hur den ska raderas.

Clarysecs policy för dataklassificering och märkning – SME är tydlig:

”Alla dokument, filer och system ska klassificeras så snart de skapas eller tas emot.”

Detta finns i policy för dataklassificering och märkning – SME, avsnittet ”Krav för genomförande av policyn”, klausul 6.1.1.

Företagsversionen policy för dataklassificering och märkning kopplar klassificering till hela hanteringskedjan:

”All hantering, överföring, åtkomst, lagring och bortskaffande av information ska överensstämma med informationens klassificeringsnivå. Som minimum:”

Detta finns i policy för dataklassificering och märkning, avsnittet ”Krav för genomförande av policyn”, klausul 6.3.1.

Zenith Blueprint lägger till genomförandevägledning för ISO/IEC 27002:2022 control 5.12, Klassificering av information. Ett klassificeringsschema bör definiera nivåer som Publik, Intern, Konfidentiell och Begränsad, omfatta kriterier baserade på skada vid obehörig åtkomst, förlust eller ändring, tillämpas på alla former av information och vara oberoende av lagringsformat eller plats.

Med andra ord följer klassificeringen innehållet, inte lagringsplatsen.

Ett begränsat dataset får inte lägre risk för att det flyttas från en databas till ett SaaS-analysverktyg. En post under bevarandespärr förlorar inte sin status för att den exporterats till CSV. Personuppgifter upphör inte att vara reglerade för att de förekommer i ett loggmeddelande.

Klassificering bör bli metadata i tillgångsregister, bevaranderegister, dataflödeskarta, åtkomstgranskning, checklista för införande av molntjänster och bortskaffningspost.

Kontrollryggraden i ISO 27001 för styrning av livscykeln

De mest effektiva programmen för datalivscykeln har en kontrollryggrad. Den kopplar ISO/IEC 27002:2022-kontroller till operativa bevis.

Clarysecs Zenith Controls: The Cross-Compliance Guide tillhandahåller vägledningen för korsvis efterlevnad i detta arbete. För styrning av datalivscykeln är tre kontroller centrala: 5.33 Skydd av poster, 5.34 Integritetsskydd och skydd av PII samt 8.10 Radering av information.

I Zenith Controls beskrivs ISO/IEC 27002:2022 control 5.33, Skydd av poster, genom förebyggande kontrollegenskaper som stödjer konfidentialitet, riktighet och tillgänglighet, med operativa förmågor inom juridik och regelefterlevnad, tillgångshantering och informationsskydd. Den kopplar till säkerhetskopiering, klassificering, säker avveckling av utrustning, rättsliga och regulatoriska krav, efterlevnad av policyer, åtkomstkontroll och incidentrespons.

Control 5.34, Integritetsskydd och skydd av PII, stödjer konfidentialitet, riktighet och tillgänglighet. Zenith Controls kopplar den till tillgångsförteckning, datamaskering, molnsäkerhet, klassificering, informationsöverföring, åtkomstkontroll, identitetshantering och säkerhetsgranskning av projekt och ändringar.

Control 8.10, Radering av information, är förebyggande och fokuserar på konfidentialitet. Zenith Controls kopplar den till märkning, informationsöverföring, immateriella rättigheter, privilegierad åtkomst, datamaskering, dataförlustprevention, skydd av poster, konfigurationshantering och efterlevnad av policyer och standarder.

Tillsammans skapar dessa kontroller livscykelkedjan.

Tabellen är inte bara till för revisorer. Den är en operativ modell för informationssäkerhetschefer, dataskyddsombud, complianceansvariga och verksamhetsägare som behöver ett gemensamt styrningsspråk för integritet, cybersäkerhet och resiliens.

Bygg bevaranderegistret före raderingsprocessen

En raderingsprocess utan ett bevaranderegister är farlig. Den kan ta bort poster som måste bevaras, missa data som ska raderas eller inte kunna skilja mellan operativ radering och undantag från radering på grund av bevarandespärr.

Clarysecs policy för databevarande och säker bortskaffning – SME anger baslinjen:

”Ett bevaranderegister ska etableras och underhållas, med viktiga uppgiftskategorier, rättsliga krav och tilldelade bevarandetider.”

Detta finns i policy för databevarande och säker bortskaffning – SME, avsnittet ”Styrningskrav”, klausul 5.1.1.

För företagsprogram definierar Clarysecs policy för databevarande och bortskaffning målet:

”Att etablera och tillämpa konsekventa bevarandescheman baserade på informationsklassificering, tillgångstyp, tillämpliga lagar och riskexponering.”

Detta finns i policy för databevarande och bortskaffning, avsnittet ”Mål”, klausul 3.3.

Ett användbart bevaranderegister bör koppla samman rättsliga, operativa, säkerhetsmässiga och molnrelaterade förutsättningar.

Ett litet fintechbolags bevaranderegister kan innehålla:

Den viktiga poängen är att bevarande ska vara riskbaserat och styrkt med underlag. Lagringsminimering enligt GDPR kräver att personuppgifter inte bevaras längre än nödvändigt, men tillåter också bevarande när en rättslig skyldighet eller ett berättigat behov finns. NIS2 förväntar sig tillgångshantering, åtkomstkontroll och cyberhygien. DORA förväntar sig dokumenterad IKT-riskhantering och kontinuitetsdisciplin. Bevaranderegistret är platsen där dessa skyldigheter blir beslut.

Bevarandespärr måste byggas in, inte skickas via e-post

Ett moget livscykelprogram ska radera data när de inte längre behövs, men får inte radera poster som omfattas av bevarandespärr, utredning eller revisionsbevarande.

Policy för databevarande och säker bortskaffning – SME är uttrycklig:

”Ingen post som omfattas av bevarandespärr och stopp för radering får förstöras eller ändras, även om dess bevarandetid har löpt ut.”

Detta finns i policy för databevarande och säker bortskaffning – SME, avsnittet ”Krav för genomförande av policyn”, klausul 6.3.4.

Företagsversionen policy för databevarande och bortskaffning tillämpar samma styrningsprincip:

”Om en bevarandespärr och ett stopp för radering utfärdas (t.ex. vid pågående rättsprocess, utredning eller revision) ska data som annars skulle förstöras bevaras utöver sin normala bevarandetid.”

Detta finns i policy för databevarande och bortskaffning, avsnittet ”Krav för genomförande av policyn”, klausul 6.4.1.

Bevarandespärr ska inte vara ett e-postmeddelande som kanske eller kanske inte når systemadministratörer. Det ska vara en status i bevaranderegistret, kopplad till system, uppgiftskategorier, informationsägare och raderingsautomation.

Ett försvarbart arbetsflöde för bevarandespärr omfattar:

• Utlösare, såsom rättsprocess, regulatorisk förfrågan, säkerhetsincident, revision eller intern utredning
• Ägare till spärren, normalt juridik eller regelefterlevnad
• Berörda uppgiftskategorier, system och informationsägare
• Instruktioner om stopp för raderingsjobb, utgång av säkerhetskopior och arkivrensning
• Åtkomstbegränsningar för att bevara riktighet
• Periodisk granskning av spärren
• Godkännande av hävning och dokumenterad återgång till normal bevaring
• Underlag för vad som bevarades, av vem och när

Detta är särskilt viktigt vid incidentrespons. Loggar, avbildningar, exporter och kommunikation kan behöva bevaras även när normal bevarandetid har löpt ut. Radering måste vara tillräckligt kontrollerad för att kunna stoppas, motiveras och återupptas.

Radering i moln och SaaS är där livscykelstyrning brister

År 2026 tappar de flesta organisationer inte livscykelkontrollen i sin primära databas. De tappar den i lagringsytor i molnet, SaaS-exporter, supportplattformar, CRM-bilagor, samarbetsytor, API-loggar, datalager, ögonblicksbilder och backupvalv.

Zenith Blueprint, fasen Controls in Action, steg 23, som behandlar ISO/IEC 27002:2022 control 5.23, informationssäkerhet vid användning av molntjänster, varnar för att molnleverantörer säkrar infrastrukturen men att kunden fortfarande är ansvarig för data, konfigurationer, åtkomstpolicyer och beredskap för incidenthantering. Felkonfigurerade lagringsytor, publika kontrollpaneler och överdrivna moln-IAM-behörigheter är styrningsbrister, inte leverantörsbrister.

Den anger också att användning av molntjänster måste behandlas som en del av ledningssystemet för informationssäkerhet. Organisationer måste klassificera molntjänster, förstå vilka data som behandlas eller lagras i dem, utvärdera leverantörens säkerhetsläge, etablera avtalsklausuler och hantera ändringar eller utökad omfattning.

Clarysecs policy för användning av molntjänster – SME omsätter detta i krav vid avveckling:

”Bekräftelse av rutiner för säker radering före kontostängning”

Detta finns i policy för användning av molntjänster – SME, avsnittet ”Krav för genomförande av policyn”, klausul 6.3.5.

Företagsversionen policy för användning av molntjänster kräver styrning över:

”Dataägarskap samt återlämning eller radering vid upphörande”

Detta finns i policy för användning av molntjänster, avsnittet ”Styrningskrav”, klausul 5.4.1.

För finansiella entiteter som omfattas av DORA är detta inte frivillig hygien. DORA Article 28 kräver hantering av IKT-tredjepartsrisk, ett register över avtalsarrangemang för IKT, leverantörsgranskning före avtal, beaktande av koncentrationsrisk, revisions- och åtkomsträttigheter, rätt att säga upp avtalet och exitstrategier för IKT-tjänster som stödjer kritiska eller viktiga funktioner. Article 30 kräver avtalsvillkor som omfattar tjänstebeskrivningar, platser för behandling och lagring, skydd för tillgänglighet, autenticitet, riktighet och konfidentialitet, åtkomst till data, återställning, återlämning, incidentstöd och övergångsstöd.

För NIS2-entiteter måste leverantörsbeslut beakta cybersäkerhet i leveranskedjan samt sårbarheter och resiliens i produkter och tjänster. Styrning av datalivscykeln måste därför omfatta leverantörer och inte stanna vid upphandlingsgodkännande.

En sprint på en vecka för att skapa ett kontrollpaket för livscykeln

Börja inte med att försöka kartlägga varje system i bolaget. Börja med ett högriskdataflöde och skapa ett upprepbart kontrollpaket.

Dag 1: Välj ett högriskdataflöde

Välj ett meningsfullt dataflöde, till exempel kundonboarding, avslut av anställning, hantering av betalningstvister, ärendehantering i support eller säkerhetsloggning.

För ett fintechbolag är kundonboarding en stark kandidat eftersom den kan omfatta identitetshandlingar, PII, transaktionsposter, bedrägeriindikatorer, tredjepartsleverantörer för verifiering, molnlagring, supportåtkomst och regulatoriskt bevarande.

Dag 2: Bygg den avgränsade tillgångs- och dataförteckningen

Använd Zenith Blueprint, fasen Controls in Action, steg 22, ISO/IEC 27002:2022 control 5.9, för att fånga fysiska, digitala, logiska, tjänsterelaterade och ansvarsbundna tillgångar.

Dokumentera insamlade datakategorier, auktoritativa källsystem, SaaS-plattformar som tar emot kopior, API:er, integrationer, användarroller, privilegierade roller, platser för säkerhetskopior, arkivplatser, dataägare, systemägare, klassificering, PII-flaggor och leverantörsberoenden.

Målet är inte perfektion. Målet är att synliggöra dolda replikeringspunkter.

Dag 3: Tillämpa klassificering och åtkomstlogik

Tillämpa policy för dataklassificering och märkning och klassificera varje datakategori. Kontrollera därefter om åtkomstbehörigheter återspeglar klassificeringen.

Begränsade kundidentitetshandlingar ska inte vara brett åtkomliga via supportverktyg. Säkerhetsloggar som innehåller identifierare ska inte exporteras slentrianmässigt till ohanterade kalkylblad. Åtkomst ska mappas till roll, syfte, godkännande och granskningsunderlag.

Dag 4: Skapa poster för bevarande och bevarandespärr

Använd policy för databevarande och bortskaffning och policy för databevarande och säker bortskaffning – SME för att skapa bevarandeposter för varje uppgiftskategori. Inkludera rättslig grund, verksamhetssyfte, rättsligt krav, bevarandetid, raderingsmetod och status för bevarandespärr.

Om det finns en aktiv tvist, incident eller utredning ska stopp för radering markeras och godkännaren registreras.

Dag 5: Verifiera radering hos moln- och leverantörstjänster

Använd policy för användning av molntjänster och policy för användning av molntjänster – SME för att kontrollera varje moln- eller SaaS-leverantör i flödet.

Bekräfta villkor för dataägarskap, återlämning eller radering vid upphörande, tidsfrister för radering, hur radering hanteras i säkerhetskopior, konsekvenser av underbiträden, underlag för radering och skyldigheter att bistå vid incidenter.

För DORA-miljöer ska IKT-tredjepartsregistret och exitplanen uppdateras. För NIS2-miljöer ska överväganden om leverantörsrisk och beroenden kopplade till cyberhygien dokumenteras.

Dag 6: Definiera underlag och övervakning

Underlag ska inte skapas först efter en revisionsbegäran. Definiera det under processdesignen.

Policy för databevarande och bortskaffning kräver att bortskaffning ska vara:

”Loggad i bortskaffningsregistret, inklusive tillgångs-ID, klassificering, metod och operatör”

Detta finns i policy för databevarande och bortskaffning, avsnittet ”Krav för genomförande av policyn”, klausul 6.5.3.2.

Ett starkt bevispaket omfattar poster i bevaranderegistret, resultat från åtkomstgranskning, raderingsärenden, loggar i bortskaffningsregistret, bekräftelser på radering i molntjänster, godkännanden av bevarandespärr, inställningar för bevarande av säkerhetskopior, leverantörsavtalsklausuler och granskningsposter för arkiv.

Dag 7: Uppdatera risker och tillämpbarhetsförklaringen

Uppdatera ISO 27001-riskregistret och tillämpbarhetsförklaringen. Om livscykelgranskningen hittade ohanterade SaaS-exporter, obegränsat bevarande av säkerhetskopior, överdriven åtkomst, otydliga raderingsvillkor eller saknat ägarskap är detta risker som kräver behandling.

Denna sprint på en vecka skapar ett upprepbart kontrollpaket för livscykeln. Upprepa det för nästa dataflöde och därefter nästa.

Mappning för korsvis efterlevnad: ett livscykelprogram, många skyldigheter

Värdet med ISO 27001-styrning av datalivscykeln är att samma underlag kan stödja integritet, cyberhygien, IKT-risk och revisionsförväntningar.

NIST CSF 2.0 är användbart för kommunikation med ledningen eftersom dess GOVERN-funktion förväntar sig att rättsliga, regulatoriska, avtalsmässiga och integritetsrelaterade skyldigheter förstås och hanteras, att riskaptit fastställs, att ledningens ansvarsskyldighet är tydlig, att policyer tillämpas och att resultat granskas. Dess resultat för tillgångshantering kräver inventeringar och livscykelhantering för hårdvara, programvara, system, tjänster och data.

COBIT 2019 tillför styrningsspråk för styrelser och revisionskommittéer. Zenith Controls mappar Skydd av poster till COBIT-processer såsom hantering av säkerhetskopiering och återställning, hantering av säkerhet för information i vila och hantering av poster. Den mappar Integritetsskydd och skydd av PII till integritet, informationsskydd och styrning av integritetsprogram. Den mappar Radering av information till risk- och driftsmål, vilket förstärker radering som en styrd process snarare än en ad hoc-rensning.

Vad revisorer faktiskt kommer att testa

Ett program för styrning av livscykeln är trovärdigt först när det klarar revisionstestning.

En ISO/IEC 27001:2022-revisor börjar med omfattning, krav från intressenter, risker, tillämpbarhetsförklaring, dokumenterad information och underlag för operativa kontroller. För styrning av livscykeln kan urval förväntas. Revisorn kan välja ett avtal, en HR-post, en logguppsättning eller en finansiell post och följa den genom skapande, lagring, säkerhetskopiering, åtkomst och bortskaffande.

Med revisionsperspektivet i Zenith Controls för Skydd av poster kontrollerar revisorer om poster inom omfattningen är identifierade, om bevarandescheman finns, hur poster lagras, hur åtkomst styrs och hur riktighet skyddas.

För Radering av information förklarar Zenith Controls att revisorer granskar policyer för bevarande och radering, raderingsmetoder, ansvar, raderingsloggar, revisionsspår, intyg om medieförstöring och underlag från saneringsverktyg. De undersöker också om säkerhetskopior och arkiv omfattas.

En integritets- eller PII-revisor granskar integritetspolicyer, dataförteckningar, DPIA:er eller PIA:er, utbildningsloggar och tekniska åtgärder såsom kryptering av data i vila och data under överföring. Revisorn kan ta ett urval av en begäran från registrerad, bekräfta var relevanta data finns, verifiera om radering eller begränsning har tillämpats och kontrollera att undantag såsom bevarandespärr är motiverade.

En NIST-orienterad bedömare kan granska anpassning till NIST CSF-resultat och tekniska kontroller såsom NIST SP 800-53 AU-11 Audit Record Retention, samt rutiner för mediesanering baserade på NIST SP 800-88. Bedömaren kan testa återställning från säkerhetskopia, inspektera regler för loggbevarande, verifiera kryptering och kontrollera om onödig PII minimeras.

En COBIT- eller ISACA-revisor fokuserar på styrningsprocesser och kvaliteten på underlag. De frågar vem som äger poster, om kontroller i verksamhetsprocesser bevarar riktighet, om övervakning av efterlevnad upptäcker överbevarande och om driften omfattar uppgifter för säker radering.

Vanliga felmönster i styrning av livscykeln

Clarysec ser ofta samma mönster hos små och medelstora företag och reglerade organisationer.

Det första är klassificering utan tillämpning. Data märks som konfidentiella, men åtkomsträttigheter, SaaS-delning, exporter och raderingsmetoder förändras inte.

Det andra är bevarande utan repliker. Schemat omfattar det primära systemet men inte loggar, säkerhetskopior, datalager, supportexporter, kalkylblad eller tredjepartsplattformar.

Det tredje är avveckling av molntjänster utan bevis. Avtalet säger att data ska raderas, men ingen känner till raderingsmetoden, tidslinjen, hanteringen av säkerhetskopior eller formatet på underlaget.

Det fjärde är bevarandespärr via e-post. Juridik skickar instruktioner, men raderingsjobb fortsätter eftersom inget operativt system använder spärrstatusen.

Det femte är revisionsbevis i efterhand. Team återskapar bevis för radering och bevarande manuellt, vilket skapar inkonsekvens och onödig osäkerhet.

Det sjätte är återuppväckning från säkerhetskopior. Data som raderats från produktion återkommer vid återställning eller testning eftersom bevarande och rensningslogik för säkerhetskopior aldrig anpassades till policyn för databevarande.

Varje brist kan förebyggas när klassificering, inventering, bevarande, molnstyrning, radering och underlag utformas som en sammanhållen livscykel.

Clarysecs operativa modell för styrning av datalivscykeln

Clarysecs modell är rak: etablera en kontrollryggrad för livscykeln och koppla därefter regulatoriska skyldigheter och underlag till den.

Kontrollryggraden omfattar:

• Tillgångs- och dataförteckning
• Ägarskap och syfte
• Klassificering och märkning
• Rättslig grund och behandlingsändamål
• Bevaranderegister
• Bevarandespärr och stopp för radering
• Livscykelklausuler för moln och leverantörer
• Åtkomstkontroll och styrning av privilegierad åtkomst
• Regler för säkerhetskopiering och arkiv
• Säker radering och bortskaffningsregister
• Loggning, övervakning och incidentunderlag
• Periodisk granskning och uppdateringar av riskbehandling

Zenith Blueprint ger färdplanen för genomförande genom Controls in Action-steg för inventering, klassificering, molnstyrning och radering av information. Zenith Controls tillhandahåller vägledningen för korsvis efterlevnad som visar hur ISO/IEC 27002:2022-kontroller kopplar till GDPR, NIS2, DORA, NIST, COBIT, ISO/IEC 27701, ISO/IEC 27018, ISO/IEC 27017, ISO/IEC 27040, ISO 15489 och ISO 22301. Clarysecs policyer ger de operativa klausuler som team kan genomföra omedelbart.

Styrning av livscykeln kan inte bara ligga hos integritet, säkerhet eller IT. Den måste vara ett gemensamt ledningssystem.

Om din organisation inte kan svara på var reglerade data finns, vem som äger dem, hur länge de bevaras, vad som förhindrar radering under bevarandespärr, hur SaaS-data tas bort och vilket underlag som bevisar bortskaffande, är det dags att åtgärda detta nu.

Börja med ett högriskdataflöde. Använd Zenith Blueprint: An Auditor’s 30-Step Roadmap för att bygga grunden för inventering och klassificering. Använd Zenith Controls: The Cross-Compliance Guide för att mappa Skydd av poster, Integritetsskydd och skydd av PII samt Radering av information över GDPR, NIS2, DORA, NIST och COBIT. Genomför därefter relevanta Clarysec-policyer, inklusive policy för dataklassificering och märkning, policy för databevarande och bortskaffning, policy för användning av molntjänster och deras SME-motsvarigheter där det är relevant.

Det praktiska målet är inte att blint behålla mindre data. Det är att behålla rätt data, av rätt skäl, under rätt kontroller, under rätt tid, med underlag som håller inför kunder, tillsynsmyndigheter, revisorer och styrelsen.

Ladda ned Clarysecs policyverktygslådor, mappa dina kontroller med Zenith Controls, eller använd Zenith Blueprint för att genomföra din första kontrollsprint för livscykeln innan nästa raderingsbegäran blir en revisionsiakttagelse.