Sletningscertifikater for PII ved ophør af databehandlerforhold

Maria, CISO i en voksende europæisk fintechvirksomhed, stirrede på en kort e-mail fra DataLeap, den SaaS-udbyder til marketinganalyse, som hendes virksomhed netop havde opsagt.

“Vi bekræfter, at alle data knyttet til jeres konto er slettet fra vores produktionssystemer.”

Den var høflig, hurtig og næsten ubrugelig.

I tre år havde DataLeap behandlet kundeidentifikatorer, kampagneinteraktionsdata, lead scoring-attributter, samtykkemetadata og adfærdsanalyser for tusindvis af EU-kunder. FinSecure forberedte sig på en DORA-revision, databeskyttelsesrådgiveren (DPO) gennemgik GDPR-dokumentation for ansvarlighed, og indkøbsteamet ville lukke leverandørregistreringen før næste faktureringscyklus. E-mailen besvarede kun ét snævert spørgsmål: produktionsdata. Den sagde intet om backups, logfiler, supportsager, analysearbejdsområder, caches hos underdatabehandlere, testkopier, API-legitimationsoplysninger eller arkiverede rapporter.

Maria stillede det spørgsmål, som enhver CISO, DPO og compliance-ansvarlig før eller siden møder ved ophør af en SaaS-relation:

Hvor er sletningscertifikatet?

Det spørgsmål forvandler en almindelig kontraktopsigelse til en compliance-hændelse. Efter GDPR skal dataansvarlige kunne dokumentere overholdelse af principper som opbevaringsbegrænsning, integritet, fortrolighed og ansvarlighed. Efter DORA skal finansielle enheder styre IKT-tredjepartsrisici gennem hele relationens livscyklus, herunder opsigelse og exitstrategier, der forebygger driftsafbrydelser, manglende lovoverholdelse og skade for kunder. Efter ISO/IEC 27701:2025 har organisationer brug for rollebaseret PIMS-dokumentation for behandlingsaktiviteter som dataansvarlig, databehandler, underdatabehandler og cloud PII-databehandler. Efter ISO/IEC 27001:2022 skal leverandørafhængigheder, eksterne tjenester, operationelle kontroller og opbevaret bevismateriale styres i ledelsessystemet for informationssikkerhed.

Manglerne opdages sjældent under onboarding. De viser sig ved exit. Kontrakten siger, at data skal slettes, men definerer ikke bevismateriale. Cloududbyderen kan eksportere en CSV-fil, men kan ikke forklare håndteringen af backups. Indkøb kan opsige leverandøren, men compliance kan ikke dokumentere den endelige håndtering. IT kan deaktivere konti, men deaktivering af adgang er ikke sletning. Jura kan sende en opsigelsesmeddelelse, men revisorer forventer en dokumenteret beviskæde.

Clarysec behandler ophør af databehandlerforhold som en revisionsklar kontrolkæde, ikke som en administrativ eftertanke.

Hvorfor ophør af databehandlerforhold er blevet et compliance-fokusområde

Ophøret af en relation med en SaaS-, løn-, HR-, finans-, CRM-, cloudhosting-, marketinganalyse- eller administreret IKT-tjeneste er et af de mest risikofyldte tidspunkter i personoplysningers livscyklus. Under normal drift ved organisationen i det mindste, hvilket system der er aktivt, hvem der ejer det, og hvilken kontrakt der gælder. Ved opsigelse fragmenteres ejerskabet hurtigt. Indkøb lukker leverandørregistreringen. IT deaktiverer brugere. Jura arkiverer kontrakten. Forretningen flytter til erstatningsplatformen. Den tidligere leverandør fortsætter med at opbevare data efter standardcyklusser for backup, arkiv eller logning.

Det er netop den fragmentering, revisorer og tilsynsmyndigheder tester.

