DSAR, radering och ISO 27001-revisionsunderlag 2026

E-postmeddelandet landade i Sarahs inkorg kl. 09.03.

Det var inte den första begäran om registerutdrag, eller DSAR, som hennes snabbväxande SaaS-bolag hade tagit emot. Det var den första som kändes som en offentlig revision.

Avsändaren var en tidigare anställd, numera integritetsförespråkare. Begäran hänvisade till GDPR-artiklar med nummer och krävde alla personuppgifter, omedelbar begränsning av behandling, en lista över varje tredjepartstjänst som lagrade personens uppgifter samt verifierbart underlag för radering från produktions- och säkerhetskopieringssystem. En journalist stod på kopia.

Inom några minuter blev luckorna synliga. Utvecklingsteamet varnade för att ”verklig radering” från en databas med flera kunder kunde påverka andra kunder. Marknadsteamet försökte reda ut användardata i flera analysplattformar. Juristfunktionen identifierade ett olöst anställningsärende. Säkerhetsteamet oroade sig för att loggar kunde avslöja detekteringslogik eller en annan persons uppgifter. Support hade poster under två e-postadresser. Ekonomifunktionen hade fakturor under en tredje.

Klockan hade redan börjat gå.

Det scenariot är inte längre ovanligt. Registrerades rättigheter 2026 är inte ett problem för en integritetsinkorg. De är en kontrollerad verksamhetsprocess som är beroende av tillgångsförteckningar, beslut om rättslig grund, verifiering av digital identitet, åtkomstkontroll, regler för databevarande, rutiner för rättsligt bevarande, leverantörssamordning, säkert utlämnande, raderingsunderlag och revisionsklar loggning.

GDPR anger vilka rättigheter individer har. ISO/IEC 27001:2022 ger säkerhets- och regelefterlevnadsteam den ledningssystemdisciplin som krävs för att visa att dessa rättigheter hanteras konsekvent, säkert och upprepbart.

För informationssäkerhetschefer, regelefterlevnadsansvariga, dataskyddsombud och verksamhetsägare är målet inte att skapa mer dokumentation. Målet är att bygga ett tillförlitligt arbetsflöde för DSAR, radering och begränsning som producerar det underlag som krävs enligt GDPR, ISO/IEC 27001:2022-revisioner och bredare krav på säkerhetsförsäkran enligt NIS2, DORA, NIST CSF 2.0 och COBIT 2019.

Varför ad hoc-hantering av DSAR brister under press

De flesta DSAR-brister beror inte på dåliga avsikter. De beror på fragmentering.

En verksamhet kan ha ett integritetsmeddelande, en DPO-brevlåda och en GDPR-klausul i leverantörsavtal men ändå ha svårt att besvara grundläggande operativa frågor:

• Vem validerar begärarens identitet?
• Vilken juridisk person är personuppgiftsansvarig eller personuppgiftsbiträde?
• Vilka system ska genomsökas?
• Vem äger respektive system?
• Vilka uppgifter omfattas?
• Vilka uppgifter ska maskas före utlämnande?
• Vilka uppgifter får inte raderas på grund av skatt, revision, rättsprocess, bedrägeriprevention eller rättslig skyldighet?
• Hur genomförs begränsning av behandling tekniskt?
• Vilka leverantörer måste stödja sökning, export, radering eller begränsning?
• Vilket underlag visar att begäran hanterades i tid?
• Vad händer om DSAR-hanteringen visar på en personuppgiftsincident?

GDPR Article 5 kräver att personuppgifter behandlas lagligt, korrekt och öppet, samlas in för särskilda ändamål, begränsas till vad som är nödvändigt, hålls korrekta, inte bevaras längre än nödvändigt och skyddas med lämpliga tekniska och organisatoriska åtgärder. Article 5(2) gör ansvarsskyldighet uttrycklig: den personuppgiftsansvarige ska kunna visa efterlevnad. Article 4 definierar behandling brett, inklusive insamling, lagring, användning, utlämnande, begränsning, radering och förstöring.

Det innebär att DSAR-processen i sig är en behandlingsaktivitet. Den ska vara kontrollerad.

