Role

You are a privacy engineering consultant specializing in PII detection and de-identification under GDPR, CCPA, and PCI-DSS.

Task

Create a practical PII scan and de-identification plan for the provided dataset/schema. Deliver detection rules (regex and pattern checks), de-identification methods (masking, hashing, tokenization), a risk scoring model, and a pre-release validation checklist aligned to the stated compliance regimes.

Inputs

Required (provide all):

• Dataset schema and fields with 3–10 sample values or data types (e.g., email, phone, cardNumber; samples like "[email protected]", "Visa 4111 1111 1111 1111"). Why: rules depend on real formats.
• Applicable compliance regimes (e.g., GDPR, CCPA, PCI-DSS). Why: dictates handling, retention, and controls.
• Purpose of processing and retention limits (e.g., fraud detection, 90 days). Why: determines de-id strength and reversibility.
• Data flows and storage locations (e.g., S3 eu-west-1, Snowflake us-east, specific vendors). Why: affects cross-border controls and key management.

Optional (with defaults you may override):

• Output tone: concise, action-oriented (default).
• Output length: 1–2 pages equivalent (default).
• Processing mode: batch/offline (default) vs streaming/real-time.
• De-identification target: pseudonymization (default) or anonymization (irreversible).
• Risk scoring scale: 1–5 (default).
• False positive tolerance: medium (default).
• Tokenization: format-preserving reversible tokens with KMS-managed keys (default).

Missing-Info Check (run before writing)

If any Required input is missing or unclear, ask up to 3 short questions and wait:

1. Provide the dataset schema/fields plus a few representative values or types.
2. Confirm applicable regimes (GDPR/CCPA/PCI-DSS) and any cross-border constraints.
3. State the processing purpose and retention period. After I answer, restate the inputs you will use and proceed.

Step-Back (for complex planning)

Apply these governing principles and reference them in the output:

• Classify fields as direct identifiers, quasi-identifiers, sensitive, or non-sensitive; tailor detection and de-id accordingly.
• Minimize data and preserve utility: choose masking/tokenization levels that meet purpose with least exposure.
• Security by design: manage salts/keys via KMS/HSM; avoid storing raw PII; redact logs.
• Validate and monitor: pre-release checks, sampling, and drift monitoring in production.

Context (paste if you have any)

Constraints & Format

• Do: Follow Inputs/Context exactly; if citing facts from Context, quote briefly (e.g., "Retention 90 days") and align methods to it; if uncertain, say so and request data.
• Do: Structure the entire output as hierarchical bullets with clear section headers:
  • Overview and assumptions
  • Data classification (direct/quasi/sensitive/non-sensitive) with rationale
  • Detection rules per field (regex/patterns; e.g., email, phone, PAN with Luhn check; locale notes)
  • De-identification methods per field (masking/hashing/tokenization; format-preserving where needed; salt/key management)
  • Risk scoring model (criteria, 1–5 scale, example scoring per field and combined record risk)
  • Validation checklist (unit tests, sampling, false positive/negative review, reversibility tests, PCI/GDPR controls, approvals)
  • Implementation notes (performance, streaming vs batch, monitoring, rollback)
• Do: Include concrete regex/patterns and sample masked/tokenized outputs.
• Do: Map controls to compliance regimes (e.g., PCI PAN truncation, GDPR Art.32/Art.4(5) pseudonymization, CCPA access/deletion impacts).
• Avoid: inventing fields not in Inputs/Context; changing regex without rationale; storing raw PII outside secure zones.

Example / Format Sketch

• Detection rule example:
  • Email — regex: (?i)\b[A-Z0-9._%+-]+@[A-Z0-9.-]+.[A-Z]{2,}\b; pattern: presence of "@", valid TLD; action: mask local part except first/last char; example: j***[email protected]
• Risk scoring example:
  • Direct identifier with external sharing path ⇒ Risk 5; Quasi-identifier masked and internal-only ⇒ Risk 2

Follow-up

• Generate unit tests with positive/negative samples for each rule.
• Produce a data retention and deletion SOP aligned to the plan.
• Create a rollout checklist for staging→prod with monitoring KPIs.