anonym.legal

By · Last updated 2026-06-05

Terug na BlogGDPR & Nakoming

Excel PII: Anonimiseer Honderde Kolomme

Excel is een van die mees PII-digte dokumenttipes in besigheidsoperasies. Hier is waarom standaardteksanalise op sigblaaie misluk en hoe kolomkonteks-bewustheid help.

June 5, 20268 min lees
Excel GDPRspreadsheet anonymizationXLSX complianceHR datadata minimization

Waarom Excel U Hoogste-Risiko Leertipe Is

Excel-leers is een van die grootste GDPR-risiko's in die meeste besighede. Mediese rekords mag meer sensitiewe data per ry bevat. Maar sigblaaie stapel PII vinnig op -- en nakomingspanne mis dit dikwels.

Drie dinge maak Excel-leers moeilik om te bestuur.

Volume: Een XLSX-leer kan 50 000 rye en 100 kolomme bevat. Dit is vyf miljoen selle. Geen handmatige oorsig kan almal kontroleer nie.

Roosteruitleg: Teks vloei in een rigting. Excel versprei data oor rye en kolomme. Persoonlike data kan oral in hierdie rooster wegkruip.

Gemengde inhoud: Loonbande, departementskodes en posvlakke sit in dieselfde leer as SSN's en e-posadresse. Alles uitwis maak die leer nutteloos.

Lang bewaring: Personeellyste en klientrekords bly jare lank in Excel. GDPR Artikel 5(1)(e) se data moet 'nie langer as nodig' gehou word. Leers wat 'nuttig mag wees' bly dikwels ver verby hierdie punt.

Waarom Standaard Tekskandering op Sigblaaie Misluk

Teksanalise-instrumente is vir dokumente gebou. Hulle breek op sigblaaie op 'n paar algemene maniere.

Die SSN-as-Nommer Probleem

Excel stoor Sosiale Sekerheidsnommers sonder streppe (123456789) as gewone getalle -- nie teks nie. 'n Skandeerder gebou om ###-##-#### te vind, sal hulle mis. 'n Goeie instrument moet weet dat 'n 9-syfernommer in 'n kolom genaamd 'SSN' 'n Sosiale Sekerheidsnommer is.

Die Datum-as-Nommer Probleem

Excel stoor datums as reeksnommers. 6 Februarie 2024 word as 45329 gestoor. 'n CSV-uitvoer sal '45329' in 'n 'Geboortedatum'-kolom wys. 'n Skandeerder moet daardie nommer na 'n werklike datum omskakel voor dit die waarde kan merk.

Die Gedeeltelike SSN Probleem

Sommige stelsels wys slegs die laaste vier syfers van 'n SSN (*--1234). Die volle nommer sit in 'n geslote kolom. Die gedeeltelike waarde moet steeds geanonimiseer word -- selfs as dit nie soos 'n volle SSN lyk nie.

Die Formule PII Probleem

Sommige selle bou PII uit ander selle. 'n Sel met =CONCATENATE(B2," ",C2) wys 'n volle naam. As u kolomme B en C uitvee, is daardie volle naam steeds sigbaar in die formulisel. 'n Instrument wat slegs gestoorde waardes lees -- nie formulieskakelinge nie -- sal PII op sy plek laat.

Die Multivel Probleem

'n Groot werksboek kan vyf bladsye he: Klientelys, Bestellings, Ondersteuningsinskrywings, Rekening en Analise. Klientename verskyn in almal vyf. 'John Smith' in een blad moet dieselfde teken word -- 'PERSOON_0047' -- in elke ander blad. Twee verskillende tekens breek rekordskakels.

Kolomopskrifte as 'n Sein

Die beste verbetering in sigblad-PII-opsporing is kolomopskrif-analise.

'n Kolom genaamd 'SSN' vertel die instrument dat alle waardes in daardie kolom Sosiale Sekerheidsnommers is. Dit werk selfs as waardes gedeeltelik, vreemd geformateer of as getalle gestoor is.

KolomopskrifWat dit aandui
SSN / Sosiale Sekerheid / Belasting-IDBehandel 9-syfergetalle as SSN's
E-pos / E-mail / E-posadresMerk selfs gedeeltelike e-pospatrone
Foon / Telefoon / Selfoon / SelAanvaar enige foonformaat
DOB / Geboortedatum / VerjaardagSkakel reeksnommers na datums om
Voornaam / Van / Volle NaamVerlaag die drempel vir naamopsporing
Adres / Straat / Stad / PoskodeKombineer nabygeleë liggingsvelde
Pasient-ID / MRN / RekordnommerPas gesondheidssorg-ID-patrone toe

