Tilbake til BloggGDPR & Overholdelse

Excel og PII: Anonymiser hundrevis av kolonner

Excel er blant de mest PII-tette dokumenttypene i forretningsdrift. Her er hvorfor standard tekstanalyse feiler pa regneark, og hva kolonnebasert kontekst kan gjore.

March 6, 20268 min lesing
Excel GDPRspreadsheet anonymizationXLSX complianceHR datadata minimization

Hvorfor Excel er din filtype med hoyest risiko

Excel-filer er en av de storste GDPR-risikoene i de fleste virksomheter. Medisinske journaler kan inneholde mer sensitiv data per rad. Men regneark samler opp PII raskt — og etterlevselsteam misser dem ofte.

Tre ting gjor Excel-filer vanskelige a handtere.

Volum: En XLSX-fil kan inneholde 50 000 rader og 100 kolonner. Det er fem millioner celler. Ingen manuell gjennomgang kan sjekke alle.

Rutenettoppsett: Tekst flyter i en retning. Excel sprer data over rader og kolonner. Personlige data kan gjemme seg hvor som helst i det rutenettet.

Blandet innhold: Lonnsband, avdelingskoder og stillingsniver sitter i samme fil som personnummer og e-postadresser. A slette alt gjor filen ubrukelig.

Lang oppbevaring: Personallister og kundeposter blir liggende i Excel i arevis. GDPR artikkel 5(1)(e) sier at data skal holdes "ikke lenger enn nodvendig." Filer som "kan vare nyttige" holder seg ofte langt forbi dette punktet.

Hvorfor standard tekstskanning feiler pa regneark

Tekstanalyseverktoy ble bygd for dokumenter. De bryter pa regneark pa noen vanlige mater.

Personnummer-som-tall-problemet

Excel lagrer personnummer uten bindestrek (123456789) som vanlige tall — ikke tekst. En skanner bygd for a finne ###-##-#### vil misse dem. Et godt verktoy ma vite at et 9-sifret tall i en kolonne kalt "SSN" er et personnummer.

Dato-som-tall-problemet

Excel lagrer datoer som serienummer. 6. februar 2024 lagres som 45329. En CSV-eksport vil vise "45329" i en "Fodselsdato"-kolonne. En skanner ma konvertere det tallet til en ekte dato for den kan flagge verdien.

Delvis-personnummer-problemet

Noen systemer viser bare de siste fire sifrene i et personnummer (*--1234). Det fulle nummeret sitter i en lasts kolonne. Den delvise verdien ma fortsatt anonymiseres — selv om den ikke ser ut som et fullt personnummer.

Formel-PII-problemet

Noen celler bygger PII fra andre celler. En celle med =CONCATENATE(B2," ",C2) viser et fullt navn. Hvis du sletter kolonnene B og C, er det fulle navnet fortsatt synlig i formelcellen. Et verktoy som bare leser lagrede verdier — ikke formelkoblinger — vil la PII sta igjen.

Flerark-problemet

En stor arbeidsbok kan ha fem ark: Kundeliste, Bestillinger, Supportbilletter, Fakturering og Analyse. Kundenavn vises i alle fem. "Ola Nordmann" i ett ark ma bli det samme tokenet — "PERSON_0047" — i hvert annet ark. To forskjellige tokens bryter postforbindelser.

Kolonneoverskrifter som signal

Den beste forbedringen i regneark-PII-deteksjon er analyse av kolonneoverskrifter.

En kolonne kalt "SSN" forteller verktoy at alle verdier i den kolonnen er personnummer. Dette fungerer selv om verdiene er delvise, merkelig formatert eller lagret som tall.

KolonneoverskriftHva det signaliserer
SSN / Personnummer / Skatte-IDBehandle 9-sifrede tall som personnummer
E-post / E-mail / E-postadresseFlagg selv delvise e-postmonster
Telefon / Mobilnummer / MobilAksepter ethvert telefonformat
DOB / Fodselsdato / BursdagKonverter serienummer til datoer
Fornavn / Etternavn / Fullt navnSenk terskelen for navnedeteksjon
Adresse / Gate / By / PostnummerKombiner nabe liggende stedsfelt
Pasient-ID / MRN / JournalnummerBruk helsejournals-ID-monster

