DSAR, sletning og ISO 27001-revisionsbevis i 2026

E-mailen landede i Sarahs indbakke kl. 9.03.

Det var ikke den første indsigtsanmodning fra en registreret, som hendes hurtigt voksende SaaS-virksomhed havde modtaget. Det var den første, der føltes som en offentlig revision.

Afsenderen var en tidligere medarbejder, nu privatlivsforkæmper. Anmodningen henviste til GDPR-artikler med numre og krævede alle personoplysninger, øjeblikkelig begrænsning af behandling, en liste over alle tredjepartstjenester, der opbevarede vedkommendes data, samt verificerbart bevis for sletning fra produktions- og backupsystemer. En journalist var sat på kopi.

På få minutter blev hullerne synlige. Engineering advarede om, at “ægte sletning” fra en multi-tenant-database kunne påvirke andre kunder. Marketing var ved at udrede brugerdata på tværs af analyseplatforme. Jura fandt en uafklaret ansættelsessag. Sikkerhed var bekymret for, at logfiler kunne afsløre detektionslogik eller en anden persons data. Support havde registreringer under to e-mailadresser. Økonomi havde fakturaer under en tredje.

Uret var allerede begyndt at tikke.

Det scenarie er ikke længere usædvanligt. Registreredes rettigheder i 2026 er ikke et problem, der kan løses med en privatlivsindbakke. De er en kontrolleret forretningsproces, der afhænger af aktivfortegnelser, beslutninger om behandlingsgrundlag, identitetsverifikation, adgangsstyring, opbevaringsregler, legal hold, leverandørkoordinering, sikker udlevering, bevis for sletning og revisionsklar logning.

GDPR angiver, hvilke rettigheder personer har. ISO/IEC 27001:2022 giver sikkerheds- og compliance-teams den ledelsessystemdisciplin, der skal til for at dokumentere, at disse rettigheder håndteres ensartet, sikkert og gentageligt.

For CISO’er, complianceansvarlige, privatlivsansvarlige og virksomhedsejere er målet ikke at skabe mere papirarbejde. Målet er at opbygge én pålidelig arbejdsgang for DSAR, sletning og begrænsning, som producerer det revisionsbevis, der kræves af GDPR, ISO/IEC 27001:2022-revisioner og bredere dokumentationsforventninger under NIS2, DORA, NIST CSF 2.0 og COBIT 2019.

Hvorfor ad hoc-håndtering af DSAR fejler under pres

De fleste DSAR-fejl skyldes ikke dårlige intentioner. De skyldes fragmentering.

En virksomhed kan have en privatlivsmeddelelse, en DPO-postkasse og en GDPR-klausul i leverandørkontrakter, men stadig have svært ved at besvare grundlæggende driftsmæssige spørgsmål:

• Hvem validerer anmoderens identitet?
• Hvilken juridisk enhed er dataansvarlig eller databehandler?
• Hvilke systemer skal gennemsøges?
• Hvem ejer hvert system?
• Hvilke data er omfattet?
• Hvilke data skal redigeres før udlevering?
• Hvilke data kan ikke slettes på grund af skat, revision, retssager, svigforebyggelse eller retlig forpligtelse?
• Hvordan håndhæves begrænsning af behandling teknisk?
• Hvilke leverandører skal understøtte søgning, eksport, sletning eller begrænsning?
• Hvilket revisionsbevis dokumenterer, at anmodningen blev håndteret rettidigt?
• Hvad sker der, hvis DSAR’en afdækker et brud på persondatasikkerheden?

GDPR artikel 5 kræver, at personoplysninger behandles lovligt, rimeligt og gennemsigtigt, indsamles til specificerede formål, begrænses til det nødvendige, holdes korrekte, ikke opbevares længere end nødvendigt og beskyttes med passende tekniske og organisatoriske foranstaltninger. Artikel 5(2) gør ansvarlighed eksplicit: den dataansvarlige skal kunne dokumentere overholdelse. Artikel 4 definerer behandling bredt, herunder indsamling, opbevaring, brug, udlevering, begrænsning, sletning og tilintetgørelse.

Det betyder, at selve DSAR-processen er en behandlingsaktivitet. Den skal kontrolleres.

