piidetectionapi.com
Home
Solutions - Fundamentals
What Is PII Detection? NER vs Regex vs Rules Accuracy, Precision & Recall PII in Test Data
Solutions - Compliance
GDPR Personal Data HIPAA PHI Detection CCPA / CPRA PCI DSS Card Data
Solutions - AI & LLM Safety
LLM Guardrails Chatbot PII Filtering RAG Pipelines
Solutions - Data Discovery & DLP
Data Loss Prevention Log File Scanning Support Tickets Email Scanning Documents & PDFs Database Discovery ETL & Streaming Pipelines
Industries - Financial
Banking Fintech Insurance
Industries - Healthcare
Healthcare Pharma & Clinical Trials Telehealth
Industries - Public Sector & Legal
Government & FOIA Law Enforcement Law Firms & eDiscovery Education (FERPA)
Industries - Technology
SaaS Platforms Cybersecurity & IR Telecommunications Gaming & Platforms
Industries - Other
HR & Recruiting Retail & E-commerce Call Centers & BPO Real Estate Travel & Hospitality Marketing & AdTech
How-to Guides - Identity & Contact
Detect Names Detect Email Addresses Detect Phone Numbers Detect Physical Addresses Detect Dates of Birth
How-to Guides - IDs & Financial
Detect SSNs Detect Passport Numbers Detect Drivers Licenses Detect Credit Card Numbers Detect Bank Accounts & IBAN
How-to Guides - Technical & Health
Detect IP & Device IDs Detect Medical Records & PHI
Resources
Pricing API Docs Supported Entities Languages About Contact Sign In Try the Live Demo Get Started
Cybersecurity & Incident Response

PII Detection for Cybersecurity & Incident Response

Answer the question every breach asks first: whose data was in there? Triage exfiltrated dumps, quantify notification obligations, find leaked credentials in logs, and sanitize threat intel before you share it — all through one detection API.

SIEM / SOC data GDPR 72-hour clock Credential & secret detection TLP-safe intel sharing 150+ entity types

Security Teams Swim in Other People's PII

The tooling a modern SOC runs on — SIEM, EDR, NDR, email security, ticketing — exists to collect evidence, and evidence is soaked in personal data. Proxy logs carry usernames and the sites employees visit. Email security gateways quarantine messages containing medical claims and payroll figures. EDR telemetry records file paths like C:\Users\jsmith\Documents\divorce_settlement.docx. Packet captures and alert payloads embed whatever content happened to be in flight. Security teams rarely think of themselves as data controllers, yet the SIEM is often the single largest concentration of personal data in the company — and the least governed one.

That creates two distinct problems. Day to day, PII and secrets accumulate in detection pipelines where analysts, MSSP contractors, and third-party tools can see them, quietly expanding regulatory scope and insider risk. And on the worst day, when data has actually been stolen, the incident commander faces a deadline-driven question that manual review cannot answer at scale: exactly which records in the affected data contained personal information, of what kinds, for roughly how many people?

Our PII Detection API gives security engineering a programmatic answer to both. Send any text — a log batch, an alert payload, a paste-site dump, a recovered file — and get back every detected entity with its type, character offsets, and confidence score, plus an optionally masked copy. It is a single JSON endpoint you can call from a SOAR playbook, a log shipper, or a one-off triage script during an active incident.

Detection is a security control, not just a privacy checkbox

The same scan that finds an SSN in a log line also finds an AWS_CREDENTIALS block or an SSH_KEY pasted into a ticket. PII detection and secret detection are one problem — sensitive strings in places they should not be — and the API treats them as one, with credential entity types alongside the classic identifiers. Browse all 150+ types in the entity catalog and the request format in the API documentation.

Breach Impact Assessment on a Regulatory Clock

Notification law does not care how large the stolen dataset is — it cares what was in it, and it starts the timer the moment you know

GDPR: 72 Hours to Characterize the Breach

Article 33 gives you 72 hours from awareness to notify the supervisory authority, and the notification must describe the categories and approximate number of data subjects and records concerned. Article 34 adds direct notification to individuals when risk is high. You cannot meet either duty by eyeballing a 40 GB dump — automated entity classification is what turns "we lost some files" into the categorized inventory the regulator expects. See our GDPR PII detection guide.

US State Breach Laws: Definitions Drive Duties

All 50 states define "personal information" as specific combinations — typically a name plus SSN, driver's license number, financial account, or medical data. Whether you must notify at all, and in which states, depends on which combinations appear in the compromised records. Detection output maps directly onto those statutory definitions: SSN hits plus PERSON_NAME hits in the same record is a notification trigger; marketing copy is not.

