Imported from jeremylongshore/tons-of-skills-marketplace (plugins/security/data-privacy-scanner/skills/scanning-for-data-privacy-issues/SKILL.md). Install upstream with npx skills add jeremylongshore/tons-of-skills-marketplace --skill scanning-for-data-privacy-issues. Copyright stays with the author (MIT).

Scanning for Data Privacy Issues

Overview

Scan codebases for data privacy violations, PII exposure, and non-compliance with privacy regulations including GDPR, CCPA, HIPAA, and LGPD. This skill detects hardcoded personal data, unprotected PII in logs and databases, missing consent mechanisms, improper data retention, and insufficient anonymization or pseudonymization of sensitive fields.

Prerequisites

Access to the target codebase and configuration files in ${CLAUDE_SKILL_DIR}/
Knowledge of the data types processed by the application (PII categories, PHI, financial data)
Standard shell utilities and Grep/Glob available for pattern matching
Reference: ${CLAUDE_SKILL_DIR}/references/README.md for scanner API documentation, GDPR compliance guide, and sensitive data pattern definitions

Instructions

Define the PII categories relevant to the application: email addresses, phone numbers, Social Security numbers, credit card numbers, IP addresses, geolocation data, biometric data, health records, and any domain-specific identifiers.
Scan source code for hardcoded PII using regex patterns -- detect email patterns ([a-zA-Z0-9+_.-]+@[a-zA-Z0-9.-]+), SSN patterns (\d{3}-\d{2}-\d{4}), credit card patterns (Luhn-valid 13-19 digit sequences), and phone number patterns. Flag each as CWE-312 (Cleartext Storage of Sensitive Information).
Examine logging statements (console.log, logger.info, logging.debug, Log.d) for PII field references -- flag any logging of user email, password, token, SSN, or credit card fields as CWE-532 (Insertion of Sensitive Information into Log File), severity high.
Analyze database schemas and ORM models for PII fields stored without encryption -- check for columns named email, phone, ssn, date_of_birth, address that lack encryption-at-rest annotations or transparent data encryption.
Review data transmission: verify PII is transmitted over TLS only, check for PII in URL query parameters (visible in server logs and browser history), and flag unencrypted API responses containing sensitive fields.
Assess consent management: search for cookie consent implementations, privacy policy links, data processing agreements, and opt-in/opt-out mechanisms. Flag applications collecting PII without documented consent flows as a GDPR Article 6/7 gap.
Check data retention: look for automated data deletion jobs, retention policy configurations, and user data export/deletion endpoints (GDPR Article 17 Right to Erasure). Flag absence of retention controls.
Evaluate anonymization and pseudonymization: verify that analytics, reporting, and non-production environments use anonymized or pseudonymized data rather than production PII. Flag test fixtures containing real PII.
Scan configuration files and environment variables for PII used as defaults, seeds, or test data -- flag hardcoded test emails or phone numbers that match real-world patterns.
Classify findings by severity and regulation, produce a data flow diagram identifying where PII enters, is stored, is processed, and exits the system.

Output

PII inventory: Table of all detected PII types, their locations (file:line), storage mechanism, and encryption status
Findings report: Each finding includes severity, regulation reference (GDPR Article, CCPA Section, HIPAA Rule), CWE reference (CWE-312, CWE-532, CWE-359), affected file, and remediation steps
Data flow analysis: Summary of PII entry points (forms, APIs, imports), processing locations, storage mechanisms, and exit points (exports, API responses, logs)
Compliance gap matrix: GDPR/CCPA/HIPAA requirement mapped to implementation status (Compliant, Gap, Not Applicable)
Remediation plan: Prioritized actions including field encryption, log sanitization, consent implementation, and retention policy setup

Error Handling

Error	Cause	Solution
High false positive rate on PII patterns	Regex patterns matching non-PII strings (e.g., UUIDs matching SSN patterns)	Refine patterns with context-aware checks; filter results by file type and surrounding code context
Encrypted PII not detected	Application uses transparent encryption that masks PII at the code level	Check encryption configuration separately; mark encrypted fields as "protected" in the inventory
Third-party data processors not visible	PII sent to external services via API calls	Grep for HTTP client calls and map destination URLs; flag external services requiring Data Processing Agreements
Large codebase scan timeout	Millions of lines to scan	Scope to high-risk directories first (`src/`, `api/`, `config/`); exclude `node_modules/`, `vendor/`, and build artifacts
Test data flagged as PII exposure	Test fixtures use realistic but fake data	Verify test data is synthetic; recommend using obviously fake data (e.g., `test@example.com`) to avoid false positives

Examples

PII in Application Logs

Grep ${CLAUDE_SKILL_DIR}/src/ for logging statements that reference user fields: logger.info.*email, console.log.*password, Log.d.*phone. Flag each match as CWE-532, severity high. Recommend implementing a log sanitizer middleware that redacts PII fields before writing to log output.

GDPR Data Subject Rights

Scan ${CLAUDE_SKILL_DIR}/src/api/ for endpoints supporting data subject rights: user data export (GET /api/users/:id/export), data deletion (DELETE /api/users/:id), and consent withdrawal. Flag missing endpoints as GDPR Article 15/17/21 gaps, severity high. Recommend implementing a data subject request handler.

Credit Card Data in Codebase

Search for credit card number patterns across all source files using \b[0-9]{13,19}\b with Luhn validation context. Check that any payment processing code uses tokenization rather than storing raw card numbers. Flag PAN storage as PCI DSS Requirement 3 violation and CWE-312, severity critical.

scanning-for-data-privacy-issues

About