GDPR artikel 3 er også vigtig for cloud-, SaaS-, fintech- og digitale virksomheder uden for EU. Hvis I tilbyder varer eller tjenester til personer i Unionen, overvåger deres adfærd eller behandler personoplysninger i forbindelse med en etablering i EU, kan GDPR finde anvendelse, selv når driften er outsourcet, eller infrastrukturen er global.

ISO/IEC 27001:2022 giver struktur til denne virkelighed. Clause 4.1 to 4.4 kræver, at organisationen forstår sin kontekst, interessenter, krav, ISMS-omfang og samvirkende processer. En registreret er en interessent. GDPR-rettigheder er krav. SaaS-applikationer, identitetsudbydere, analyseplatforme, supportværktøjer, data warehouses og cloudbackups er samvirkende processer. En DSAR-arbejdsgang hører hjemme i ISMS’et, ikke ved siden af det.

De tre rettigheder for registrerede, der skaber mest pres

Indsigt, sletning og begrænsning synliggør det største gab mellem juridisk løfte og operationel kapacitet.

GDPR artikel 6 er central for denne beslutningslogik. I kan ikke behandle, opbevare, udlevere eller afvise sletning uden at forstå behandlingsgrundlaget. Artikel 9 hæver kravet for særlige kategorier af personoplysninger, f.eks. helbredsoplysninger, biometriske data anvendt til entydig identifikation eller data, der afslører følsomme karakteristika. I et SaaS-miljø i 2026 kan dette påvirke onboarding, identitetsverifikation, svigovervågning, vedhæftede filer i kundesupport og medarbejderregistre.

Clarysecs virksomhedsrettede Databeskyttelses- og privatlivspolitik [P17] beskriver forpligtelsen direkte. I Mål clause 3.6 kræver den, at organisationen skal:

Opretholde registreredes rettigheder, herunder indsigt, berigtigelse, sletning, begrænsning, dataportabilitet, indsigelse og beskyttelse mod automatiske afgørelser.

Det mål bliver først revisionsbart, når det knyttes til ejere, registre, arbejdsgange, kontroller og revisionsbevis.

Start dér, hvor revisorer starter: omfang, interessenter og ejerskab

I Zenith Blueprint: en revisors 30-trins køreplan [ZB] fokuserer fasen ISMS Foundation & Leadership, Step 2, på interessentbehov og ISMS-omfang. For GDPR identificerer Blueprint myndighedsforventninger som:

EU-tilsynsmyndigheder
(GDPR)

Lovlig behandling af personoplysninger,
anmeldelse af brud inden for 72 timer,
registreredes rettigheder

Udpeg databeskyttelsesrådgiver, etabler
proces for håndtering af brud, procedurer for
håndtering af dataanmodninger.

Dette er det rigtige udgangspunkt. Før tickets automatiseres, eller portaler konfigureres, skal omfanget af behandlingen af registreredes rettigheder defineres:

1. Hvilke juridiske enheder fungerer som dataansvarlig, fælles dataansvarlig eller databehandler?
2. Hvilke produkter, tjenester og geografiske områder er omfattet?
3. Hvilke kategorier af registrerede findes, f.eks. kunder, medarbejdere, prøvebrugere, kundeemner, leverandører, websitebesøgende eller app-brugere?
4. Hvilke systemer, repositories og leverandører opbevarer personoplysninger?
5. Hvilke roller godkender udlevering, afslag, sletning, begrænsning eller eskalering?
6. Hvilke metrikker rapporteres til ledelsen?

ISO/IEC 27001:2022 clause 5.1 to 5.3 kræver lederskab, politiktilpasning, ressourcer og tildelte ansvarsområder. Det stemmer direkte overens med ansvarlighed efter GDPR.

Databeskyttelses- og privatlivspolitik [P17], Krav til implementering af politikken clause 6.4.1, angiver:

Databeskyttelsesrådgiveren (DPO) skal vedligeholde dokumenterede processer for modtagelse, validering, sporing og besvarelse af anmodninger fra registrerede (DSR).

For SMV’er anvender Clarysecs Databeskyttelses- og privatlivspolitik - SMV [P17S] et tilpasset ejerskab. Styringskrav clause 5.2.1 angiver:

Koordinatoren for databeskyttelse skal vedligeholde et register over alle behandlingsaktiviteter med personoplysninger, herunder datakategorier, formål, behandlingsgrundlag og opbevaringsperioder