Leaked Credentials Are Their Own Incident

A dump that contains PASSWORD, API_KEY, AWS_CREDENTIALS, or SSH_KEY entities is not just a privacy event — it is an active intrusion vector. Scanning stolen or exposed data for credential types tells the response team what to rotate first, hours before any manual review would surface it. Several state laws and the GDPR's "risk to rights and freedoms" test also treat exposed credentials as escalating factors.

Contract & Framework Obligations

Beyond statute, customer DPAs, cyber-insurance policies, PCI DSS incident procedures, and frameworks like NIST 800-61 all require you to determine the sensitivity of affected data as part of scoping. GDPR confidentiality criteria expect monitoring for sensitive-data exposure in operational systems. A detection pipeline produces the evidence trail for all of them from the same scans — the approach our DLP guide covers in depth.

From "We Think It Was Bad" to a Defensible Number

Regulators and plaintiffs' counsel both punish vagueness. Companies that over-notify spend millions on credit monitoring for people whose data was never touched; companies that under-notify face enforcement when the real scope surfaces later. The difference is granular knowledge of the affected data, produced fast enough to matter.

The workflow that produces it is mechanical: chunk the affected files, run each chunk through the API with all entity types enabled, and aggregate counts by type and by record. Within hours you have a table — 41,200 records with EMAIL_ADDRESS, 3,914 with SSN, 220 with MEDICAL_DATA, zero with CREDIT_CARD_NUMBER — that legal counsel can map onto notification statutes jurisdiction by jurisdiction. That table is also what your cyber insurer, your board, and your press statement are built on. Teams that rehearse this pipeline in tabletop exercises report that it removes the single largest source of delay in their breach playbooks.

Where Sensitive Data Hides in the Security Stack

A map of the systems a SOC operates, the identifiers and secrets that pool in them, and the entity filters to scan them with

PERSON_NAME
Usernames, victims, analysts
EMAIL_ADDRESS
Phishing samples, alert payloads
IP_ADDRESS / MAC_ADDRESS
Flow logs, IOC lists
SSN / NATIONAL_ID
Exfiltrated HR & customer data
CREDIT_CARD_NUMBER
Carding dumps, PCI incidents
AWS_CREDENTIALS
Leaked access key pairs
SSH_KEY / PRIVATE_KEY
Repos, tickets, pastes
API_KEY / AUTH_TOKEN
Debug logs, HTTP traces
PASSWORD
Credential stuffing lists
DATABASE_CONNECTION_STRING
Config leaks, error traces
DEVICE_ID / IMEI
EDR & mobile telemetry
MEDICAL_DATA
Breach severity escalator
Security Data Source Sensitive Content That Accumulates Why It Matters Recommended Entity Filter
SIEM ingestion pipeline (Splunk, Sentinel, Elastic) Usernames, emails, URLs with tokens, request bodies, file paths containing names GDPR minimization, MSSP/analyst access scope, retention costs PERSON_NAME, EMAIL_ADDRESS, AUTH_TOKEN, PASSWORD, IP_ADDRESS
Exfiltrated dump / ransomware leak site data Whatever was stolen: HR files, customer exports, finance spreadsheets Breach notification scoping under GDPR Art. 33/34 and state laws All entities (default), threshold: 0.5, aggregate by type
Phishing & email security quarantine Victim names, reply chains with PII, credential-harvest payloads Analyst exposure, safe sample sharing with vendors PERSON_NAME, EMAIL_ADDRESS, PHONE_NUMBER, PASSWORD, CREDIT_CARD_NUMBER
Threat intel reports & IOC feeds Victim identifiers embedded in narratives, internal IPs and hostnames, employee emails TLP handling rules, ISAC/ISAO sharing agreements, victim privacy PERSON_NAME, EMAIL_ADDRESS, IP_ADDRESS, URL, EMPLOYMENT
DFIR evidence & case notes Disk artifacts, browser history, chat exports, interview notes Legal privilege workflows, need-to-know inside the IR team All entities plus MEDICAL_DATA, SEXUAL_ORIENTATION for sensitivity flags
Ticketing & SOAR case records Pasted log excerpts, screenshots' OCR text, credentials shared "temporarily" Tickets outlive incidents; contractors and integrations read them PASSWORD, API_KEY, AWS_CREDENTIALS, SSH_KEY, SSN

Triaging Exfiltrated Data Dumps at Machine Speed

