The toughest challenge: email

Let’s begin with the part where the GDPR normally causes most trouble for lawyers: email. Most lawyers write emails in Outlook, and when we start typing ‘he’ in the recipient field, Outlook immediately suggests ‘Henrik’. The question is whether the Henrik Outlook has in mind is the right one.

Having auto-completion of email recipients turned on is one of the greatest risks when it comes to GDPR compliance. No doubt most lawyers think it’s only other people who make mistakes, but anyone can fall into the trap when things are busy, and we have seen a great many emails sent to the wrong recipients for this reason.

Individual assessments

The case management system contains a great deal of data that is regulated by the GDPR. The system can of course help with GDPR compliance, but there are still many decisions that have to be assessed by the lawyers.

When is a case obsolete? And who then is to assess whether an obsolete case should be erased or just anonymized?

The same applies to clients and parties. Should an obsolete client or party be anonymized or deleted altogether? It depends on the situation.

Where is personally sensitive data stored?

Personally sensitive data obviously exists on cases, clients and parties, and it can be in many different places. There may be personally sensitive data such as a social security number on the case card, or the case might be recorded as concerning a particular disease or something else of a personally sensitive nature.

But where else is personally sensitive data stored?

What about former employees? This is an area that calls especially for anonymization, because there may be very old time registrations that will be required as documentation at a later time.

The time registrations themselves, and the posted entries, may say something like ‘collection of doctor’s note re mental illness diagnosis’. That is personally sensitive, too.

Then there is all the data stored outside the case and ERP system, such as all the documents stored in a document solution (e.g. SharePoint) or on a file share. The documents will naturally contain a lot of personal data.

Nor is it certain that only searchable documents are involved. There may be audio files or video recordings of case hearings, for example. These are harder to search by name or personal details. And what about email attachments: how can those be caught?

Deletion has consequences

When you start anonymizing and deleting data in practice, a number of challenges crop up.

We ourselves have built GDPR features into our case management system, Navokat. The aim is of course to provide lawyers with as much support as possible in anonymizing and erasing data, but all decisions require individual assessments, so that it is unfortunately far from the whole process that can take place in an automated way.

We have built logic into the system allowing it to suggest cases that should be deleted. It does this according to certain criteria that you set up yourself. The lawyer can then look through the suggestions and choose what to delete. For example, you can ask the solution to propose cases that were archived more than X years ago.

Unfortunately, we have already known a customer to put too much faith in the system’s suggestions and end up erasing cases that should not in fact have been erased. And now the data is gone. It is completely gone, because, if there were an ‘undo’ feature, we would not be complying with the GDPR.

When you choose to delete a case, it is not just the case card and the journal that go. It may also be clients, parties and all the documents associated with the case. This includes time registrations, posted entries – everything in the belly of the ERP system.

Deleting a case is a weighty decision. It is required under the GDPR, but you must be sure that you understand the consequences when making your decision.

Vi har selv bygget GDPR-features i vores sagsbehandlingssystem, Navokat. Formålet er naturligvis at støtte advokaterne mest muligt i at anonymisere og slette, men alle beslutninger kræver individuelle vurderinger, så det er desværre langt fra hele processen, der kan foregå per automatik.

Vi har indbygget en logik i systemet, så der kan dannes forslag til sager, der bør slettes. Det sker med udgangspunkt i nogle kriterier man selv opsætter. Så kan advokaten kigge forslagene igennem og vælge at slette. Du kan fx bede løsningen om at foreslå sager, som er ældre end x år efter arkiveringsdato.

Vi har desværre allerede oplevet, at en kunde stolede for meget på systemets forslag og kom til at slette sager, der faktisk ikke skulle slettes. Og så er data væk. De er helt væk, for hvis der var en ”fortryd”-funktion, så ville vi jo ikke opfylde GDPR.