Dette register over behandlingsaktiviteter er det operationelle centrum for DSAR-beredskab. Hvis det er ufuldstændigt, søger DSAR-teamet ud fra hukommelse, Slack-beskeder og uformel viden. Hvis det er korrekt, søger teamet efter behandlingsaktivitet, datakategori, systemejer, leverandør og opbevaringsregel.

Clarysecs DSAR-arbejdsgang: fra modtagelse til lukning

En revisionsklar DSAR-arbejdsgang skal være enkel nok til at køre under pres, men kontrolleret nok til at kunne modstå en tilsynsmyndighed, en kundes dokumentationsgennemgang eller en ISO/IEC 27001:2022-revision.

1. Modtagelse og bekræftelse

Anmodninger bør komme ind via en kontrolleret kanal, f.eks. en privatlivspostkasse, portal, supportformular eller juridisk modtagelseskø. Medarbejdere skal kunne genkende anmodninger formuleret i almindeligt sprog. En person behøver ikke at skrive “DSAR” for at udøve en rettighed. “Hvilke data har I om mig?” eller “slet min profil” kan være nok til at udløse arbejdsgangen.

Databeskyttelses- og privatlivspolitik - SMV [P17S], Krav til implementering af politikken clause 6.5.2, fastsætter et klart serviceniveau:

Koordinatoren for databeskyttelse skal bekræfte modtagelse af anmodninger inden for 3 arbejdsdage og svare inden for 30 dage

Bekræftelsen bør indeholde anmodningsreference, afklaring af omfang hvis nødvendigt, instruktioner til identitetsverifikation og forventet svartidspunkt.

2. Identitetsverifikation og kontrol af bemyndigelse

En DSAR kan blive et brud på persondatasikkerheden, hvis oplysninger sendes til den forkerte person. Verifikation skal være proportional og må ikke indsamle unødigt mange nye personoplysninger. Brug autentificerede portaler, hvor det er muligt. For tidligere brugere valideres mod kendte kontodata. For medarbejdere koordineres med HR. For repræsentanter kræves dokumentation for bemyndigelse.

Opbevar revisionsbevis for verifikationsmetoden, dato for gennemførelse, godkender, eventuelle yderligere oplysninger, der blev anmodet om, og beslutningen, hvis verifikationen ikke lykkes.

3. Klassificér anmodningen

Én enkelt besked kan indeholde flere rettigheder. Klassificér hver rettighed særskilt, fordi indsigt, sletning, begrænsning, indsigelse og dataportabilitet kræver forskellig beslutningslogik og forskelligt revisionsbevis. Markér også potentielle klager, medarbejdersager, børns data, særlige kategorier af personoplysninger og potentielle brud på persondatasikkerheden.

4. Søg i fortegnelsen, ikke kun i de oplagte systemer

Det er her, ISO/IEC 27001:2022 bliver praktisk. Zenith Blueprint [ZB], fasen Controls in Action, Step 22, advarer om, at fortegnelsens omfang er bredere, end mange organisationer forventer:

Omfanget af denne fortegnelse er bredere, end de fleste er klar over. Den bør omfatte:

✓ Fysiske aktiver: bærbare computere, servere, telefoner, backupbånd, flytbare medier, udskrevne
registreringer.
✓ Digitale aktiver: dokumenter, datasæt, repositories, e-mails, kildekode, cloudlagrede
filer.
✓ Logiske aktiver: brugerkonti, legitimationsoplysninger, nøgler, softwarelicenser, API’er.
✓ Servicerelaterede aktiver: SaaS-platforme, administrerede sikkerhedstjenester, outsourcet
lagring.
✓ Mennesker som aktiver: ikke i en varegjort betydning, men i forhold til tildelte ansvarsområder,
adgang og rollebaseret eksponering for information.

Step 22 forklarer også ejerskab:

Hvert aktiv bør have en defineret ejer, ikke den person, der bruger det, men den, der er ansvarlig for
dets brug, beskyttelse og livscyklus. Ejerskab er afgørende for kontroltilpasning: hvem klassificerer
aktivet (5.10), hvem beslutter dets adgangsniveau (8.3), hvem håndterer dets sletning (8.10), hvem sikrer,
at det returneres (5.9 overlapper diskret med procedurer for tilbagelevering af aktiver).

I Zenith Controls: vejledningen til cross-compliance [ZC] behandles ISO/IEC 27002:2022 control 5.9, Fortegnelse over information og andre tilknyttede aktiver, som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed. Dens cybersikkerhedskoncept er Identify, dens operationelle kapacitet er Asset Management, og dens sikkerhedsdomæner omfatter Governance, Ecosystem og Protection.