When your data appears on a leak site, or a researcher hands you a paste of "your" records, the first task is verification and scoping: is this really ours, how current is it, and what categories of personal data does it contain? Manual sampling misleads — dumps are heterogeneous, and the one folder you skim may be the only one without SSNs in it.

The API-driven approach is exhaustive instead. A triage script walks the dump, extracts text (including OCR output for scanned documents — see our document scanning guide), and submits chunks of up to 50,000 characters per request. Because responses include exact offsets and per-entity confidence, you can build a record-level index: which files contain which identifier types, at what density. Credential types get routed straight to the rotation queue; regulated identifier combinations feed the notification analysis; everything else derisks the "assume the worst" defaults that make breaches more expensive than they need to be.

The same pipeline works preventively. Point it at your own object storage, file shares, or databases before an attacker does, and you get a prioritized map of where a future breach would hurt most — the data-driven input your crown-jewels assessment has been missing.

Security & IR Use Cases

Six places security teams wire in detection first — from steady-state log hygiene to worst-day breach triage

1

SIEM Log Sanitization

Scan log batches at the shipper or ingestion tier and mask identifiers before they index. Analysts keep full investigative context via typed placeholders, correlation on hashed values still works, and your SIEM stops being the company's largest unaudited PII store. Patterns in our log scanning guide.

Input
authfail [email protected] src=203.0.113.44 pw_attempt="Summer2026!"
Detected & Masked
authfail user=[EMAIL_ADDRESS] src=[IP_ADDRESS] pw_attempt="[PASSWORD]"
2

Breach Dump Classification

During an active incident, batch-scan the affected dataset and aggregate entity counts per file and per record. Legal maps the output to GDPR Article 33/34 and state notification statutes; the IC gets a defensible scope number within hours instead of weeks of contractor review.

Input
row 8412: Albright, Dana | 512-33-8890 | 1979-03-14 | 44 Cedar Ln, Provo UT
Detected & Masked
row 8412: [PERSON_NAME] | [SSN] | [DATE_OF_BIRTH] | [ADDRESS]
3

Credential & Secret Sweeps

Run scheduled scans over tickets, wikis, chat exports, and build logs for AWS_CREDENTIALS, SSH_KEY, API_KEY, DATABASE_CONNECTION_STRING, and PASSWORD. Context-aware detection catches secrets that entropy-based scanners miss — a password sitting in prose, a key split across a sentence.

Input
temp fix: connect with postgres://svc_ops:R3dTeam#22@db-prod:5432/core until SSO works
Detected & Masked
temp fix: connect with [DATABASE_CONNECTION_STRING] until SSO works
4

Threat Intel Sanitization

Before a report leaves your org for an ISAC, a vendor, or a TLP:CLEAR advisory, scan it and mask victim names, employee emails, internal hostnames-in-URLs, and any customer identifiers that rode along in the evidence. You share the tradecraft, not the victims.

Input
Actor phished finance lead Tomas Vega ([email protected]) then pivoted via 10.2.8.11
Detected & Masked
Actor phished finance lead [PERSON_NAME] ([EMAIL_ADDRESS]) then pivoted via [IP_ADDRESS]
5

Phishing Sample Handling

User-reported phish arrive with the victim's whole reply chain attached. Scan samples before they enter the analysis queue or get submitted to sandboxes and vendor portals, so the original recipient's HR dispute or medical referral does not become a training artifact in someone else's system.

Input
FW: Re: your claim #A-2231 — Hi Dr. Okafor, my member ID is HZ4482913...
Detected & Masked
FW: Re: your claim #A-2231 — Hi [PERSON_NAME], my member ID is [HEALTH_INSURANCE_ID]...
6

SOAR Playbook Enrichment

Add a detection step to your SOAR playbooks: every DLP alert, mail-flow anomaly, or endpoint exfil signal gets its artifact text scanned automatically. The entity summary lands on the incident record, driving severity scoring — an alert whose payload contains 900 SSN hits routes very differently from one containing marketing copy.

Input
DLP alert #5521: outbound attachment customers_q3.csv, 2.1MB, dest: personal Gmail
Enriched Verdict
scan: SSN=1,204 · EMAIL=8,430 · CARD=0 → severity CRITICAL, auto-escalate
<200ms
Typical Latency — Playbook-Ready
150+
Entity Types incl. Secrets
60+
Languages
50k
Characters per Request

Wire Detection into Your Security Stack

One endpoint for log shippers, triage scripts, and SOAR playbooks — same contract in steady state and mid-incident

cURL — Scan an Incident Log Line for PII and Secrets

