Find the regulated columnthat isn't handled.
A column-aware PII readiness check for CSV and CRM exports. It reads your table, classifies each column by the kind of PII it holds, and checks whether that column is protected to the minimum its class requires — and one exposed regulated column is enough to hold the whole dataset.
Document scanners find a needle. Your CRM export is the whole haystack.
An exposed regulated column — every row's SSN in the clear — holds the dataset.
The grain that matters for tables: is this column protected across all rows?
AI, network, or uploads — deterministic, offline, a sample of your own export.
Text-scanning tools read a document and flag findings — an SSN here, an email there. But a CSV or CRM export isn't prose; it's columns. The right question is whether your ssn column is handled across every row, not whether one cell tripped a regex. This kit works at the column grain, and it knows that a regulated column with no protection is dispositive.
Set a class, change the handling, watch the gate.
Live demo · set a column's PII class and handling
| Column | PII class | Handling | Verdict |
|---|---|---|---|
| customer_id | HANDLED | ||
| full_name | HANDLED | ||
| HANDLED | |||
| phone | HANDLED | ||
| ssn | EXPOSED | ||
| dob | HANDLED | ||
| plan | HANDLED | ||
| signup_ip | HANDLED |
Dataset verdict
HOLD
regulated-exposed gate FIRED on ssn
Columns
7 handled · 0 mask first · 1 exposed (6 PII, 83% handled)
Fix first: ssn
Handling either meets the minimum its class requires or it doesn't. One regulated column left EXPOSED trips the gate and holds the whole dataset — 83% handled with an open SSN column is still a HOLD. The handled-share is context only.
Verbatim output on the shipped 8-column CRM sample.
Seven of eight columns read HANDLED and the dataset is 83% handled — and yet the verdict is HOLD, because the one regulated column (ssn) sits with no handling and the gate is dispositive. The percentage would have told you a comforting story; the gate tells you the truth.
PII DETECTION FOR STRUCTURED DATA (as of 2026-06-23) ====================================================================== customer_id class=none handling=none -> HANDLED full_name class=low handling=access_controlled -> HANDLED email class=moderate handling=masked -> HANDLED phone class=moderate handling=access_controlled -> HANDLED ssn class=regulated handling=none -> EXPOSED dob class=moderate handling=access_controlled -> HANDLED plan class=none handling=none -> HANDLED signup_ip class=low handling=none -> HANDLED ---------------------------------------------------------------------- Columns: 7 HANDLED / 0 MASK FIRST / 1 EXPOSED (6 PII-bearing, 83% handled) Regulated-exposed gate: FIRED on ssn DATASET VERDICT: HOLD Fix first: ssn Flags what to handle; does NOT mask or remove anything. Reads a sample of your own export; does not score or rank people. Lightly regulated — confirm your regulated categories and data-handling policy with your security/compliance owner. Not legal advice.
Three rules that keep a PII check honest.
A table's risk lives in its columns. Each column is classified by the PII it holds and checked across every row — not one matched cell at a time.
Handling either meets the minimum its class requires or it doesn't. Regulated needs strong protection; access control alone isn't enough for a regulated column.
Any EXPOSED regulated column forces HOLD. The handled-share % is context only — it never lets a dataset with one open SSN column call itself safe.
A readiness flag, not a de-identifier.
- A column-level PII classifier for CSV / CRM exports.
- A handling check against the minimum each PII class requires.
- A runnable engine plus a workbook that reproduces the scoring.
- Deterministic and offline — a sample of your own export, no AI, nothing uploaded.
- A de-identification tool — it flags; it doesn't mask, tokenize, or remove.
- A certified compliance certification of your data.
- A document text-scanner — that's the PII Redaction Readiness Kit.
- A score of people; it classifies columns, not individuals.
Not legal advice. This kit flags what to handle; it does not mask, tokenize, or remove anything, and is not a certified de-identification tool. It does not score or rank people. Which categories count as regulated, and the handling each requires, vary by jurisdiction and policy — confirm your regulated categories and data-handling rules with your security or compliance owner.
Anyone exporting tables that carry PII.
- · Data and ops teams shipping CSVs to vendors or analysts.
- · RevOps owners exporting CRM segments and lists.
- · Anyone handing a dataset to a tool, partner, or model.
- · Security and compliance leads spot-checking exports.
- · Engineers prepping training or test data that must be de-identified.
- · Teams who need column-level PII visibility, not a cell-by-cell scan.
Where this sits in the line.
The unstructured-document counterpart — scans file text for PII findings before you share.
Validate each record's fields by rule — the correctness layer alongside this safety layer.
Sets the data-handling policy this kit operationally checks your exports against.
Is the file even structurally sound? Gate the export's schema upstream of this PII check.
The questions data and compliance teams actually ask before an export leaves.
They work at different grains. The PII Redaction Readiness Kit scans unstructured document text and flags individual findings — an SSN here, an email there — before you share a file. PII Detection for Structured Data works at the column grain on tables: it classifies each whole column by the kind of PII it holds and checks whether that column is protected across every row, to the minimum its class requires. A document scanner asks “did a cell match a regex?”; this asks “is the ssn column handled, period?” For a CSV or CRM export, the column is the unit of risk, which a cell-by-cell text scan can't express. Many teams own both — the document kit for prose, this for tables.
Because one exposed regulated column is dispositive. In the worked 8-column sample, seven columns read HANDLED and the dataset is 83% handled — but the ssn column (regulated) sits with no handling at all, so the regulated-exposed gate fires and the whole dataset is HOLD. The handled-share percentage is shown for context only and never sets the verdict. An open SSN column across every row isn't made safe by everything else being fine; the gate refuses to let a comforting average bury it. Add masking, tokenization, or encryption to that column and the dataset clears.
Each column's handling is checked against the minimum strength its PII class requires. HANDLED means the handling meets or exceeds that minimum (or the column holds no PII). MASK FIRST means PII is present and there's some handling, but it's below the minimum — for example, access control alone on a regulated column that needs masking or encryption. EXPOSED means PII is present with no qualifying handling at all. At the dataset level: SAFE TO USE when every PII-bearing column is HANDLED, REMEDIATE when there's a MASK FIRST or a non-regulated EXPOSED but no regulated column open, and HOLD the moment any regulated column is EXPOSED.
It infers a class from the column name (hints like ssn, email, dob) plus a sample of the actual values (a detector fires when a regex matches a meaningful share of non-blank cells) — and the highest-class detector wins, biasing conservative on ambiguous numeric columns. You can override any column's class, because what counts as regulated, and the handling it requires, vary by jurisdiction and policy. The defaults (SSN, card, bank, health = regulated) are a sensible baseline, not a legal determination. The included Column Classification Playbook walks through setting classes for your own schema.
No. PII Detection for Structured Data flags what to handle — it never masks, tokenizes, redacts, or removes anything itself, and it's not a certified de-identification tool. It reads a sample of your own export, classifies the columns, checks the handling you declare, and returns a per-column and dataset verdict with the column to fix first; the included Remediation Runbook tells you how to fix each one. It's deterministic and offline — no AI, no network, nothing uploaded — so the same export always produces the same verdict, and it classifies columns, never people.
No. It's a lightly-regulated readiness check, not a compliance certification and not legal advice — it cites no specific statute, figure, or deadline, and it never concludes you are “compliant.” It gives you an honest, column-level read on which regulated data in an export isn't protected yet, so you can fix it before the file leaves. Which categories count as regulated and the handling each requires vary by jurisdiction and your own policy, so confirm those with your security or compliance owner. It pairs with the CSV / Data-Export Schema & Quality Gate (is the file even structurally sound?) and the AI Governance & Acceptable Use Starter Kit (the policy this operationally checks against).
New to the document-ops line? Run the Document Processing Pipeline Diagnostic first — it scores your workflow across six stages and routes you to the exact drop that fixes your bottleneck.
Know which columns are exposed
before the export leaves.
One purchase, lifetime access, 12 months of updates. $79, once.
Not legal advice. Flags what to handle; does not mask or remove anything, and is not a certified de-identification tool. Does not score or rank people. Confirm your regulated categories and data-handling policy with your security or compliance owner.
Sold by RedHub AI LLC · Secured by Stripe · redhub.ai