By · Last updated 2026-06-05

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.

June 5, 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 285+ enhetstyper på 48 språk.

About this page

We update this page when our platform or the law changes.

Read our founder note for how we work.

Each change shows up in the timestamp at the top.

Related reading

We follow these rules

  • GDPR (EU 2016/679).
  • ISO/IEC 27001:2022.
  • NIS2 (EU 2022/2555).
  • HIPAA safe harbor under 45 CFR § 164.514(b)(2).

Our promise

We do not sell your data.

We do not train models on your text.

We store your files in Germany.

You can delete your account at any time.

You own your work.

Where we run

Our servers live in Falkenstein, Germany.

We use Hetzner. They hold ISO 27001 certification.

All data stays in the EU.

Backups run every day.

Need help?

Email support@anonym.legal.

We reply within one business day.

How we test

We run a full check suite on every release.

Each surface gets its own sweep script and report.

Human reviewers spot-check the output each week.

We track recall and precision on a labelled set.

Bad runs block the deploy.

What we never do

  • We never sell your information to third parties.
  • We never train models on what you upload.
  • We never keep your work after you delete it.
  • We never share keys with any outside firm.
  • We never run ads inside the product.

Plans in plain words

We sell credits, not seats.

One credit covers one short job.

Long jobs use a few credits each.

You can top up at any time.

Unused credits roll over each month.

Read the plans page for current rates.

Who built this

A small team of engineers and lawyers built this.

We ship from Europe and work in the open.

Our founder note spells out why we started.

Where to start

How the parts fit

A browser add-on cleans text inside Chrome.

A Word plug-in handles drafts in Office.

A small desktop tool works on whole folders.

An agent protocol link feeds large models safely.

All four share one core engine and one rule set.

Words from our team

We started this work after a lunch about cookies.

One friend kept getting odd ads on her phone.

We asked why a court file leaked through a draft.

We sketched the first build on a napkin that week.

By month three we had a tiny demo for a friend.

She used it on her first case the next day.

Common questions we hear

Can the tool read scanned PDFs? Yes, with OCR.

Does it work on long files? Yes, in small chunks.

Can I roll my own rule set? Yes, save it as a preset.

Does it run offline? The desktop build runs offline.

Do you keep my files? No, the cloud build wipes after each run.

Will it learn from my work? No, we never train on inputs.

A short tour of the workflow

Upload a file or paste a snippet of prose.

Pick the entities you want gone from the draft.

Choose a method: replace, mask, hash, encrypt, or redact.

Press run and watch the side panel show each hit.

Skim the result and tweak any rule that misfired.

Save the cleaned file or send it to a teammate.