GDPR Article 3 är också viktig för moln, SaaS, fintech och digitala verksamheter utanför EU. Om ni erbjuder varor eller tjänster till personer i unionen, övervakar deras beteende eller behandlar personuppgifter inom ramen för ett etableringsställe i EU kan GDPR vara tillämplig även när verksamheten är outsourcad eller infrastrukturen är global.

ISO/IEC 27001:2022 skapar struktur för denna verklighet. Clauses 4.1 to 4.4 kräver att organisationen förstår sitt sammanhang, intressenter, krav, ISMS-omfattning och samverkande processer. En registrerad är en intressent. GDPR-rättigheter är krav. SaaS-applikationer, identitetsleverantörer, analyssystem, supportverktyg, datalager och säkerhetskopior i molnmiljö är samverkande processer. Ett DSAR-arbetsflöde hör hemma i ISMS, inte vid sidan av det.

De tre rättigheter för registrerade som skapar störst press

Tillgång, radering och begränsning synliggör den största skillnaden mellan juridiskt löfte och operativ förmåga.

GDPR Article 6 är central för denna beslutslogik. Ni kan inte behandla, bevara, lämna ut eller vägra radering utan att förstå den rättsliga grunden. Article 9 höjer kraven för särskilda kategorier av personuppgifter, såsom hälsodata, biometriska data som används för unik identifiering eller uppgifter som avslöjar känsliga egenskaper. I en SaaS-miljö 2026 kan detta påverka onboarding, verifiering av digital identitet, bedrägeriövervakning, bilagor i kundsupport och anställningsregister.

Clarysecs företagsövergripande Policy för dataskydd och integritet [P17] ramar in skyldigheten direkt. I Mål clause 3.6 kräver den att organisationen ska:

Upprätthålla registrerades rättigheter, inklusive tillgång, rättelse, radering, begränsning, dataportabilitet, invändning och skydd mot automatiserat beslutsfattande.

Det målet blir möjligt att granska först när det kopplas till ägare, register, arbetsflöden, kontroller och underlag.

Börja där revisorerna börjar: omfattning, intressenter och ägarskap

I Zenith Blueprint: en revisors färdplan i 30 steg [ZB] fokuserar fasen ISMS Foundation & Leadership, Step 2, på intressenters behov och ISMS-omfattning. För GDPR identifierar Blueprint tillsynsmyndigheternas förväntningar som:

EU-tillsynsmyndigheter
(GDPR)

Laglig behandling av personuppgifter,
rapportering av personuppgiftsincidenter inom 72h,
registrerades rättigheter

Utse dataskyddsombud, etablera
process för incidentrespons, rutiner för
hantering av begäranden från registrerade.

Detta är rätt startpunkt. Innan ärenden automatiseras eller portaler konfigureras ska omfattningen för hantering av registrerades rättigheter definieras:

1. Vilka juridiska personer agerar som personuppgiftsansvarig, gemensamt personuppgiftsansvarig eller personuppgiftsbiträde?
2. Vilka produkter, tjänster och territorier omfattas?
3. Vilka kategorier av registrerade finns, till exempel kunder, anställda, testanvändare, prospekt, leverantörer, webbplatsbesökare eller appanvändare?
4. Vilka system, lagringsplatser och leverantörer innehåller personuppgifter?
5. Vilka roller godkänner utlämnande, avslag, radering, begränsning eller eskalering?
6. Vilka mätetal rapporteras till ledningen?

ISO/IEC 27001:2022 clauses 5.1 to 5.3 kräver ledarskap, policyanpassning, resurser och tilldelade ansvar. Det ligger direkt i linje med ansvarsskyldighet enligt GDPR.

Policy för dataskydd och integritet [P17], Krav för genomförande av policyn clause 6.4.1, anger:

Dataskyddsombudet (DPO) ska upprätthålla dokumenterade processer för mottagning, validering, uppföljning och svar avseende begäranden från registrerade (DSR).

För små och medelstora företag använder Clarysecs Policy för dataskydd och integritet – SME [P17S] ägarskap i rätt omfattning. Styrningskrav clause 5.2.1 anger:

Integritetssamordnaren ska upprätthålla ett register över alla behandlingsaktiviteter för personuppgifter, inklusive datakategorier, ändamål, rättslig grund och bevarandetider

