By · Last updated 2026-06-05

Bumalik sa BlogGDPR & Pagsunod

Excel PII: Mag-Anonymize ng Daan-daang Column

Ang mga Excel file ay kabilang sa pinaka-PII-dense na uri ng dokumento sa mga operasyon ng negosyo. Narito kung bakit nabibigo ang karaniwang text analysis sa mga spreadsheet at ano ang ginagawa ng column-context.

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

Bakit ang Excel ang Iyong Pinaka-Mapanganib na Uri ng File

Ang mga Excel file ay isa sa pinakamalaking GDPR na panganib sa karamihan ng negosyo. Ang mga medikal na talaan ay maaaring magtago ng mas sensitibong data bawat row. Ngunit mabilis na nag-iipon ng PII ang mga spreadsheet - at madalas na napapalampas ito ng mga compliance team.

Tatlong bagay ang nagpapalubha ng pamamahala ng mga Excel file.

Volume: Ang isang XLSX file ay maaaring magtago ng 50,000 row at 100 column. Iyon ay limang milyong cell. Walang manual na pagsusuri ang kayang suriin ang lahat ng ito.

Grid layout: Dumadaloy ang teksto sa isang direksyon. Nagkakalat ng data sa mga row at column ang Excel. Maaaring magtago ang personal na data kahit saan sa grid na iyon.

Mixed na nilalaman: Ang mga pay band, department code, at job grade ay nasa parehong file kasama ang mga SSN at email address. Ang pagbura ng lahat ay ginagawang walang silbi ang file.

Matagal na pagtatago: Ang mga listahan ng empleyado at rekord ng customer ay nananatili sa Excel nang maraming taon. Sinasabi ng GDPR Article 5(1)(e) na ang data ay dapat itago "hindi hihigit sa kinakailangan." Ang mga file na "maaaring maging kapaki-pakinabang" ay madalas na nananatili nang higit pa sa puntong iyon.

Bakit Nabibigo ang Karaniwang Text Scan sa mga Spreadsheet

Ang mga text analysis tool ay ginawa para sa mga dokumento. Nagsisira ang mga ito sa mga spreadsheet sa ilang karaniwang paraan.

Ang Problema ng SSN-bilang-Numero

Ang Excel ay nagse-save ng Social Security Number na walang gitling (123456789) bilang plain na numero - hindi teksto. Ang isang scanner na ginawa para mahanap ang ###-##-#### ay mapapalampas ang mga ito. Dapat malaman ng isang magandang tool na ang isang 9-digit na numero sa isang column na tinatawag na "SSN" ay isang Social Security Number.

Ang Problema ng Petsa-bilang-Numero

Ang Excel ay nag-iimbak ng mga petsa bilang mga serial na numero. Ang Pebrero 6, 2024 ay nakaimbak bilang 45329. Ang isang CSV export ay magpapakita ng "45329" sa isang column na "Date of Birth." Ang isang scanner ay dapat i-convert ang numerong iyon sa tunay na petsa bago ito matanda.

Ang Problema ng Partial SSN

Ilang sistema ay nagpapakita lamang ng huling apat na digit ng SSN (*--1234). Ang buong numero ay nasa locked na column. Ang partial na halaga ay kailangan pa ring i-anonymize - kahit na hindi ito mukhang buong SSN.

Ang Problema ng Formula PII

Ilang cell ang nagtatayo ng PII mula sa ibang mga cell. Ang isang cell na may =CONCATENATE(B2," ",C2) ay nagpapakita ng buong pangalan. Kung iali-clear mo ang mga column B at C, ang buong pangalang iyon ay makikita pa rin sa formula cell. Ang isang tool na nagbabasa lamang ng mga nakaimbak na halaga - hindi ng mga formula link - ay mag-iiwan ng PII.

Ang Problema ng Multi-Sheet

Ang isang malaking workbook ay maaaring may limang sheet: Customer List, Orders, Support Tickets, Billing, at Analytics. Ang mga pangalan ng customer ay lumalabas sa lahat ng lima. Ang "John Smith" sa isang sheet ay dapat maging parehong token - "PERSON_0047" - sa bawat isa pang sheet. Ang dalawang magkaibang token ay nagsisira ng mga rekord na link.

Mga Column Header bilang Senyales

Ang pinakamahusay na pagpapabuti sa spreadsheet PII detection ay ang column header analysis.

Ang isang column na tinatawag na "SSN" ay nagsasabi sa tool na ang lahat ng halaga sa column na iyon ay mga Social Security Number. Gumagana ito kahit na partial, kakaibang na-format, o nakaimbak bilang mga numero ang mga halaga.

Column headerAno ang isinasaad nito
SSN / Social Security / Tax IDTratuhin ang 9-digit na numero bilang SSN
Email / E-mail / Email AddressI-flag kahit partial na email pattern
Phone / Telephone / Mobile / CellTanggapin ang anumang format ng telepono
DOB / Date of Birth / BirthdayI-convert ang mga serial na numero sa mga petsa
First Name / Last Name / Full NameIbaba ang bar para sa name detection
Address / Street / City / ZIPPagsamahin ang mga kalapit na location field
Patient ID / MRN / Record NumberIlapat ang mga pattern ng healthcare ID

