PII Detection for SaaS Platforms

The Processor's Dilemma: You Host Data You Never Asked For

Every SaaS product with a text box is a PII repository, whether its founders intended that or not. A project-management tool fills up with customer names pasted into task descriptions; a CRM's notes fields accumulate health details and dates of birth; an internal wiki hosts an exported spreadsheet of employee salaries; a feedback widget receives a card number from a confused end user. Your terms of service may say "don't put sensitive data here" — your database says people do it anyway.

As a processor, you carry contractual duties for that data the moment it lands: your Data Processing Agreements promise technical measures, breach notification within fixed windows, assistance with data-subject requests, and controlled use of sub-processors. As a product, you face the same problem from the feature side: your customers increasingly ask what you offer to help them find and govern the PII their own users leave in your platform. Enterprise security questionnaires now ask both questions explicitly.

The PII Detection API answers both with one integration. Point it at any text your platform stores or emits and it returns every detected entity with type, character offsets and a confidence score — plus an optional masked rendering. Use it internally to keep PII out of your logs, analytics and LLM features; expose it in-product to give customers content-scanning, warnings and redaction as first-class functionality. The API overview covers the full surface.

Two hats, one API. SaaS companies integrate PII detection in two directions: inward (scanning their own telemetry, logs and support tools so customer PII doesn't leak into internal systems) and outward (shipping detection as a customer-facing feature). The endpoint, contract and entity taxonomy are identical — only the caller changes.

DPAs, Sub-processors and the Obligations You Signed

The compliance duties every B2B SaaS company inherits with its first enterprise contract

GDPR Article 28 & Your DPA

Article 28 requires processors to implement appropriate technical and organizational measures, process only on documented instructions, and assist controllers with security and data-subject rights. Your DPA translates that into commitments auditors will test. Automated PII detection is a demonstrable technical measure: it shows you can locate personal data in unstructured customer content instead of merely asserting that you protect it. See the GDPR PII detection guide.

Sub-processor Management

Every vendor that touches customer content — your cloud host, your logging platform, your LLM provider, your support desk — is a sub-processor you must disclose and bind by equivalent terms. The practical control is minimization: scrub PII from data before it flows to a vendor, and that vendor may fall out of the personal-data path entirely. Detection at the egress point is how you enforce (and evidence) that boundary.

Breach Notification Windows

GDPR gives processors "without undue delay" to notify controllers; most enterprise DPAs tighten it to 24–72 hours. When an incident exposes a store of customer content, the first question is what personal data it held. Batch-scanning the affected corpus produces entity counts per tenant within hours — the difference between a precise notification and telling every customer their data "may have been affected".

GDPR, ISO 27001 & Security Reviews

Trust-services criteria for confidentiality and privacy expect controls over sensitive data identification. Enterprise security questionnaires ask "how do you prevent customer PII from reaching logs, analytics or model training?" A detection layer wired into those paths converts a policy answer into a technical one — with scan metrics as audit evidence. The PII Detection API itself is GDPR-native audited, simplifying your own vendor review of us.

The AI Feature Problem

Nearly every SaaS roadmap now includes LLM features — summarization, autocomplete, chat over customer data. Each one creates a new personal-data flow to a model provider that your DPA and sub-processor list must cover, and each prompt that includes raw customer content is a potential disclosure. Legal review of these features stalls on exactly one question: what data leaves, and to whom?

Detection-based guardrails unblock the roadmap. Scan prompt payloads before they leave your boundary, mask identity entities, and let the LLM work on scrubbed text; re-insert identifiers afterward if the UX requires it, using the offsets the API returned. The pattern — covered in depth in our LLM guardrails guide and RAG pipeline guide — turns "we hope the model provider is careful" into "the model provider never receives personal data".

Where PII Accumulates in a SaaS Platform

Content surfaces and telemetry paths worth scanning — with the entities that show up in each

PERSON_NAME

Docs, tasks, comments, CRM notes

EMAIL_ADDRESS

Mentions, imports, form fills

PHONE_NUMBER

Contact records, signatures

CREDIT_CARD_NUMBER

Pasted into tickets & fields

SSN / NATIONAL_ID

Uploaded spreadsheets, HR docs

MEDICAL_DATA

Unexpected PHI in content

API_KEY / AUTH_TOKEN

Secrets pasted into docs & chat

PASSWORD / SSH_KEY

Credentials in support threads

DATABASE_CONNECTION_STRING

Config pasted for debugging

AWS / GCP / AZURE CREDENTIALS

Cloud keys in shared content

IP_ADDRESS / DEVICE_ID

Telemetry, audit logs, sessions

ADDRESS

Imported contact & order data

Secrets Are PII's Twin Problem

SaaS content attracts credentials the way it attracts personal data — users paste API keys into wikis, connection strings into tickets, and private keys into chat to "just get it working". A leaked customer credential can be more immediately damaging than leaked PII, and it is your platform hosting it.

The API's taxonomy treats credentials as first-class entities: API_KEY, AUTH_TOKEN, PASSWORD, SSH_KEY, PRIVATE_KEY, DATABASE_CONNECTION_STRING and cloud-provider credentials for AWS, Azure and GCP. One scan pass over content therefore powers two features — PII governance and secret hygiene — and one internal pipeline keeps both out of your logs and analytics. Our log scanning guide shows the internal wiring; the entities page lists the full 150+ types.

Detection is context-aware across 60+ languages, so a German customer's content is governed identically to an English customer's — a requirement, not a nicety, once you sell into the EU.

From DPA Clause to Technical Control

How detection maps each contractual promise to something your engineers can actually build and prove

DPA / Compliance Obligation	Where It Bites in a SaaS Stack	Detection-Based Control	Evidence Produced
Appropriate technical measures (GDPR Art. 28/32)	Unstructured customer content in databases and file stores	Scheduled tenant-content scans; PII inventory per workspace	Scan reports with entity counts and `processing_time_ms` logs
Assistance with data-subject requests	A controller asks: "find this person's data in our workspace"	Targeted batch scan of the tenant's content; offsets locate each match	Per-request match report delivered to the controller
Sub-processor data minimization	Logs, analytics, LLM providers, helpdesk vendors	Scrub at egress: mask entities before payloads leave your boundary	Egress scan metrics; vendor payload samples that contain placeholders
Breach notification (24–72h contractual)	Exposed bucket or database with mixed tenant content	Emergency batch scan of the affected corpus, grouped by tenant	Entity counts per tenant to scope each controller's notice
Acceptable-use limits (e.g. "no PHI without BAA")	Customers paste medical or card data into a product not certified for it	Detect `MEDICAL_DATA` / `CREDIT_CARD_NUMBER`; warn tenant admin	Policy-violation alerts and remediation trail
Data retention & deletion promises	Old exports, backups, analytics copies of departed customers	Scan-then-purge jobs verify no residual identifiers survive deletion	Post-deletion verification scans (zero-hit reports)

"An unauthorized party may have accessed customer data" — sent to all 3,000 tenants

After

41 affected tenants notified with exact entity counts; 2,959 tenants confirmed unaffected

Endpoint to embed — no ML team needed

<200ms

Typical scan latency per call

150+

Entity types incl. credentials

60+

Languages for global tenants

Building PII Scanning Into Your Own Product

Buying detection as an API beats building it for the same reason your customers buy your product instead of building it: the hard part is not the first demo, it's the long tail. A credible in-house PII engine needs multilingual NER models, entity taxonomies, confidence calibration, evaluation datasets, retraining pipelines and an on-call rotation when precision drifts. That is a product company's roadmap-quarters spent off-roadmap.

Embedding the API collapses the project to integration work. The architecture is straightforward: your backend proxies scan requests (your API key never reaches the browser), per-tenant settings map to request parameters — entity lists, threshold, custom_instruction — and results persist in your own schema for reporting. Whether you expose raw detections, aggregate dashboards, redaction buttons or automated policies is product design, not machine learning. Metering is simple too: the response's entities_detected and your call counts give you everything needed to bill scanning as an add-on SKU if you choose to.

Commercially, detection features punch above their engineering weight: they unblock enterprise deals stuck on security review, justify premium tiers, and differentiate against competitors whose answer to "how do we find PII in your product?" is a shrug. Start against the live demo, then review volume pricing and the API documentation for production planning.

Per-tenant configuration maps 1:1 to the request. Store each tenant's scanning preferences — which entities matter, how strict the threshold, any plain-English exceptions — and pass them straight through as entities, threshold and custom_instruction. No per-tenant models, no retraining: configuration is just JSON.

Integration Examples for Product Teams

From a first scan to a multi-tenant feature — the same canonical contract throughout

First Scan with cURL

A representative SaaS payload: a support ticket where a user pasted both personal data and a database credential. One request returns typed detections for both categories — the foundation for warnings, redaction and admin reporting alike.

Note that no entities filter is passed here, so the full taxonomy applies — the right default for exploratory scanning of arbitrary customer content. Filters come later, per tenant, when you know what each customer cares about.

cURL — Customer Content Scan

# Scan a ticket comment for PII and pasted secrets (all entity types)
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": "Import fails for our HR file. Sample row: Dana Whitfield, SSN 419-70-3341, [email protected]. Our connection string is postgres://admin:[email protected]:5432/hr if you want to reproduce.",
    "mask_mode": "replace",
    "threshold": 0.5
  }'