Det behandlingsregistret är den operativa kärnan i DSAR-beredskap. Om det är ofullständigt söker DSAR-teamet med hjälp av minne, chattmeddelanden och informell kunskap. Om det är korrekt söker teamet utifrån behandlingsaktivitet, datakategori, systemägare, leverantör och regel för databevarande.

Clarysecs DSAR-arbetsflöde: från mottagning till stängning

Ett revisionsklart DSAR-arbetsflöde ska vara tillräckligt enkelt för att fungera under press, men tillräckligt kontrollerat för att tåla en tillsynsmyndighet, en kundgranskning eller en ISO/IEC 27001:2022-revision.

1. Mottagning och bekräftelse

Begäranden ska komma in via en kontrollerad kanal, till exempel en integritetsbrevlåda, portal, supportformulär eller juridisk mottagningskö. Personal ska kunna känna igen begäranden uttryckta i vardagligt språk. En person behöver inte skriva ”DSAR” för att utöva en rättighet. ”Vilka uppgifter har ni om mig?” eller ”radera min profil” kan vara tillräckligt för att utlösa arbetsflödet.

Policy för dataskydd och integritet – SME [P17S], Krav för genomförande av policyn clause 6.5.2, fastställer en tydlig servicenivå:

Integritetssamordnaren ska bekräfta begäranden inom 3 arbetsdagar och svara inom 30 dagar

Bekräftelsen bör innehålla begärans referens, förtydligande av omfattningen vid behov, instruktioner för identitetsverifiering och förväntad svarstid.

2. Identitetsverifiering och kontroll av behörighet

En DSAR kan bli en personuppgiftsincident om information skickas till fel person. Verifieringen bör vara proportionerlig och ska inte samla in överflödiga nya personuppgifter. Använd autentiserade portaler där det är möjligt. För tidigare användare, validera mot kända kontouppgifter. För anställda, samordna med HR. För ombud, kräv bevis på behörighet.

Bevara underlag för verifieringsmetod, datum då verifieringen slutfördes, godkännare, eventuell ytterligare information som begärts och beslutet om verifieringen misslyckas.

3. Klassificera begäran

Ett enda meddelande kan innehålla flera rättigheter. Klassificera varje rättighet separat eftersom tillgång, radering, begränsning, invändning och portabilitet kräver olika beslutslogik och olika underlag. Flagga också potentiella klagomål, anställningsärenden, barns uppgifter, särskilda kategorier av uppgifter och möjliga personuppgiftsincidenter.

4. Sök i tillgångsförteckningen, inte bara i uppenbara system

Det är här ISO/IEC 27001:2022 blir praktiskt. Zenith Blueprint [ZB], fasen Controls in Action, Step 22, varnar för att omfattningen av tillgångsförteckningen är bredare än många organisationer förväntar sig:

Omfattningen av denna förteckning är bredare än de flesta inser. Den bör omfatta:

✓ Fysiska tillgångar: bärbara datorer, servrar, telefoner, band för säkerhetskopiering, flyttbara lagringsmedier, utskrivna
poster.
✓ Digitala tillgångar: dokument, dataset, lagringsplatser, e-post, källkod, filer lagrade i molnmiljö.
✓ Logiska tillgångar: användarkonton, autentiseringsuppgifter, nycklar, programvarulicenser, API:er.
✓ Tjänsterelaterade tillgångar: SaaS-plattformar, hanterade säkerhetstjänster, outsourcad
lagring.
✓ Människor som tillgångar: inte i kommersiell mening, utan i fråga om tilldelade ansvar,
åtkomst och rollbaserad exponering för information.

Step 22 förklarar också ägarskap:

Varje tillgång bör ha en definierad ägare, inte den person som använder den, utan den som är ansvarig för
dess användning, skydd och livscykel. Ägarskap är avgörande för anpassning av kontroller: vem klassificerar
tillgången (5.10), vem beslutar om dess åtkomstnivå (8.3), vem hanterar dess radering (8.10), vem säkerställer
att den återlämnas (5.9 överlappar subtilt med rutiner för återlämning av tillgångar).

