What should I scan before sharing a repository or log file?

Review schemas and migrations, seed and fixture data, CSV and JSON samples, configuration examples, application and build logs, exports, generated artifacts, and documentation that may contain copied records.

Is an email address always PII?

An email-like pattern is a review signal, not an automatic legal classification. Determine whether the value relates to an identified or identifiable person, whether it is synthetic, and which jurisdiction and use context apply.

Does a clean automated scan prove that a codebase contains no personal data?

No. Personal data can use unexpected formats or become identifying only when combined with other information. Automated scanning should prioritize human review, not replace it or certify compliance.

// personal-data preflight

How to scan a codebase for PII before sharing logs or sample data

Personal data rarely stays in one database table. It leaks into fixtures, exports, configuration examples, debug output, support attachments, and the sample files someone copied from production because they were convenient.

By H.J. Westerfield · Updated July 21, 2026 · 9 minute read

The short version

Inventory every repository surface that can contain records, then scan for both data-bearing field names and pattern-like values. Keep the run read-only and narrowly scoped. Triage each result in context without copying the full value into a report. Replace real records with purpose-built synthetic data, fix the path that created the leak, rerun the scan, and preserve evidence of what was checked. Treat a clean scan as one control, not proof that the repository is compliant or free of personal data.

Scan for identifiers, then decide what they mean in context

The GDPR definition is intentionally broad: personal data is information relating to an identified or identifiable natural person, including direct identifiers and data that can identify someone indirectly. NIST likewise recommends context-based identification and protection of PII rather than treating every match as equally sensitive.

That distinction matters in code. A field called email is a schema signal, not proof that the file contains a person's address. test@example.com may be synthetic. A location, account ID, or unique combination of otherwise ordinary fields may be identifying even when no familiar regex matches it.

Use automated matches to build a prioritized human-review queue. Do not let the pattern engine make the legal or business decision.

Inventory the surfaces people forget

Surface	What to inspect	Typical failure
Schemas and migrations	Column names, JSON keys, comments, defaults, and embedded backfill values.	The structure advertises sensitive fields, or a migration carries copied production rows.
Seeds and fixtures	SQL inserts, factories, snapshots, test accounts, and demo records.	Real customer data was substituted for synthetic data to reproduce a bug.
CSV and JSON	Samples, imports, exports, mocks, cached API responses, and notebooks.	A file intended as a format example contains an intact record set.
Configuration	Example configs, environment templates, YAML, JSON, and local overrides.	A username, phone, endpoint parameter, or account identifier is committed as a default.
Logs and traces	Application logs, build logs, browser traces, screenshots, request bodies, and error dumps.	Debugging captures more of the request or user object than the incident requires.
Docs and tickets	README examples, issue attachments, support transcripts, and copied terminal output.	The code is clean, but the reproduction steps disclose a person's data.
Generated artifacts	Reports, build folders, exports, backups, and temporary files.	The source was sanitized while a generated copy remained shareable.

A six-step personal-data preflight

Define the sharing boundary

Name what is about to happen: public repository, vendor handoff, support ticket, AI-agent context, or internal release. List the exact files and folders that will cross that boundary. Exclude unrelated areas from the scanner's access rather than scanning an entire home directory for convenience.

Inventory data-bearing files

Search by file type and purpose, not just obvious names. Include schemas, migrations, seeds, fixtures, CSV, JSON, configuration, logs, traces, exports, and generated reports. NIST's Privacy Framework treats understanding and inventorying data processing as foundational to managing privacy risk.

Scan names and values separately

First find field and key names that imply personal data: email, phone, address, government identifiers, account IDs, and similar labels. Then scan values for recognizable formats such as email addresses, SSN-like sequences, credit-card-like numbers, and phone numbers. Keep the two finding types separate so a schema hint is not mistaken for an exposed record.

Triage in place

Open the finding at its source. Decide whether it is real, synthetic, a placeholder, or a false positive, and whether surrounding fields make it identifying. Record the rule, file, line, classification, and owner. Do not paste the full matched value into a new Markdown report, chat, or ticket.

Remove the source, not only the symptom

Replace real seed or sample records with purpose-built synthetic data. Change logging so it records only what the operational use case needs. OWASP recommends removing, masking, sanitizing, hashing, or encrypting sensitive data rather than recording it directly, and specifically calls out personal data, tokens, passwords, connection strings, and payment data.

If the file was already shared, treat cleanup in the current branch as only one step. Assess copies, history, caches, attachments, backups, recipients, and any incident-response or notification obligations with the appropriate privacy or legal owner.

Rerun and keep minimal evidence

Run the same scoped scan after remediation. Preserve counts and locations without preserving sensitive values. Add a repeatable pre-commit, pre-release, or pre-handoff review appropriate to the risk, and periodically test that the logging configuration still excludes data it should not collect.

Build a review record that does not become a second leak

A useful finding needs enough evidence to reproduce and fix the problem, but not enough to expose the person again. Prefer a masked sample and a one-way fingerprint only when your policy allows it.

Minimal finding record

Rule: EMAIL_VALUE
Location: fixtures/customers.json:18
Evidence: email-like value ending in @example-customer.com; local part withheld
Classification: confirmed real customer record
Action: replace fixture with synthetic record and audit how production data entered test assets
Verification: rerun found zero real values in the scoped fixture directory

False positives are expected. Phone-like timestamps, random numeric identifiers, example addresses, and test domains can resemble personal data. False negatives are also expected: nicknames, free-form notes, encoded data, images, archives, and combinations of fields may evade simple patterns. The right output is an honest review state, not a theatrical zero.

Turn the inventory into a review queue

PII & Data-Leak Scanner covers the repository surfaces in this workflow: SQL, CSV, JSON, schema and seed data, configuration, and logs. It flags both PII-indicating names and pattern-like values, and ties each finding to a location and review note.

PII & Data-Leak Scanner Build the local review queue across schemas, samples, configuration, and logs. Heuristic by design; every match still needs context. See the scanner and its boundaries → AI-built app release audit Continue from repository data exposure to authorization, real data paths, failure behavior, production evidence, backup, and rollback. Build the wider release evidence →

Primary sources

Scan before the file crosses a boundary.

Start with a narrowly scoped, evidence-first review. Decide what each match means before removing or sharing anything.

Get PII & Data-Leak Scanner on Agensi