For DSAR’er betyder det, at fortegnelsen ikke er et IT-regneark. Den er kortet, der fortæller privatlivs-, juridiske og sikkerhedsfunktioner, hvor personoplysninger kan findes.

5. Gennemgå, redigér og godkend udlevering

Et DSAR-svar bør ikke være en rå eksport. Gennemgangen skal beskytte andre personers personoplysninger, fortrolige forretningsoplysninger, advokatfortrolighed, sikkerhedsfølsomme data, svigsignaler og data uden for anmodningens omfang.

Godkendelse bør være risikobaseret. Rutinemæssige svar på indsigtsanmodninger kan godkendes af koordinatoren for databeskyttelse eller DPO’en. Anmodninger, der involverer medarbejdere, retssager, særlige kategorier af personoplysninger, børn, svig, sikkerhedslogfiler eller store eksporter, bør involvere juridisk funktion, HR eller sikkerhedsledelse.

6. Lever sikkert

Vedhæft ikke store ukrypterede filer til e-mails. Brug autentificerede portaler, krypterede filer med separat levering af adgangskode eller sikre overførselslinks med udløb og logning af adgang. Registrér leveringsmetode, dato, modtagerkonto, udløbsdato og bekræftelse, hvor det er tilgængeligt.

7. Luk med revisionsbevis

Databeskyttelses- og privatlivspolitik [P17], clause 6.4.3, er eksplicit:

Alle udførte handlinger skal logges til revisionsformål, herunder beslutninger om at afvise anmodninger.

Databeskyttelses- og privatlivspolitik - SMV [P17S], clause 6.5.4, angiver:

Alle svar på anmodninger fra registrerede skal logges i et sikkert register med adgang begrænset til koordinatoren for databeskyttelse og den administrerende direktør

En DSAR er ikke afsluttet, når e-mailen er sendt. Den er afsluttet, når registret viser anmodningen, identitetskontrollen, beslutningerne, de gennemsøgte systemer, svaret, undtagelserne, godkendelserne, leveringen og lukningen.

Sletning er kontrolleret tilintetgørelse, ikke en slet-knap

Anmodninger om sletning afslører, om privatliv er indbygget i systemerne eller blot sat på efter lancering.

Clarysecs virksomhedsrettede Dataopbevarings- og bortskaffelsespolitik [P14], Roller og ansvar clause 4.3.3, tildeler ansvar til den rolle, der:

Besvarer anmodninger om sletning og sikrer rettidig, verificerbar sletning af personoplysninger, hvor det kræves.

Formuleringen “hvor det kræves” er kritisk. Sletning efter GDPR er ikke absolut. Organisationer kan være nødt til at opbevare data af hensyn til retlige forpligtelser, revision, skat, regulatoriske forpligtelser, svigforebyggelse, sikkerhed, retssager eller fastlæggelse, udøvelse eller forsvar af retskrav. Arbejdsgangen skal omfatte en lovlig beslutning om opbevaring og undtagelse.

Zenith Blueprint [ZB], fasen Controls in Action, Step 19, forklarer ISO/IEC 27002:2022 control 8.10, Sletning af information, i operationelle termer:

Denne kontrol sikrer, at data ikke opbevares længere end nødvendigt, og når de ikke længere
er nødvendige, skal de slettes sikkert og pålideligt. Mange organisationer opbygger store
datamængder over tid, men uden en klar sletningsproces kan disse data ligge ubenyttede og
ubeskyttede, hvilket stille øger risikoen for eksponering, brud eller regulatorisk overtrædelse.

Den advarer også:

Glem ikke backups og arkiverede systemer; de bevarer ofte historiske data længe efter deres
operationelle værdi. Sletningspolitikker skal omfatte:

✓ Indstillinger for backupopbevaring,
✓ Livscyklusser for snapshots,
✓ Arkiverede e-mail- eller dokumentrepositories.

Og den afslutter med revisionsbevis:

Selve sletningsprocessen skal logges, og for højrisikodata eller regulerede data skal den
gennemgås eller godkendes. Det sikrer sporbarhed og beskytter mod utilsigtet eller
uautoriseret tilintetgørelse af værdifulde registreringer.