Multi-Tenant Workspace Scanner in Python

The engine behind a "scan workspace" feature: iterate a tenant's documents, apply that tenant's stored preferences, and aggregate entity counts into a report row per document. One tenant per request preserves isolation; per-tenant settings ride along as plain parameters.

The aggregate output — types, counts, document references — is exactly the shape an admin dashboard, a CSV export or a compliance PDF needs.

Python — Tenant Scan Engine

import requests

def scan_document(tenant, doc):
    # tenant.settings: {"entities": [...], "threshold": 0.6, "instruction": "..."}
    resp = requests.post(
        "https://piidetectionapi.com/api/moderate.php",
        json={
            "api_key": "YOUR_API_KEY",
            "api_type": "pii_detection",
            "text": doc.text[:50000],
            "entities": tenant.settings.get("entities"),      # None = all types
            "threshold": tenant.settings.get("threshold", 0.5),
            "custom_instruction": tenant.settings.get("instruction", ""),
        },
        timeout=30,
    )
    data = resp.json()

    counts = {}
    for e in data["detected_entities"]:
        counts[e["type"]] = counts.get(e["type"], 0) + 1

    return {
        "doc_id": doc.id,
        "tenant_id": tenant.id,          # never mix tenants in one call
        "entity_counts": counts,
        "total": data["entities_detected"],
    }