Ang column context ay hindi pumapalit sa content scanning. Nagdadagdag ito sa scanning. Isang column na tinatawag na "SSN" na may 100 halaga: nahahanap ng content scanning ang 99 na maayos na naformat. Nahahanap ng column context ang isa na mukhang kakaiba.

Panatilihin ang Istruktura, Alisin ang mga Pangalan

Ang layunin sa karamihan ng Excel GDPR case ay hindi ang sirain ang file. Ito ay ang alisin ang personal na data habang pinapanatili ang mga bahagi na ginagawang kapaki-pakinabang ang file.

Para sa isang 15,000-row na file ng talaan ng empleyado, kailangan ng compliance officer ang:

Alisin:

  • Pangalan ng empleyado → mga token na PERSON_XXXX
  • Mga SSN → REDACTED
  • Mga email address → REDACTED
  • Mga numero ng telepono → REDACTED
  • Mga home address → REDACTED

Panatilihin:

  • Mga department code
  • Mga pamagat ng trabaho (pangkalahatang papel lamang)
  • Mga pay band (malawak na kategorya)
  • Mga performance score (data ng grupo)
  • Mga petsa ng pagsisimula (para sa mga stat ng tenure)
  • Mga code ng manager (kung pseudonymized)

Ang isang tool na nakaaalam ng pagkakaiba sa pagitan ng "data na nagpapangalan ng mga tao" at "data na naglalarawan ng mga trabaho" ay nagbibigay sa iyo ng isang file na gumagana pa rin para sa HR analysis - at nakakatugon sa mga patakaran ng GDPR data minimization.

Tunay na Kaso: M&A HR Data Transfer

Ang isang acquiring company ay nakatanggap ng mga rekord ng empleyado mula sa target na kumpanya: isang 15,000-row na XLSX na may 40 column. Ang file ay kailangang pumunta sa isang external na HR firm para sa pagpaplano ng benepisyo. Sinasabi ng GDPR na ang data lamang na kailangan para sa gawain na iyon ang maaaring ibahagi.

Bago mag-proseso: 40 column na may buong pangalan, SSN, email, home address, emergency contact, at detalye ng bangko.

Pagkatapos ng column-context processing:

  • 12 column ang direktang nagpapakilala ng mga tao (pangalan, SSN, email, telepono, address, data ng bangko): pinalitan ng mga konsistenteng token
  • 3 column ang hindi direktang nagpapakilala ng mga tao (staff ID, code ng manager, code ng trabaho): pinalitan ng mga pseudonymous token na nagtatugma sa loob ng file
  • 25 column ang aggregate na data (pay band, departamento, tenure, grade): naiwan nang hindi binago

Oras: 8 minuto para sa 600,000 cell

Output: Parehong XLSX na layout, 40 column, 15 anonymized, 25 hindi binago

Audit log: Rekord sa antas ng cell ng bawat aksyon na may uri ng entity, confidence score, at ginamit na signal ng column

Natatanggap ng HR firm ang buong dataset para sa trabaho nito - na walang pangalan o ID. Nakakakuha ang rekord ng compliance ng katibayan na ang tamang data lamang ang ibinahagi.

Ang hamong ito ay hindi natatangi sa Excel. Bawat format ng file ay nabibigo sa sariling paraan. Tingnan kung paano nakakaapekto ang format fragmentation sa PII detection para sa isang pagtingin sa iba't ibang uri ng file.

Tatlong GDPR Article 5 na Patakaran, Isang Proseso

Ang nakaayos na spreadsheet anonymization ay nakakatugon sa tatlong patakaran nang sabay-sabay.

Data minimization (Art. 5(1)(c)): Ang mga column lamang na kailangan para sa gawain ang pumupunta sa tatanggap. Ang mga column na nagpapakilala ay binubura.

Storage limitation (Art. 5(1)(e)): Nananatili ang orihinal na file para sa legal na pagtatago. Ginagawa ang malinis na kopya para sa pagbabahagi - na may mas maikli o walang pangangailangan sa pagtatago.

Integridad at pagiging kumpidensyal (Art. 5(1)(f)): Walang data na nagpapakilala ang umaalis sa control zone. Mga malinis na kopya lamang ang ibinabahagi.

Ang audit log mula sa proseso ay ang iyong katibayan ng Article 5(2). Ipinapakita nito kung paano natutugunan ang bawat patakaran para sa bawat file.

Kung ang iyong team ay nangangasiwa ng mga DSAR o malalaking data export, ang parehong lohika ay nalalapat sa antas ng API. Tingnan kung paano gumagana ang GDPR data minimization sa real-time na API.

Para sa mga team na nakikitungo sa mataas na volume sa ilalim ng mahigpit na deadline, tingnan ang GDPR DSAR batch processing sa malaking sukat para sa mga pattern ng workflow na nalalapat din dito.

Mga Pinagkukunan

Handa nang protektahan ang iyong data?

Simulan ang anonymization ng PII gamit ang 285+ uri ng entidad sa 48 wika.

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.