I Zenith Controls [ZC] kortlægges ISO/IEC 27002:2022 control 8.10, Sletning af information, som en forebyggende kontrol med fokus på fortrolighed, tilpasset cybersikkerhedskonceptet Protect og knyttet til de operationelle kapaciteter Information Protection samt Legal and Compliance.

For komplekse cloudarkitekturer kan kryptografisk sletning være relevant, hvis den er designet korrekt. Hvis personoplysninger krypteres med en nøgle, der er specifik for den registrerede eller tenant’en, kan destruktion af nøglen gøre data permanent utilgængelige, også hvor krypterede rester bliver liggende i backups indtil planlagt rotation. Dette skal designes, dokumenteres, testes og godkendes omhyggeligt. Det er ikke en omgåelse af en dårlig sletningsarkitektur.

Applikationsberedskab er derfor afgørende. Clarysecs Politik for krav til applikationssikkerhed - SMV [P09S], clause 6.5.1.3, kræver, at applikationer:

muliggør sikker eksport og sletning af personoplysninger, når det kræves efter lovgivningen (f.eks. GDPR Article 17 – retten til sletning).

Hvis produktteams ikke bygger eksport- og sletningskapacitet, tvinges privatlivsteams over i databasescripts, leverandørtickets og inkonsistent manuelt arbejde.

Legal hold og suspension af sletning

En moden arbejdsgang for sletning skal omfatte en “slet ikke”-vej. Det er ikke en undskyldning for at ignorere sletning. Det er en kontrolleret undtagelse.

Clarysecs SMV-Dataopbevaringspolitik og politik for sikker bortskaffelse - SMV [P14S], Styringskrav clause 5.4, angiver:

Data, der er omfattet af Legal Hold og sletningssuspension (f.eks. i forbindelse med retssag, revision eller undersøgelse), skal være tydeligt identificeret i systemet og beskyttet mod sletning, selv hvis den planlagte opbevaringsperiode er udløbet.

Dataopbevarings- og bortskaffelsespolitik [P14], clause 6.4.1, afspejler samme princip:

Hvis der udstedes legal hold og sletningssuspension (f.eks. ved verserende retssag, undersøgelse eller revision), skal data, der ellers ville være omfattet af tilintetgørelse, bevares ud over deres normale opbevaringsperiode.

Revisorer ønsker begge sider af historien: revisionsbevis for rettidig sletning og revisionsbevis for begrundet opbevaring.

Begrænsning af behandling: den undervurderede rettighed

Anmodninger om begrænsning kræver ikke altid sletning. De kræver, at organisationen begrænser aktiv behandling, samtidig med at data opbevares under kontrollerede forhold.

Almindelige eksempler omfatter:

• En kunde bestrider korrektheden og beder jer om at stoppe med at bruge dataene, mens de verificeres.
• En tidligere medarbejder gør indsigelse mod behandling, men registreringen er nødvendig for retskrav.
• En bruger anmoder om sletning, men minimale data skal opbevares for at vedligeholde en suppressionliste.
• En svigundersøgelse kræver opbevaring, men ikke normal operationel brug.

En praktisk arbejdsgang for begrænsning bør omfatte en juridisk beslutning, systemmarkering, justering af adgangsstyring, marketing-suppression, udelukkelse fra analyse, leverandørinstruks, periodisk gennemgang og revisionsbevis for undtagelser.

I Zenith Controls [ZC] behandles ISO/IEC 27002:2022 control 5.34, Privatliv og beskyttelse af personhenførbare oplysninger (PII), som en forebyggende kontrol, der understøtter fortrolighed, integritet og tilgængelighed. Den kortlægges til Identify og Protect med operationelle kapaciteter inden for Information Protection og Legal and Compliance.

Zenith Blueprint [ZB], fasen Controls in Action, Step 23, opsummerer revisionstesten:

Bekræft, at organisationen har implementeret privatlivsforanstaltninger (5.34), der er tilpasset
gældende lovkrav. Verificér klassificering af personhenførbare oplysninger (PII), passende adgangsstyring, sikker
håndteringspraksis og awareness-træning. Valider, om anmodninger om indsigt,
sletning af data eller logfiler for behandling understøttes operationelt, ikke kun af politikken.

Nøgleformuleringen er “understøttes operationelt, ikke kun af politikken.”

Kortlægning af DSAR-arbejdsgange til ISO/IEC 27001:2022-revisionsbevis