Kolonnekontekst erstatter ikke innholdsskanning. Den tillegger den. En kolonne kalt "SSN" med 100 verdier: innholdsskanning fanger 99 velformaterte. Kolonnekontekst fanger den ene som ser merkelig ut.

Bevar strukturen, fjern navnene

Malet i de fleste Excel GDPR-saker er ikke a odelegge filen. Det er a strippe ut persondata mens man beholder de delene som gjor filen nyttig.

For en 15 000-raders personaldatafil trenger en compliance-offiser:

Fjerne:

  • Ansattnavn → PERSON_XXXX-tokens
  • Personnummer → REDACTED
  • E-postadresser → REDACTED
  • Telefonnummer → REDACTED
  • Hjemmeadresser → REDACTED

Beholde:

  • Avdelingskoder
  • Stillingstitler (kun generelle roller)
  • Lonnsband (brede kategorier)
  • Prestasjonsscore (gruppedata)
  • Startdatoer (for tjenestestatistikk)
  • Lederkoder (hvis pseudonymisert)

Et verktoy som vet forskjellen mellom "data som navngir folk" og "data som beskriver jobber" gir deg en fil som fortsatt fungerer for HR-analyse — og som oppfyller GDPR-dataminimeringskravene.

Reelt tilfelle: M&A HR-dataoverforing

Et overtakende selskap far personaldata fra det overtatte firmaet: en 15 000-raders XLSX med 40 kolonner. Filen ma ga til et eksternt HR-firma for fordelsplanlegging. GDPR sier at bare de dataene som er nodvendige for den oppgaven kan deles.

For behandling: 40 kolonner med fulle navn, personnummer, e-poster, hjemmeadresser, nodkontakter og bankdetaljer.

Etter kolonnekontekstbehandling:

  • 12 kolonner identifiserer direkte folk (navn, personnummer, e-poster, telefon, adresser, bankdata): erstattet med konsistente tokens
  • 3 kolonner identifiserer folk indirekte (stabs-ID, lederkode, jobbkode): erstattet med pseudonyme tokens som matcher innenfor filen
  • 25 kolonner er aggregerte data (lonnsband, avdeling, tjenestetid, grad): uendret

Tid: 8 minutter for 600 000 celler

Utdata: Samme XLSX-oppsett, 40 kolonner, 15 anonymisert, 25 uendret

Revisjonslogg: Celleniva-oversikt over hver handling med enhetstype, konfidensscore og kolonnesignal brukt

HR-firmaet far et fullstendig datasett for sitt arbeid — uten navn eller ID-er. Etterlevselsjournalen far bevis pa at bare de riktige dataene ble delt.

Denne utfordringen er ikke unik for Excel. Hvert filformat feiler pa sin egen mate. Se hvordan formatfragmentering pavirker PII-deteksjon for en gjennomgang pa tvers av filtyper.

Tre GDPR artikkel 5-regler, en prosess

Strukturert regnearkanoynmisering oppfyller tre regler pa en gang.

Dataminimering (art. 5(1)(c)): Bare kolonnene som er nodvendige for oppgaven gar til mottakeren. Identifiserende kolonner slettes.

Lagringsgrense (art. 5(1)(e)): Originalfilen beholdes for juridisk oppbevaring. En ren kopi lages for deling — med kortere eller ingen oppbevaringsbehov.

Integritet og konfidensialitet (art. 5(1)(f)): Ingen identifiserende data forlater kontrollsonen. Bare rene kopier deles.

Revisjonssporet fra prosessen er ogsa ditt artikkel 5(2)-bevis. Det viser hvordan hver regel ble oppfylt for hver fil.

Hvis teamet ditt handterer DSAR-er eller store dataeksporter, gjelder den samme logikken pa API-niva. Se hvordan GDPR-dataminimering fungerer i sanntids-API-er.

For team som behandler hoy volum under stramme frister, se GDPR DSAR batch-behandling i storskala for arbeidsflytmonstre som ogsa gjelder her.

Kilder

Klar til å beskytte dataene dine?

Begynn å anonymisere PII med 273 enhetstyper på 48 språk.