# Scan a suspicious log entry pulled during an investigation
curl -X POST https://piidetectionapi.com/api/moderate.php \
  -H "Content-Type: application/json" \
  -d '{
    "api_key": "YOUR_API_KEY",
    "api_type": "pii_detection",
    "text": "ALERT exfil: [email protected] uploaded dump.sql from 10.4.22.17 using key AKIAIOSFODNN7EXAMPLE conn postgres://admin:[email protected]:5432/customers",
    "entities": ["EMAIL_ADDRESS", "IP_ADDRESS", "AWS_CREDENTIALS", "DATABASE_CONNECTION_STRING", "PASSWORD", "API_KEY"],
    "mask_mode": "replace",
    "threshold": 0.5
  }'
# Response
{
  "detected_entities": [
    {"type": "EMAIL_ADDRESS", "text": "[email protected]", "start": 13, "end": 32, "confidence": 0.99},
    {"type": "IP_ADDRESS", "text": "10.4.22.17", "start": 57, "end": 67, "confidence": 0.97},
    {"type": "AWS_CREDENTIALS", "text": "AKIAIOSFODNN7EXAMPLE", "start": 78, "end": 98, "confidence": 0.95},
    {"type": "DATABASE_CONNECTION_STRING", "text": "postgres://admin:[email protected]:5432/customers", "start": 104, "end": 158, "confidence": 0.94}
  ],
  "anonymized_text": "ALERT exfil: [EMAIL_ADDRESS] uploaded dump.sql from [IP_ADDRESS] using key [AWS_CREDENTIALS] conn [DATABASE_CONNECTION_STRING]",
  "entities_detected": 4,
  "processing_time_ms": 171,
  "mask_mode_used": "replace",
  "status": 200
}

Python — Triage a Leaked File for Notification Scoping

import requests
from collections import Counter

API_URL = "https://piidetectionapi.com/api/moderate.php"
CHUNK = 40_000  # stay under the 50k char limit

def triage_dump(path: str) -> Counter:
    """Classify every chunk of a recovered file; return entity totals."""
    totals = Counter()
    text = open(path, encoding="utf-8", errors="replace").read()
    for i in range(0, len(text), CHUNK):
        resp = requests.post(API_URL, json={
            "api_key": "YOUR_API_KEY",
            "api_type": "pii_detection",
            "text": text[i:i + CHUNK],
            # no "entities" filter: scan for everything
            "mask_mode": "replace",
            "threshold": 0.5,
        }, timeout=30)
        for e in resp.json()["detected_entities"]:
            totals[e["type"]] += 1
    return totals

counts = triage_dump("leaked/customers_export.csv")

# Feed the notification analysis: statutory PII combos first
notify_triggers = ["SSN", "DRIVERS_LICENSE_NUMBER",
                   "FINANCIAL_ACCOUNT_NUMBER", "MEDICAL_DATA"]
rotate_now = ["PASSWORD", "API_KEY", "AWS_CREDENTIALS", "SSH_KEY"]

print("Notification-relevant:", {k: counts[k] for k in notify_triggers})
print("Rotate immediately:", {k: counts[k] for k in rotate_now})

JavaScript — SOAR Playbook Step with Auto-Escalation

// Node.js: detection step invoked by a SOAR playbook webhook
async function classifyArtifact(text) {
  const res = await fetch(
    "https://piidetectionapi.com/api/moderate.php",
    {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        api_key: process.env.PII_API_KEY,
        api_type: "pii_detection",
        text,
        entities: ["SSN", "CREDIT_CARD_NUMBER",
                   "MEDICAL_DATA", "PASSWORD",
                   "AWS_CREDENTIALS", "SSH_KEY"],
        mask_mode: "replace",
        threshold: 0.6
      })
    }
  );
  return res.json();
}

app.post("/playbooks/dlp-alert", async (req, res) => {
  const data = await classifyArtifact(req.body.artifactText);

  const summary = {};
  data.detected_entities.forEach(e =>
    summary[e.type] = (summary[e.type] || 0) + 1);

  // Regulated identifiers or live secrets: escalate, never close
  const critical = ["SSN", "CREDIT_CARD_NUMBER",
                    "AWS_CREDENTIALS", "SSH_KEY"]
    .some(t => summary[t]);

  await soar.updateIncident(req.body.incidentId, {
    piiSummary: summary,                // counts only, no raw values
    sanitizedExcerpt: data.anonymized_text.slice(0, 500),
    severity: critical ? "critical" : "moderate"
  });
  res.sendStatus(204);
});
Rehearse before you need it