ISO/IEC 27001:2022 erstatter ikke GDPR. Den organiserer revisionsbevis.

Clause 6.1.1 to 6.1.3 kræver risikovurdering, risikobehandling, kriterier for risikoaccept, risikoejere, kontroludvælgelse, en anvendelighedserklæring og en risikobehandlingsplan. DSAR-risici omfatter uautoriseret udlevering, overskredne frister, ufuldstændig sletning, ulovlig opbevaring, overdreven identitetsverifikation, manglende leverandørsamarbejde og manglende evne til at begrænse behandling.

Clause 8.1 kræver, at organisationer planlægger, implementerer og styrer ISMS-processer, opbevarer dokumenteret revisionsbevis, styrer ændringer og sikrer, at eksternt leverede processer, produkter og tjenester, der er relevante for ISMS’et, kontrolleres. Det passer til DSAR-drift, fordi anmodninger går på tværs af interne funktioner og eksterne databehandlere.

En stærk bevispakke omfatter DSR-procedure, DSR-register, register over behandlingsaktiviteter, aktivfortegnelse, dataopbevaringsplan, legal hold-register, procedure for identitetsverifikation, vejledning i redigering, sikker udleveringsmetode, sletningsprocedure, procedure for begrænsning, leverandørplaybook, undtagelsesregister, træningsregistreringer, resultater fra intern revision og rapportering fra ledelsens gennemgang.

En praktisk arbejdsgang for indsigt, sletning og begrænsning

Denne arbejdsgang gør Sarahs krise til en revisionsbar proces. Hvert trin har en ejer, et kontrolgrundlag og revisionsbevis.

Cross-compliance-værdi ud over GDPR

En DSAR-arbejdsgang har rod i GDPR, men de samme kontroller understøtter bredere frameworks.

NIS2 Article 20 gør cybersikkerhed til et ledelsesansvar for væsentlige og vigtige enheder. Article 21 kræver passende og forholdsmæssige tekniske, operationelle og organisatoriske foranstaltninger, herunder risikoanalyse, hændelseshåndtering, forretningskontinuitet, sikkerhed i forsyningskæden, effektivitetsvurdering, cyberhygiejne, træning, adgangsstyring, styring af aktiver, autentifikation og sikker kommunikation. DSAR’er afhænger af mange af de samme kapaciteter.

DORA har været gældende siden 17. januar 2025 for mange finansielle enheder og fastsætter ensartede krav til styring af IKT-risiko, rapportering af hændelser, robusthedstest og IKT-tredjepartsrisiko. Article 5 and 6 kræver governance og dokumenteret styring af IKT-risiko. Article 17 to 20 omhandler hændelsesdetektion, klassificering, eskalering, kommunikation og lukning. Article 24 to 30 omhandler robusthedstest, IKT-tredjepartsrisiko, tjenesteregistre, revisionsrettigheder, datalokation, bistand ved hændelser og exitstrategier. En fintechvirksomhed, der håndterer DSAR’er via cloudplatforme, bør afstemme håndteringen af privatlivsanmodninger med sit IKT-tjenesteregister.

NIST CSF 2.0 hjælper med at omsætte det samme arbejde til cybersikkerhedsresultater. GOVERN omhandler retlige, regulatoriske og kontraktlige krav, risikostrategi, roller, politik og tilsyn. IDENTIFY og PROTECT flugter stærkt med synlighed over aktiver, dataklassificering, adgangsstyring, sletning, leverandørstyring og privatlivsbeskyttelse.

COBIT 2019 stiller governance-spørgsmål. Hvem ejer processen? Hvilke mål er defineret? Hvordan måles performance? Hvordan godkendes undtagelser? Hvordan opnås assurance? DSAR-revisionsbevis kan understøtte mål som APO13 Managed Security, APO14 Managed Data og DSS06 Managed Business Process Controls.

Revisorens perspektiv

Opret ikke særskilt revisionsbevis for hvert framework. Opret én pålidelig DSAR-arbejdsgang, og kortlæg den godt.

DSAR-metrikker, som ledelsen bør se

Ledelsen kan ikke føre tilsyn med det, den ikke kan se. Nyttige metrikker omfatter anmodningsvolumen pr. rettighedstype, gennemsnitlig tid til bekræftelse, gennemsnitlig lukningstid, fristoverholdelse, rater for identitetsafklaring, sletningsundtagelser, legal hold-sager, leverandørers svartider, delvise afslag, hændelser identificeret under håndteringen og åbne afhjælpende foranstaltninger.