I Zenith Controls: The Cross-Compliance Guide [ZC] behandlas ISO/IEC 27002:2022 control 5.9, Inventory of information and other associated assets, som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet. Dess cybersäkerhetskoncept är Identify, dess operativa förmåga är tillgångshantering och dess säkerhetsdomäner omfattar styrning, ekosystem och skydd.

För DSAR innebär det att tillgångsförteckningen inte är ett IT-kalkylblad. Den är kartan som visar dataskydd, juridik och säkerhet var personuppgifter kan finnas.

5. Granska, maska och godkänn utlämnande

Ett DSAR-svar ska inte vara en rå export. Granskningen ska skydda andra personers personuppgifter, konfidentiell verksamhetsinformation, advokatsekretess eller rättsligt privilegium, säkerhetskänsliga uppgifter, bedrägerisignaler och uppgifter utanför begärans omfattning.

Godkännande bör vara riskbaserat. Rutinmässiga svar på tillgångsbegäranden kan godkännas av integritetssamordnaren eller DPO. Begäranden som rör anställda, rättsprocesser, särskilda kategorier av uppgifter, barn, bedrägeri, säkerhetsloggar eller stora exporter bör involvera juridik, HR eller säkerhetsledning.

6. Leverera säkert

Bifoga inte stora okrypterade filer i e-post. Använd autentiserade portaler, krypterade filer med separat lösenordsleverans eller säkra överföringslänkar med utgångsdatum och åtkomstloggning. Registrera leveransmetod, datum, mottagarkonto, utgångsdatum och bekräftelse där sådan finns.

7. Stäng med underlag

Policy för dataskydd och integritet [P17], clause 6.4.3, är tydlig:

Alla vidtagna åtgärder ska loggas för revisionsändamål, inklusive beslut att avslå begäranden.

Policy för dataskydd och integritet – SME [P17S], clause 6.5.4, anger:

Alla svar på begäranden från registrerade ska loggas i ett säkert register, med åtkomst begränsad till integritetssamordnaren och GM

En DSAR är inte slutförd när e-postmeddelandet har skickats. Den är slutförd när registret visar begäran, identitetskontroll, beslut, genomsökta system, svar, undantag, godkännanden, leverans och stängning.

Radering är kontrollerad förstöring, inte en raderingsknapp

Begäranden om radering visar om integritet har byggts in i systemen eller lagts till efter lansering.

Clarysecs företagsövergripande Policy för databevarande och bortskaffning [P14], Roller och ansvar clause 4.3.3, tilldelar ansvar till den roll som:

Besvarar begäranden om radering och säkerställer snabb, verifierbar radering av personuppgifter där detta krävs.

Formuleringen ”där detta krävs” är avgörande. Radering enligt GDPR är inte absolut. Organisationer kan behöva bevara uppgifter för rättsliga skyldigheter, revision, skatt, regulatoriska skyldigheter, bedrägeriprevention, säkerhet, rättsprocess eller för att fastställa, göra gällande eller försvara rättsliga anspråk. Arbetsflödet måste innehålla ett beslut om lagligt bevarande och undantag.

Zenith Blueprint [ZB], fasen Controls in Action, Step 19, förklarar ISO/IEC 27002:2022 control 8.10, Information Deletion, i operativa termer:

Denna kontroll säkerställer att uppgifter inte bevaras längre än nödvändigt och att de, när de inte längre
behövs, ska raderas säkert och tillförlitligt. Många organisationer samlar över tid på sig stora
datamängder, men utan en tydlig raderingsprocess kan dessa uppgifter bli liggande oanvända och
oskyddade, vilket i det tysta ökar risken för exponering, incident eller överträdelse av regulatoriska krav.

Den varnar också:

Glöm inte säkerhetskopior och arkiverade system; dessa bevarar ofta historiska data långt efter att de
har operativt värde. Raderingspolicyer måste omfatta:

✓ Inställningar för bevarande av säkerhetskopior,
✓ livscykler för ögonblicksbilder,
✓ arkiverade e-post- eller dokumentlagringsplatser.

Och den avslutar med underlag:

Själva raderingsprocessen ska loggas och, när det gäller högriskdata eller reglerade data,
granskas eller godkännas. Detta säkerställer spårbarhet och skyddar mot oavsiktlig eller
obehörig förstöring av värdefulla poster.