Når du vælger, at en sag skal slettes, så er det ikke bare sagskortet og journalen. Det er måske også klienter, parter og alle de dokumenter, der hører til sagen. Det er tidsregistreringer, bogføringer – alt det inde i maven på ERP-systemet.

Det er en omfattende beslutning at slette en sag. Den er krævet i henhold til GDPR, men man skal være sikker på, at man forstår konsekvenserne, når man træffer sin beslutning.

Nogle sager skal anonymiseres – ikke slettes

Det vigtigste parameter er grundlæggende tid. Når sager er så gamle, at vi ikke længere har et formål med at gemme dem, så skal de slettes. Nogle advokater fortolker det som 10 år, andre siger 5 år. Der er faktisk forskellige holdninger, men tid er altid det vigtigste kriterium.

Men det er jo ikke alt, der skal slettes. Hvis man har en god grund til at beholde data, så må man gerne det. En god grund kan fx være, at sagen har principielt karakter, eller har pressens eller myndigheders opmærksomhed.

Principielle sager skal naturligvis ikke slettes – men på et tidspunkt skal de måske anonymiseres.

Det bliver igen en vurderingssag, om det har principiel betydning, at et specifikt navn fremgår af sagen, eller om navnet kan anonymiseres. Det er igen en vurdering, som din IT-løsning desværre ikke kan hjælpe med.

Udfordringen med anonymisering bliver desværre værre endnu.

Hvis vi skal anonymisere Peter Petersen, som er vidne i en sag, så kan vi godt søge efter hans navn. Nogle steder står der kun P. Petersen eller Hr. Petersen. Og på side 37 i et dokument står der ”ejeren af cykelbutikken”, hvilket alle naturligvis ved er Peter Petersen, fordi det er en lille by, og der er kun én cykelbutik. Den omtale skal også anonymiseres.

Det er svært at få et IT-system til at genkende, at ”ejeren af cykelbutikken” henviser til Peter Petersen, så det er igen en opgave, hvor det er svært at få hjælp fra teknologien. Teknologien skal ikke alene genkende ”ejeren af cykelbutikken” som en henvisning til en person – den skal også vurdere om det er formålsvigtigt for den konkrete omtale at vide, at det handler om cykelhandleren. Det kræver enten noget seriøst kunstig intelligens – eller mange timers manuelt læsearbejde.

Hvor modent er dit IT-system?

Der er 4 trin for hvordan dine IT-systemer kan hjælpe dig med at slette og anonymisere:

1. Det første trin er, at systemet kommer med forslag til sager, som du skal evaluere.
2. Det andet trin er, at systemet kan gennemføre sletningen af de sager, inkl. poster og dokumenter, som du vælger at slette.
3. Det tredje trin er, at systemet kan udføre anonymisering af sager ud fra søgekriterier, som du vælger. Det er en slags søg-og-erstat i sagsstyrings-systemet.
4. Det endegyldige trin er, at systemet via kunstig intelligens kan finde alle de udtryk, som er personfølsomme, som i eksemplet med ”ejeren af cykelbutikken”.

Langt de fleste systemer er på trin 1 og 2. Vi kan slet ikke nævne nogen, der er på trin 4 eller har udsigt til det. Men selv om systemerne kunne dække pkt. 1-4, ville der stadig ligge en del af ansvaret for GDPR-compliance hos advokaterne, der skal vurdere, hvad der skal gøres i de konkrete sager.

Indsigtsbegæring

Nu har vi talt nok om at slette og anonymisere. Et andet emne, som kan give advokatkontorerne en stor arbejdsbyrde, er indsigtsbegæringer.

Alle kan henvende sig og bede om at få at vide, hvad vi ved om dem. Og så tager vi en medarbejder ud af produktionen, som sidder og bladrer igennem dokumenter for at finde de steder, hvor pågældende person er omtalt. Det virker helt uoverskueligt for et almindeligt advokatkontor, hvis der kommer mange af den slags indsigtsbegæringer. Det har vi også brug for systemmæssig hjælp til.