Get a key on the get started page, run your last tabletop exercise's mock dump through the interactive demo, and time the triage. Volume tiers on the pricing page cover both steady-state log scanning and burst capacity for incident days.

DFIR Workflows and Intel Sharing Without Collateral Exposure

Forensic work multiplies copies of sensitive data: disk images become file listings, file listings become case notes, case notes become the report that goes to outside counsel, the insurer, and sometimes law enforcement. Every hop widens the audience. Building detection into the DFIR toolchain — scan extracted text before it enters the case file, mask by default, keep raw evidence in the forensically controlled store only — keeps the chain of custody narrow without slowing examiners down. Confidence scores and offsets are preserved in the structured output, so nothing about masking degrades the evidentiary record; the pointer back to the raw artifact remains.

Intel sharing has the same shape. The Traffic Light Protocol governs who may see a document, but nothing in TLP magically removes the victim PII inside it. ISAC and ISAO sharing agreements, and CISA's guidance for sharing cyber threat indicators, explicitly expect personal information unrelated to the threat to be removed before submission. A pre-share detection pass operationalizes that expectation: IOCs like attacker IPs and malicious URLs are precisely what you keep, while employee names, victim emails, and internal account identifiers are masked. Using entities filters, you can even codify per-destination policies — what may go in a TLP:GREEN advisory differs from what your commercial intel vendor may receive under contract.

Because the API also powers LLM guardrails, teams adopting AI-assisted triage get a third win: alert text and case notes are scrubbed before they reach a copilot model, so the SOC's productivity tooling never becomes its newest leak vector. For a broader architecture view, our DLP guide shows where detection sits relative to blocking controls.

Cybersecurity PII Detection FAQ

What SOC leads, IR managers, and detection engineers ask before integrating

Can we use this mid-incident on data we believe was stolen?

Yes — scoping a breach is processing you are already obligated to do, and doing it with an automated classifier is faster and more defensible than manual review. Treat the API as you would any IR subprocessor: it appears in your data-flow documentation, and scan results you store should be counts and offsets, not raw matched values. For investigations where data cannot leave your environment at all, the same engine is available as an on-premise deployment; ask via the contact page.

How is this different from the DLP and secret scanners we already run?

Most DLP engines and secret scanners are pattern- and entropy-based: strong on canonical formats, weak on context. Transformer NER reads meaning, so it distinguishes a routing number from an order ID, catches a password sitting in prose, and recognizes names and addresses in 60+ languages where regex has nothing to match. It also returns structured offsets and confidences you can build workflows on. The comparison is covered in depth in NER vs regex vs rules — most teams run detection alongside their existing DLP as the classification brain, not as a replacement for enforcement points.

Will masking logs break correlation and investigations?

Not if you use mask_mode: "hash" for identifier fields you correlate on. Each value maps to a consistent token, so "same user across 400 events" still resolves in the SIEM — analysts pivot on the hash exactly as they would on the email. For the subset of investigations that require true identity, re-identification happens through an access-controlled lookup in the system authorized to hold the raw value, which is precisely the audit boundary most SOC access policies want anyway.

What throughput can we expect for a large dump triage?

Each request carries up to 50,000 characters and typically returns in under 200ms, and requests parallelize freely. A triage job running 20 concurrent workers moves on the order of gigabytes of text per hour — enough to fully classify most exfiltrated datasets well inside the GDPR 72-hour window, with entity aggregation happening in your own code as results stream back. Start with a single worker against the demo to calibrate, then scale workers to your deadline.

Which credential and secret types are detected?

The catalog includes PASSWORD, API_KEY, AUTH_TOKEN, AWS_CREDENTIALS, AZURE_AUTH_TOKEN, GCP_CREDENTIALS, SSH_KEY, PRIVATE_KEY, and DATABASE_CONNECTION_STRING, alongside the 140+ personal-data types. You can scan for secrets only by passing just those types in entities, or run the full catalog and split the results downstream — the full list lives on the entities page.

Can we sanitize reports automatically before ISAC or vendor sharing?

Yes — that is one of the most common integrations. A pre-publish hook scans the draft, masks person names, victim emails, and internal identifiers, and leaves IOCs intact; the custom_instruction field lets you state exclusions in plain language, such as "do not mask IP addresses or URLs listed as indicators of compromise." The masked copy goes to the sharing community; the original stays in your case management system with normal access controls.

Related Resources

Deep dives on the pipelines, identifiers, and regulations security teams deal with daily

Know What Was in the Data — Before the Regulator Asks

Paste a real log excerpt or a mock breach record into the demo and watch it come back classified in milliseconds. Then wire the same call into your playbooks.