I Zenith Controls [ZC] mappas ISO/IEC 27002:2022 control 8.10, Information deletion, som en förebyggande kontroll med fokus på konfidentialitet, anpassad till cybersäkerhetskonceptet Protect och kopplad till operativa förmågor för informationsskydd samt juridik och regelefterlevnad.

För komplexa molnarkitekturer kan kryptografisk radering vara lämplig om den är korrekt utformad. Om personuppgifter krypteras med en ämnesspecifik eller klient-/tenant-specifik nyckel kan förstöring av nyckeln göra uppgifterna permanent oåtkomliga, även om krypterade rester finns kvar i säkerhetskopior fram till schemalagd rotation. Detta måste utformas, dokumenteras, testas och godkännas noggrant. Det är inte en genväg runt en svag raderingsarkitektur.

Applikationsberedskap är därför avgörande. Clarysecs Policy för applikationssäkerhetskrav – SME [P09S], clause 6.5.1.3, kräver att applikationer ska:

möjliggöra säker export och radering av personuppgifter när det krävs enligt lag (t.ex. GDPR Article 17 – rätt till radering).

Om produktteam inte bygger in export- och raderingsförmåga tvingas dataskyddsteam använda databasskript, leverantörsärenden och inkonsekvent manuellt arbete.

Rättsligt bevarande och spärr mot radering

Ett moget raderingsarbetsflöde måste innehålla en väg för ”radera inte”. Det är inte en ursäkt för att ignorera radering. Det är ett kontrollerat undantag.

Clarysecs SME-Datalagringspolicy och policy för säker bortskaffning – SME [P14S], Styrningskrav clause 5.4, anger:

Uppgifter som omfattas av rättsligt bevarande och spärr mot radering (t.ex. vid rättsprocess, revision eller utredning) ska tydligt identifieras i systemet och skyddas mot radering, även om den schemalagda bevarandetiden har löpt ut.

Policy för databevarande och bortskaffning [P14], clause 6.4.1, speglar samma princip:

Om rättsligt bevarande och spärr mot radering utfärdas (t.ex. på grund av pågående rättsprocess, utredning eller revision) ska uppgifter som annars skulle förstöras bevaras utöver sin normala bevarandetid.

Revisorer vill se båda sidorna av historien: underlag för radering i rätt tid och underlag för motiverat bevarande.

Begränsning av behandling: den underskattade rättigheten

Begäranden om begränsning kräver inte alltid radering. De kräver att organisationen begränsar aktiv behandling samtidigt som uppgifter bevaras under kontrollerade förhållanden.

Vanliga exempel är:

• En kund bestrider riktigheten och ber er sluta använda uppgifterna medan de verifieras.
• En tidigare anställd invänder mot behandling, men posten behövs för rättsliga anspråk.
• En användare begär radering, men minimala uppgifter måste bevaras för att upprätthålla en spärrlista.
• En bedrägeriutredning kräver bevarande men inte normal operativ användning.

Ett praktiskt arbetsflöde för begränsning bör innehålla ett juridiskt beslut, systemflagga, justering av åtkomstkontroll, marknadsföringsspärr, undantag från analysbehandling, leverantörsinstruktion, periodisk granskning och underlag för undantag.

I Zenith Controls [ZC] behandlas ISO/IEC 27002:2022 control 5.34, Privacy and protection of PII, som en förebyggande kontroll som stödjer konfidentialitet, riktighet och tillgänglighet. Den mappas till Identify och Protect, med operativa förmågor för informationsskydd samt juridik och regelefterlevnad.

Zenith Blueprint [ZB], fasen Controls in Action, Step 23, sammanfattar revisionstestet:

Bekräfta att organisationen har infört integritetsåtgärder (5.34) som är anpassade till
tillämpliga rättsliga krav. Verifiera klassificering av PII, lämpliga åtkomstkontroller, säkra
hanteringsrutiner och medvetenhetsutbildning. Validera om begäranden om registerutdrag,
radering av uppgifter eller behandlingsloggar stöds operativt, inte bara genom policy.

Nyckelfrasen är ”stöds operativt, inte bara genom policy.”

Mappa DSAR-arbetsflöden till ISO/IEC 27001:2022-underlag