GDPR definerer behandling bredt, herunder opbevaring, sletning og destruktion. Forordningen skelner mellem dataansvarlige, der fastlægger formål og hjælpemidler, og databehandlere, der handler på vegne af dataansvarlige. Article 5 fastlægger principper som formålsbegrænsning, dataminimering, opbevaringsbegrænsning samt integritet og fortrolighed. Article 5(2) tilføjer ansvarlighedsprincippet, hvilket betyder, at den dataansvarlige skal kunne dokumentere overholdelse. Article 28(3)(g) kræver, at databehandleraftaler angiver, at databehandleren efter den dataansvarliges valg skal slette eller tilbagelevere alle personoplysninger ved tjenestens ophør og slette eksisterende kopier, medmindre lovgivningen kræver opbevaring.

En uformel leverandørmail opfylder sjældent dette niveau, når data omfatter lønoplysninger, finansielle registre, sundhedsrelaterede oplysninger, kundeidentifikatorer, autentifikationslogfiler eller regulerede kunderegistre.

DORA skærper kravene for finansielle enheder. Fra 17. januar 2025 gælder DORA som EU’s regelsæt for digital operationel robusthed i den finansielle sektor. DORA kræver, at finansielle enheder styrer IKT-tredjepartsrisici som en integreret del af deres samlede risikostyringsramme og fortsat har det fulde ansvar for efterlevelse, når tjenester outsources. DORA forventer, at organisationer vedligeholder informationsregistre over IKT-tjenestekontrakter, identificerer tjenester, der understøtter kritiske eller vigtige funktioner, gennemfører due diligence, vurderer koncentrationsrisiko, indarbejder kontraktlige rettigheder til adgang, genopretning og tilbagelevering af data samt vedligeholder opsigelses- og exitstrategier.

For kritiske eller vigtige funktioner skal DORA-kontrakter gå længere. De skal indeholde bestemmelser om revisionsrettigheder, overgangsperioder, serviceniveauer, beredskabstest, samarbejdsforpligtelser og exitsupport. Et sletningscertifikat er ikke hele DORA-exitpakken, men det er et kritisk bevisartefakt i den.

NIS2 er også relevant for mange udbydere i den bredere IKT-kæde, herunder cloud computing-udbydere, datacenterudbydere, udbydere af administrerede tjenester (MSP’er), udbydere af administrerede sikkerhedstjenester og andre udbydere af digital infrastruktur. NIS2 Article 21 kræver passende og forholdsmæssige tekniske, driftsmæssige og organisatoriske foranstaltninger, herunder sikkerhed i forsyningskæden, kontroller for leverandørrelationer, adgangsstyring, aktivstyring, hændelseshåndtering, kontinuitet og cyberhygiejne. For finansielle enheder omfattet af DORA fungerer DORA generelt som den sektorspecifikke EU-retsakt for sammenlignelige krav til IKT-risiko, rapportering, test og tredjepartsforhold, men NIS2 rammesætter stadig det bredere cybersikkerhedsøkosystem.

Det praktiske budskab er enkelt: Hvis en leverandør har behandlet PII, understøttet regulerede aktiviteter eller indgået i jeres IKT-tjenestekæde, er exitdokumentation en risikokontrol.

Clarysecs perspektiv: Ophør af databehandlerforhold er en kontrolkæde

En moden arbejdsgang for ophør af databehandlerforhold besvarer tre spørgsmål:

1. Hvilke data, systemer og underdatabehandlere er omfattet?
2. Hvilken tilbagelevering, overførsel, sletning eller bortskaffelse kræves juridisk og kontraktligt?
3. Hvilket bevismateriale dokumenterer, at handlingen var fuldført, før exit blev lukket?

I Zenith Controls: The Cross-Compliance Guide kortlægges dette scenarie til ISO/IEC 27002:2022 kontrol 5.20, “Addressing information security within supplier agreements”; kontrol 8.10, “Information deletion”; og kontrol 7.14, “Secure disposal or re-use of equipment.” Det er ikke separate tjeklistepunkter. Ophør af databehandlerforhold forbinder leverandøraftaler, styring af datalivscyklus, offboarding fra cloudtjenester, fjernelse af adgang, aktivejerskab, opbevaring af bevismateriale og revisionsberedskab.