Disse metrikker viser, om registreredes rettigheder er operationelt sunde eller afhængige af helteindsats.

Almindelige mangler i DSAR-beredskab

Clarysec ser ofte de samme svagheder på tværs af SaaS, fintech, professionelle tjenester og cloud-first SMV’er:

• Ingen ejer for hvert system, der indeholder personoplysninger
• Register over behandlingsaktiviteter stemmer ikke overens med faktisk SaaS-brug
• Marketing-, analyse- og data warehouse-platforme udelades fra søgninger
• Ingen dokumenteret standard for identitetsverifikation
• Ingen redigeringsgennemgang før udlevering
• Sletning i produktionsmiljø udføres uden håndtering af backups
• Ingen legal hold-kontrol før sletning
• Begrænsning håndteres manuelt uden systemmarkering
• Leverandørkontrakter mangler vilkår om DSAR-bistand
• Afslag og delvise afslag dokumenteres ikke
• Ingen intern revisionsstikprøve af afsluttede DSAR’er
• Frontlinjemedarbejdere er ikke trænet i at genkende anmodninger

Din tjekliste for DSAR-beredskab i 2026

Brug dette som modenhedstest:

• Har vi en dokumenteret proces for modtagelse, validering, sporing og besvarelse af DSR’er?
• Bekræfter vi modtagelse af anmodninger inden for en defineret intern SLA?
• Vedligeholder vi et sikkert DSR-register med begrænset adgang?
• Har vi et aktuelt register over behandlingsaktiviteter med kategorier, formål, behandlingsgrundlag og opbevaringsperioder?
• Kender vi hvert system, hver SaaS-platform, hvert repository og hver leverandør, der kan opbevare personoplysninger?
• Har hvert relevant aktiv en ansvarlig ejer?
• Kan vi eksportere personoplysninger sikkert?
• Kan vi slette personoplysninger sikkert, hvor det kræves efter lovgivningen?
• Kan vi begrænse behandling teknisk eller proceduremæssigt?
• Kontrollerer vi legal hold før sletning?
• Dokumenterer vi beslutninger om afslag, delvist afslag og undtagelser?
• Understøtter leverandørkontrakter DSAR-bistand?
• Tester vi arbejdsgangen gennem intern revision eller tabletop-øvelser?
• Rapporterer vi DSAR-performance til ledelsen?
• Kortlægger vi DSAR-kontroller til ISO/IEC 27001:2022-risikobehandling og anvendelighedserklæringen?

Hvis flere svar er “ikke konsekvent”, kan den næste anmodning afsløre hullet.

Gør registreredes rettigheder til revisionsklart revisionsbevis

Registreredes rettigheder i 2026 kræver mere end gode intentioner og en privatlivsindbakke. De kræver en arbejdsgang, der kan finde data, validere identitet, træffe lovlige beslutninger, koordinere leverandører, beskytte udlevering, gennemføre sletning, håndhæve begrænsning og bevare revisionsbevis.

Clarysec hjælper organisationer med at opbygge denne arbejdsgang uden at skabe et parallelt compliance-bureaukrati. Start med Zenith Blueprint for at placere registreredes rettigheder i den rette ISMS-fase og de rette trin. Brug Clarysecs Databeskyttelses- og privatlivspolitik, Databeskyttelses- og privatlivspolitik - SMV, Dataopbevarings- og bortskaffelsespolitik, Dataopbevaringspolitik og politik for sikker bortskaffelse - SMV og Politik for krav til applikationssikkerhed - SMV til at definere ejerskab og driftsregler.

Brug derefter Zenith Controls til at kortlægge ISO/IEC 27002:2022 controls 5.9, 5.34 og 8.10 til cross-compliance-revisionsbevis for GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 og COBIT 2019-assurance.

Hvis du vil vide, om jeres arbejdsgange for DSAR, sletning og begrænsning ville overleve en revision i morgen, kan Clarysec hjælpe jer med at teste processen, lukke hullerne og opbygge bevispakken, før den næste anmodning kommer. Download de relevante Clarysec-politikskabeloner, eller book en vurdering af DSAR-beredskab for at gå fra reaktiv respons til kontrollerede, revisionsklare privatlivsprocesser.