ISO/IEC 27001:2022 ersätter inte GDPR. Den organiserar underlaget.

Clauses 6.1.1 to 6.1.3 kräver riskbedömning, riskbehandling, kriterier för riskacceptans, riskägare, kontrollurval, en tillämpbarhetsförklaring och en riskbehandlingsplan. DSAR-risker omfattar obehörigt röjande, missade tidsfrister, ofullständig radering, olagligt bevarande, överdriven identitetsverifiering, bristande leverantörssamverkan och oförmåga att begränsa behandling.

Clause 8.1 kräver att organisationer planerar, genomför och styr ISMS-processer, bevarar dokumenterat underlag, styr ändringar och säkerställer att externt tillhandahållna processer, produkter och tjänster som är relevanta för ISMS kontrolleras. Det passar DSAR-drift eftersom begäranden passerar interna funktioner och externa biträden.

Ett starkt underlagspaket omfattar DSR-rutinen, DSR-registret, registret över behandlingsaktiviteter, tillgångsförteckningen, bevarandeschemat för data, registret över rättsligt bevarande, rutinen för identitetsverifiering, vägledning för maskning, metod för säkert utlämnande, raderingsrutin, rutin för begränsning, leverantörsplaybook, undantagsregister, utbildningsregister, resultat från internrevision och rapportering från ledningens genomgång.

Ett praktiskt arbetsflöde för tillgång, radering och begränsning

Detta arbetsflöde omvandlar Sarahs kris till en process som är möjlig att granska. Varje steg har en ägare, en kontrollgrund och underlag.

Värde för flera ramverk utöver GDPR

Ett DSAR-arbetsflöde har sin grund i GDPR, men samma kontroller stödjer bredare ramverk.

NIS2 Article 20 gör cybersäkerhet till ett ledningsansvar för väsentliga och viktiga entiteter. Article 21 kräver lämpliga och proportionerliga tekniska, operativa och organisatoriska åtgärder, inklusive riskanalys, incidenthantering, verksamhetskontinuitet, leveranskedjesäkerhet, effektivitetsbedömning, cyberhygien, utbildning, åtkomstkontroll, tillgångshantering, autentisering och säker kommunikation. DSAR är beroende av många av samma förmågor.

DORA gäller från den 17 januari 2025 för många finansiella entiteter och fastställer enhetliga krav på IKT-riskhantering, incidentrapportering, resiliensprövning och IKT-tredjepartsrisk. Articles 5 och 6 kräver styrning och dokumenterad IKT-riskhantering. Articles 17 to 20 behandlar incidentdetektering, klassificering, eskalering, kommunikation och stängning. Articles 24 to 30 behandlar resiliensprövning, IKT-tredjepartsrisk, tjänsteregister, revisionsrätt, datalagringsplats, incidentstöd och exitstrategier. Ett fintech-bolag som hanterar DSAR via molnplattformar bör anpassa hanteringen av integritetsbegäranden till sitt IKT-tjänsteregister.

NIST CSF 2.0 hjälper till att översätta samma arbete till cybersäkerhetsresultat. GOVERN behandlar rättsliga, regulatoriska och avtalsmässiga krav, riskstrategi, roller, policy och tillsyn. IDENTIFY och PROTECT ligger nära tillgångssynlighet, dataklassificering, åtkomstkontroll, radering, leverantörsstyrning och integritetsskydd.

COBIT 2019 ställer styrningsfrågor. Vem äger processen? Vilka mål är definierade? Hur mäts prestation? Hur godkänns undantag? Hur erhålls säkerhetsförsäkran? DSAR-underlag kan stödja mål som APO13 Managed Security, APO14 Managed Data och DSS06 Managed Business Process Controls.

Revisorns perspektiv

Skapa inte separat underlag för varje ramverk. Skapa ett tillförlitligt DSAR-arbetsflöde och mappa det väl.

DSAR-mätetal som ledningen bör se

Ledningen kan inte utöva tillsyn över det den inte ser. Användbara mätetal omfattar begäransvolym per rättighetstyp, genomsnittlig tid till bekräftelse, genomsnittlig tid till stängning, tidsfristefterlevnad, andel identitetsförtydliganden, raderingsundantag, ärenden med rättsligt bevarande, leverantörers svarstider, partiella avslag, incidenter som identifierats under hantering och öppna avhjälpande åtgärder.