Clarysecs Zenith Blueprint: An Auditor’s 30-Step Roadmap placerer dette i fasen Controls in Action. I Step 23, Organizational controls, forventes leverandøraftaler at dække bestemmelser ved kontraktophør, kontroller for underleverandører, revisionsrettigheder og hændelsesprotokoller. Blueprint beskriver typiske områder i leverandøraftaler som blandt andet:

“Bestemmelser ved kontraktophør, såsom tilbagelevering eller destruktion af data, genopretning af aktiver og deaktivering af konti.”

Det er i den sætning, GDPR-ansvarlighed, ISO/IEC 27701:2025 PIMS-dokumentation, DORA-forventninger til exit, NIS2-sikkerhed i forsyningskæden og ISO/IEC 27001:2022-operationel kontrol mødes.

Den samme Zenith Blueprint forklarer i Step 19, Technological Controls I, sletterisikoen bag ophør af databehandlerforhold:

“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.”

Step 18, Physical Controls II, omsætter forventningen til bevismateriale til praksis:

“Hvis der anvendes en ekstern udbyder, skal destruktionscertifikater indhentes og opbevares som revisionsbevismateriale.”

For cloudbaserede systemer ligger fysisk bortskaffelse normalt uden for kundens direkte kontrol. Det gør kontraktlig bekræftelse af sletning, sletningscertifikater på compliance-niveau og arkiveret ISMS-dokumentation endnu vigtigere.

Clarysecs driftsmodel er direkte: kontraktklausul, exitudløser, datafortegnelse, slettehandling, bekræftelse fra underdatabehandler, register over bevismateriale og endelig verifikation.

Hvorfor “slettet” ikke er det samme som dokumenteret

En typisk revisionskonstatering lyder sådan:

“Organisationen oplyste, at leverandøren havde slettet dataene, men kunne ikke fremlægge bevismateriale for sletningen, sletningens omfang, dato for sletning, ansvarlig part, omfattede systemer, håndtering af backups eller bekræftelse fra underdatabehandlere.”

Det sker i store virksomheder, men det er også almindeligt i SMV’er, der i høj grad anvender SaaS-værktøjer til løn, support ticketing, CRM, HR-onboarding, cloudlagring, samarbejde, analyse og softwareudvikling. Når en leverandør udskiftes, ligger personoplysninger ofte fortsat i inaktive konti, supportvedhæftninger, midlertidige migreringsfiler, udviklingseksporter, stagingdatabaser og backupcyklusser.

Clarysecs politiksæt gør “slettet” til et krav om bevismateriale.

Third party and supplier security policy [P26] kræver i klausul 6.5.1.2:

“Tilbagelevering eller certificeret destruktion af alle organisationsejede oplysninger”

Klausul 6.5.1.3 kræver derefter:

“Endelig compliance-verifikation (f.eks. loggennemgang, overensstemmelsesattester)”

Denne sondring er vigtig. Et sletningscertifikat er ikke hele kontrollen. Det er ét artefakt i en samlet pakke for endelig compliance-verifikation. Revisorer vil se, om certifikatet stemmer overens med leverandørkontrakten, datafortegnelsen, exit-ticketen, adgangslogfiler, listen over underdatabehandlere, opbevaringsplanen og risikovurderingen.

For SMV’er giver Third-Party and Supplier Security Policy - SME [P26S] en praktisk baseline. Klausul 5.3.6 under styringskrav kræver:

“Opsigelsesvilkår, herunder sikker tilbagelevering eller destruktion af data”

Klausul 6.4.2.3 under krav til implementering af politikken kræver, at leverandører:

“Skriftligt bekræfter, at data er slettet sikkert”

Data Retention and Disposal Policy [P14] tilføjer kravet om bevismateriale i klausul 4.7.2:

“Skal på anmodning fremlægge dokumenteret bevismateriale for efterlevelse (f.eks. sletningslogfiler, destruktionscertifikater).”

For SMV’er kræver Data Retention Policy and Secure Disposal Policy - SME i klausul 6.2.3:

“Bortskaffelseshændelser skal logges med dato, registreringskategori, metode og ansvarlig person.”

Det er forskellen mellem tillid til leverandøren og revisionsbevismateriale.

ISO/IEC 27701:2025: Rollebaseret exitdokumentation

ISO/IEC 27701:2025 tilføjer et lag for databeskyttelsesstyring til ISMS. Ophør af databehandlerforhold skal afspejle organisationens PIMS-rolle. En dataansvarlig, der forlader et databehandlerforhold, har andre ansvarsområder end en databehandler, der afslutter en relation til en underdatabehandler. En databehandler, der handler efter kundens instrukser, skal dokumentere, at instrukserne er fulgt. En cloud-databehandler skal vise, at tilbagelevering, overførsel, sletning eller bortskaffelse fandt sted inden for den tidsramme, der er aftalt med kunden.

Clarysecs PIMS-politiksæt bruger rollemærkninger til at gøre dette operationelt. “Both” gælder, uanset om organisationen er dataansvarlig eller databehandler. “Processor” gælder ved behandling af PII efter dokumenterede instrukser fra den dataansvarlige. “Subprocessor” gælder, når organisationen er engageret af en anden databehandler.

Processor, Subprocessor and Third-Party Privacy Management Policy kræver i klausul 4.5.6:

“[Begge] Den leverandør- eller indkøbsansvarlige SKAL indhente bevismateriale for tilbagelevering, sletning, bortskaffelse eller overgang i REG08 senest 30 dage efter kontraktopsigelse, udløb, kundens instruks eller godkendt exithændelse, medmindre en kortere kontraktperiode gælder.”

PII Retention, Deletion and Disposal Policy adskiller databehandler- og underdatabehandlerforpligtelser. Klausul 4.3.3 fastslår:

“[Databehandler] Den leverandør- eller indkøbsansvarlige SKAL udføre eller bekræfte kundestyret tilbagelevering, overførsel, sletning eller bortskaffelse i REG08 senest på den kontraktlige frist eller datoen for den dokumenterede kundeinstruks.”

Klausul 4.3.4 fastslår:

“[Underdatabehandler] Den leverandør- eller indkøbsansvarlige SKAL indhente bevismateriale for underdatabehandlerens tilbagelevering, sletning eller bortskaffelse i REG08 inden for den kontraktlige dokumentationsperiode efter kundens instruks, serviceexit eller opsigelse af underdatabehandleren.”

Klausul 7.1.7 knytter kravet tilbage til lukning:

“[Begge] Den leverandør- eller indkøbsansvarlige SKAL indhente bevismateriale fra databehandler, underdatabehandler eller ekstern tjeneste for krævede tilbageleverings-, overførsels- eller endelige håndteringshandlinger i REG08, før serviceexit lukkes.”

For cloudtjenester kræver Cloud PII Processor Policy i klausul 4.6.3:

“[Databehandler] Systemejer / applikationsejer SKAL gennemføre godkendt tilbagelevering, overførsel, sletning eller bortskaffelse af kundens PII inden for den tidsramme, der er aftalt med kunden, og registrere færdiggørelsesbevismateriale i REG08 eller REG12.”

Den operationelle forbedring er øjeblikkelig. Vent ikke på en revision. Opret kravet om bevismateriale ved exitudløseren, tildel en ejer, fastsæt en frist, og forhindr lukning, indtil REG08 eller REG12 er fuldstændig.

Hvad en god bevispakke for ophør af databehandlerforhold indeholder

Et sletningscertifikat bør ikke være en vag PDF med et logo og én sætning. Det skal understøtte en struktureret bevispakke, der kan modstå en GDPR-forespørgsel, en ISO/IEC 27701:2025 PIMS-revision, en ISO/IEC 27001:2022-overvågningsrevision, en DORA-tilsynsanmodning, en kundes assurance-gennemgang eller intern revision.

Dette er ikke bureaukrati. Det er en praktisk, sporbar beviskæde for PII ved serviceexit.

Kontraktklausulen, der forebygger krisen

