gdpr data map generator

The problem

Data maps built from high-level architecture diagrams often miss real-world PII leaks in logging, message queues, and third-party SDKs. Relying on "how it should work" rather than how the code actually executes creates significant GDPR Article 30 compliance gaps.

What it does

• Traces personal data flows through database models, API endpoints, and third-party SDK integrations directly from source code.
• Identifies indirect PII leaks in structured logging, Redis/Kafka payloads, and reflection-based serializers.
• Generates Article 30 Records of Processing Activities (ROPA) documents using distinct field sets for controller vs. processor roles.
• Detects the "dual-role pattern" where a processor might be acting as a controller for analytics or ML training.
• Flags auto-instrumenting SDKs (Sentry, Datadog) and tag managers as high-risk data recipients.

Why this beats prompting it yourself

Generic prompts often hallucinate compliance or miss non-obvious data paths like feature-flagged code or cross-tenant analytics jobs. This skill enforces strict "Iron Rules" for data discovery, ensuring unconfirmed flows are highlighted in a mandatory dashboard rather than buried in a table.

Use cases

• Generating a ROPA document for an upcoming GDPR audit or DPA request.
• Auditing a microservices architecture to see where PII leaves service boundaries.
• Identifying third-party SDKs that are capturing request/response bodies by default.
• Verifying if a B2B vendor is accidentally processing tenant data for their own ML models.

Known limitations

This is a point-in-time trace of provided code, not a live monitoring tool. It cannot see tag manager configurations (GTM/Segment) managed in external UIs or verify downstream sub-processor actions.