En fil kan befinde sig flere steder
En redaktion sletter et uploadet kontraktudkast fra sit arbejdsområde. Dermed forsvinder det fra den daglige visning, men måske ikke i samme øjeblik fra alle tekniske kopier. En søgefunktion kan stadig have en post i sin cache, en sikkerhedskopiering kan indeholde den tidligere version, og en sikkerhedslog kan dokumentere sletningen.
Disse kopier tjener forskellige formål. Arbejdsområdet stiller indhold til rådighed, en cache gør adgangen hurtigere, en sikkerhedskopi gør det muligt at gendanne efter et nedbrud, og logfiler hjælper med at undersøge hændelser. En enkelt oplysning som "Vi gemmer data i 30 dage" forklarer derfor ikke nok. Den lader det stå åbent, hvilke data og hvilket sted der menes.
Ved en købsbeslutning er denne opdeling vigtigere end et så kort reklamebudskab som muligt. En leverandør bør kunne beskrive, hvornår data forlader den aktive brug, hvornår midlertidige lagre opdateres, og hvordan gamle sikkerhedskopier udfases. Afledte filer og anvendte tjenesteudbydere hører også med i dette billede. Først da opstår der en realistisk forståelse af, hvor længe information kan være tilgængelig, kunne gendannes eller stadig eksistere teknisk.
Opbevaring begynder med et konkret formål
Det giver ikke mening at opbevare data, blot fordi lagerplads er billig. En organisation har brug for en velbegrundet årsag. En udgivet artikel forbliver tilgængelig, så længe den er en del af tilbuddet. Faktureringsdata kan være nødvendige i længere tid på grund af lovkrav. En ubearbejdet testimport har derimod normalt ingen varig værdi og bør ikke ligge i produktkontoen i årevis.
Formålet bestemmer også, hvilke dele der er nødvendige. Til fakturering kan et beløb med tilknytning til kontrakten være nødvendigt, mens hele indholdet af et oversat dokument ikke er det. Differentierede opbevaringsperioder forhindrer, at alle oplysninger gemmes lige længe. Samtidig gør det indsigt, eksport og senere sletning lettere, fordi datamængderne er tydeligere afgrænset.
En frist skal have et forståeligt starttidspunkt. "90 dage" kan regnes fra upload, seneste redigering, kontraktens ophør eller anmodningen om sletning. Disse forskelle er væsentlige for købere. Den udløsende hændelse skal betyde det samme i produktet og i kontrakten. En fil, der gemmes under en femårig kontrakt og i yderligere 90 dage, har en anden levetid end et udkast, der automatisk forsvinder 90 dage efter seneste brug.
En cache er en midlertidig arbejdskopi
En cache holder ofte anvendte data tættere på brugerne. Det får et websted til at indlæse hurtigere og betyder, at en tjeneste ikke behøver at generere det samme indhold på ny ved hvert besøg. Kopien er ikke tænkt som et permanent arkiv. Den bør udløbe efter en begrænset periode eller opdateres målrettet, når det gældende indhold ændres.
Efter en rettelse kan en gammel tekst alligevel kortvarigt være synlig, hvis cachen endnu ikke er opdateret. Ved et udskiftet titelbillede er det som regel irriterende. Ved et ændret alarmnummer eller en slettet personoplysning kan det være alvorligt. Leverandører bør derfor forklare, hvor hurtigt akutte ændringer når ud til alle leveringspunkter, og om cachen kan tømmes med det samme.
Der kan opstå caches i browseren, leveringsnetværket og selve applikationen. Sletning i hovedsystemet når ikke automatisk alle disse lag på samme tidspunkt. Et robust produktkoncept kender de involverede lagringssteder og forbinder dem med sletteprocessen. Der bør også tages højde for adfærden på browsersider, som allerede er åbne. Købere behøver ikke selv tegne et teknisk kort, men bør få en klar oplysning om den maksimale forsinkelse.
Sikkerhedskopier beskytter mod tab, ikke mod beslutninger
En sikkerhedskopi bevarer en tidligere tilstand, hvis et system bliver beskadiget, data slettes ved en fejl, eller et angreb ændrer det aktive miljø. Kopien er netop nyttig, fordi den ikke overtager enhver ændring med det samme. Hvis en utilsigtet sletning straks fjernede alle sikkerhedskopier, ville gendannelse næsten være umulig.
Det betyder dog ikke, at sikkerhedskopier skal bevares ubegrænset. En leverandør kan oprette nye sikkerhedskopier hver dag og overskrive ældre kopier efter en fast periode. Fristen afhænger af behovet for gendannelse, risikoen og juridiske krav. Den bør være dokumenteret og må ikke ubemærket blive længere og længere, fordi gamle lagringsmedier aldrig bliver kontrolleret.
Sikkerhedskopier er heller ikke et ekstra produktarkiv. Medarbejdere bør normalt ikke søge efter gamle kundedata i dem eller kopiere enkelte filer ud til nye formål. Adgangen skal være begrænset til gendannelse og snævert afgrænsede tekniske kontroller. Kun få autoriserede personer bør have adgang, og brugen bør logges på en måde, der kan efterprøves. Når en sikkerhedskopi gendannes, skal tidligere slettede datasæt efterfølgende fjernes igen eller på anden måde udelukkes fra aktiv brug.
Sletning har flere synlige trin
Når en bruger sletter et dokument, bør det først forsvinde fra brugerfladen og almindelige søgeresultater. Det må heller ikke fortsat være tilgængeligt via en gammel adresse. Baggrundsopgaver, miniaturebilleder og afledte tekstversioner skal følge samme status. Ellers forbliver indholdet reelt tilgængeligt, selv om brugerfladen allerede har bekræftet, at sletningen lykkedes.
Nogle produkter tilbyder først en papirkurv. Denne korte mulighed for gendannelse kan forhindre utilsigtede tab, men skal beskrives tydeligt. Personen bør vide, hvor længe et objekt bliver liggende der, og hvem der kan gendanne det. Der må ikke stå "slettet", hvis objektet i virkeligheden blot er flyttet til et skjult område uden tidsbegrænsning.
Efter den endelige sletning forsvinder datasættet fra de aktive systemer. I roterende sikkerhedskopier kan en tidligere kopi blive liggende, indtil sikkerhedskopieringsperioden udløber, uden at blive brugt i den almindelige drift. Den berørte person skal have en forståelig og korrekt oplysning om dette. Denne undtagelse kræver en konkret varighed, adgangsbegrænsninger og en proces, der forhindrer, at data vender permanent tilbage ved en gendannelse.
En supportsag viser hele datarejsen
En kunde sender supporten et skærmbillede med navn og kontonummer. Billedet ligger først i supportsystemet og måske også i en indbakke. Hvis det videresendes til en teknisk specialist, kan der opstå endnu en kopi. Skærmbilledet er nyttigt til at løse problemet, men efter sagens afslutning er det fulde indhold muligvis ikke længere nødvendigt.
En klar regel skelner mellem supportsagen og dens bilag. Den korte sagsgang kan bevares i en begrænset periode til senere spørgsmål, mens det følsomme skærmbillede fjernes tidligere. Statistiske oplysninger om fejltypen kan være nyttige længere uden navne. På den måde følger fristen det resterende formål i stedet for generelt at følge det største datasæt.
Hvis kunden senere lukker sin konto, skal produktdata, åbne eksporter og supportsystemet betragtes samlet. Leverandøren bør kunne forklare, hvilke oplysninger der forsvinder med det samme, hvilke der opbevares spærret på grund af en forpligtelse, og hvornår sikkerhedskopierne udløber. Åbne supportsager må ikke ubemærket blive liggende i en sidekanal. Et gennemskueligt svar følger datarejsen i stedet for blot overfladen i et enkelt produkt.
Købere har brug for konkrete frem for absolutte udsagn
Løftet "Data slettes straks" lyder betryggende, men er tvetydigt uden en forklaring. Gælder det det aktive datasæt, alle caches, søgeindekser, logfiler og sikkerhedskopier? Et troværdigt svar nævner lagene og deres respektive tidsperioder. Det forklarer også, om sletningen sker automatisk eller skal sættes i gang af et supportteam.
Det er også vigtigt, hvad der sker ved kontraktens ophør. Nogle tjenester giver kunderne en kort periode til eksport og spærrer derefter adgangen. Andre fjerner aktivt indhold med det samme. Købere bør vide, hvornår perioden begynder, hvordan de bestiller en tidligere sletning, og om tilknyttede underdatabehandlere gennemfører den samme proces inden for fastlagte frister.
En leverandør behøver ikke at love, at hver eneste tekniske kopi fjernes på sekundet. Leverandøren bør dog kende det faktiske forløb og kunne beskrive det forståeligt. Uklare formuleringer som "branchens normale varighed" eller "i det nødvendige omfang" er ikke tilstrækkelige til en vurdering. Et eksempel på en besvarelse om et typisk datasæt kan gøre oplysningerne konkrete. Klare grænser, dokumenterede undtagelser og ansvarlige funktioner viser, at løftet er forankret i driften.
Eksporter og logfiler kræver deres egne grænser
En dataeksport opretter en ny fil uden for det almindelige arbejdsområde. Den kan ligge klar i et downloadområde eller blive sendt via et link. Sådanne filer indeholder ofte særligt mange oplysninger og bør udløbe automatisk efter kort tid. Ved sletning af den oprindelige konto må en eksport, der stadig kan tilgås, ikke blive overset.
Logfiler hjælper med at opdage fejl og uautoriseret adgang. Til det formål kan bruger-id, tidspunkt og den udførte handling være nødvendige. Hele dokumentets indhold hører normalt ikke hjemme i hver loglinje. Hvis følsomme tekster kopieres ind i fejlmeddelelser, opstår der kopier, som er svære at finde, og som muligvis har en langt længere opbevaringsperiode end dataene i selve produktet.
Anonymiserede data kræver også en præcis beskrivelse. Hvis en person kan genkendes igen ved hjælp af yderligere oplysninger, er dataene ikke reelt anonyme. Permanent statistik bør kun indeholde de kendetegn, der er nødvendige til formålet, og som ikke muliggør en ny tilknytning. Sjældne kombinationer af kendetegn kan gøre det særligt let at identificere en person. Pseudonyme identifikatorer reducerer synligheden, men erstatter ikke regler for opbevaring og sletning.
En gendannelse må ikke bringe slettede data tilbage
Efter et alvorligt nedbrud gendanner en leverandør en sikkerhedskopi fra dagen før. Den indeholder data, som kunderne har slettet siden da. Uden yderligere forholdsregler ville indholdet dukke op igen i det aktive system. Derfor kræver gendannelsen en afstemning med senere sletninger og spærringer, før produktet igen kan bruges fuldt ud.
Denne afstemning kan ske via et særskilt beskyttet register over slettehændelser. Det indeholder kun de nødvendige identifikatorer og tidspunkter, ikke selve det slettede indhold. Efter gendannelsen gennemfører systemet beslutningerne igen. Opbevaringsfrister, der er udløbet i mellemtiden, medregnes også, så den gamle tilstand ikke bliver den nye permanente løsning.
Gendannelser bør afprøves regelmæssigt. En sikkerhedskopi, som ingen kan gendanne med succes, giver kun en illusion af sikkerhed. Testen skal samtidig vise, at adgangsrettigheder, sletninger og aktuelle indstillinger bevares. Resultaterne fører til rettelser, inden der opstår en reel nødsituation. For købere er denne sammenhæng afgørende: Beskyttelse mod datatab og beskyttelse mod uønsket genkomst hører til den samme pålidelige drift.
En god regel kan efterprøves i hverdagen
Opbevaringsfrister hører ikke kun hjemme i en kontrakt. Produktet skal håndhæve dem teknisk, og ansvarlige teams skal opdage afvigelser. En regelmæssig kontrol kan vise, om gamle eksporter faktisk forsvinder, udløbne papirkurve bliver tømt, og sikkerhedskopier overskrives efter den planlagte periode. Resultatet bør være forståeligt for de ansvarlige personer.
Hvis et formål, en juridisk forpligtelse eller en teknisk tjeneste ændrer sig, skal reglen vurderes igen. En ny søgeleverandør kan skabe yderligere kopier, og et mindre supportbehov kan gøre en hidtidig frist overflødig. Ændringer besluttes ikke kun på papir, men følges hele vejen til caches, underdatabehandlere og gendannelsesprocesser.
Tillid opstår gennem præcise og afgrænsede udsagn. Aktive data forbliver kun tilgængelige, så længe formålet kræver det. Caches udløber hurtigt, sikkerhedskopier roterer under beskyttede forhold, og sletninger føres videre gennem tilknyttede systemer. Den, der forklarer disse forskelle åbent, gør en velbegrundet købsbeslutning mulig og forhindrer forkerte forventninger til en kompleks teknisk proces.