Marias problem begyndte flere år før DataLeaps sidste e-mail. Det begyndte, da kontrakten blev underskrevet med en vag sletteklausul og uden krav om bevismateriale. Den stærkeste arbejdsgang for ophør af databehandlerforhold starter ved indkøb, ikke ved opsigelse.

For cloudtjenester kræver enterprise-udgaven af Cloud Usage Policy i klausul 5.4.4:

“Opsigelsesklausuler, der muliggør sikker og verificerbar offboarding”

For SMV’er kræver Cloud Usage Policy - SME i klausul 6.3.5:

“Bekræftelse af sikre sletteprocedurer før kontolukning”

En praktisk leverandørkontraktklausul bør kræve tilbagelevering eller sletning, definere frister, dække backups og underdatabehandlere, kræve bevismateriale og bevare revisionsrettigheder.

Eksempelklausul: Tilbagelevering, sletning og bevismateriale for data

Ved opsigelse eller udløb af aftalen eller efter den dataansvarliges skriftlige instruks skal databehandleren efter den dataansvarliges valg sikkert tilbagelevere alle personoplysninger i et aftalt maskinlæsbart format eller sikkert slette alle personoplysninger fra systemer, medier, backups og miljøer under databehandlerens kontrol, medmindre EU-ret eller medlemsstatsret kræver opbevaring.

Senest tredive kalenderdage efter gennemførelsen af den krævede handling, eller inden for en kortere periode hvis kontraktligt aftalt, skal databehandleren fremlægge et underskrevet sletningscertifikat eller en tilsvarende overensstemmelsesattest. Certifikatet skal identificere tjenesten, datakategorier, omfattede systemer, datointerval for sletning, sletningsmetode, håndtering af backups og arkiver, status for underdatabehandlere, opbevarede undtagelser og autoriseret underskriver.

Den dataansvarlige kan anmode om rimeligt understøttende bevismateriale, herunder logfiler, bortskaffelsesregistreringer, attester fra underdatabehandlere og procesdokumentation, for at verificere certifikatet og lukke leverandørens exitregistrering.

Denne formulering gør ansvarlighed til en operationel leverance.

Praktisk eksempel: Exit fra løn-SaaS

Forestil dig en SMV, der flytter fra PayrollCloud A til PayrollCloud B. PayrollCloud A har behandlet medarbejdernavne, adresser, skatteidentifikatorer, bankoplysninger, lønhistorik, sygefraværsoplysninger og supportsager. Leverandøren anvendte en cloududbyder og en supportplatform som underdatabehandlere.

En Clarysec-tilpasset exit ville fungere sådan.

1. Opret en leverandør-exit-ticket

Indkøb opretter en exit-ticket knyttet til leverandørregistreringen. Ticketen indeholder kontraktens opsigelsesdato, sidste servicedato, forretningsejer, systemejer, DPO eller databeskyttelseskontakt, og om særlige kategorier af personoplysninger kan være involveret. Fordi løn kan omfatte følsomme ansættelses- og sundhedsrelaterede oplysninger, er risikovurderingen høj.

2. Kortlæg exit mod aftalen

Den leverandøransvarlige kontrollerer kontrakten for klausuler om tilbagelevering, sletning, revision, overgang og underdatabehandlere. Hvis kontrakten er svag, sender ejeren stadig en formel instruks, der kræver tilbagelevering, sletning og bekræftelse fra underdatabehandlere. Forventningen til bevismateriale forankres i Clarysec-politikkerne, herunder P26, P26S, P14, Cloud Usage Policy og Cloud Usage Policy - SME.

3. Definér PII-omfanget

Systemejeren udfylder en erklæring om dataomfang, der dækker produktionslønregistre, medarbejderes selvbetjeningsdokumenter, vedhæftninger, eksporter, supportsager, revisionslogfiler med brugeridentifikatorer, API-integrationsfiler, midlertidige migreringsudtræk, backups, snapshots og data hos underdatabehandlere.