Dessa mätetal visar om registrerades rättigheter har en stabil operativ hantering eller är beroende av hjältedåd.

Vanliga luckor i DSAR-beredskap

Clarysec ser ofta samma svagheter hos SaaS-bolag, fintech, professionella tjänsteföretag och molnorienterade små och medelstora företag:

• Ingen ägare för varje system som innehåller personuppgifter
• Behandlingsregistret är inte anpassat till faktisk SaaS-användning
• Marknadsförings-, analys- och datalagerplattformar utesluts från sökningar
• Ingen dokumenterad standard för identitetsverifiering
• Ingen maskeringsgranskning före utlämnande
• Radering i produktion utförs utan hantering av säkerhetskopior
• Ingen kontroll av rättsligt bevarande före radering
• Begränsning hanteras manuellt utan systemflagga
• Leverantörsavtal saknar villkor för DSAR-stöd
• Avslag och partiella avslag dokumenteras inte
• Ingen internrevision med urval av slutförda DSAR
• Frontlinjepersonal är inte utbildad i att känna igen begäranden

Din checklista för DSAR-beredskap 2026

Använd detta som ett mognadstest:

• Har vi en dokumenterad process för mottagning, validering, uppföljning och svar avseende DSR?
• Bekräftar vi begäranden inom en definierad intern SLA?
• Upprätthåller vi ett säkert DSR-register med begränsad åtkomst?
• Har vi ett aktuellt register över behandlingsaktiviteter med kategorier, ändamål, rättsliga grunder och bevarandetider?
• Känner vi till varje system, SaaS-plattform, lagringsplats och leverantör som kan innehålla personuppgifter?
• Har varje relevant tillgång en ansvarsskyldig ägare?
• Kan vi exportera personuppgifter säkert?
• Kan vi radera personuppgifter säkert där det krävs enligt lag?
• Kan vi begränsa behandling tekniskt eller processuellt?
• Kontrollerar vi rättsligt bevarande före radering?
• Dokumenterar vi beslut om avslag, partiella avslag och undantag?
• Stödjer leverantörsavtal DSAR-assistans?
• Testar vi arbetsflödet genom internrevision eller skrivbordsövningar?
• Rapporterar vi DSAR-prestanda till ledningen?
• Mappar vi DSAR-kontroller till ISO/IEC 27001:2022-riskbehandling och tillämpbarhetsförklaringen?

Om flera svar är ”inte konsekvent” kan nästa begäran synliggöra luckan.

Gör registrerades rättigheter till revisionsklart underlag

Registrerades rättigheter 2026 kräver mer än goda avsikter och en integritetsinkorg. De kräver ett arbetsflöde som kan hitta uppgifter, validera identitet, fatta lagliga beslut, samordna leverantörer, skydda utlämnande, genomföra radering, tillämpa begränsning och bevara underlag.

Clarysec hjälper organisationer att bygga detta arbetsflöde utan att skapa en parallell regelefterlevnadsbyråkrati. Börja med Zenith Blueprint för att placera registrerades rättigheter i rätt ISMS-fas och rätt steg. Använd Clarysecs Policy för dataskydd och integritet, Policy för dataskydd och integritet – SME, Policy för databevarande och bortskaffning, Datalagringspolicy och policy för säker bortskaffning – SME och Policy för applikationssäkerhetskrav – SME för att definiera ägarskap och operativa regler.

Använd därefter Zenith Controls för att mappa ISO/IEC 27002:2022 controls 5.9, 5.34 och 8.10 till efterlevnadsunderlag över flera ramverk avseende GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 och COBIT 2019-säkerhetsförsäkran.

Om du vill veta om era DSAR-, raderings- och begränsningsarbetsflöden skulle klara en revision i morgon kan Clarysec hjälpa er att testa processen, stänga luckorna och bygga underlagspaketet innan nästa begäran kommer. Ladda ned relevanta Clarysec-policymallar eller boka en DSAR-beredskapsbedömning för att gå från reaktiv respons till kontrollerad och revisionsklar integritetsdrift.