def scan_workspace(tenant):
    report = [scan_document(tenant, d) for d in tenant.documents()]
    dashboard.publish(tenant.id, report)   # feeds the admin PII report

Paste-Time Warning Endpoint in Node.js

The backend for a save-time interception UX. The client posts draft content; the server scans it and returns the masked suggestion plus which entity types triggered. Your API key stays server-side, and the frontend simply renders the "mask it?" dialog when flagged is true.

The same endpoint doubles as an internal egress guard: call it on any payload bound for a logging vendor or LLM provider and forward masked instead of the original.

Node.js — Scan-on-Save API

// POST /api/content/scan — backend proxy for in-product scanning
app.post("/api/content/scan", async (req, res) => {
  const { tenantId, draftText } = req.body;
  const prefs = await settings.forTenant(tenantId);

  const r = 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,   // never exposed to the browser
      api_type: "pii_detection",
      text: draftText,
      entities: prefs.entities ?? ["PERSON_NAME", "EMAIL_ADDRESS",
        "PHONE_NUMBER", "SSN", "CREDIT_CARD_NUMBER",
        "API_KEY", "PASSWORD", "DATABASE_CONNECTION_STRING"],
      mask_mode: "replace",
      threshold: prefs.threshold ?? 0.5,
    }),
  });
  const data = await r.json();

  res.json({
    flagged: data.entities_detected > 0,
    types: [...new Set(data.detected_entities.map(e => e.type))],
    masked: data.anonymized_text,          // offered as the safe version
    spans: data.detected_entities.map(({ type, start, end }) => ({ type, start, end })),
  });
});

SaaS Platform PII Detection FAQ

Common questions from product, engineering and compliance teams at software companies

If we embed your API, does PII Detection API become our sub-processor?