Udfordringen er principielt den samme som med anonymisering. Vi skal kunne finde data i alle afkroge af sager og dokumenter. Den IT-mæssige udfordring er den samme, og teknologisk er den svær at løse.

Hvem må egentlig gøre hvad?

Der er mange del-opgaver inden for dette område, og spørgsmålet er, hvem der egentlig må gøre hvad i din organisation? Når du får en slette-knap til rådighed, så nytter det ikke, at alle kan komme til at trykke på den, og så er data bare pist borte.

1. Den første opgave er identifikation. Det handler om at producere en bruttoliste over de sager og data, som måske skal slettes. Det er en opgave, som IT-systemerne i høj grad skal udføre, og det er okay, at de fleste i organisationen har adgang til bruttolisten.
2. Den næste opgave er vurdering af bruttolisten. Her må advokaterne med indsigt i den enkelte sag vurdere, hvilke sager der skal slettes og anonymiseres. Der skal måske være interne processer for, hvor lang tid over deadline, man må trække en sletning, uden at involvere en partner i beslutningen.
3. Og så kommer vi til selve sletningen. Her er spørgsmålet: Hvem har lov til at trykke på slet-knappen? Hvem skal have mandat til at slette en sag? Her mener vi, det bør overvejes nøje, om det fx skal være en partner, der kan godkende den endegyldige sletning.

Hvem må se hvad?

Databeskyttelsen handler også om at sikre data mod at blive delt med uvedkommende. Hvordan sikrer vi, at der ikke er nogen i virksomheden, der kommer til at se noget, de ikke må se?

Der skal naturligvis være styr på IT-sikkerheden, så hackere ikke kan snuppe data og sælge eller fjerne det fra systemet og kræve betaling for at lægge det ind igen, som man har set eksempler på. Vi kan desværre se, at der er rigtig mange forgæves loginforsøg på fjernskrivebord med Navokat-løsningen, hvor programmer står og prøver sig frem for at skaffe sig adgang. Det er en trussel, alle skal tage alvorligt.

Men på de interne fronter skal vi også helt enkelt sørge for, at kun de rette medarbejdere har adgang til data. Skal alle brugere på kontoret have adgang til al data i alle sager, eller kan der laves begrænsninger, der imødekommer krav til GDPR, uden at det spænder ben for den daglige drift?

På samme måde kan man overveje, om den eksterne IT-leverandør til enhver tid skal have ubegrænset adgang til data. De skal naturligvis kunne yde support og afhjælpe IT-problemer, og i den forbindelse kan det give mening fx at give tidsbegrænset adgang til data, men IT-leverandøren skal ikke nødvendigvis have fri adgang hele tiden.

Hvem har haft adgang til hvad?

Det er naturligvis også vigtigt at kunne dokumentere, hvordan den enkelte person har anvendt sine rettigheder. Hvem har kigget på hvilke data hvornår?

Det er vigtigt at have denne adgangslog for at kunne dokumentere, at databeskyttelsen er overholdt, og for at kunne svare fyldestgørende på en indsigtsbegæring.

Hvor langt er du kommet i GDPR-processen?

Det er en stor mundfuld, hvis man som advokatkontor skal leve op til hvert et hjørne af GDPR. Det er også et omdiskuteret spørgsmål, hvor meget man med rimelighed kan forventes at leve op til, hvis man er et mindre kontor med få ressourcer, og teknologien faktisk ikke kan hjælpe på alle områder endnu.

Men det første skridt er at gøre status, så du ved hvor langt du er, og så lægge en plan for, hvor store ambitioner du ønsker at have inden for GDPR.

Hvis du har behov for at sparre med nogen om GDPR inden for sagsbehandlingssystemer, så står vi meget gerne til rådighed for en samtale, uden at det skal koste dig en krone. Vi er altid friske på en debat om et af de emner, der fylder rigtig meget for advokater for tiden.