Dette understøtter GDPR-ansvarlighed, ISO/IEC 27701:2025 PIMS-dokumentation, ISO/IEC 27001:2022-operationel kontrol og, for finansielle enheder, DORA-forventninger til informationsregister over IKT-tredjepartsforhold.

4. Anmod om tilbagelevering, sletning og bevismateriale fra underdatabehandlere

Den leverandøransvarlige sender en struktureret anmodning til PayrollCloud A om at bekræfte gennemført endelig eksport, sletning af produktionsdata for tenant, håndtering af backups og uforanderlige arkiver, sletning af vedhæftninger i supportsager, tilbagekaldelse af kundespecifikke konti og API-legitimationsoplysninger, bevismateriale for underdatabehandleres sletning eller bortskaffelse samt et underskrevet sletningscertifikat.

5. Registrér færdiggørelse i REG08 eller REG12

Den leverandøransvarlige registrerer hvert bevisobjekt i REG08. Hvis organisationen handler som databehandler, og cloudapplikationen indeholdt kundens PII, kan færdiggørelsen også registreres i REG12 efter Cloud PII Processor Policy.

6. Udfør endelig verifikation før lukning

Compliance sammenholder sletningscertifikatet med erklæringen om dataomfang. IT kontrollerer adgangslogfiler og bevismateriale for kontolukning. DPO kontrollerer, om der findes en opbevaringsundtagelse, f.eks. en retlig forpligtelse eller et bevaringspålæg (legal hold) på grund af en tvist. Sikkerhed verificerer, at API-tokens, servicekonti og SSO-konfigurationer er fjernet.

Først derefter lukkes exit-ticketen.

Hvis leverandøren nægter at fremlægge bevismateriale, bliver forholdet et spørgsmål om risikobehandling. Det kan udløse eskalering, kontraktlige retsmidler, analyse af kundeunderretning, regulatorisk vurdering, øget overvågning under overgangen eller ændringer i leverandørens risikovurdering.

DORA, NIS2 og IKT-robusthed: Exitdokumentation ud over databeskyttelse

DORA behandler leverandørexit som en del af robusthed, ikke kun som administration af databeskyttelse. En finansiel enhed er fortsat ansvarlig for efterlevelse, selv når IKT-tjenester outsources. Den skal vedligeholde et informationsregister over IKT-tjenestekontrakter, skelne mellem tjenester, der understøtter kritiske eller vigtige funktioner, udføre due diligence, vurdere koncentrationsrisiko og vedligeholde exitstrategier.

Et databehandlersletningscertifikat kan påvirke flere DORA-forhold:

• Kontinuitet i kundeservice
• Regulatorisk rapportering
• Dataintegritet
• Hændelseshåndtering
• Revisionsrettigheder
• Operationel robusthed
• Planlægning af genopretning og overgang
• Styring af kritiske eller vigtige funktioner

For et betalingsinstitut, et investeringsselskab, et kreditinstitut, en udbyder af kryptoaktivtjenester eller en fintechplatform skal sletningscertifikatet indgå i en bredere exitpakke. Det er ikke nok at dokumentere, at PII er slettet, hvis organisationen ikke også kan dokumentere, at serviceovergangen undgik driftsafbrydelser, at regulatoriske forpligtelser fortsat blev opfyldt, og at kundepåvirkninger blev håndteret.

NIS2 udvider drøftelsen af leverandørsikkerhed ud over finansielle tjenesteydelser. Ophør af databehandlerforhold er en test af sikkerheden i forsyningskæden. Hvis en væsentlig eller vigtig enhed ikke kan dokumentere, at en leverandør tilbageleverede eller slettede data ved tjenestens ophør, har den en svaghed i leverandørrelationsstyring, aktivkontrol, adgangsstyring, databeskyttelse og potentielt hændelsesberedskab.

Hvis en mislykket exit medfører uautoriseret adgang, tab, videregivelse eller driftsafbrydelse, kan organisationen være nødt til at vurdere rapporteringsforpligtelser vedrørende hændelser efter gældende ret og nationale gennemførelsesregler.

Kortlægning på tværs af compliance-krav: Én arbejdsgang, mange forpligtelser