If you send customer personal data to the cloud endpoint, yes — treat us like any other sub-processor: execute a DPA, list us in your disclosures, and rely on our security documentation for diligence. Submitted text is processed for detection and not used for model training. Teams that prefer to avoid the sub-processor question entirely deploy the detection engine on-premise inside their own boundary; ask via the contact page.

Can we white-label detection results inside our own product?

Yes. The API returns structured JSON — entity types, matched text, offsets, confidence — and your product renders it however fits: highlights in a document view, an admin report, a redaction button, an automated policy. Your customers interact with your UX; the API stays invisible infrastructure, like your email or payments provider.

How do we handle multi-tenant isolation when calling the API?

Never combine content from different tenants in one request — one tenant per call, with that tenant's own entity list, threshold and custom_instruction. Calls are stateless, so isolation is preserved by construction on the API side; your job is to keep the batching discipline and record tenant IDs in your scan logs for auditability.

Will scanning every save add noticeable latency to our product?

Typical calls return in under 200ms, which fits inside most save paths; the response even reports its own processing_time_ms for your monitoring. Where the UX is latency-critical, scan asynchronously after the write and reconcile — flag or mask seconds later — or scan only on specific triggers such as sharing a document externally or exporting data.

Can detection catch API keys and passwords, not just classic PII?

Yes — credentials are part of the standard taxonomy: API_KEY, AUTH_TOKEN, PASSWORD, SSH_KEY, PRIVATE_KEY, DATABASE_CONNECTION_STRING, and AWS/Azure/GCP credential formats. Many SaaS teams ship "secret detection" and "PII detection" as one feature from the same scan pass, which is also how their own internal log-hygiene pipeline runs.

How does this interact with our LLM features and model providers?

Scan every prompt payload before it leaves your boundary and send the masked rendering to the model. Because detections include offsets, you can map placeholders back to real values in the model's response when the UX requires it. The model provider then processes no personal data — which dramatically simplifies your sub-processor analysis and your enterprise customers' security reviews. See the LLM guardrails guide for full patterns.

What does volume pricing look like for product-embedded scanning?

Pricing is per-request with volume tiers that fit both internal pipelines and customer-facing features; batching related content into single 50,000-character calls stretches each request further. Current tiers are on the pricing page, and enterprise agreements with committed volume are available for platforms metering scans to their own customers.

The Processor's Dilemma: You Host Data You Never Asked For

DPAs, Sub-processors and the Obligations You Signed

GDPR Article 28 & Your DPA

Sub-processor Management

Breach Notification Windows

GDPR, ISO 27001 & Security Reviews

The AI Feature Problem

Where PII Accumulates in a SaaS Platform

PERSON_NAME

EMAIL_ADDRESS

PHONE_NUMBER

CREDIT_CARD_NUMBER

SSN / NATIONAL_ID

MEDICAL_DATA

API_KEY / AUTH_TOKEN

PASSWORD / SSH_KEY

DATABASE_CONNECTION_STRING

AWS / GCP / AZURE CREDENTIALS

IP_ADDRESS / DEVICE_ID

ADDRESS

Secrets Are PII's Twin Problem

From DPA Clause to Technical Control

SaaS Platform Use Cases

In-Product PII Scanning for Customers

Paste-Time Warnings & Redaction UX

Telemetry & Log Hygiene

LLM Feature Guardrails

Breach Triage by Tenant

Building PII Scanning Into Your Own Product

Integration Examples for Product Teams

First Scan with cURL

cURL — Customer Content Scan

Multi-Tenant Workspace Scanner in Python

Python — Tenant Scan Engine

Paste-Time Warning Endpoint in Node.js

Node.js — Scan-on-Save API

SaaS Platform PII Detection FAQ

If we embed your API, does PII Detection API become our sub-processor?

Can we white-label detection results inside our own product?

How do we handle multi-tenant isolation when calling the API?

Will scanning every save add noticeable latency to our product?

Can detection catch API keys and passwords, not just classic PII?

How does this interact with our LLM features and model providers?

What does volume pricing look like for product-embedded scanning?

Related Resources

Ready to Ship PII Detection — In Your Stack and In Your Product?