Kolomkonteks vervang nie inhoudskandering nie. Dit voeg daaraan toe. 'n Kolom genaamd 'SSN' met 100 waardes: inhoudskandering vang 99 goeie geformateerde een. Kolomkonteks vang die een wat vreemd lyk.

Hou die Struktuur, Verwyder die Name

Die doel in die meeste Excel GDPR-gevalle is nie om die leer te vernietig nie. Dit is om persoonlike data te verwyder terwyl die dele wat die leer nuttig maak behou word.

Vir 'n 15 000-ry personeelrekordsleer benodig 'n nakomingsbeampte:

Verwyder:

  • Werknemer name -> PERSOON_XXXX tekens
  • SSN's -> GEREDIGEER
  • E-posadresse -> GEREDIGEER
  • Telefoonhommers -> GEREDIGEER
  • Tuisadresse -> GEREDIGEER

Hou:

  • Departementskodes
  • Postitel (algemene rolle slegs)
  • Loonbande (bree kategoriee)
  • Prestasietelling (groepdata)
  • Aanvangsdatums (vir diensjaarstatistieke)
  • Bestuurskodes (as gepseudoanomiseer)

'n Instrument wat die verskil ken tussen 'data wat mense noem' en 'data wat werk beskryf' gee u 'n leer wat steeds vir HR-analise werk -- en aan GDPR-dataminimiseringreels voldoen.

Werklike Geval: F&O HR-data-oordrag

'n Verkrygende maatskappy kry personeelrekords van die teikenmaatskappy: 'n 15 000-ry XLSX met 40 kolomme. Die leer moet na 'n buite-HR-maatskappy gaan vir voordelebeplanning. GDPR se slegs die data wat vir daardie taak benodig word, kan gedeel word.

Voor verwerking: 40 kolomme met volle name, SSN's, e-posse, tuisadresse, noodkontakte en bankbesonderhede.

Na kolomkonteksverwerking:

  • 12 kolomme identifiseer mense direk (name, SSN's, e-posse, foon, adresse, bankdata): vervang met konsekwente tekens
  • 3 kolomme identifiseer mense indirek (personeels-ID, bestuurskode, poscode): vervang met pseudonieme tekens wat binne die leer ooreenstem
  • 25 kolomme is gegroepeerde data (loonband, departement, dienstyd, graad): onveranderd gelaat

Tyd: 8 minute vir 600 000 selle

Uitset: Dieselfde XLSX-uitleg, 40 kolomme, 15 geanonimiseer, 25 onveranderd

Ouditlogboek: Selniveaurekord van elke aksie met entiteitstipe, vertrouenstelling en kolomsein gebruik

Die HR-maatskappy kry 'n volledige datastel vir sy werk -- sonder name of ID's. Die nakomingsrekord kry bewys dat slegs die regte data gedeel is.

Hierdie uitdaging is nie uniek aan Excel nie. Elke leertipe misluk op sy eie manier. Sien hoe formaatfragmentasie PII-opsporing beinvloed vir 'n oorsig oor leertipes.

Drie GDPR Artikel 5-reels, Een Proses

Gestruktureerde sigbladanonimisering voldoen aan drie reels gelyktydig.

Dataminimisering (Art. 5(1)(c)): Slegs die kolomme wat vir die taak benodig word, gaan na die ontvanger. Identifiserende kolomme word verwyder.

Stoorbepaling (Art. 5(1)(e)): Die oorspronklike leer bly vir regsbewaringsdoeleindes. 'n Skoon kopie word vir deling gemaak -- met 'n korter of geen bewaringsbehoef.

Integriteit en vertroulikheid (Art. 5(1)(f)): Geen identifiserende data verlaat die beheersone nie. Slegs skoon kopies word gedeel.

Die ouditlogboek van die proses is ook u Artikel 5(2) bewys. Dit wys hoe elke reel vir elke leer nagekom is.

As u span DSAR's of groot data-uitvoere hanteer, geld dieselfde logika op API-vlak. Sien hoe GDPR-dataminimisering in intydse API's werk.

Vir spanne wat groot volumes onder krap sperdatums hanteer, sien GDPR DSAR-bondelprosessering op skaal vir werkvloeipatrone wat hier ook van toepassing is.

Bronne

Gereed om u data te beskerm?

Begin om PII te anonimiseer met 285+ entiteitstipes in 48 tale.

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.