Værdien af en veldesignet arbejdsgang for ophør af databehandlerforhold er, at den opfylder flere rammeværker på én gang.

NIST CSF 2.0 er især nyttig som kommunikationslag. GOVERN-funktionen kræver, at organisationer forstår juridiske, regulatoriske, kontraktlige og databeskyttelsesrelaterede forpligtelser, definerer risikostrategi, tildeler roller og etablerer tilsyn. Dens resultater for Cybersecurity Supply Chain Risk Management dækker leverandørkrav i kontrakter, overvågning af leverandørrisiko og aktiviteter efter afslutningen af et partnerskab eller en serviceaftale. GV.SC-10 er præcis dér, hvor ophør af databehandlerforhold hører hjemme.

Hvad revisorer vil spørge om

Forskellige revisorer tilgår ophør af databehandlerforhold fra forskellige vinkler, men bevispakken bør være stærk nok til dem alle.

En ISO/IEC 27001:2022-revisor begynder muligvis ikke med at bede om et “PII-sletningscertifikat”. Vedkommende kan starte med omfang, krav fra interessenter, leverandørkontrol, anvendelighedserklæring, risikobehandling og opbevaret dokumenteret information. Hvis sletningscertifikatet ikke kan forbindes til disse elementer, kan det fremstå som et isoleret artefakt frem for dokumentation for en fungerende kontrol.

En PIMS-revisor vil spørge, om organisationen forstod sin databeskyttelsesrolle. Var den dataansvarlig, databehandler, underdatabehandler eller cloud PII-databehandler? Var exit baseret på dokumenterede kundeinstrukser? Blev underdatabehandlerforpligtelser videreført? Blev bevismaterialet opbevaret i det korrekte register? Var undtagelser begrundet?

En DORA-gennemgang vil spørge, om tjenesten er i IKT-informationsregistret, om den understøtter en kritisk eller vigtig funktion, om kontrakten indeholdt tilbagelevering af data og revisionsrettigheder, og om overgangen undgik driftsafbrydelser og skade for kunder.

Den samme bevispakke bør kunne besvare dem alle.

Almindelige fejlmønstre

Clarysec ser gentagne gange de samme svagheder ved gennemgange af ophør af databehandlerforhold:

• Kontrakter kræver sletning, men definerer ikke bevismateriale.
• Leverandører leverer generiske sletteerklæringer uden systemomfang.
• Backups, snapshots og uforanderlige arkiver ignoreres.
• Sletning hos underdatabehandlere antages, men dokumenteres ikke.
• Deaktivering af adgang behandles som sletning af data.
• Indkøb lukker leverandøren, før compliance gennemgår bevismaterialet.
• Opbevaringsundtagelser er udokumenterede.
• Udviklere beholder testeksporter efter afslutning af outsourcet udvikling.
• Cloudkonti lukkes, før slettebekræftelse er indhentet.
• Revisionsbevismateriale opbevares i e-mail, ikke i et kontrolleret register.

Scenariet med outsourcet udvikling er særligt almindeligt. Outsourced development policy - SME kræver i klausul 7.4.1.2:

“Alle data, som udviklere ligger inde med, skal slettes, og bevismateriale kan kræves”

For udviklingsteams omfatter dette lokale datasæt, stagingdatabaser, debuglogfiler, crash dumps, screenshots, supporteksporter, AI-testprompts og midlertidige migreringsfiler. Hvis arbejdsgangen for leverandørexit ignorerer data hos udviklere, er den ufuldstændig.

Tjekliste for ophør af databehandlerforhold

En stærk proces for ophør af databehandlerforhold behøver ikke være kompleks, men den skal være disciplineret.

• Identificér exitudløseren: opsigelse, udløb, kundens instruks, leverandørudskiftning, håndtering af brud, godkendt overgang eller opsigelse af underdatabehandler.
• Bekræft PIMS-rollen: dataansvarlig, databehandler, underdatabehandler, fælles dataansvarlig eller cloud PII-databehandler.
• Knyt leverandørregistreringen: kontrakt, serviceejer, forretningsfunktion, kritikalitet og datakategorier.
• Identificér PII-omfanget: produktion, backups, logfiler, eksporter, supportsager, analyse, testdata og underdatabehandlere.
• Udsted skriftlige instrukser: tilbagelevering, overførsel, sletning, bortskaffelse eller opbevaringsundtagelse.
• Indhent bevismateriale: sletningscertifikat, destruktionscertifikat, logfiler, attest fra underdatabehandler og bevis for lukning af adgang.
• Registrér bevismateriale i REG08 eller REG12: placering af bevismateriale, dato, metode, ansvarlig person og gennemgangsansvarlig.
• Verificér før lukning: sammenhold bevismateriale med dataomfang, kontrakt og kundens instrukser.
• Eskalér undtagelser: manglende bevismateriale, forsinket udløb af backup, omtvistet opbevaring, usamarbejdsvillig leverandør eller resterende adgang.
• Indarbejd forbedringer: opdatér kontraktskabeloner, leverandørens risikovurdering, opbevaringsplan, revisionsplan og ledelsesrapportering.

Sådan arbejder Zenith Blueprint, Zenith Controls og Clarysecs politiksæt sammen. Blueprint viser, hvor kontrollen hører hjemme i implementeringsforløbet. Politikkerne definerer den krævede adfærd. Zenith Controls kortlægger kontrolrelationen på tværs af ISO/IEC 27002:2022, GDPR, DORA, NIS2, NIST og revisionsforventninger.

Budskabet til bestyrelsen

Ophør af databehandlerforhold er ikke et administrativt trin ved afslutningen af en kontrakt. Det er en live test af databeskyttelsesstyring, leverandørstyring, cloudsikkerhed, IKT-robusthed og disciplin for revisionsbevismateriale.

Et sletningscertifikat har kun værdi, når det er knyttet til:

• En kendt leverandørrelation
• Et defineret dataomfang
• En kontraktlig instruks eller kundeinstruks
• En sikker slette- eller bortskaffelsesmetode
• Bevismateriale for videreførelse til underdatabehandlere
• Lukning af adgang
• Håndtering af backups og arkiver
• Et kontrolleret register over bevismateriale
• Endelig compliance-verifikation

Uden den kæde baserer organisationen sig på tillid netop på det tidspunkt, hvor den bør basere sig på bevismateriale.

Næste skridt med Clarysec

Hvis din organisation bruger SaaS, cloud, løn, HR, finans, support, udvikling eller administrerede IKT-udbydere, bør I gennemgå jeres arbejdsgang for ophør af databehandlerforhold, før den næste opsigelsesmeddelelse sendes.

Clarysec kan hjælpe jer med at implementere en praktisk, revisionsklar model for ophør af databehandlerforhold ved hjælp af:

• Zenith Blueprint: An Auditor’s 30-Step Roadmap til at placere leverandørexit, sletning og bortskaffelse i de rigtige implementeringstrin.
• Zenith Controls: The Cross-Compliance Guide til at kortlægge leverandøraftaler, informationssletning og sikker bortskaffelse på tværs af ISO/IEC 27002:2022, GDPR, DORA, NIS2, NIST og revisionsforventninger.
• Processor, Subprocessor and Third-Party Privacy Management Policy og PII Retention, Deletion and Disposal Policy til at operationalisere REG08-bevismateriale.
• Third party and supplier security policy, Data Retention and Disposal Policy og Cloud PII Processor Policy til at gøre exitdokumentation håndhævelig.

Jeres næste handling er enkel: Vælg én nyligt opsagt leverandør, og opbyg en retrospektiv exitbevispakke. Hvis I ikke kan dokumentere tilbagelevering, sletning, bekræftelse fra underdatabehandlere og endelig verifikation, er det jeres første afhjælpningspunkt.

Clarysec kan hjælpe jer med at omsætte den mangel til en gentagelig kontrol for ophør af databehandlerforhold, før en revisor, tilsynsmyndighed eller kunde efterspørger den.